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

Code:

_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..

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?

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.

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.

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.

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.

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.