Na zestawie Antonia II w trybie turbo plus IDE+ rzecz ładuje się z ATR-a ok. 21 sekund do menu, a po wybraniu levelu mamy następne ok. 70 sekund ładowania.

A ile to byłoby rekordów w normalu na kasecie? Kilka kaset murowane, jakiś specjalny loader by musiał być z przerwą na zmianę strony i taśmy.

CAŁA NOC WGRYWANIA NA ATARI i... :)

PS. Teraz widzę dopiero, że to 2 mega skompresowane jest, a 6,5 po odpakowaniu. Żadna noc, to byłoby prawie 32 kasety sześcdziesiątki jeśli ładować zdekranczowane...
Po wgraniu (zakładając że nie wystąpiłby błąd I/O naturalny albo ten z OS-u) już by się komputera nigdy nie wyłączało no i może magnet byłby też lekko zajechany.

tak, to prawda, jest to tam wydrukowane i poszczególne fragmenty są nagrywane, jeden po drugim, może to chwilę potrwać... ale byłoby ciekawie na Turbo Blizzard :)

To ważne, czy mógłbyś spróbować nagrać to na wideo?

Trochę się w tym gubię, mam w domu Antonię II i jeszcze jedno Atari, ale muszę kupić jeszcze jeden vbxe na testy..

galiba.. ponieważ nie mam akceleratora, nie wiem jak to sprawdzić, ale naprawię to.

Nie wiem, pewnie bałbym się napisać do Phareona o czymś, co napisała AI... :D
BTW, Peri Noid potwierdził artefakty również w swoim przypadku

Dzięki, mam nadzieję, że udało mi się to naprawić... Właściwie, kiedy wyłączyłem łatkę D: w Altirze, to nie działało. Teraz powinno być dobrze. Nowa wersja na FTP.

https://github.com/viktorcech/doom-vbxe

To od AI:
Założenie, że "BCB jest tutaj zablokowany" jest cechą Altira, a nie VBXE. Altira wywołuje LoadBlitter() bezpośrednio w procedurze obsługi BLITTER_START (vbxe.cpp:1361, z komentarzem dokładnie o tym, że dema nadpisują pierwszy rekord bez czekania). Prawdziwy rdzeń efektów pobiera te 21 bajtów BCB z pamięci VRAM w cyklach, które daje mu wyświetlacz - a te dwie instrukcje (~10 cykli, znacznie mniej w systemie Rapidus) wyprzedzą to pobieranie.

Rezultat:
- cm_flush - kopia kolumny źródłowej będzie miała szerokość 1 zamiast cm_n, więc wszystkie bliźniaki z wyjątkiem pierwszego pozostaną stare → dokładnie te paski o długości 2-5 kolumn.
- bg_blit - wypełnienie tła będzie miało szerokość 1 kolumny zamiast bg_w → szersze "odbijające się fragmenty" w lukach, które BSP pozostawił otwarte.

To wyścig, więc zdarza się sporadycznie i nie może się zdarzyć w emulatorze. To pasuje do "tylko na prawdziwym sprzęcie".

Poprawka

Usunąłem oba wpisy po BL_START (pod .if !TEX_RUNS z powodu martwej gałęzi z draw_vspan). Niezmiennik "return BCB to 1 px" nie ma już czytnika: przy TEX_RUNS=1 cm_flush jest jedynym użytkownikiem TWALL BCB, a bg_blit jest jedynym użytkownikiem slotu 0 VLINE BCB, i oba ustawiają BCB_WIDTH przy każdym wywołaniu. Blok skurczył się o 8 bajtów, wszystkie zabezpieczenia ert przeszły pomyślnie.

Czy nie jest tak również w oryginale? dosbox:

Na mojej liście zostało jeszcze 5-6 błędów, będę je stopniowo naprawiać