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: CommentAuthormarok
   • CommentTime28 Oct 2022 10:10

    
   65816 - czy się *u nas* programuje pod ten procesor? (>1 *men*)
   {Apropo, temat mocno nadający się pod szeroką, nieco dyletancką(?), bo polegającą bardziej na wyobrażeniach i odczuciach, deskusję - taką akurat "pod forum", tj. dzielenia i kształtowania opinii, ale potencjalnie też inspirującą i pobudzającą własną ciekawość przedmiotu.}
   
   
   Jak się właśnie zorientowuję, w Japonii rozwijano procesory na bazie 65c02 w interesującym kierunku (cała rodzina mikroprocesorów i mikrokontrolerów "740" i pokrewnych; ciekawość "bynajmniej" nie ogranicza się u mnie do tego, ale szczególna uwaga: MUL i DIV w 16(+4) cykli).
   
   Jeśli chodzi o "różnej maści" procesory "z epoki" i ich warsztatowe opanowanie (czy zapoznanie już) znalazłem na pewno pomocną, wartościową, godną polecenia stronę: ->link<-
   
   Tak apropo niej (oto tak reklamuję), z tutoriala dla 6502 jest wzmianka jak zrobić "podmiankę" obu nibble w bajcie (miejcami) za pomocą "zastępczego" kodu (na co wcześniej sam nie bardzo wpadłem, a może okazać się przydatne zwłaszcza do obsługi i przekształceń danych graficznych na atari).
   
   asl @
   adc #$80
   rol @
   
   .. razy dwa, powyższa sekwencja.
   
   
   Informacja dot. istnienia i dostępności, o wszelkich symulatorach procesorów z epoki byłaby interesująca dla mnie (ciężko mi wypatrzeć samemu). Debugger ma z lekka inną specyfikę działania, ale w zasadzie można (w wielu przypadkach) nim się posłużyć w zastępstwie symulatora.
   A z tych, najchętniej widziałbym 65816 (68c02?), 740x (mnogo ich, jak się okazuje identycznych co do opkodów, o różnej numeracji), 65e02 (ukłony dla Voy'a - art/ przedruk w "Serious").
   
   Rozumiem, w związku z powyższym życzeniem, że można z powodzeniem posłużyć się debuggerem z poziomu monitoru emulatora, ale też nie jestem w tej materii zorientowany (aktualnie nie korzystam, z przyczyn w zasadzie nawet obiektywnych, z emulatorów atari). Z tego co zdaje mi się gdzieś informacja mi się przewinęła, zarówno Altirra (od którejś wersji) jak i być może Atari++ debugują kod 65816.
2. • 2: CommentAuthormono
   • CommentTime28 Oct 2022 10:10

    
   Draco i Święty programują 816. Ktoś coś kombinował drzewiej z Motorolą 6809 chyba.
3. • 3: CommentAuthortebe
   • CommentTime28 Oct 2022 10:10

    
   Altirra wspiera 65816 (Rapidus)
   
   jest emulator ZX Spectrum napisany przez Draco
   
   player MOD-ów w Mad Pascalu, ze wstawkami ASM dla 65816
   ->link<-
4. • 4: CommentAuthormono
   • CommentTime28 Oct 2022 12:10

    
   To jest Pascal, to się nie liczy :D
5. • 5: CommentAuthorpin
   • CommentTime28 Oct 2022 13:10

    
   @tebe - ten player na real hw gra źle.
6. • 6:
      
     CommentAuthorCyprian
   • CommentTime28 Oct 2022 14:10 zmieniony

    

   marok:

   Jak się właśnie zorientowuję, w Japonii rozwijano procesory na bazie 65c02 w interesującym kierunku (cała rodzina mikroprocesorów i mikrokontrolerów "740" i pokrewnych; ciekawość "bynajmniej" nie ogranicza się u mnie do tego, ale szczególna uwaga: MUL i DIV w 16(+4) cykli).
   

   
   Fajny jest ten procesor, ciekawe czy zadziałałby w Atari
   ->link<- en.wikipedia.org/wiki/Mitsubishi_740
7. • 7: CommentAuthormarok
   • CommentTime28 Oct 2022 15:10

    
   Gwoli ścisłości - o playerze do MOD-ów w tym kontekście dotąd nie słyszałem…
   { taki player to użyteczna, pierwszorzędna robota swoją drogą - dzięki relacji video z ostatniej "Grawitacji" - trochę looknąłem - byłem w stanie się o tym osobiście jakoby przekonać }
   
   Pozwolę sobie w tym momencie na odrobinę gawędziarstwa i drobnej spekulacji (moja "inklinacja" do podobnych).
   
   Sprawa 65816 wygląda podobnie jak przy VBXE (oględnie: znikoma ilość unikalnych zastosowań).
   
   Co można było zrobić (ewewntualnie, można jeszcze)?
   
   - Jakaś cykliczna produkcja "scenowa" ala zin (wiadomo że na niezłym poziomie), przyciągająca uwagę i trochę wyglądana (nieobojętna).
   
   
   Uważam, że 65816 nie jest oczywisty (inaczej: wymagający na wstępie przez pewne swoje skomplikowanie i odmienność), jak mógłby może być jakiś inny procesor typowo tylko "dozbrojony" użytecznymi istrukcjami, ale nadal 8-bit (np. 65e02) bez szczególnie egzotycznych trybów adresowych (bo może i w tym jest trochę "pies pogrzebany"). To stwarza poważną już barierę (przynajmniej dla "średniaków") "psychologiczną". Pisząc, trochę po sobie, można się go z jednej strony trochę obawiać (czy sobie dałbym radę w opanowaniu), z drugiej nie do końca w pełni być przekonanym do jego walorów (w kontekście porównywania z "alternatywami", nawet takimi tylko do wyobrażenia: co taki procek powinien w repertuarze posiadać, gdybyśmy mieli na to wpływ - taka sfera marzeń, do której czasem możemy się odnosić w kontekście kształtowania naszego nastawienia do 65816).
   Wiadomo, że pierwszorzędną przewagą (która mogłaby z racjonalnego punktu widzenia zamykać kwestię wszelkich wątpliwości) tego procesora w relacji z atari do innych jest to, że jest on opracowany i w pełni wdrożony do systemu (od strony systemowego kodu na atari wiadomo komu to się zawdzięcza, więc nie wspominam, acz jak najbardziej doceniam - inaczej nie sposób) - gotowy i "czekający". Ale człowiek bywa malkontentem i szuka sobie różnych wymówek (psychologicznych, takich sam dla siebie, racjonalizuje tak, bywa, swoją niechęć do podjęcia znów nie tak banalnego dla siebie wyzwania).
   Brakuje może więc takich dodatkowych impulsów (nie wspominam o: czasu, rozumu, bo to różnie z tym ma prawo być i wyglądać - i trudno, nioc się nie poradzi na takie).
   No bo i wypowiadający się w tym wątku TeBe zrobił dużo (MADS) aby również ułatwić wykorzystanie tego procesora do zastosowań w atari (choć w oderwaniu od niego, na co niektórzy z nas są "skazani"), o czym wiem i wspominam dla samej "przyzwoitości" (o "zasłużonych" w hardware już nie piszę - wybaczcie - z tej jednakowoż przyczyny, że wszystiego i klarownie "ni znaju mienia").
8. • 8: CommentAuthormarok
   • CommentTime28 Oct 2022 15:10

    
   @Cyprian:
   "Piewsze primo" - mamy co mamy (65816), chyba nie powinniśmy już szukać niczego (chyba że jako kooprocesor do czego te procki mogą się podejrzewam nadawać). Drugie primo, te procesorki nie są już produkowane (dostępność). Kwestia samego zagadnienia czy procek jest rewelacyjny czy z uwagi na coś istotnego - bardziej do niczego, to poza pierwszym wrażeniem, które zawsze ma prawo być na super (mając przesłanki), ważna jest wnikliwa ocena pewnej komplementarności całości zestawu instrukcji (i jakoś też elektroniki). Czy instrukcje w oferowanych trybach adresowych sumarycznie stanowią taką całość, która ułatwia zmaganie w tworzeniu kodu o możliwie (i wszechstronnie) skomplikowanych założeniach, czy są jakieś poważne w tym braki, niedostatki, przeoczenia (a może też jakieś nieoczekiwane bugi - wyjątki, niekonsekwenje - w działaniu się objawiają). Aby to ocenić samemu (nie opierając się na czymś pewnym) trzeba by się pobawić w tworzenie jakiś zadań programistycznych, "w boju" to spradzić. Do tego nadawałby się nieźle (pozostawiając pewną dozę niepewności na nieoczekiwane różnice w stosunku do imitowanego działania real chipu) jakiś symulator albo jakieś środowisko emulatorskie. Z tym bywa trochę ciężko, jeśli jest to mniej znana "platforma".
9. • 9: CommentAuthortebe
   • CommentTime28 Oct 2022 18:10 zmieniony

    
   asl @
   adc #$80
   rol @
   
   do paczki z Mad Assemblerem w przykładach od "wieków" dołączony jest taki plik
   
   ->link<-
   
   z niego dowiemy się kto jest autorem tego NYBBLE-SWAP-a
   
   p.s.
   program Rasta Juice umożliwia zapis obrazka z mapą kolorów dla Rapidus-a (65816), gęstsza zmiana kolorów w linii
10. • 10: CommentAuthormarok
    • CommentTime28 Oct 2022 19:10 zmieniony

     
    Dowiedziałem się i ja, dzięki.
    
    Jednakowoż, że się tak wyrażę, koło można wymyśleć nie tylko raz - że ktoś na coś takiego wpadł wcześniej nie determinuje tego, że nikt później "niezależnie" drugi raz do tego samego nie dojdzie. Stąd zresztą, co można było wyczytać chyba między wierszami, miałem do siebie "pretensję", że nie wpadłem na ten obiektywnie niespecjalnie złożony konstrukt samodzielnie wcześniej (sądząc, że miałem ku temu sposobność), zanim na niego się na tammtej stronie nie napatoczyłem (natomiast przyjmuję, że przykłady na tamtej stronie, z której przytaczałem, są zaczerpnięte skądinąd - nie są więc w tym sensie własne, co mogłem zasugerować).
    
    Morał mógłby być taki, żeby przed opublikowaniem w zasadzie wszystkiego dokładnie sprawdzać zasoby internetu, a tak poza wszystkim ogólnie znać "klasykę" (to, co wypada znać).
11. • 11: CommentAuthormarok
    • CommentTime21 Nov 2022 09:11

     
    Jest z mojej strony kilka ewentualnych (do-) pytań krążących szeroko wokół problematyki 65816 (i Rapidusa), może jeszcze kilku (mam nadzieję względnie ciekawych) propozycji do rozważenia.
    
    Emulacja ZX-Spectrum jest najbardziej spektakularnym osiągnięciem na Rapidusie, jak dotąd (ze sporym prawdopodobieństwem iż tak może już pozostać).
    
    W sprawie tego elitarnego programu, ponieważ (bez wchodzenia w szczegóły) nie mogę w stanie obecnym przyjrzeć się działaniu tego emulatora w żaden sposób, mam pytanie natury dość szczegółowej.
    
    Na stronie domowej jest napisane (piszę z głowy, więc mogę być tu mało precyzyjny), że emulacja na Rapidusie odbywa się z zachowaniem prędkości ~100% oryginału.
    Zastanawia mnie tu:
    - czy mogłaby teoretycznie działać szybciej? (pytanie pomocnicze) - "moce przerobowe" zapewne pozostają jeszcze w dyspozycji, "zgaduję";
    - czy program się (więc, i słusznie) "synchronizuje" tak aby odpowiadało to działaniu z prędkością, jak w oryginale (pytanie niemal zasadnicze),
    i przyjmując, że tak w istocie jest (że się "synchronizuje"), to zastanawia mnie: - jak on to robi (pytanie zasadnicze).
    
    Przejrzałem dyskusję z forum Atari.org, jaka odbywała się przy początkach prac nad tym emulatorem (oraz oddzielnych Xxl'a nad swoją wersją w tematyce zbliżonej) i tam ten problem został także podniesiony.
    Został podniesiony przez Xxl, więc podejrzewam, że Autor emulatora ZX-Spectrum miał jasną wizję poradzenia sobie z tym problemem (dowodem może być działanie samego emulatora).
    Problem dotyczy w zasadzie więc tego (aby to obrazowo i prosto opisać), że przy emulacji kodu innego procesora tym "właściwym" działającym "na wyższym biegu" (bo tylko wtedy można nadążyć z emulacją o czasie - nie opóźniać się w jednostce czasu odpowiednio wyskalowanej - w gruncie rzeczy chodzi tu o ~1/50 sek.) nie przeganiać oryginału, obsługując kod w znacznie większych "porcjach", niż on (ten emulowany procesor) to by zrobił. Cały problem zasadza się na tym, że w pewnych przypadkach, kod wywoływany przerwaniem o ustalonych interwałach czasu (VBLANK) w warunkach "emulacji" czy "normalnie", robi coś (w warunkach emulacji) nie o czasie (za późno, w tym przypadku) w stosunku do tego, co robi w oryginalnych warunkach (na procku emulowanym). To bywa zauważalnym i istotnym problemem (podobno).
    
    Na takie "diktum" istnieją teoretyczne rozwiązania, które mają istotne mankamenty.
    Pierwsze polega na liczeniu cykli emulowanych rozkazów aby osiągnąć ustalony i przeliczony poziom "spustu" (fazę oczekiwania na VBLANK, przerwanie przetwarzania kodu z wątku głównego). Jest to zadanie poważnie czasochłonne dla procesora (ale jeśli się by wyrobił, to nie jest to przeszkoda) i dość uciążliwe, przy tym obarczone chyba jakimś ryzykiej delikatnej niedokładności (różne warunkowane opóźnienia, którym podlega procesor z uwagi "na system", dodatkowe cykle zajmowane przez rozkaz z uwagi na jedną z takich reguł).
    Innym rozwiązaniem, mało już precyzyjnym (ale szybszym i prostszym), jest ustalenie wykonania określonej liczny rozkazów i ich zliczanie, w oczekiwaniu na synchronizachę z VBLANK. Tutaj z dyskusji z poprzednio wspomnianego wątku na forum, wymienia się problem istrukcji złożonych, które operują na kroczącym obrabianiu (kopiowaniu) komórek pamięci. Mogą one bardzo przekraczać czas średniego wykonywania "przeciętnej" instrukcji. Rozwiązaniem na to mogłaby być dodatkowa logika rozpoznawania czasu wykonywania takiej "specjalnej" instrukcji (w przeliczeniu na "liczbę instukcji" podlegających zliczaniu). Ponieważ trudno określić w miarę dokładnie liczbę tak zliczanych ("od sztuki") istrukcji, która by dobrze odpowiadała czasowi między wywołaniami VBLANK, to ta wartość, dopuszczałbym, mogłaby zmianiać się w pewnych granicach, co VBLANK (w zależności od *pewnych wskazań*). Niemniej jest to rozwiązanie ogólnie dość wątpliwe i mało przekonujące.
    
    Synchronizacja (w przetwarzaniu podobnej porcji kodu w emulowanym środowisku do emulowanego) do VBLANK może odbywać się wykorzystując pomocniczo wskazanie VCOUNT. Jeśli przyjmiemy (tak to sobie dobierzemy doświadczalnie, podpierając się może obliczeniami), że określony poziom tej wartości względem emulowanego środowiska odpowiada względnie porcji kodu, który wykonałby się "w ramce", to byśmy już mieli to szukane rozwiązanie.
    Jest to bowiem rozwiązanie proste (mniej obciążające pracę procesora), z drugiej jednak strony nie nazbyt precyzyjne (czasem można "przeskoczyć" jakąś ramkę w tym sensie, że program w wątku głównym przebiegnie mniej więcej "podwójnie" w stosunku do tego, ile byłoby dokładniej to odwzorować, inaczej pisząc - przyspieszy; przy tym, dodajmy od razu, że poprzednio opisane sposoby obarczone byłyby podobną "wadę"). W grach może to mieć pewne już znaczenie, ale jest to jeszcze taki poziom odwzorowania, w który można pójść.
    Jest to też dla mnie najbardziej prawdopodobna postać synchronizacji, którą zastosowano w emulatorze ZX-Spectrum (najbardziej zdawałoby się mi logiczne rozwiązanie).
    
    Jeszcze jest jedna koncepcja, ale chyba mniej realistyczna. Korzystanie z licznika pokeya - ale z uwagi, że może on być wykorzystywany przez program emulowany(?), choć jako taki emulator ZX-Spectrum może niekoniecznie, jest to raczej rozwiązanie trudne bądź wręcz (powiedzmy) niemożliwe do wykorzystania. Jest zresztą trudne z czysto poznawczego punktu widzenia - trzeba te rzeczy dobrze rozumieć i umieć z takiego rozwiązania korzystać, co w moim przypadku, a sądzę że nie tylko, jest trochę obszarem poza zwyczajowym zasięgiem. Ponieważ jednak licznik pokeya "bije" tak samo "w emulowanym środowisku", jak normalnie, to synchronizacja wydaje się być do zrobienia bez "wady", o której pisałem wcześniej.
    
    
    Tak sobie pomyślałem o koncepcji emulacji procesorów z rodziny 6502 ("modów") na 65816. Byłoby o tyle łatwiej, że duża część rozkazów nie musiałaby chyba być emulowana, ale wykonywana "natywnie".
    Koncepcja jest bardzo ogólnie taka, że można "zestronicować" program podlegający emulacji gdzieś w obszar wysokiej pamięci (chodzi mi w tym określeniu o przekopiowaniu programu dokładnie od tego samego adresu przy innej wartości "banku pamięci" procesora 65816, ale w ten sposób, aby te odmienne (specyficzne) rozkazy dla emulowanego procesora wyzerować ("obrejkować"). W ten sposób wywoływać brk (napotkawszy na taki rozkaz) i w prosty sposób mieć już odwołanie do "pararelnego" obszaru z oryginalnym kodem, tylko przez "wymianę" banku pamięci (może to źle nazywam, ale wiadomo chyba o co chodzi). W ten sposób wiemy już, jaką istrukcję mamy emulować (po obrejkowaniu tej przepisanej i wykonanej chwilę wcześniej).
    
    Co można tak emulować to napisałem, że dotyczy to wszystkich odmian 6502, ale w szczególności warto zwrócić uwagę na 65ce02 lub jego współczesnego następcę 45sg02. Chodzi bowiem o to (można to brać za ważki argument), że jest to nie do końca martwy procek. Z tego, co się zdążyłem zorientować, powstał komputer na bazie tego procesora (dla ciekawych: MEGA65), poza tym istnieją chyba wcześniejsze modele komputerów z 65ce02 (jeszcze chyba jeden poza prototypowym c65), choć z małą ilością softu (więc to może nie jest argument).
    
    
    Zmieniając na krótko i szybko wątek - Rapidus i działanie synchroniczne na obu dostępnych procesorach. Spotkałem się tylko z pokazem (wideo od Pasia), że działa to na tej zasadzie, że procek 6502 przejmuje pełną kontrolę nad 65816 (a ten czeka, aż się go "obudzi", ale jak się go obudzi to on wywołuje tylko reset, więc formalnie nie widać działania obu). Miałbym w tym punkcie więcej pytań, ale na tą chwilę zapytam dość fundamentalnie:
    - czy rzeczywiście da się "zapuścić" oba procesory równocześnie (w pewnych uwarunkowaniach, o czym możemy przeczytać chyba na atariki) i jak to można uzyskać (chciałbym dostać się choćby do kodu "BOOT6502.COM" z tej prezentacji Pasia), ewentualnie do jakich celów może to posłużyć, waszym zdaniem?
    
    A co do pomysłów na praktyczne zastosowanie Rapidusa (ze względu na pojemność pamięci) to przypomina mi się problem formatu A2M pod rozszerzkę YAMari (od tOri).
    ->link<-
    
    To duży projekt by był, ale do wykonania.
    
    Ogólnie uważam też, że powinien powstać specjalny "bank pomysłów" pod dopałkę Rapidusa. Pomysły + kto się deklaruje jako (w tym momencie, co można by "odhaczyć") aktualnie zainteresowany realizacją danego projektu, ale widziałby chętnie kooperację w tym względzie (albo dzielenie się szczegółowymi koncepcjami realizacji).
12. • 12: CommentAuthortebe
    • CommentTime21 Nov 2022 10:11 zmieniony

     
    "Dom pomysłów"
    
    Rapidusem można ustawić duszki obok siebie w pojedyńczej szerokości, ten efekt wykorzystuje tryb bez interlace HPM (A-tari G-raphics S-tudio)
    
    można gęściej zmiany kolorów w linii ustawiać, z tego korzysta 'Rasta Juice'
13. • 13: CommentAuthorRocky
    • CommentTime21 Nov 2022 13:11 zmieniony

     
    Rapidus to nie skok Atari w 16 bit, gdyż najważniejszy jest chipset i on stanowi, że to Atari, a nie CPU, które może się znaleźć w milionie innych urządzeń..
    Dostęp do pamięci "chip" powoduje, że Rapidus musi zwolnić do 1.79MHz.. Pełną prędkość uzyskuje jedynie działając w swojej pamięci "Fast"..
    Analogia do Amigi tu pasuje, gdyż architekturą te dwie maszyny są bardzo zbliżone i Rapidus działa trochę podobnie jak dopałki w Amigach..
    
    Co do emulatorów, to czekam na emulator C64, który powinien być prostszy niż emulator ZX z racji kompatybilnego CPU:
    - cała pamięć c64 była by odwzorowana w pamięci Rapidusa
    - emulacją VICa zajął by się VBXE i w VBXE byłaby ulokowana pamięć całej grafiki (duchy, czcionki..)
    Rapidus by musiał zaemulować nielegalne rozkazy oraz SIDa no i ew. proc stacji dla starych dem.. i na to raczej czasu mu nie zabraknie działając 20x szybciej niż CPU c64.
    
    Wąskim gardłem byłaby magistrala Atari, ale służyła by jedynie do karmienia POKEYa oraz VBXE..
    W sumie SIDa można emulować programowo 2xPokey, COVOX lub jak kto ma hardwarowo..
14. • 14: CommentAuthormarok
    • CommentTime21 Nov 2022 17:11

     
    > Co do emulatorów, to czekam na emulator C64
    
    Prawda, że to powinien być oczywisty wybór. Trochę dziwne to nawet sięgać po "różności" nie zająwszy się wcześniej właśnie tym super popularnym przecież kompem. (Tym bardziej, że można w teorii nawet "szarpnąć się" po symulację C64 z SuperCPU, czyli z 65816, co byłoby o tyleż prostsze, że nie trzeba nic szczególnego na tą okoliczność emulować.)
    
    
    > Rapidus by musiał zaemulować nielegalne rozkazy oraz SIDa no i ew. proc stacji dla starych dem.. i na to raczej czasu mu nie zabraknie działając 20x szybciej niż CPU c64.
    
    Właśnie. Te "nielegale" to może dałoby się podciągnąć pod pracę procesora 6502 obecnego wciąż przy Rapidusie, mimo innego alokowania pamięci pod emulowany C64, do której dostęp tego procesora nie byłby wszak możliwy (wychodząc z tych założeń powyżej). Z drugiej strony po co emulować coś, co się już ma?
    SIDa nie wiem, czy tak łatwo zemulować, a nawet jeśli to wykonalne (nieco z tego widziałem), to czy byłoby to wykonanie w pełni udane (ktoś może mieć zastrzeżenia o wierność emulacji; jakieś kompromisy, bo - zasoby; w sumie trochę nie znam tematu, ale jestem "wątpiąco-sceptyczny"). Tym bardziej, że w takiej sytuacji podeprzeć się można istniejącymi rozszerzeniami sprzętowymi SIDa do Atari (bo czemuż nie).
    Co do pracy stacji dyskietek, to jest to znów Z80 (po emulatorze ZX-Spectrum), więc byłoby teoretycznie z czego skorzystać. Z tym że ja uważam, że gdyby wszystko to miało być emulowane jednocześnie (a nawet dwie z tych rzeczy tylko na raz), to nie jestem wcale pewien czy by się procesor wyrobił ze wszystkim, więc tym bardziej jestem za "sprytnym" ominięciem tego, co można ominąć w kwestii emulacji, a zastąpienia tego rozwiązaniami hardwarowymi.
    Co do możliwości VBXE ufam, że dałoby się to zrobić (co by było konieczne), ale też nic w sumie nie wiem na temat tegoż (bo się nie zajmowałem z braku okazji). W każdym razie potężne narzędzie i niezbędne przy wszystkich tego rodzaju "operacjach" (emulacji innych sprzętów) na Atari z Rapidusem (co znajduje potwierdzenie w istniejącym emulatorze).
    
    
    > Rapidusem można ustawić duszki obok siebie w pojedyńczej szerokości, ten efekt wykorzystuje tryb bez interlace HPM (A-tari G-raphics S-tudio)
    
    można gęściej zmiany kolorów w linii ustawiać, z tego korzysta 'Rasta Juice'
    
    
    Muszę się przyznać, że nie znam tych dokonań i jeszcze się o nich nie dowiadywałem (czytam o nich chyba powtórnie od Ciebie w krótkim czasie). Nie miałem styczności z Altirrą z opcją emulowania Rapidusa (tym bardziej "żywego" sprzętu nie dotykałem, który by pozwolił na eksperymenty - i kiedy już to powstało).
15. • 15: CommentAuthortebe
    • CommentTime22 Nov 2022 11:11 zmieniony

     
    w Altirra wystarczy ustawić CPU 65816 na 21.48 MHz, HighRAM na 16MB nie będzie to 100% accurate ale wystarczające (nie trzeba ustawiać w Device Rapidusa)