@Fox konkrety:

Głównym problemem dla mnie było to, że opcja przeszukiwania wydawała się być uszkodzona, bo nigdy nie udało mi za jej pomocą nic znaleźć, ale jak się przyjrzałem, to okazało się, że powód jest bardzo trywialny, a jednocześnie absurdalny. Ta dokumentacja jest po prostu niekompletna: wszystko od kontrola asemblacji w dół jest wycięte. A dotyczy to tego, czego się szuka, czyli wszystkie pseudorozkazy i dyrektywy. Bez tego fragmentu ta dokumentacja jest zwyczajnie bezużyteczna.

@mono dzięki za linka. To polepsza trochę sprawę. Choć nie jestem fanem faktu, że będę musiał to pamiętać i wpisywać z palca, gdy na stronie jest link do czegoś absurdalnie bezużytecznego.

Nie dajcie się zwieść, że to "tylko GBA". GBA ma 16 MHz ARM7TDMI + 32 kB RAM na szynie 32-bitowej (czyli 1 cykl na rozkaz ARM) i 256 kB RAM + max 32 MB ROM na szynie 16-bitowej (czyli 2 cykle na rozkaz ARM i 1 cykl na rozkaz Thumb). To bardzo mocna maszyna, która ma do rysowania na ekranie 240*160 przy całkiem przyjaznych trybach graficznych.

A no tak. Ten przypadek to nie jest błąd, ale można chyba z czystym sumieniem stwierdzić, że niedociągnięcie madsa, bo generuje dwa bloki, które mógłby połączyć, ale nie łączy bo org jest "dziwny". Ja nawet tego nie zauważyłem, bo wynik madsa i tak wpada do mojego programu, w którym sobie go obrabiam jak chcę. Nie ma żadnych gotowców, które potrafią optymalizować takie rzeczy? xebin tego nie robi? Jak nie to napisanie tego to 15 minut roboty.

Proponuję napisać prawidłowy kod źródłowy ;)

Statystyki dla nerdów twierdzą, że video jest w 1920x1080@30, więc ta cieczka mnie nie dziwi. Kwestia czy da się wymusić 50 Hz. Widuję filmy w 50 Hz na YT (np. https://www.youtube.com/watch?v=W-3DG-yoMv0 ).

Hej.

Główny wątek był tu: http://www.atari.org.pl/forum/viewtopic.php?id=17351 jest tam numeracja która śruba do czego.

Mam sporo M3x25 i B2.9X6.5, ale skończyły się B2.9x9.5

Można kupić je w TME, jak jesteś zdeterminowany, to kup paczuszkę a ja mogę Ci podesłać te co mam i mógłbyś przejąć pałeczkę dystrybucji śrubek potrzebującym STkowcom :)

A mnie ciekawi czy i kiedy pojawi się następny batch CosmosExa...

Wyobrażam sobie różnice pomiędzy oboma archiwami, typu demo znanej grupy z nieznanego roku lub odwrotnie.

Zasadniczo API jest te samo co w starym LynxSD, tylko funkcja inicjalizacji może być pusta. GD ma tylko inne timingi - pomiędzy operacjami trzeba trochę poczekać (zapętlenie X od 0 do 255 u mnie wystarczało).
Dokumentacji jako takiej nie ma, ale są źródła np te i te. Można użyć albo przepisać sobie na asembler (ja przepisałem).

Strzałki, z, x, 1, 2, 3.

Jeszcze jest f10 pause i f9 unpause, ale jest coś zbugowane.

Muszę zrobić stronę wiki na klawiszologię. Mam też issue żeby było konfigurowalne.

Do opisu lua też dodam wiki

To jest dość delikatne zagadnienie. Wewnętrzne sprawy Lynxa są bardzo mało poznane. W sumie główna nadzieja, że ktoś dotrze do RJ Micala i dostanie od niego jakieś papiery jak to zostało zaprojektowane. Podstawowe dwa zagadnienia, jakie składają się na nieprecyzyjną prędkość to:
1. Cykl 6502 (czyli cykl dostępu do szyny) może trwać 4 ticki zegara albo 5. 5 Trwa jeśli pamięć jest adresowana w pełni, a 4 jeśli adresujemy wewnątrz aktualnej strony. Mikey ma zaszytą jakąś logikę, które decyduje kiedy jak adresować. No oczywiście dokumentacja mówi, że zrobili to jakoś tak żeby było fajnie. Osobiście podejrzewam, że to radosna twórczość i już nikt nie pamięta jak. Żeby to odtworzyć, trzeba napisać serię testów, które sprawdzają ile trwa cykl dostępu do szyny w różnych scenariuszach. Póki co Felix ma to zrobione "mniej więcej" na zasadzie, że jeśli adresujemy po sobie dwa kolejne adresy, to wtedy 4, a jak jest "random access" to 5 (tak jak robi to w sumie ARM).
2. Prędkość blitowania sprajtów to prawdziwa niewiadomo. Ja oparłem swoje timingi na założeniu, że logika Suzy "nic nie trwa" a trwają tylko dostępy do pamięci. Podejrzewam, że emuluję to trochę za szybko. Ale znowu - bez napisania testów i pomiarów nie wiadomo ile to powinno trwać. A wpisywanie opóźnień z palca, żeby się mniej więcej zgadzało nie chcę. Nie wiadomo też jak jest z przerywaniem działania Suzy (przerwanie CPU potrafi przerwać rysowanie sprajta, które można później kontynuować). Hady nie miał przerywania wcale (tam cały sprajt rysował się w całości, stąd rysowanie sprajtów tam jest dużo szybsze niż w rzeczywistości), ja zaprogramowałem przerywanie przy dowolnym dostępie do pamięci, prawda jest gdzieś po środku, a gdzie, to nie wiadomo.

Reasumując nie robiłem jeszcze porównań prędkości działania. Prędkość CPU powinna być dość wierna, Suzy mniej wierna, ale możliwe, że całość jest sumarycznie bardziej wierna niż Handy. Ale to tylko moje przypuszczenia i mogę się mylić.