Reflektowałbym zatem na 5 szt. Cart i 5 szt. ECI.

Jeśli zmieścisz się w 512K można rozważać jeszcze wersję wykorzystującą pamięć VBXE. Choć nie wiem czy istnieją w przyrodzie jednostki mające VBXE a nie mające XRAM.

Jest jeszcze AtariMAX 8Mb (1MB). Obawiam się, że nie ma uniwersalnego schematu bankowania. Zerknij na: https://sourceforge.net/p/atari800/sour ... C/cart.txt

http://www.worldofspectrum.org/ ?
Ja się jeszcze posiłkuję papierem: "Przewodnik po ZX Spectrum" http://www.worldofspectrum.org/infoseek ... id=2000592

Bez zbędnych rotacji pamięci:

        lsr
        ror
        sta res+1
        ror
        tax
        and #%11000000
        sta res
        ror
        adc res
        sta res
        txa
        and #%00011111
        adc res+1
        and #%01111111
        sta res+1

36 cykli.

mul96   lsr
        ror
        pha
        and #%00111111
        sta res+1
        pla
        ror
        pha
        and #%11000000
        sta res
        ror
        adc res
        sta res
        pla
        and #%00011111
        adc res+1
        sta res+1
        rts

Edit: pha/pla możesz zastąpić tax/txa co oszczędzi 6 cykli.

Ja jestem zinteresowany DOS-ami.

Błąd w oryginalnym playerze zrobionym przez Pelca polega na tym, że do resetowania POKEY-a używa rejestru $D21F zamiast $D20F. Stąd kiedy masz Stereo to pierwszy POKEY gra źle bo po komunikacji z magnetofonu/stacji dysków zostają mu stare ustawienia, a resetowany jest drugi POKEY (a muzyka  Lasermanii gra tylko na pierwszym POKEY-u).
Nawiasem mówiąc w Lasermanii, Misji, Fredzie, Saperze i Klosie używany jest Avalon Music Composer a nie Chaos music Composer :) Ale błąd w obydwu playerach jest ten sam.

Edit: Problem nie objawia się kiedy ładujesz grę z dowolnego urządzenia które nie korzysta z komunikacji szeregowej (IDE+, SIDE), bo wtedy rejestry POKEY-a nie są przez procedury transmisji dotykane i POKEY jest zresetowany jeszcze przez procedurę RESET.

Ładne, ładne :) A końcówka...

Porządna rzecz. Dzięki!

Niektóre algorytmy zakładają, że to co zostało dotychczas zdekompresowane jest już ciągle dostępne i odwołują się do tych danych np. kopiują fragment w bieżące miejsce. No i to mi nie odpowiada bo wtedy tak czy inaczej musiałbym rozkompresować całość do pamięci, a ja chcę w pamięci mieć tylko fragment pliku - dokładnie to, co w najbliższej przyszłości zostanie zagrane, a co po zagraniu zostanie usunięte. Więc na tym polegała by "dekompresja strumieniowa" że w dowolnej chwili chcę zdekompresować kolejny blok danych bez konieczności trzymania w pamięci tego co zostało zdekompresowane wcześniej. Oczywiście nie jest problemem, że w pamięci musi być jakiś bufor albo słownik z którego dekompresor korzysta.

Jeśli masz na myśli LHAsa, to jest tu: https://github.com/fragglet/lhasa
Przykładowe dumpy:
- .ym: archiwum https://pacidemo.planet-d.net/html.html lub ftp://ftp.modland.com/pub/modules/YM/ (opis formatu: http://leonard.oxg.free.fr/ymformat.html - .ym można łatwo zdekompresować za pomocą "lha x modul.ym" i dostajesz wtedy docelowy plik z nagłowkiem "YMx!" itd.),
- .vtx: archiwum https://bulba.untergrund.net/music_e.htm (opis formatu: https://documentation.help/AY-3-8910.12 ... _e0irc.htm tu dane do dekompresji są już zaszyte w środku)
W załączniku przykłady.