Protracker player with support for external sound fx

[clebin]

That's incredibly helpful - thanks phx. I'll give it a go and report back...

[clebin]

I'm Using SAS\C at the moment (next time I'll cross-compile...)

ptplayer.asm didn't want to compile with SAS\C's 'asm' assembler - I got loads of errors: "data generation must occur in reloc section"

I compiled it using vasm instead:

vasmm68k_mot -Fhunk ptplayer.asm

I included that in the makefile and everything compiles and runs ok except for the "mt_Enable = 1" line, which gives me this error:

_mt_Enable symbol - Near reference to data item not in near data section

  First Reference in Unit main.c at offset 00000010 in file ‘o/main.o’
  To Unit put-layer at offset 00000010 in file ‘o/ptplayer.o’

Am I going about this the right way and is it something I can fix? Sorry if this is a noob question..

[alkis]

Don't have ptplayer.h but I'd assume that mt_Enable is declared there.

Try adding __far keyword right after type and before the name (mt_Enable)

[clebin]

Originally Posted by alkis

Don't have ptplayer.h but I'd assume that mt_Enable is declared there.

Try adding __far keyword right after type and before the name (mt_Enable)

Crikey, never heard of near and far pointers before - something else to read up on. I modified the 'ptplayer.h' that comes with PTPlayer to add the __far keyword and the module plays fine:

extern __far UBYTE mt_Enable;

Thanks for the help!

[alkis]

Originally Posted by clebin

Crikey, never heard of near and far pointers before - something else to read up on. I modified the 'ptplayer.h' that comes with PTPlayer to add the __far keyword and the module plays fine:

extern __far UBYTE mt_Enable;

Thanks for the help!

You are welcome. I am glad it worked!

[phx]

Originally Posted by clebin

_mt_Enable symbol - Near reference to data item not in near data section

SAS/C defaults to small data? Then you should also use small data for ptplayer.asm. Assemble it with "SDATA" defined:

vasmm68k_mot -Fhunk -DSDATA -o ptplayer.o ptplayer.asm

I'm using small data in all of my game projects.

[roondar]

This is widely off-topic (apologies for that!) but could someone point me in the right direction to actually get this whole small data/large data (plus the whole near/far) thing explained in a clear manner?

Because I'm still not sure I understand it or how to use it

[phx]

Small data means that you are accessing all data in a section via a base register (usually A4). On program startup the base register is loaded with the section's base address + 32766, which enables you to read and write a region of up to 64K.

The advantage is shorter code, less relocations in the executable and faster data access (hmm, perhaps not on 68040).

You can always make your own kind of small data, by defining some memory region which you access via any base register. For example with the BASEREG directive or just an RS-structure. But here I am talking about the standard method, how all Amiga compilers are doing it and which makes sense to adapt in your assembler code as well.

Small data also means in most cases that you will use a Data-Bss section for it, i.e. a data section which has a greater size defined in the executables's header than it actually has. The extra size is allocated as uninitialized (Kick 1.x) or cleared (V36+) memory, doesn't occupy any space in the executable and is used for the BSS part. For Kickstart 1.x you should better clear this area during startup.

The linker supports small data in several ways. It will automatically merge small data sections and makes sure that all initialized small data sections come first and then all uninitialized ones (allowing Data-Bss in the output). Small data sections are either detected by the appropriate relocations or references to it, or by name. Sections named as __MERGED will be automatically merged as Data-Bss sections.

The linker also defines useful linker-symbols which help you to set up small data in the startup code. For example _LinkerDB always points to the small data section's base + 32766. Small data relocs are resolved with this value in mind. With __BSSBAS and __BSSLEN you can clear the unitialized part of that section.

The C-attribute __far can be used to enforce absolute 32-bit access to data, even when your program was compiled in small data mode. Also worth mentioning is the __saveds attribute in this context, because it sets up the base register for the function with it (and saves/restores the previous contents). Useful for interrupt handlers, callback-functions, etc., which are called from a not-small-data-aware context.

In assembler you have even more options and your code can be small and large data at the same time. Put all your small objects into the small data section and all large objects into other sections. Then these 64K will always be sufficient.

I'm using small data in all my assembler projects and most C projects.

[roondar]

Thanks for the explanation!

I'll read it carefully a few more times. Seems it's a clever way to get the advantages of PC relative code without needing to actually code 'PC relative' (though register relative is kind of the same thing). Moving the offset so far ahead also allows for 64K, which is pretty neat.

I might consider it for new projects, just to see how it works. In my experience trying stuff is always the best way to get to grips with it. As is, I try to write almost all code as PC relative as I can make it, so it shouldn't be that much of a change.

[DanScott]

Very similar to how I used to do it in the 1990's with my games... A6 would always point to $dff000 and A5 would point to my variables.. so every var was accessed off A5

I like that +32766 idea though to give a full 64k range

[ross]

You can also see some compiler that use Hunk reloc for a real full 64k (32768*2 ).

Like:

	SECTION code,code
	lea	DT,A4
	lea	-$8000(a4),a0	; buffer


	SECTION small_data,data
buffer	ds.b 32768
DT	ds.b 32768

[clebin]

Great explanation. - thanks again phx. I've added this page to my reading list to digest it properly.

[arti]

Possible to add xm support?

Or is there xm player like this ?

[phx]

Implementing XM-support on the Amiga is quite CPU-intensive. As ptplayer is primarily intended for games this makes no sense at all (unless you're doing a text-adventure ).

[arti]

I mean for games for stronger Amigas 060+.

[phx]

Major enhancements of the player, like XM, are driven by my personal demand. And I have no plans to make games for 060+.

[daxb]

XM and any other formats that are multi channel is at the end "only" mixed by CPU to a stereo stream. So I think a XM player would be much different to phx's player (uses the default Amiga 4 hardware channels as far as I know. no mixing). How difficult it is to mix the music stream (xm for example) with sound fx samples I don't know. At least there is no need for the technique that phx used to "mix" music with sound fx samples. So, my guess is that for such a 060+ multichannel player you need some else if exists.

[roondar]

Originally Posted by daxb

XM and any other formats that are multi channel is at the end "only" mixed by CPU to a stereo stream. So I think a XM player would be much different to phx's player (uses the default Amiga 4 hardware channels as far as I know. no mixing). How difficult it is to mix the music stream (xm for example) with sound fx samples I don't know. At least there is no need for the technique that phx used to "mix" music with sound fx samples. So, my guess is that for such a 060+ multichannel player you need some else if exists.

Seems one does indeed exist (XM player that is): http://aminet.net/package/dev/asm/xmplay-lib

However, there's just something about 4 channel Protracker modules... I've always found them quite nice (assuming they're properly made). Some of them sound really good, so maybe XM playback is not quite needed.

Anyway, PHX's player is pretty awesome by itself. I can highly recommend using it: I found it easy to integrate in my code and it works really well. Not found a module it doesn't play yet.

[arti]

That thing is f*cking slow even on WinUAE. I don't know how author used this.

I have found ten times faster C player, just need it a bit more optimised for my needs.

[saimon69]

One thing i miss on mod that i have in xm is indipendent timeline volume; so maybe a cut down version of the xm player for four-channel only XM to play directly in paula might give more control?