megalmodtam a tutit, az összes variaciora legeneraljuk előre a digi lejátszó ciklust,nem bontjuk szét a vezerlest, mivel megúsztuk az önmódosító kódot, és oda update-eljuk be az értékeket, amit majd később meg is hívunk a következő vezerlesig. Ja és így nem kell jatszadozni az idozitesekkel sem, mert időtartamra a negyszogjel lejátszó rutin is olyan hosszú lesz, mint a többi.

Négyszögjelnél valójában a másik megoldás tűnik gyorsabbnak (4 ciklus különbség), de annak a használata növelné a kód méretét. Viszont kimaradt az INC IXL. Azonban ha jól látom, a DE regiszter már nem használt, ezért címezhetné az a delaytbl-t az IX helyett, így még a PUSH IX/POP IX is megtakarítható lenne.

Nem tudom, ez hasznos-e, de ha sok az előre generált kód és táblázat, akkor azok lehetnek -raw -m2 -blocksize 8192 tömörített formátumban is, és a decompressDataBlock kicsomagolhatná a 8000h-9FFFh területre (a 2-es szegmenst átmenetileg belapozva a 3. lapra) a hangminták generálása előtt. Így a dacTable tárolásához sem kellene külön RLE formátum ha 8800h kezdőcímre kerül.

Az ilyen módon tömörítetendő kód külön forrás file-ba kerülne (org 8000h és a végén nullákkal feltölteni hogy a méret 8192 legyen), a különböző lejátszó változatokat makrók generálhatnák, és a dacTable beépítéséhez elég lenne egy egyszerű include "dactable.s".

Szerk.: valami ilyesmire gondoltam (bár ez nem teljes vagy optimális megoldás):

Ezt eddig nem vettem észre, de nem rossz ötlet, bár ennek már 632 byte a tömörített mérete:
Össze kellene hasonlítani az egyszerűbb változattal, hogy valóban hallhatóan jobb-e.

Szerk.: ez így valójában nem jó, az INC E-k helyett egyenletesebben elosztva kellene futtatni a sidSynth ciklust, és nem a végén egyszerre 194-szer.

Mi történt, reggel láttam még egy tegnap esti hozzászólást, már nem, letörölted?

Lehet jobban szól a 3 részre bontott változat a bonyolultabb visszatérés ellenére is, én is arra gondoltam, hogy meg kéne csinálni a két verziót, és összehasonlítani