Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

• Zapomniane hasło?
• Poproś o członkostwo

1. • 1: CommentAuthormrk
   • CommentTime25 Nov 2020 zmieniony

    
   Ostatnio w wolnym czasie sporo dłubię w Rust'owym silniku do gier Bevy (mam na koncie na przykład ->link<- - plugin bevy renderujący w przeglądarce w WebGl2) i port Robbo który kojarzycie pewnie z oddzielnego wątku). I jakoś przy okazji wpadłem na pomysł emulowania ANTIC'a na GPU (tworzymy wyspecjalizowany vertex / fragment shader, dajemy mu displaylistę ANTIC'a + pamięć ekranu i dostajemy wyrenderowany obraz, przy minimalnym obciążeniu CPU). Zrobiłem mały POC i jestem całkiem zadowolony z efektu :) ->link<- kod źrodłowy: ->link<-
   
   Nie wygląda to może na razie spektakularnie, ale renderowanie jest w całości na shader'ach - po uploadowaniu na GPU generatora znaków i fragmentu pamięci ekranu dostajemy powyższy output.
   
   Po rozbudowaniu i podpięciu gotowego emulatora CPU (na przykład ->link<- ale jest tego więcej) może powstać z tego całkiem sensowny wieloplatformowy emulator działający także w przeglądarce.
2. • 2:
      
     CommentAuthorKrótki
   • CommentTime25 Nov 2020

    
   Nie sądzę aby takie podejście miało sens. W Atari, jak i w większości komputerów i konsol 8/16/32-bit, procesor może modyfikować dane ekranu w trakcie gdy ten ekran jest generowany. Nie możesz sobie tak po prostu wziąć display listy i pamięci ekranu, i machnąć obrazek shaderem - bo generowanie obrazu należy przerwać co każde 4 piksele aby zaemulować 1 cykl programu procesora (nie wspominając o emulacji innych komponentów komputera). To żeby cokolwiek przyspieszyć, musiałbyś pewnie emulację CPU i reszty systemu też zaimplementować w shaderach, co chyba nie jest realne.
   
   Poza tym, przestrzegałbym przed hostowaniem plików binarnych chronionych prawem autorskim na GitHubie.
3. • 3: CommentAuthormrk
   • CommentTime25 Nov 2020 zmieniony

    
   Tak, zdaję sobie z tego sprawę, ale wydaje mi się że można spokojnie ograniczyć się do synchronizacji z przerwaniami DisplayListy'y. Czyli na przykład w takim Robbo z tego co wiem przerwanie jest w każdej linii trybu tekstowego i przełączany jest generator znaków - więc prawdopodobnie można by rysować całą linię trybu tekstowego na raz przy odpowiedniej synchronizacji. Dodatkowo to renderowanie można pewnie batchować jakoś, by faktycznie nie robić kilkuset draw calls per ramkę
4. • 4:
      
     CommentAuthorpirx
   • CommentTime25 Nov 2020

    
   zamiast `atari.rom` możesz wrzucić rom z altirra OS, jeśli Cię GPL nie męczy :]
5. • 5: CommentAuthormono
   • CommentTime25 Nov 2020

    
   Synchronizacja z DLI to za mało, bo można w dowolnej (prawie) chwili zrekonfigurować ANTIC i GTIA zmieniając choćby kolory, czy sprajty (położenie, rozmiar, priorytet, kształt). Albo np. tryb GTIA w rastrze.
6. • 6: CommentAuthormrk
   • CommentTime25 Nov 2020 zmieniony

    
   Fakt, zapomniałem że wrzuciłem ROM też. Ok, wywalam z repo, dzięki. I faktycznie alternatywny z altirry może być dobrym pomysłem
   
   EDIT: Ok, podmieniłem na ROM z altirry, dzięki za zwrócenie uwagi.
7. • 7:
      
     CommentAuthortdc
   • CommentTime26 Nov 2020 zmieniony

    
   A ja przypomnę, że w czasach Atari Magazynu pojawił się nowy komputer Atari Falcon - więc zastanawialiśmy się nad tym, że jego architektura właśnie idealnie odpowiada koncepcji małego Atari - czyli 6502 można emulować na M68030 a ANTIC można emulować wyłącznie na DSP. Jest to z wielu względów lepsze rozwiązanie niż GPU dzisiejszych pecetów.
   
   Pytanie było następujące, czy DSP Falcona da radę uciągnąć emulację ANTICa w czasie rzeczywistym. Mieliśmy co do tego poważne obawy bo jeszcze nie był znany potencjał jaki daje faktyczna moc tego DSP. Przykładowo wiadomo było jedynie że ma 32 MHz, jednak trudno było się domyślać co to może oznaczać. Dopiero potem okazało się, że DSP pracując na swojej pamięci osiąga duże prędkości - o wiele większe niż zakładaliśmy, oraz nieco później dowiedziałem się, że odpowiednio napisany program DSP daje wykonanie 1 rozkazu w 1 cyklu, czyli przekłada się 32 MHz na 32 miliony wykonanych operacji. Wtedy to była naprawdę nieprawdopodobna wydajność - wprost niewyobrażalna, bo przykładowo pecety miały wtedy np. 486 taktowane zegarem 32 MHz ale nie przekładało się to na jego faktyczną wydajność, która była marna. Jednak w Falconie to było coś!
   Dziś znamy efekt z różnych gier i dem;)
   
   Dużo o tym rozmawiałem w redakcji z KMK. On jako posiadacz Falcona poważnie brał pod uwagę napisanie takiego emulatora. O ile wiem to faktycznie zaczął taki robić, coś też kombinował z jakimś innym autorem, ale koniec końców nic z tego nie wyszło.
   Czyli kwestia emulacji ATNICa na DSP do dziś czeka na kodera, który chce fajnie spędzić czas przed Falconem;) Oraz jak to faktycznie wypadnie wydajnościowo - bo tego cały czas nie jestem pewien - bo z szacunków wychodzi tak na styk;)
   Ktoś chętny?;)
8. • 8:
      
     CommentAuthorKrótki
   • CommentTime26 Nov 2020

    
   @mrk: Myślę że ogólnie gra nie będzie warta świeczki, bo zamiana danych w pamięci na piksele obrazu to jest wydajnościowo bardzo mała część całej emulacji komputera. Można na GPU zrzucić temat korekcji proporcji ekranu albo generowania artefaktów NTSC/PAL, tak jak to robi np. Altirra, ale samo generowanie "bazowego" 256-kolorowego obrazka to raczej zadanie dla CPU.
   
   

   pirx:

   zamiast `atari.rom` możesz wrzucić rom z altirra OS, jeśli Cię GPL nie męczy :]

   
   Akurat AltirraOS jest na niecopyleftowej licencji:
   "Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty."
   (Zob. nagłówki plików źródłowych w src/Kernel/source.)
   
   

   tdc:

   Jest to z wielu względów lepsze rozwiązanie niż GPU dzisiejszych pecetów.

   
   Zawsze gdy TDC wchodzi w rolę orędownika wyższości Atari nad <enter name here>, to korci mnie żeby poprosić o pokrycie wypowiedzi argumentami. No więc, TDC-u, z jakich względów DSP Falcona jest lepszy od współczesnych GPU? Nie licząc być może mniejszego śladu węglowego.
9. • 9:
      
     CommentAuthorCyprian
   • CommentTime26 Nov 2020

    

   tdc:

   odpowiednio napisany program DSP daje wykonanie 1 rozkazu w 1 cyklu, czyli przekłada się 32 MHz na 32 miliony wykonanych operacji

   
   
   To zależy.
   Tutaj przykład trzech instrukcji:
   

   MACR  X0,Y0,A    X:(R0)+,X0      Y:(R4)+,Y0

   
   Mnożenie, ładowanie danych z pamięci do rejestru X0, ładowanie danych z pamięci do rejestru Y0.
   
   Całość wykona się w jednym cyklu jeżeli rejestry R0 i R4 wskazują na pamięć wewnętrzną;
   W dwóch cyklach jeżeli R0/R4 wskazują pamięć zewnętrzną.
10. • 10: CommentAuthorilmenit
    • CommentTime26 Nov 2020

     
    Zgadzam się z Krótkim, emulacja CPU na GPU wymaga liniowego wykonania kodu i synchronizacji z innymi emulowanymi układami i cały zysk z mocy zrównoleglenia operacji na GPU się traci.
11. • 11:
       
      CommentAuthorKrótki
    • CommentTime26 Nov 2020

     
    Jest to też powodem dla którego praktycznie cała emulacja Atari (w Altirrze i w Atari800) wykonuje się na jednym rdzeniu procesora: bo uwielowątkowienie spowodowałoby pogorszenie wydajności, z uwagi na konieczność synchronizacji wątków miliony razy na sekundę. W związku z tym w osobnych wątkach wykonywane są tylko czynności bardzo poboczne, jak np. odtwarzanie dźwięku czy efekty artefaktów właśnie.
    
    W teorii jest możliwe sensowne zrównoleglenie emulacji, np. w taki sposób: główny wątek generuje nie nie tyle gotowy 256-kolorowy obraz, lecz tylko "program" do generowania obrazu, tzn. zapisuje sobie taką listę zdarzeń:
    - w takim a takim punkcie ekranu nastąpiła zmiana koloru,
    - w takim a takim punkcie ekranu nastąpiło przesunięcie duszka,
    itd.
    
    A osobny wątek generowałby na podstawie takiego "programu" właściwy obraz. Wówczas synchronizowanie wątków byłoby konieczne tylko raz na ramkę.
    
    Ale nikt tego tak jeszcze nie zaimplementował, więc jest niesprawdzone ryzyko, że generowanie ww. "programu" może się okazać tak samo lub bardziej złożone obliczeniowo niż po prostu wygenerowanie 256-kolorowego obrazka.
12. • 12:
       
      CommentAuthorlaoo
    • CommentTime26 Nov 2020

     
    @Krótki W praktyce główny wątek musiałby też załatwiać DMA żeby przesyłać wszystkie bajty jakie zasysa ANTIC. W takim scenariuszu robota dla tego drugiego wątku byłaby bardzo mała, a koszt generowania takiej pośredniej listy komend/danych wydaje mi się, że niekoniecznie mniejszy niż wygenerowanie obrazu bezpośrednio - lista komend byłby dość duża, a jak wiemy współczesne procesory zużywają najwięcej czasu nie na obliczeniach tylko na dostępie do pamięci i koszt dostępu do niej mógłby przeważyć delegowanie część pracy na równoległy rdzeń.
    
    Ogólnie o tym pomyśle już myślałem kilka razy (i o GPU i o kilku wątkach) i rezultat rozmyślań był zawsze negatywny. Zresztą jako autorytet może posłużyć to Phaeron - jeśli on nie zrównoleglił Altirry to nikt nie zrównolegli :)
13. • 13:
       
      CommentAuthorKrótki
    • CommentTime26 Nov 2020

     
    Aaa i jeszcze należy pamiętać, że komunikacja (tak to nazwijmy) "komputer->obraz" nie jest jednokierunkowa, bo podczas generowania obrazu dostajemy informację o kolizjach P/MG, która powinna natychmiast "wrócić" do CPU.
    
    Apropos Phaerona - on nawet kiedyś wykładał na forum swoje argumenty przeciwko zrównoleglaniu, z konieczności identyczne z powyższymi. Ale w ogólności ja tam bym nie traktował go jako absolutnej wyroczni - niektórych rzeczy w emulatorze nie zrobił, bo jeszcze nie miał na to czasu albo go nie interesowały, a nie dlatego że się nie da.
14. • 14: CommentAuthormrk
    • CommentTime26 Nov 2020 zmieniony

     
    Ok, dzięki za masę wskazówek, po prostu sprawdzę to sobie stopniowo w praktyce (najpierw chcę umieć poprawnie wygenerować statyczną grafikę ze statycznej displaylisty / statycznych rejestrów / ramu), podpięcie CPU potem. Całość kompilowana do WASM, postaram się wrzucać linki do kolejnych iteracji.
    Właśnie napisałem prosty parser plików stanu emulatora atari800 ->link<- i oglądam sobie displaylistę planszy tytułowej Robbo :]
15. • 15: CommentAuthorastrofor
    • CommentTime26 Nov 2020

     
    hmm może to niekoniecznie bylo by dobre narzedzie do emulacji np gier, ale moglo by powstac narzedzie do konwersji obrazkow z pc, oparte na gpu, czyli z mozliwocia wykorzystania tensorflow, czyli konwersja obrazkow nie trwala by juz godzin jak teraz. Z drugiej strony jezeli tego do tej pory @ilmenit nie napisal to zadanie delikatnie mowiac jest nietrywialne ;)
16. • 16: CommentAuthortebe
    • CommentTime26 Nov 2020

     
    innymi słowy, nie wiesz dokąd Cię to zaprowadzi, testuj, eksperymentuj, zdobędziesz wiedzę i doświadczenie
17. • 17: CommentAuthorastrofor
    • CommentTime27 Nov 2020

     
    o

    • Screenshot 2020-11-27 at 00.17.00.png
      
      
      
      
18. • 18:
       
      CommentAuthorAlex
    • CommentTime27 Nov 2020

     
    Dodając swoje "trzy grosze" powiem, że szkoda czasu. Koledzy mają rację. GPU nijak nie nadaje się do uproszczonego generowania obrazu w emulatorze. Procesor, choć za szybki nie jest, może pisać po rejestrach w trakcie rysowania linii. Czasem mamy takie "kwiatki", jak nieudokumentowana możliwość zmiany trybu graficznego w linii czy ściganie duszków. Jak to chyba napisał kiedyś autor Altirry, ANTIC jest głównym procesorem w Atari, który de facto zarządza resztą i na nim powinna opierać się emulacja. Trudno jest mi się z nim nie zgodzić :)
19. • 19: CommentAuthorilmenit
    • CommentTime27 Nov 2020

     
    Ja się zgodzę tu z Tebe - jeżeli temat zrobienia emulatora na GPU jest dla mrk ciekawy, niech go rozwija! Nawet jeżeli nie uzyska w ten sposób wyników lepszych niż działanie na 1 core CPU, to co się przy tym nauczy wykorzysta potem w przyszłych projektach, czy związanych z Atari, czy z interpreterami, czy z programowaniem GPU.
20. • 20:
       
      CommentAuthortdc
    • CommentTime27 Nov 2020 zmieniony

     

    Krótki:

    Zawsze gdy TDC wchodzi w rolę orędownika wyższości Atari nad <enter name here>, to korci mnie żeby poprosić o pokrycie wypowiedzi argumentami. No więc, TDC-u, z jakich względów DSP Falcona jest lepszy od współczesnych GPU? Nie licząc być może mniejszego śladu węglowego.

    
    
    Źle mnie zrozumiałeś, nie miałem na myśli wyższości DSP nad GPU współczesnych pecetów. Chodziło mi o adekwatność Atari Falcon jako spójnego wewnętrznie sprzętu, który został zaprojektowany właśnie do takich rzeczy;)
    
    Swoją drogą to bardzo ciekawe, że rola DSP w Falconie jest właściwie identyczna do tego co daje dziś GPU w PC - czyli posiadacze pecetów mają od niedawna coś co na Atari było zupełnie naturalne od 1991/1992 roku;))
    
    
    

    Cyprian:

    Mnożenie, ładowanie danych z pamięci do rejestru X0, ładowanie danych z pamięci do rejestru Y0.
    
    Całość wykona się w jednym cyklu jeżeli rejestry R0 i R4 wskazują na pamięć wewnętrzną;
    W dwóch cyklach jeżeli R0/R4 wskazują pamięć zewnętrzną.

    
    No właśnie!;)
    Fajnie, że to tutaj przytoczyłeś.
    
    Pamiętam, że właśnie wprowadzenie PowerPC w latach 90. to było wielkie wydarzenie, Atarowcy planowali używać tych procesorów, a Amigowcy naprawdę zaczęli używać. Wtedy takie to było NIESAMOWITE, że współczynnik wykonanych rozkazów na cykl zegarowy może być mniejszy niż 1 CPI - wtedy szok!;)
    
    Tylko tak jak mówiłem atarowcy tu w Polsce (i pewnie na świecie), nie byli świadomi tego jak fantastyczny sprzęt mają do dyspozycji, no ale skąd mieliśmy taką wiedzę wtedy brać? Było jak było... Właśnie pamiętam z tamtych czasów że chcieliśmy wierzyć, że w falconowym DSP może to wynosić 1 CPI, a o tym że może to być mniej to nikt nie marzył;))
    
    Choć w domu u KMK widziałem, że miał ogromnie gruby podręcznik do DSP. Zaświeciły mi się oczy na ten widok!;)
21. • 21:
       
      CommentAuthorKaz
    • CommentTime27 Nov 2020

     
    Astrofor - dobre :D. A brwi powinny się jeszcze układać w znak JIL :D
22. • 22: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    Pomimo tylu sceptycznych głosów cisnę dalej: ->link<-
    
    Kilka słów co się tu dzieje:
    * Render jest robiony w całości na GPU, jeden draw-call na jedną linię DisplayListy - więc bardzo opłacalna sprawa w szczególności dla trybów tekstowych. Program wysyła do GPU dane pamięci ekranu danej linii, rejestry kolorów, bufor z generatorem znaków, resztę robi już shader. Co więcej - jeżeli na kolejnych pozycjach DisplayListy nie ma ustawionego przerwania IRQ i jest ciągła pamięć ekranu można pomyśleć o rysowaniu tych wszystkich linii na raz - w tym konkretnym przypadku dało by się pewnie zejść do 3 "draw calls" na ramkę.
    * Dane wejściowe to plik state z atari800 - zrzut pamięci i snapshot rejestrów ANTIC'a / GTIA
    * Na razie jest to emulacja samego ANTIC'a (a tak naprawdę bardzo małego podzbioru potrzebnego do wyrenderowania tej konkretnej display listy: tryb tekstowy 0x2 i graficzny 0xa). Przekłamania kolorów oczywiście z powodu braku procesora do obsługi DLI :)
    * Pomimo że ten render wygląda statycznie, to na zintegrowanej grafice Intel jest u mnie stabilne 60FPS i jakieś 30% zużycia CPU (jeśli chodzi o redukcję obciążenia CPU to można sporo jeszcze wycisnąć, na razie nie skupiałem się na robieniu żadnych optymalizacji ofc)
    
    Zaimplementowanie reszty trybów graficznych powinno być już banalne, sprzętowego HSCROLL / VSCROLL'a też. Największym wyzwaniem będzie oczywiście pożenienie tego z emulatorem CPU i zrobienie synchronizacji z ANTIC. Ale jak widzę taką dokumentację jak: "Altirra Hardware Reference Manual" ->link<- to jestem optymistą :)
    
    I jestem prawie pewny że Robbo i inne porządnie napisane gry będą się dobrze na tym renderowały, pomimo synchronizacji CPU z ANTIC'iem z dokładnością do linii a nie pojedynczych cykli zegara. Stay tuned ;)
23. • 23:
       
      CommentAuthorpirx
    • CommentTime27 Nov 2020

     
    piękne! no i jakbyśmy robili tylko to, co ma sens, to w ogóle nie byłoby demosceny i tego sajtu też :)
24. • 24: CommentAuthorbob_er
    • CommentTime27 Nov 2020

     
    Jeśli nie obsługujesz zmian parametrów (kolory, tryby, ...) w środku linii, to mimo wszystko całkiem sporo rzeczy będzie działać.
25. • 25: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    @bob_er - mało kto zmienia kolory w środku linii by wpływać na wygląd właśnie wyświetlanej linii IMHO - generalnie powinno się to robić przed wyświetleniem danej linii. I wtedy spokojnie powinno to działać.
26. • 26: CommentAuthorbob_er
    • CommentTime27 Nov 2020

     
    Zmian rejestrów w linii używa się do zwiększenia liczby kolorów w linii w zasadzie na wszystkich platformach 8- i 16- bitów (jak już tutaj w wątku napisano). Na XE dodatkowo można zmieniać tryb graficzny, ale działa to tylko z trybami GTIA.
    Najbardziej popularny jest G2F i jego pochodne. Kilka(naście/dziesiąt) dem też używa tej techniki, a gra żadna mi do głowy nie przychodzi.
27. • 27: CommentAuthorilmenit
    • CommentTime27 Nov 2020

     
    Nawet gdyby zignorować zmiany rejestrów kolorów w linii, w jaki sposób chcesz zrobić obsługę np. DLI? To już jest w bardzo wielu grach do zmiany kolorów czy charsetu.
28. • 28: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    @ilmenit - jasne, DLI musi działać, widać to zresztą bardzo dobrze nawet na tym startowym ekranie z Robbo. I wydaje się dość proste do zaimplementowania. Przeplatasz po prostu renderowanie pozycji z DisplayListy i emulację CPU, na przykład jedna linia trybu tekstowego 2 i wyliczona odpowiednio na podstawie ilości scanlines dla tej linii ilość cykli procesora. Przy takim podejściu powinno się udać podawać IRQ tak często jak trzeba. Oczywiście będzie niezła zabawa z dobraniem odpowiedniej ilości cykli (by uwzględnić na przykład cykle podkradane procesorowi przez ANTIC'a) ale powinno być robialne.
29. • 29: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    Jest jedna rzecz której zaimplementowanie wydaje się deko trudne przy tym podejściu - mianowicie emulacja sprzętowego wykrywania kolizji PM (o czym wspomniał @Krótki wyżej) Wydaje mi się że będzie można to też robić w programie shader'a, ale nie myślałem jeszcze jak (i na starcie wydaje się że można to spokojnie odpuścić. BTW orientuje się ktoś jak bardzo popularne było / jest używanie tych kolizji w praktyce?)
30. • 30:
       
      CommentAuthorpirx
    • CommentTime27 Nov 2020

     
    w starych grach było bardzo pop, bo miały często pusty playfield, dodatkowo to był podstawowy modus operandi na VCS i ludzie tego używali. W nowszych prodkach mniej, bo tło bardziej skomplikowane, sprajty software'owe itp.
    Ale np.

    by się bez kolizji nie udało w 10 linijkach :]
31. • 31: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    @pirx hehe, zdecydowanie nie jestem na bieżąco jeżeli chodzi o nowsze rzeczy (nowsze, czyli powstałe po 1990 roku ;)
    Ekran rozumiem w trybie antic 4 i chyba nie trzeba DLI specjalnie? Idealny kandydat do renderowania na GPU, tylko trzeba te kolizje nieszczęsne jakoś ogarnąć :)
    
    EDIT:jest chyba jedno DLI przełączające charset
    EDIT2: w sumie chyba można zrobić multi-mode charset zawierający rury i te znaki do score :)
32. • 32:
       
      CommentAuthorpirx
    • CommentTime27 Nov 2020

     
    nie ma dli, to czysty basic :]
33. • 33: CommentAuthormrk
    • CommentTime27 Nov 2020 zmieniony

     
    Ostatni dzisiaj update.
    Nie wytrzymałem i dodałem emulator CPU - na razie tylko by zobaczyć czy da się pociągnąć emulację w przeglądarce. Dla zainteresowanych kod: ->link<- - niesamowite jest to, że da się dzisiaj takie rzeczy zrobić w pół godziny w kilkudziesięciu linijkach kodu.
    
    I rezulaty są bardziej niż zadowalające. Emulator 6502 wykonuje cały czas prostą, aktywną pętlę (NOP/JMP), w każdej ramce wykonywane jest 35568 cykli procesora (przepisana z manuala Altirry ilość cykli na ramkę dla PAL), więc całość chodzi 20% szybciej niż fizyczne Atari (bo 60FPS a nie 50 jak w PAL) - poprawcie mnie jak coś poknociłem w tych wyliczeniach. I teraz najlepsze - przy 60FPS zużycie procesora raportowane przez przeglądarkę ok. 30%. Spróbuję jeszcze rozbudować nieco ten benchmark, ale nie sądzię by wiele to zmieniło.
    
    Uaktualniona wersja tu: ->link<- - do logów (DeveloperTools w chrome / firefox) wrzucam ilość ramek / cykli cpu od początku uruchomienia (dodałem logowanie bo myślałem że emulacja cpu po prostu nie działa).
34. • 34: CommentAuthormrk
    • CommentTime29 Nov 2020 zmieniony

     
    Emulator CPU wykonuje już prawdziwy kod Atari, po dobie debugowania jest prawie dobrze :)
    
    ->link<-
    
    Kilka szczegółów technicznych:
    * zaimplementowane przeplatanie CPU i programu ANTIC'a (114 cykli procesora na scanline)
    * zaimplementowane przerwanie VBI, na razie brak DLI
    * brak DLI nie przeszkadza w poprawnym zmienianiu kolorów w trakcie ramki w powyższym demku, bo poprawnie działa rejestr VCOUNT
    * wydzielone oddzielne moduły dla ANTIC, GTIA, POKEY i PIA (w POKEY musiałem zaimplementować rejestr RANDOM, by kolory w powyższym demku poprawnie się zmieniały :)
    
    W dalszej kolejności chcę się przerzucić ze snapshot'a Robbo na jakieś demo - może macie jakieś propozycje?
35. • 35:
       
      CommentAuthorjhusak
    • CommentTime29 Nov 2020

     
    No no no... Jestem pod wrażeniem. To jak zadziała demko 3 tryby graficzne w jednej linii, będzie święto!
    Na Firefoksie/OSX Mojave działa, na Safari niestety nie.
    
    @Krotki, widzisz, zawsze znajdzie się ktoś, kto nie wie, że się nie da. I zrobi to.
36. • 36:
       
      CommentAuthorKaz
    • CommentTime29 Nov 2020

     
    Ha ha, nieźle panie mrk. Fajnie, że wziąłeś na tapetę Robbocika :D

    • emulated_robbo.jpg
      
      
      
      
37. • 37: CommentAuthormrk
    • CommentTime29 Nov 2020 zmieniony

     

    jhusak:

    Na Firefoksie/OSX Mojave działa, na Safari niestety nie.

    
    Przeglądarka musi wspierać webgl2, a Safari niestety standardowo jeszcze tego nie robi. Podobno webgl2 jest dostępny jako experymentalny feature i da się jakoś odblokować.
    WebGL2 dobrze chodzi też w Chrome (u mnie pod linuksem dużo lepiej niż Firefox)
    
    

    Kaz:

    Fajnie, że wziąłeś na tapetę Robbocika :D

    
    Akurat wybór softu do testów był dla mnie oczywisty :) Uruchomienie pełnej gry jest bardzo blisko. Właśnie przed chwilą dopisałem obsługę trybu 4 - niestety w samej grze jest już potrzebna obsługa DLI do przełączania charset'ów (jak przeleci instrukcja robbo wyświetla migawki leveli - widać co prawda kaszę na razie, ale za to płynnie animowaną - właśnie uploadowałem uaktualnioną wersję więc można się przekonać osobiście).
38. • 38:
       
      CommentAuthormgr_inz_rafal
    • CommentTime29 Nov 2020

     
    Jak to mówi pewien znany, amigowy celebryta: "Eleganckowość i stabilizacja!".
39. • 39:
       
      CommentAuthorjhusak
    • CommentTime29 Nov 2020 zmieniony

     
    WebGL2.0 jest owszem w Safari eksperymentalny, odblokowanie go daje zamiast pustej strony czarny ekran emulatora, ale nic więcej. Jeszcze próbuję odblokować wszystko.
    --edit--
    odblokowanie wszystkiego nie zadziałało.
    Ja bym na koniec prosił o artykuł, jak takie cudo się robi kroczek po kroczku, linki, narzędzia, itepy.
40. • 40: CommentAuthortebe
    • CommentTime30 Nov 2020

     
    ten tryb 4 z przełączaniem charsetów to tryb 4+ lub JGP od Jet Graphics Planner, Avalon wprowadził ten tryb na salony ;)
    
    ->link<-
    
    ->link<-
41. • 41: CommentAuthormrk
    • CommentTime30 Nov 2020 zmieniony

     
    @tebe - co ciekawe jak się okazuje Robbo używa zwykłego trybu 4 - czyli charset nie jest podmieniany co drugą linię. Co daje tylko 32 'kafelki' 2x2 do wykorzystania. Wystarczy, jeżeli się przedefiniowuje znaki na bieżąco. Widać to w ogóle dobrze w przeglądarce jak się włącza demo - nie widać animowanych elementów np robbo, strzały, promienie lasera / NPC - prawdopodobnie te znaki są wkopiowywane do generatora znaków w miarę potrzeby (odpowiednia klatka animacji) - a mój emulator na razie używa statycznej kopii pamięci do generowania znaków.
42. • 42: CommentAuthorilmenit
    • CommentTime30 Nov 2020

     
    @mrk - bardzo fajnie to działa. Podobnie jak jhusak też jestem ciekawy jak do tego podchodzisz od strony programowania (narzędzia, jaki emulator CPU używasz).
43. • 43:
       
      CommentAuthorKrótki
    • CommentTime30 Nov 2020 zmieniony

     

    jhusak:

    @Krotki, widzisz, zawsze znajdzie się ktoś, kto nie wie, że się nie da. I zrobi to.

    
    Ale czy ja twierdzę że się nie da?
    
    Ja się po prostu martwię o ślad węglowy tego emulatora, gdy już osiągnie dokładność emulacji na poziomie poczciwego XL-it! z 1997 r.
44. • 44:
       
      CommentAuthorjhusak
    • CommentTime30 Nov 2020 zmieniony

     
    Haha! Ślad najczęstszego stałego (w temp. pokojowej) pierwiastka we wszechświecie! To tak, jakby to, że oddychasz i wydychasz (m. in.) parę wodną powodowało efekt cieplarniany :D (ojoj, żebym nie podpowiedział komuś, kto to podchwyci).
    
    <żart mode on>
    Chociaż maszyny parowe zostały wycofane ze względu na generowanie gazów cieplarnianych, głównie pary wodnej właśnie. i zastąpione bezpiecznymi spalinowymi.
    <żart mode off>
45. • 45: CommentAuthormrk
    • CommentTime30 Nov 2020 zmieniony

     
    @Krotki - bez obaw, nie zamierzam się ścigać w jakości emulacji z taką Altirrą (ostatnio sporo wertowałem Altirra Hardware Reference Manual - jeżeli autor faktycznie zaimplementował wszystko co tam opisał (na przykład masę hardware'owych bugów) to jest to na pewno niedościgniony wzór). Natomiast po tych paru dniach jestem już pewny że jest miejsce dla emulatora działającego w przeglądarce, nawet jak będzie w stanie uruchomić poprawnie tylko 90% atarowskiego softu.
46. • 46: CommentAuthormrk
    • CommentTime30 Nov 2020

     
    @ilmenit @jhusak ok, postaram się coś napisać (na pewno zacznę od wrzucenia po prostu README do projektu z opisem jak emulator zbudować i uruchomić lokalnie)
47. • 47: CommentAuthormrk
    • CommentTime30 Nov 2020 zmieniony

     
    Panie i Panowie - zapraszam do pyknięcia kilku leveli Robbo prosto w przeglądarce: ->link<-
    
    Oczywiście brakuje dźwięku oraz emulacji VSCROLL'a, więc obraz trochę skacze przy scrollowaniu, ale IMHO jest całkiem grywalnie :)
48. • 48: CommentAuthorastrofor
    • CommentTime1 Dec 2020

     
    @mrk: Czy mi sie wydaje czy to już trzecie przeglądarkowe robbo które wprowadziłeś przez ostatnie kilka dni ? 1rust, 2Bevy game engine , i teraz 3we włąsnym emulatorze ?
49. • 49: CommentAuthormrk
    • CommentTime1 Dec 2020

     
    @astrofor prawie się zgadza. Porządkując nieco:
    * wszystkie wersje są w RUST i wszystkie używają Bevy Game Engine (łącznie z emulatorem)
    * wersja ASCII powstała trochę jako żart, jak Bevy nie umiał jeszcze renderować w przeglądarce do WEBGL2
    * Wersja WebGL2 to ten sam kod co w wersji ASCII, tylko wykorzystujący wtyczkę renderującą do WebGL2 ->link<-
50. • 50: CommentAuthorilmenit
    • CommentTime1 Dec 2020

     
    Nawet jeżeli emulator nie będzie doskonały, to bardzo brakuje na Atari emulatora dostępnego online, który by można wrzucić na stronę jakiegoś projektu i dać możliwość np. zagrania w grę bezpośrednio w przeglądarce. Jest jsA8E, ale nie jest rozwijany. Ja ten projekt będę wspierał, choć jest to bardzo długa droga, gdy spojrzeć co wszystko jest do implementacji ->link<-