Inkább az a kérdés a TAP-oknál, hogy a mindenféle modern cuccal (vinyó, SD, stb), azzal megy-e?

Szerintem kb az összes játék is ezt használja (már amelyiknek nem saját loadere van). Ha jól rémlik az EP-s Spectrum Emulátorban is ez a cím van meghackkelve (plusz a save is).

Igen, nekem is ez rémlik, a 0562h és a 0556h a hivatalos belépési pont, és van egy-két elvetemült, ami másik címet hív, amire nem emlékszem.

Próbálkoztam az előbb említett másolós módszerrel, de a Space lenyomva tartásakor lefagy, ezért visszaállítottam az eredeti megoldást. Az ay_da_opt.cpp tartalmaz ayumi táblázatokat is, ezeknek a használata a compile.sh szerkesztésével engedélyezhető. A vezérlés gyorsult 12 ciklust, bár laphatáron valamivel lassabb lett (aminek kevesebb jelentősége van).

Leginkább az IM2 használata lehet megoldás a megszakítás problémára, amit javasoltál, de ez is csak akkor fontos, ha tényleg módosult a ROM loader a különböző verzióknál, egyébként jónak kéne lennie, azt akarom még megnézni, hogy véletlenül nem marad-e az épp lejátszott szegmens a 3. lapon, mert ez okozhat gondot.

32 bites sid_conv, sid_dump, epcompress és sjasm 0.39g6:
(Attachment Link)

Közzé is tettem

A fix 5F10h blokk mérettel való betöltést is kifogásolják, bár ennek eredeti magnós gépen működnie kellene, csak a valódi gépen magnót "emuláló" speciális hardvereknél okoz problémát. De úgy látszik, elsősorban az utóbbiakat használják. Tehát vagy a fejlécnek kellene külön blokkba kerülnie TAP esetén, vagy minden TAP file-nak tartalmaznia kellene a lejátszót is a megfelelő blokk mérettel fordítva.

Igen, és igen, és igen Most néztem én is, válaszoltam is, a fejléces megoldás nem jutott eszembe, az egy teljesen jó ötlet, és kevésbé macerás, de a legegyszerűbb, csinál magának mindenki egy basic loadert, és vagy lecsökken a max file méret 200h-val, vagy az egészet 200h-val eltolva töltik be, majd a lejátszó bemásolja magát meg az adatot a helyére.
A szofisztikált MB02 tap emulation, tőccsék magnóról
Úgy emlékszem a LOAD "" CODE-hoz csak a töltési címet kell megadni, de ha MB02-nél kell a hossz is, akkor mindenki bekódolhatja magának.

Lehetne a Spectrumosok számára külön rövidebb M64-eket is készíteni, tulajodnképpen nem is kellene újra konvertálni, csak egy rövid programot írni, ami kicsomagolja, 96K-ra korlátozza és újra tömöríti a parancssorban megadott összes file-t.

Az ilyen csonkított file még mindig EP kompatibilis maradna, de a lejátszót egyszerűsíthetné a Spectrum specifikus formátum, illetve az ilyen célra készült sid_conv változat figyelembe vehetné a kisebb hangerő felbontást a táblázatos hullámformáknál.

Szerintem nem érdemes ezért új programokat írni, megnézem, lehet-e a Block editorban szétdarabolni egy-egy adatblokkot, ha lehet, akkor a csomagba betett tapokban elintézem, hogy a fejléc külön legyen, és meg is van oldva a hossz probléma, azt nem tudom, hogy az 5b00h-5bffh-ra írás a gyönyörű lemezes környezetben emulált tap-oknál okoz-e problémát.
Vagy direkt lemezes rendszerekre meg lehet csinálni a basic loaderes verziót, ami mindent 200h-val eltolva tölt be mindent, majd betöltés után minden a helyére kerül.
Melyik legyen?

Szerintem nem érdemes ezért új programokat írni

Az M64 rövidítés egyszerű (ugyanúgy fordítható, mint a sid_conv.cpp):
[ Guests cannot view attachments ]

És a használata is:
./m64trunc *.m64

Tulajdonképpen a sid_conv.cpp is könnyen "Spectrumosítható" lenne, csak akkor mindent újra kellene konvertálni.

Melyik legyen?

Nem tudom, ezt valószínűleg a WOS-on tudják eldönteni, melyik megoldás használhatóbb. De a maximális file méret csökkenése szerintem nem lenne nagy probléma, a legtöbb zenének elég az 5D00h is, a kivételek (pl. IK) pedig rövidíthetők. Ami ilyen sok helyet igényel, az valószínűleg lényegesen hosszabb 2:43-nál.