rzeczywiście, umknał mojej uwadze opis drac030: "Król Offtopiku" ;)

drac030: Z przykrością muszę stwierdzić, że wykazujesz ignorację w zakresie budowy kompilatorów.

Praktycznie wszystkie kompilatory C wykonują również optymalizację pod konkretną maszynę, czasami również przez analizę wygenerowanego przez nie "wprost" kodu asemblerowego. Rezultaty są rewelacyjne. Np. cc65 analizuje kod 6502 i może stwierdzić takie rzeczy, jak np. że w określonym miejscu kodu rejestr X ma zawsze wartość zero, więc LDX #0 jest tam zbędne.

Pytanie o optymalizację było jak najbardziej na miejscu. Jeśli jej nie włączysz, to generowany jest kod, który najprościej wygenerować. Ma on wtedy wydajność porównywalną z BASICiem (jeśli nie gorszą w przypadku lepszych BASICów). Różnica może być nie tylko 6-krotna, lecz 60- i więcej-krotna.

Jest dokładnie odwrotnie. Program jest precyzyjnym zapisem algorytmu, więc kompilator dobrze go rozumie.
Kompilator ma mnóstwo informacji o architekturze konkretnych modeli procesorów, które ciężko znaleźć w opasłych dokumentacjach dla ludzi, np. w jakiej kolejności umieścić instrukcje, aby jak najwięcej z nich wykonało się równolegle. Tego typu rzeczy znacznie się różnią między poszczególnymi modelami procesorów (np. Pentium a Pentium Pro).

Samo zrozumienie nic tu nie wnosi, dopóki nie zmienisz algorytmu. Nie ma tu żadnej różnicy między asemblerem, C ani BASICiem.

Głupie pytanie, ale muszę je zadać: czy zastosowałeś opcję "-O2" w gcc? W przypadku nowoczesnych procesorów i kompilatorów, dobrze napisany kod w C jest zwykle max. kilkadziesiąt procent wolniejszy od genialnego kodu w asemblerze. Więc zupełnie nie ma sensu pisanie w asemblerze, tym bardziej, że trzeba by optymalizować pod konkretny model (w C wystarczy zmienić opcję kompilatora). Własnoręcznie wyciąłem ostatnie resztki asma x86 z emulacji GTIA, bo na oko było widać, że gcc 2.95 generuje wydajniejszy kod.

Emulację POKEYa w Atari800 można pewnie przyspieszyć z 50 razy, a resztę emulacji (czyli głównie Antic/GTIA oraz 6502) może dwukrotnie. Oczywiście wszystko cały czas w C. Wszystko jest opisane w pliku TODO ze źródłami Atari800.

Na marginesie: optymalizator cc65 wcale nie jest taki zły. Kiedyś przyglądałem mu się i zgłosiłem trochę poprawek.

Jest niemal pewne, że oba te emulatory automatycznie gubią klatki
(czyli zmniejszają refresh). Jest to w TODO Atari800. :)

W przypadku mniej wydajnych urządzeń (szczególnie pocketów) problemem jest woolny dostęp do ekranu i żadne sztuczki z asemblerem nic tu nie pomogą.

W którymś numerze Syzygy był mój artykuł o ripowaniu SAPów.

Mógłbym się też pokusić o obsługę w SAP Makerze i ASAPie formatów: Future Composer, Delta Composer, SoundTracker, Antic Music Processor, Theta Music Composer 2.0, Automat Perkusyjny, Black Music Composer, Collen Music Creator, Music Studio, Soft Synth, Benjy Soundmonitor, Advanced Music System. Potrzebuję tylko dokumentacji tych formatów i/lub źródeł plejerów, no i oczywiście pliki do testów.

Dziwny tok rozumowania.

Po prostu tak się składa, że x86 jest little-endian i nie ma problemu z dostępem do niewyrównanych słów - tak jak 6502.

ZTCP w TA był patch playera CMC. Kto go znajdzie?

eh, patrząc na temat posta pomyślałem, że Epi zmajstrował plejer MP3 na atarkę ;)

A jaka jest dokładność tych kwarców? Tj. jakie są odchyłki między poszczególnymi egzemplarzami?

b write>=aaaa write<=bbbb

ustawi pułapkę zapisu do obszaru aaaa-bbbb.

Wedle mojej wiedzy, takie "xchg" byłoby dużo szybsze na 286 i starszych,
a dużo wolniejsze na Pentium Pro i nowszych (gdzie AH jest fizycznie
osobnym rejestrem od AX i stosowana jest emulacja w celu utrzymania
wstecznej zgodności). Na nowych prockach prawdopodobnie najszybsze będzie:

mov edx, eax
shl eax, 8
shr edx, 8
and eax, 0FFFFh
add eax, edx

I've never heard of *.AR0 - are you sure they are treated exactly same as AUTORUN.SYS ?

Why not simply use AUTORUN.SYS ? This should work.

Nie wiem, co to ten "odczyt danej", ale po "shr" a przed "and" jest odczyt wskaźnika z tablicy.
Nie bardzo widzę, co ma Twoja metoda do rejestrów sprzętowych.

Ten "union" jest pozbawiony sensu: dwa bajty pod tym samym adresem.

Żeby zamienić kolejność bajtów w ax należałoby zrobić np. "rol ax, 8" (wolne jak diabli), ale wcale nie ma takiej potrzeby, bo przecież x86 jest little endian jak 6502.

Na little endian Atari800 używa teraz (*(UWORD *) (memory + adres)).
Jednak gdy przestrzeń adresowa będzie porozrzucana w różne obszary to nie jest to najlepszy pomysł:
wyobraź sobie dostęp do słowa pod adresem 0x3fff lub 0x7fff.