A fenti kódrészlet emulátoron valójában nem hibás, csak valódi gépen lehet problémás. Itt azonban hiba lehet, ha a lejátszás vezérlése közben hangminta megszakítás történik:

Megoldás lehet a megszakítások letiltása a paraméterek frissítésének a teljes időtartama alatt, vagy a hangminta rutinban nem nullázni a frekvenciát a lejátszás végén (ami egyszerű, bár növeli az átlagos CPU fogyasztást). Szerintem akkor marad ki hang, ha a frekvencia (004Dh és 0051h) vezérlése már megtörtént, de a lejátszási pozícióé (DE', és 0059h a hangminta vége) még nem teljesen, és ilyenkor következik egy megszakítás amely nullázza a frekvenciát. Természetesen ugyanez vonatkozik a jobb csatornára is.

És az is, ha nincs minden pálya külön tömörítve, hanem több van egy "csomagban". Példa:

1-es pálya tömörítetlenül, -m3, -m2 és -m0 formátumban, és ugyanezek átrendezés után:

Néztem én is mind a három formátumot, és osszfuzve is nem tudom hány pályát, a saját módi szerint jobbra jött ki, ezért maradtam annál, 140-170 byte/pálya
Alábbi segítséget köszönöm, ma megnézem.

Hangmintáknál is lehet egyébként egyszerű trükkökkel helyet megtakarítani, például a tcave.ep128s-ben található 28416 byte méretű adat 8018 lesz -m0 formátumban, azonban egyszerű szűrő (minden byte az előző hangmintához képest a különbséget tárolja) után már csak 7626 byte, mivel az egyes hangminták között gyakrabban fordul elő kis különbség.

Húúú, erről már volt szó, említetted egyszer, teljesen el is felejtettem, ha helyhiánnyal küszködök, akkor majd élek is vele, egyelőre nem szeretném lassítani a kicsomagolást, a pont általad is tesztelt file kb 2mp alatt packolódik ki, leteszteltem a másik két módot is, m3 1,5 másodperc volt, viszont összességében kb 7 KB-tot nyertem, ezért is választottam az m0-t
Gondolom még azt lehetne, hogy visszaalakítom a hangmintát  5 bitesre, (eredetileg is az volt , most is az, csak másképp ), és 2 különbséget tárolok egy bájton, kivéve ha a különbség 10h-nál nagyobb, bár gondolom ezzel ronthatok a tömörítés hatékonyságán.

A 4K-s változatban a karakterkészletek "C64" sorrendre konvertálásával lehetne még nyerni kb. 50 byte-ot.

Jó ötlet, egyelőre nem hajtom végre, mert nem tudom mit tudnék kezdeni azzal a 4x bájttal , kb annyi lenne belőle a végére, a bonyolódó bemásoló rutin miatt.

Megoldás lehet a megszakítások letiltása a paraméterek frissítésének a teljes időtartama alatt, vagy a hangminta rutinban nem nullázni a frekvenciát a lejátszás végén (ami egyszerű, bár növeli az átlagos CPU fogyasztást). Szerintem akkor marad ki hang, ha a frekvencia (004Dh és 0051h) vezérlése már megtörtént, de a lejátszási pozícióé (DE', és 0059h a hangminta vége) még nem teljesen, és ilyenkor következik egy megszakítás amely nullázza a frekvenciát. Természetesen ugyanez vonatkozik a jobb csatornára is.

Zseni vagy, ez történt, áthelyeztem a DI-t és EI-t, mostmár teljesen jó a zene.
Ha nincs kinullázás, akkor elméletileg belefuthat a lejátszás a következő hangmintába, nem?

Ha nincs kinullázás, akkor elméletileg belefuthat a lejátszás a következő hangmintába, nem?

Nem, a DE' egyébként is mindig visszaállna a hangminta végére, a nullázás csak optimalizálás.

Teszteltem több verziót, sajnos a full 2x2 karakteres tömörítés nem lehetséges, a szétszórt objektumok miatt, így van 2x2-es tömörített adat, és 1x2-es (pár pályán változtatni kellett),és az ismétlődések ha 2-nél több, akkor két byte-on tárolva, ha nincs ismétlődés, akkor 2 elem 1 byte-on tárolva. így kisebb lett a file, mint tömörítve, a pályák 140 és 160 byte között mozognak.

Valójában használhatónak tűnik a 2x2-es megoldás is, így 45 féle blokk fordulhat elő, ebből hatnál a karakterek összefüggő számsort alkotnak (pl. 60h, 61h, 62h, 63h). Tömörítve ez hasonló méretű a jelenlegi formátumhoz, bár a kód egyszerűbb lehet, ha nem is nagy a különbség.

Szerk.: még egy lehetőség: "kevert" blokk méret (1x2 és 2x2 is), de nincs RLE és két elem egy byte-ba csomagolása, tömörítés után ezek nem javítanak a méreten.

Megcsináltam a differenciált hangmintás fájlokat, egyelőre megéri szerintem:
poptechn   8361--->7925
simplemus 6671-->5774
treasmus   5358-->5321
yankee       4108-->4054

amúgy poén lett volna olyat ep program hogy a grafikának csak felezett verzióját tölti be előbb, és rákérdez hogy töltsön-e tovább és akkor betölti az egészet.
volt a jacks house, annak nálam hibás volt az utólsó blockja, emiatt nem voltak ellenségek

Gondolom még azt lehetne, hogy visszaalakítom a hangmintát  5 bitesre, (eredetileg is az volt , most is az, csak másképp ), és 2 különbséget tárolok egy bájton, kivéve ha a különbség 10h-nál nagyobb, bár gondolom ezzel ronthatok a tömörítés hatékonyságán.

Az 5 bitesre konvertálástól nagyobb lett a file, -m0 formátumnál a hangminták korlátozott értéktartományát a Huffman kódolás egyébként is kihasználja. Minimális mértékű javulást (7596 -> 7580 byte) eredményezett a kettővel osztás, azaz 0..62 helyett 0..31.

Szerk.: próbálkoztam egy 3 és egy 4 bites előjeles különbség egy byte-ba csomagolásával is, ettől ugyan nem sokkal lett nagyobb a tömörített file, de ez is rosszabb az egyszerű differenciálásnál. A különbség fixen 4 bites tartományra korlátozása javított egy keveset a méreten, ez azonban veszteséges, tehát valószínűleg nem éri meg.