Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
TURGEN 9.3.0 Kolejna wersja multiplatformowego narzędzia do zarządzania obrazami taśm.
SV 2024 WE - program imprezy Już za tydzień odbędzie się zimowa edycja Silly Venture
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
atari.area forum » Posty przez Fox
drac030: Bardzo niegrzecznie z Twojej strony. Chwalisz się, że zrobiłeś coś lepszego niż grupa ludzi tworzących od 10 lat projekt Atari800 oraz sztab ludzi tworzących gcc, a nie pokazałeś nic konkretnego i sam twierdzisz, że nie masz ochoty pokazać. To nie ja, tylko Ty masz coś do udowodnienia.
Jestem wielce ciekaw, jak zmierzyłeś wydajność samej emulacji 6502 zawartej w Atari800 oraz jakich programów Atari używałeś do porównań.
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.
kompilator nie ma bladego pojęcia, co kompilowany program robi, oraz jak można wykorzystać architekturę danej maszyny do zrobienia tego lepiej.
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).
To wie tylko człowiek, bo tylko człowiek jest w stanie zrozumieć algorytm.
Samo zrozumienie nic tu nie wnosi, dopóki nie zmienisz algorytmu. Nie ma tu żadnej różnicy między asemblerem, C ani BASICiem.
Zgadzam się z przedmówcą.
ja napisałem w asemblerze silnik 6502 sześć razy szybszy od analogicznego kodu generowanego przez gcc
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.
emulator C64 smiga mi >100% a Atari ST ~80-90% oryginalu
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ą.
>stanowią kod wykonywalny 6502, generujący dane do rejestrów POKEY-a
no ale przeciez nie wysylasz kodow "losowo". podajesz konkretne wartosci zeby uzyskac konkretne dzwieki.
Chodzi o to, że "kody" są wysyłane do POKEY-a najczęściej 50 razy na sekundę, a nuty grają kilkukrotnie wolniej. Problem polega więc na przerobieniu kilku "kodów" na jedną nutę. W drugą stronę (MIDI->SAP) byłoby pewnie łatwiej.
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.
Jaki znowu bigger?
Jak emulator chodzi na sprzęcie big-endian lub nie można jedną instrukcją pobrać słowa spod nieparzystego adresu, to np. w przypadku instrukcji LDA $ABCD bajty $CD i $AB muszą być pobrane osobno i złączone w słowo.
muliplatformowy open source project to niestety kod jest zoptymalizowany raczej pod kątem x86 :-(
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.
aaaa, znalazlo sie, pewnie chozi o to: http://tajemnice.atari8.info/6-7_93/6-7_93_digicmc.html
Właśnie.
Było jeszcze jakieś "CMC Digi Demo" czy jakoś tak. To już chyba nie w TA.
ZTCP w TA był patch playera CMC. Kto go znajdzie?
Jeśli chodzi o zapisanie gry z planszami, to robisz sobie czysty ATR wybierając Atari / Disk drives i tam New disk, następnie Single Density i Attach to drive 1. Później w Robbo Konstruktorze wybierasz co trzeba.
Jeśli chodzi o zapisanie plansz tak żeby można je później wczytać do Robbo Konstruktora, to niestety w Robbo Konstruktorze jest bug i nie należy używać jego opcji do tego służącej. Proponuję zapisać tzw. state emulatora.
eh, patrząc na temat posta pomyślałem, że Epi zmajstrował plejer MP3 na atarkę ;)
normalnie to GTIA realizuje przepisywanie ksztaltu ducha z pamieci RAM do odpowiednich rejestrow sprzetowych
Dla ścisłości: trzeba też włączyć adresowanie tej pamięci przez ANTIC. W innym przypadku dostaniemy podgląd szyny danych 6502.
aby umiescic w linii wiecej duchow o roznych ksztaltach trzeba wylaczyc z tego zadania GTIA, co wiaze sie ze strata czasu i totalnym brakiem oplacalnosci takiego rozwiazania, dlatego nie stosuje sie tego
Wyłączenie pobierania duchów z RAMu wcale nie wiąże się ze stratą czasu i brakiem opłacalności.
Jeśli chcemy mieć duże duchy, np. na szachownicę :), to właśnie to się stosuje.
A jaka jest dokładność tych kwarców? Tj. jakie są odchyłki między poszczególnymi egzemplarzami?
Tylko nie C++! :mad:
Obsługa obrazów dysków na poziomie sektorów to jedno, a obsługa zawartych tam systemów plików to drugie.
Nawet gdyby libatr obsługiwało tylko to pierwsze, dla formatów powiedzmy ATR, XFD, ATZ, XFZ, DCM i VAPI,
to i tak byłoby bardzo przydatne.
b write>=aaaa write<=bbbbustawi pułapkę zapisu do obszaru aaaa-bbbb.
Nie widzę w tym nic nadzwyczajnego. "rol" jest bardzo rzadko używaną instrukcją (szczególnie że nie ma odpowiednika w C), więc nie ma sensu jej optymalizować w sprzęcie. Za to użyte przeze mnie instrukcje są często spotykane i mogą być wykonywane równolegle w różnych potokach.
Większość RISCów pewnie nie ma wcale ROLa (przynajmniej nie 16-bitowego), więc trzeba robić podobnie kilkoma instrukcjami.
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, edxlibatr to mój pomysł :)
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.
Alex: większość zgłoszonych tu pomysłów na optymalizację nie zależy od platformy.
Jeśli chodzi o skompilowanie i poprawienie błędów, to napisałeś już do Kostasa?
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.
You begin your code with:
mva #14 $2c6 ;light
mva #8 $2c5
mva #4 $2c4
mva #0 $2c8 ;dark... and you wonder why the colors are different? :)
Piotr456: Podejrzyj źródło tego HTMLa. Przeglądarka pewnie Ci pokazuje "Ldx Dlist", a powinno tam być:
Ldx <DList
Ldy >DList- to oczywiście wpadka tego, co robił tę stronę.
Lizard: to był fragment listingu - zawartość linii obcięta po plusie a 0027 to nr linii.
Twój sposób nakłada na dostęp do każdego bajtu narzut: przesunięcie bitowe, odczyt z tablicy i and (x86 mają indeksowanie z dodawaniem dwóch rejestrów). Anda możnaby uniknąć odpowiednio modyfikując wartości w tablicy. Popatrz na mojego posta #23: dodatkowe operacje są dla każdego bajtu kodu 6502 i nie możesz używać
dostępu 16-bitowego (czyli zamiast instrukcji wczytującej 16 bitów mamy dwie instrukcje czytające po 8,
przesunięcie i dodanie).
Wygląda na to, że mój sposób 2 da się zrealizować przy pomocy funkcji mmap(). Wg wstępnych prób dopał nie jest powalający (ten mmap trochę trwa).
atari.area forum » Posty przez Fox
Wygenerowano w 0.064 sekund, wykonano 17 zapytań