VBLK nie, bo "X nie jest stałe". DLI by się nadało.

Inne podejście to jeśli procka jest jednorodna, wstawić do niej jakiś licznik, żeby sama umiała się przerwać.

zopfli --deflate --i4000: 1598 bajtów

Edit:
Dopisałem info o --i do instrukcji inflate. Pewnie nie byłem jedyną osobą, która nie wiedziała o tej opcji.

Na czym polega różnica?

Przydałby się jakiś wzorcowy dla Atari 8-bit zestaw danych do kompresji, żeby porównywać kompresory:

• riverraid.rom jest spoko, przydałby się jeszcze jakiś wiekszy nieskompresowany program

• grafika (conan.gfx jest git)

• plik tekstowy (gpl-3.0.txt?)

• cmc, mpt lub rmt bez nazw instrumentów

Może kogoś zainteresuje mój warsztat. Mam teraz monitor 4K i świetny edytor, ale przy bardziej zaawansowanych optymalizacjach kartka jest niezastąpiona.

To ma sens, bo kod jest mocno 16-bitowy i nawet kulawe przełączanie się między trybami 8/16 bitów nie powinno boleć. Plus MVN się przyda. Ale dopał nie będzie taki, jak przy szybkim mnożeniu na 6502.

Dobre pytanie.
Na PC zwykle kompresuje się tylko bardzo duże zbiory i przykłada wielką wagę do wydajności dekompresji, a mniejszą do stopnia kompresji. Shrinkler wykonuje jedno mnożenie i kilka operacji warunkowych na każdy bit skompresowanego strumienia. Nawet na wypasionym pececie dekompresja tak skompresowanych gigabajtów trochę potrwa i nie ma jak jej zrównoleglić. Na Amidze i Atari każdy poczeka te kilka sekund na rozkompresowanie pojedynczych kilobajtów. Na pececie przydałaby się akceleracja sprzętowa. Być może dałyby radę akceleratory AI, które są świetne w mnożeniach.

Syzygy 7 - "Obsługa podkatalogów".

Dlaczego masz inne wyniki od moich? Skąd wziąłeś Shrinklera i Deflater? Ja skompilowałem Shrinklera z GitHuba, a zopfli z MSYS2.

Tebe mądrze pisze we wszystkich trzech powyższych postach. Gdzie tu się klika lajki?

Zacząłem już LZFSE, ale z tego, co piszesz, nie warto kończyć. Lepiej Ci pomóc w optymalizacji unshrinklera. Na youtubie jest tak wolno, bo czyta po SIO?

To jest ten sam format i program. Ja po prostu kliknąłem "ultra" w GUIu, w dodatku mam starego 7-zipa (19.00).

Ciekawe. Wczytałbym się w ten tekst, gdybym chciał zaprojektować swoje 6502. Ciekawe, co na to mój management? ;)

W jednym akapicie jest to napisane w trybie przypuszczającym, ale już w następnym jest plot twist. A już wymyśliłem dwa zastosowania: 1. Zakończenie 256-ki z blokadą trybu przyciągania uwagi. 2. Blokada klawisza RESET w 400/800.

To akurat wynika z każdej tabelki z rozkazami 6502.

Edit:

Co do ankiety, to mogę sobie wyobrazić cartridge przełączający banki z opóźnieniem.
W ogóle dlaczego rozpatrywać cartridge, jak wystarczy zwykły samomodyfikujący kod?

asapscan -d file.sap >dump.txt

Binarkę na Windowsa znajdziesz w asap-*-win32.zip.

Próbuję zrozumieć, jak działa CRT. Być może kiedyś przełoży się to na jakąś emulację w RECOIL, ale nic nie obiecuję. ;)
Ile cali miał "standardowy monitor złomodore/philips" ?
Jeśli 14, to szerokość = 14 * 25.4 * 4 / 5 = 284.48 mm
Więc odpowiedź na tytułowe pytanie: 284.48 / 0.65 = 437. Czyli jak wyświetlamy 640 pikseli, to na każdy piksel przypada mniej, niż trójca pasków luminoforu? Czyli kolory wąskich pionowych linii są z konieczności przekłamane?