Ébredés után jutott eszembe, hogy ez nem fog menni, mert a gyorsabb vezérlésű SID-eknél az LPB biztos 1 hosszú.

gondolom most optimalizálsz, a hozzászólás eltűnéséből gondolom

Valójában azért tűnt el, mert jobban meggondolva talán mégsem igazán jó ötlet. Csak akkor gyorsul a számított mértékben, ha 100% a CPU használat, bár a kicsomagolási idők így is valamivel jobbak lettek a korábbi verziónál.

(igaz a DI-s rész 3 ciklussal hosszabb lett)

Az LD A, (BC) lehetne a DI előtt is, ez ugyan 3 byte méretnövekedést eredményez, de a FILE-os szegmensen talán nincs nagy jelentősége.

Ez ugyanaz a verzió, ha már be van építve, akkor legyen hozzá forráskód is:
 decompress_m2_8K_noIX.s (8.41 kB - downloaded 228 times.)
 decompress_m2_8K.s (7.97 kB - downloaded 226 times.)    (IX-es változat)

Sebesség teszt (nem a lejátszóban, hanem csak a kicsomagoló rutinok egy egyszerű programba építve):

INTERNA.M64 (24124 byte, 396 másodperc):

decompress_m2_new.s: 4.434 másodperc
decompress_m2_8K.s: 4.438 másodperc
decompress_m2_8K_noIX.s: 4.668 másodperc

AUFWIED.M64 (15444 byte, 369 másodperc):

decompress_m2_new.s: 3.019 másodperc
decompress_m2_8K.s: 3.027 másodperc
decompress_m2_8K_noIX.s: 3.157 másodperc

ACEII.M64 (14237 byte, 315 másodperc):

decompress_m2_new.s: 2.729 másodperc
decompress_m2_8K.s: 2.725 másodperc
decompress_m2_8K_noIX.s: 2.850 másodperc

Az IRQ kezelés optimalizálása ~17-20% gyorsulást eredményez 4 MHz-es gépen 11364 Hz-es lejátszásnál és 50 Hz-es vezérlésnél.

én már azon gondolkoztam, hogy
50Hz-es vezérlést 11904 Hz-re

Próbáltam 12500-at is, az még működik, de villog a raszter és 5 másodperc körüli kicsomagolási idő fordulhat elő. Ez akkor lehet probléma, ha az utolsó blokk nagyon rövid, bár ha jól látom, ilyenkor a vezérlés elvileg várna a következő blokkra (ha (015Bh) = 0):
itt azonban hiba lehet, hogy a pozíció növelése után a következő megszakítás már átugraná ezt a részt és szemetet játszana le. Az LD (89A1), HL-t esetleg célszerűbb lenne az LD DE, FD56 elé helyezni, így egy másik hasonló utasítás törölhető is.

A 11905 Hz még nem villog, tehát az valóban stabil lenne.

Módosítások eszközölve Legújabb teszt verzió, már ROM verzió is van a csomagban.

Egy lehetséges hiba: 4 MHz-es CPU-n 12 kHz-et ír ki, de továbbra is 11364 Hz frekvenciát állít be.

Újabb ötlet gyorsításra: video megszakítás helyett a hangminta frekvenciát osztani két lépésben, először kb. 500 Hz-re (12500 / 25), aztán tovább a vezérlés frekvenciájára (50 Hz = 500 / 10). Ha a kivezérlésjelző alatt van egy elég hosszú VINT-es LPB (a video megszakítás jelenlegi pozíciója alapján legfeljebb 48 sor azaz 3 ms idő lehetséges), akkor az 500 Hz-en még megbízhatóan figyelhető a B4h port 4. bitjén. A második számláló lefutására történik a vezérlés, a VINT bit felfutó élére pedig a kijelzés frissítése.

Ez ugyan nem egyszerű módosítás, különösen az optimális frekvencia osztók beállítása a hangminta és a vezérlés frekvencia alapján, tehát nem biztos, hogy megéri.

Amit nyerni lehet vele az IRQ rutinban:
- 25 ciklus gyorsulás a video megszakítás tárolójának a figyelése nélkül
- 3 ciklus lassulás a megszakítás törlésekor (E regiszter helyett konstans)
- 11 ciklus lassulás az első számláló (DEC E és JR Z)
- ~113 ciklus lassulás csak a lefutásakor (nem feltétlenül jól optimalizálva), átlagosan 113 / 25 = 4.52 ciklus
Azaz ~6.5 ciklus / hangminta nyerhető. Ezen kívül lehetségessé válik nem csak 50 Hz többszöröseinek a támogatása, és fix VINT pozíció használata.

Tehát úgy, hogy az 500 Hz legyen fix, tehát azt kell a tényleges lejátszási frekvenciából számolni, és a vezérlési sebességet meg az 500 Hz tovább osztásából?

Az 500 Hz változhat kis mértékben, így pontosabb lehet a frekvencia. Például 200 Hz-es bemeneti file esetén 500-ból csak 250 vagy 167 Hz lehetne, viszont a 400 vagy 600 már jól osztható. A használható tartományt korlátozza a VINT hosszúsága (nem veszhet el video megszakítás), nagyobb frekvencia pedig több CPU időt használ.

Első körben a digi lejátszó futna addig ciklusban, amíg eléri az 500 Hz-et, ilyenkor mindig csekkolunk 4. bitet a 0b4h porton, ha aktív, akkor ugrás a display vezérlésre, majd csekkolni hogy a zenevezérlő ciklus elérte-e a 0-t, ha igen, vezérlés, egyébként visszatérés a megszakításból?

Valami ilyesmivel próbálkoztam, ez nem biztos hogy optimális (vagy működő) megoldás:
Itt az l1-nél kezdődő rész lehet 30h alatt is, ha nincs elég hely. Az l4-nél Z=1 esetén a vezérlésnek kell futni, C=1-nél pedig a kijelzésnek, ezek egyszerre is történhetnek.

Szerk.: 12500 Hz-en 6 ciklussal gyorsabb megszakítás kezelés még nem elég ahhoz, hogy ne villogjon a raszter.

Szerk. 2: a CPL megtakarítható a VINT áthelyezésével a kivezérlésjelzőre és/vagy elé. Esetleg a kivezérlésjelző megoldható úgy, hogy ne legyen minden sor külön LPB, így egyszerűbb a frissítése.

Most néztem az LPT-t, elméletileg 100 raszter sorra mehet a VINT bit, 48 a volume kijelző alatt az Enterprise feliratig, és 52 a reload bitig, mivel nem akarunk interruptot, csak a figyelni a VINT beállítást, így pakolhatunk egymás utáni LPB-kbe VINT bitet, működnie kell, nem? Ezzel a második ciklusszámlálót akár csökkenthetnénk 4-re is, amivel megspórolnánk 678 ciklust. A képernyő tetején 27 raszter sor úgyszintén nem használt, előre tettem a kijelzős dolgokat, és csak utána lesz a zene vezérlés, ha esetleg a 27 képsor sor nem elég a képernyőn való piszmogásra, a VINT-es képsorokból még elvehetünk, max a ciklusszámláló 5 lesz.
Mit szólsz?