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 :)

w Rapidusie takie czary nie działają

https://github.com/floppyrom/C64-Math-Library

na C64 przygotowani są na mega tablice w REU

Hurra, wylądowałem, jutro dobrze się temu przyjrzę, mam jeszcze kilka godzin w pociągu

Czyli 10-11 procent, z grubsza tak, jak obliczał Gemini.

Załączam jeszcze propozycję kolejnych poprawek do math.asm - zdaje się, że zapomniałem je wprowadzić poprzednio.

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

Ciekawe. Zmiana dotyczy udiv24, procedury 24-bitowego dzielenia, a ściślej głównie jej "pełnej" ścieżki (od etykiety ?full), przez co maksymalny czas tego dzielenia spadł z ok. 1400 do ok. 940 cykli (o 1/3). Taki zysk powinien być gdzieś widoczny, chyba że ścieżka ?full jest używana bardzo rzadko albo tylko w specyficznych sytuacjach.

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.

Był może łaskaw podać jakiś powód?

U mnie działa. Zaraz spróbuję porównać stany licznika FPS na tej wersji i na poprzedniej.

EDIT: poprzednia od razu po załadowaniu (zero ruchów) pokazuje na liczniku FPS 4.44-4.54. Nowa: 4.76-4.84. Więc różnica przynajmniej daje się zmierzyć.

A potem podrzucę lepszą wersję tego udiv24a, bo tymczasem udało mi się ją trochę ulepszyć (worst case nie 770 cykli, tylko 390).

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

Nadal działa, jakkolwiek na samym starcie różnicy nie widać, 4.76. Ale pewnie gdzieś dalej będzie.

EDIT: licznik FPS-ów się krzaczy, jeśli zmniejszymy rozmiar obrazu klawiszem "-". Wygląda, jakby jego (licznika) tło nie było wtedy odświeżane.

EDIT 2: sprawdziłem poprzednią wersję na Rapidusie:

20 MHz: 6.45-6.66
40 MHz: 9.09-9.52

Proszę:

Krótko mówiąc, mam takie doświadczenie. Nie mówię, że tego nie zrobił, ale np. najpierw dodał odpowiedź, w której nie przywiązuje wagi do zmian - nie mogę pomóc itp. Nie mam już jego odpowiedzi. Tak czy inaczej, problem został rozwiązany.

Na początku korzystałem skills, ale Claude miał tendencję do upychania tam różnych rzeczy, notatek i robienia z tego pamiętnika - nie wiem dlaczego, więc przez długi czas korzystałem z Claude'a bez umiejętności. Teraz mam już trochę umiejętności.