tracker: avoid including tracker functions when not used

[jorgegv]

• Tracker functions have been defined as banked code under banked_code/128, that is, code that is compiled only in 128K mode. They can't be compiled in 48K mode.

• They have also been configured for conditional compilation, and the C code is only compiled if something tracker-related is used in the game

• But the global index of banked functions in banked_code/128/00main.asm includes definitions for all tracker functions, and those defs are not conditionally compiled.

• So when using a game in 128K mode that does not use any tracker functions, the build fails because the 00main.asm references are undefined: in the ASM file the tracker functions are expected to exist, but in the C code they are NOT compiled (they are not used, so conditional compilation skips them)

• We need to make the tracker functions fully conditional, including the linker references in the ASM file

• So far, we are assuming that if you are using 128K mode, one of the reasons is that you are using tracker music, so this does not harm a lot.

• Update: this will get solved when implementing banked_code: automatic generation of banked_code function definitions #104

[jorgegv]

#104 was done, so marked as solved

[TheStruggleForAntiSpaghetti]

It should not be necessary for Tracker tunes as in AY tunes to be 128 only as there's also AY add-on interfaces that provides AY music capability.

[jorgegv]

Yes, my comment is no longer relevant since I made it conditionally compilable anyway (the bug was fixed).

As of now, though, TRACKER feature depends on ZX_TARGET_128 feature (forced), and fails if you try to compile in 48 mode. Maybe I can revisit y assumptions and not make it dependent on 128 mode? Are those AY add-on interfaces mapped into the same ports as in the 128K?

Any references?

[TheStruggleForAntiSpaghetti]

I think the choice have to be separate from being 128k or not. Makes also sense as it's with these AY interfaces around, the assumption is no longer valid for an AY chip to be available that it has to be a 128k memory model.

One example of such an interface it the ZX AY (which I have): https://www.bytedelight.com/?product=zx-ay-external-stereo-audio-interface-for-all-zx-spectrum-models

Theoretically it should be possible to auto-detect presence of an AY/YM(!) chip by writing a specific value to a certain register and read it back (theoretically because I didn't test this myself and didn't encounter an example yet).

I actually just also saw a post of Allan Turvey where he is playing around with ideas of including AY tune and playback functionality according which I'm also giving feedback on.

I think best would be to, at dev time, have a AY switch bool which will include the tune/playback routine or not. Then in runtime have it test for an AY/YM chip and playback the tune or not accordingly?

[jorgegv]

Mmm seems very sensible to me. I'm adding a new issue for tracking this.

Thanks :-)

Update: created #107