Teraz jest lepiej, jest krajobraz zamiast czarnego tła, a zakłócenia w wersji na Antonię zniknęły.

EDIT:

Ja też, wyniki są z samego początku, zaraz po załadowaniu. Jeszcze raz:

Altirra 14 MHz: 5.26-5.40
Antonia II: 5.40-5.55 (wersja ogólna), 5.71-5.88 (wersja specjalna)
Rapidus 20 MHz: 7.69-8.00
Rapidus 40 MHz: 11.11-11.76

Czy byłby duży spadek FPS-ów, gdyby sam dolny panel zrobić w średniej rozdzielczości VBXE (tj. 320 pikseli w poziomie)?

Altirra: 5.26-5.40 FPS
Antonia: 5.40-5.55 FPS (wersja na Antonię: 5.71-5.88)

Ciekawe, skąd ta różnica.

Ale w ogóle chyba jest błąd, patrz obrazek: za tymi oknami nie powinno być tak czarno i w poprzedniej wersji rzeczywiście nie było.

Istnieją dużo prostsze koncepcje, które też nie znalazły powszechnego zrozumienia, np. przyśpieszenie rozkazów move'ów blokowych do 2 cykli na bajt.

Bardzo dobrze, zysk, to zysk, a poza tym uporządkowanie kodu też się liczy, może da się tam jeszcze coś ręcznie wycisnąć.

Zauważyłem wczoraj, że w wersji na Antonię II, mimo że licznik FPS-ów pokazuje na pierwszej scenie 4.76, czasami przeskakuje na 4.87 - różnica pomiędzy jednym a drugim to około 2%.

Nie, szczerze mówiąc, zaskoczony jestem, że rozdzielczość to 160x200, bo wydawało mi się tak na oko, że 160x100. Mój błąd, powinienem był obejrzeć XDL. No, ale nawet jeśli, to i tak jest lepiej: dwa banki MEMAC to lepiej niż osiem.

Na to, że dane do VBXE idą przez wolną szynę 1,77 MHz, nic się nie da poradzić: sprzętowcy (autorzy) od Antonii II i VBXE musieliby nad tym usiąść razem, a to raczej mało prawdopodobne.

Ogólnie ten program jest nieco dziwnie skonstruowany. Np. próbuje się cały kod upchnąć w pierwszych 64k, co i tak się nie udaje, w dodatku przydzielając poszczególnym blokom kodu stałe miejsca w pamięci i pilnując, czy się nie przepełniają.

Na dodatek pamięć obrazu ma 16k, ale okno do niej, mające 4k, umieszczone jest pod, o ile dobrze rozumiem, adresem $9000 - co powoduje, że na Rapidusie cały blok 16k od $8000 do $BFFF działa z prędkością 1,77 MHz.

Słowem, można byłoby (chyba?) pod $8000-$BFFF włączyć okno 16k VRAM-u dla ekranu 160x100/256 kolorów na stałe, bez bawienia się w przełączanie kawałków po 4k, a cały kod, który zawala pierwsze 64k i ledwie się tam mieści, przenieść do drugiego bloku 64k, od $010000 do $01FFFF - gdzie też jest FastRAM i nawet jest częściowo wykorzystany na kod.

Zwolniwszy w ten sposób mnóstwo pamięci w pierwszych 64k można byłoby bardzo wiele zmiennych, które w chwili obecnej są zadeklarowane jako 8-bitowe albo 24-bitowe, przedeklarować na 16 albo 32 bity, oraz ewentualnie poupychać tam tablice, które się teraz w nim nie mieszczą.

To z kolei pozwoliłoby może uprościć kod dokonujący obliczeń przez ograniczenie przełączeń na 8 bitów tylko po to, żeby nie nadpisać adresu zmienna+3, gdzie może być już coś innego.

To tylko takie luźne myśli, decyzje i tak należą do w1k.

Tu jest film o Doomie na różnych modelach Atari ST: https://www.youtube.com/watch?v=RhrLe2Xy5uY

Od piętnastej minuty z groszami zaczyna się prezentacja na 1040ST, Medze ST, gołym Falconie030 itd.

Myślę, że nie jest źle, dajemy radę.

udiv24a v.2 - nawet to testowałem i wydaje się, że działa.

Dobrze, zakładam, że prędzej czy później znajdziesz czas, żeby opublikować wersję binarną z tą poprawką.

Teraz wspomniana nieco wyżej druga sprawa:

Załączam dwie procedury napisane pod sprzęt Antonii II, czyli z wykorzystaniem sprzętowego mnożenia i dzielenia:

1) umul16a: czas stały 46 cykli (a nie minimum 80+, a maximum 360+)

2) udiv24a: czas od 60 do ok. 770 cykli (a nie od 230 do 940).

Mógłbyś w wolnej chwili zbudować wersję, która używa tych procedur zamiast oryginałów? Oczywiście na Rapidusie to nie będzie działać, ale jestem ciekaw, na ile to polepszy szykość renderowania klatek na Antonii.

A działa? Pamiętaj, że ja tego nie kompiluję, tylko zatrudniam Gemini do formalnego sprawdzenia. On nie jest nieomylny.

Czy są tam memy o tym, jak Atariki działało w zasadzie nieprzerwanie przez 20 lat, bynajmniej nie na autopilocie, czy też to przyjmujemy za rzecz oczywistą, której doceniać nie należy?

Bez wątpienia tak jest, natomiast tutaj mamy do czynienia z sytuacją, że (nazwijmy to) on niektóre rzeczy czasem umie, ale przeważnie nie.

Np. umie się sprawnie posłużyć trybem adresowania długim pośrednim indeksowanym, typu lda [zp],y. Czyli wyglądałoby, że dokumentację od CPU dostał. Ale co to za dokumentacja, która ten tryb adresowania wymienia, a analogicznego trybu bez indeksu - np. lda [zp] - już nie? I tak samo jest z lda (zp),y - to tak; ale lda (zp) - już nie.

Rozkaz stz - czasem zna. Rzadko, ale jednak. Ale przeważnie (i to bardzo przeważnie) nie, toteż prawie wszędzie daje lda #$00 / sta, marnując dwa bajty i dwa cykle (i narzekając w komentarzach, że brakuje pamięci na kod).

16-bitowy akumulator i rozkazy przełączania rep/sep - znowu, czasem zna. Przeważnie nie zna. Przeważnie nie zdaje sobie nawet sprawy z tego, że takie asl/rol, czy lsr/ror można wykonać częściowo w akumulatorze, nawet ośmiobitowym. Chociaż to powinien wiedzieć z dokumentacji od 6502 i z codebase od 6502, czego chyba akurat zbywa.

Niezbyt to rozumiem.

EDIT 8 września: druga runda poprawek (de l'escalier). Mam nadzieję, że to będzie w ogóle działało :)