tracker: avoid including tracker functions when not used

[jorgegv]

tracker: avoid including tracker functions when not used

[jorgegv]

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

Thanks :-)

Update: created #107

[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?