Kolega Alex na sasiednim forumie zaprezentowal prototyp zamiennika 6502.
interesujace :-)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
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
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Sprzęt - 8bit » 6502 Teensy
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
Kolega Alex na sasiednim forumie zaprezentowal prototyp zamiennika 6502.
interesujace :-)
Owszem :) Sprzęt już gotowy.
Jednakże testy z braku czasu odbędą się dopiero next week.
Oryginalnie emulator obsługuje wszystkie nielegale, więc nie wiem czy warto robić to w ten sposób, natomiast nic nie stoi na przeszkodzie dopisać koprocesor. Pod dowolnym adresem :) Mnożenie, dzielenie, pierwiastki, sinusy... Czego dusza zapragnie ;)
albo jakies operacje blokowe.
dodac jakis rejestr ktory bedzie wskazywal jaka obecnie strona pamieci bedzie mapowana na wewnetrznac pamiec urzadzenia - przykladowo zapis na stronie 06xx laduje w wewnetrzej pamieci a nie pamieci atari i dac mozliwosc zapisu z tej wewnetrznej pamieci do pamieci podstawowej w 1 cyklu - moze udaloby sie w ten sposob zrobic zapis do rejestrow sprzetpwych np rej. koloru w 1 cyklu? albo zrobic bliterek ;-)
Z operacjami na pamięci to generalnie będzie kłopot, bo zapisy muszą być wolne gdyż dotyczą standardowej pamięci RAM. Co innego, jeśli uda się zaimplementować extra RAM w Teensy, który będzie pomijał pamięć podstawową, ale wtedy będzie trzeba zaimplementować dostęp Antica do tej pamięci, co jest wyzwaniem z braku wolnych pinów.
@alex, ale xxl już zapodał Ci rozwiązanie. Zamiennik dziala wewnątrz swojej pamięci i podmienia (szybciej, niż by to robił oryginalny proc) pamięć w Atari.
chodzilo mi raczej o cos takiego co juz wczesniej Psychol wymyslil:
https://madteam.atari8.info/index.php?prod=gtia2
emulowany cpu pracuje na pamieci podstawowej atari ale ma tez dostep np poprzez jakis rejestr do pamieci w tensy bo stamtad juz mozna szybko wyciagac dane i kopiowac do pamieci atarki - czyli juz cos lepszego niz blitter w vbxe bo ten moze kopiowac tylko w swojej pamieci - a to rozwiazanie pozwoliloby kopiowac takze do rejestrow sprzetowych...
@sikor - nie ma póki co opcji, by tę pamięć widział Antic i reszta urządzeń zewnętrznych. Może być bez problemu, ale dostępna jedynie dla procesora. Realizacja, jak pisałem, jest dość karkołomna w tej chwili.
@xxl - Zapis do rejestrów sprzętowych jest oczywiście jak najbardziej możliwy :) Pytanie jak ustalić protokół komunikacji...
to podrzuce jeszcze jeden pomysl:
skok do programu w okreslonych adresach np. strona d8 czyli pakiet matematyczny wskoczy do programu emulowanego cpu ale juz w pamieci tensy, tylko odczyt i zapis do rejestrow fp bylby wolny ale wszystkie obliczenia blyskawiczne.
---
probowalem zainteresowac tym innych przy obejsciu ND ale nie wyszlo a z tensy to wydaje sie jeszcze lepsze :-) http://www.atari.org.pl/forum/viewtopic.php?id=17382
Operacje FP ale jako rozkazy dodatkowe takiego CPU to niezły pomysł. Ale haki z jakimiś specjalnymi adresami to jakieś takie słabe.
FP mogłoby funkcjonować tak, że w A jest adres na ZPG jednego rejestru FP, a jako argument brać adres drugiego rejestru FP. Tryby adresowania dla argumentu standardowe. Albo tryb FP włączany dodatkowym znacznikiem F rejestru flagowego :) Wtedy wszystkie ADC, SBC, CMP, ROL, ROR itp. działałyby na liczbach FP na ZPG :) Tylko przydałoby się jeszcze MUL/DIV i EXP/LOG i może pewnie parę innych. No i MOV do przesłań rejestrów FP. I jakaś normalizacja liczby FP pewnie też.
a wlasnie ze "haki ze specjalnymi adresami" sa najlepsze! wlasciwie przedzialami adresow, dzieki temu np. mozesz caly rom umiescic w pamieci tensy - pomyslow jest wiecej ... wlasnie dzieki takiej funkcjonalnosci...
natomaist te rozkazy z liczbami fp mozna dodac jako kody dodatkowe zastepujace rozkazy JAM/CIM ktore normalnie i tak blokuja cpu - wlasnie to chcial wykonac gosc na aage jakis czas temu.
@xxl - Inne procki można też emulować :) Potencjał jest ogromny. W sumie nic nie stoi na przeszkodzie, by były różne rdzenie do wyboru przełączane programowo :D
Póki co w najbliższym tygodniu będę walczył problemami sprzętowym, a konkretnie zegarem. Mam nadzieję, że do letniej edycji Silly Venture będę mógł zaprezentować w pełni działający prototyp.
Kolega Alex na sasiednim forumie zaprezentowal prototyp zamiennika 6502.
interesujace :-)
Mam płytkę Teensy 4.1 pod projekt "Rapidus Again" od 1 grudnia 2022. Płytka ta jak i kilka innych mikokontrolerów zostało sfinansowane z projektu SAVO :)
W październiku rozmawiałem o tym z ASem i Krapem, a na początku listopada z Draco.
To tak tytułem wstępu harmonogramu projektu.
Na chwilę obecną projekt przesuwa się na wakacje ze względu na:
1. dodatkowe projektu płytek SAVO+ oraz SAVO MAX oraz dodatkowych płytek SAVO, które są w preorderze
2. laboratorium dotyczące sygnałów zegarowych na płycie Atari - bliski ukończenia
3. karta stereo dual Pokey z pełnym mikserem oparta o kontroler Atmega (lub ESP32), które są uzupełnieniem projektu SAVO
(2) i (3) są prekursorem dla projektu RapidusAgain!
W założeniu projekt RapidusAgain będzie soft-corem procesorów 6502C oraz 65C816. Możliwe, że będzie hybryda tych procesorów, ale nie sprawdzałem dekoderów rozkazów i nakładania się ich, tak żeby np. zbudować 65C816 z illegalsami 6502C. Mogłoby być fajne, ale nie wiem czy możliwe.
Zanim zacznę taki projekt formalnie potrzebna mi jest wiedza o stabilizacji tego co już jest. Na chwilę obecną nie znam osoby, która potrafi odpowiedzieć na pytanie co poprawić, gdy się wsadzi wszystkie możliwe rozszerzenia i zaczyna całe nowe Atari działać mało stabilnie. Sam mam kilka pomysłów i nawet dzisiaj będę siedział nad kolejnym testem.
Docelowo takie rozszerzenie może zawierać w sobie implementację popularnych rozszerzeń pamięci. Ze względu jednak na technologię MCU, implementacja taka nie będzie bazować na istniejącym hardwarze, zielonych klonach, albo innych wynalazkach naruszających dobra właścicielu autorskich praw majątkowych. Taka technologia może bazować na otwartym kodzie emulatora Altirra. Mówiąc wprost, można stworzyć na MCU rozwiązanie, w którym oprócz symulacji RT procesorów, reimplementowane będą fragmenty Altirry, bryżowane do płyty Atari. Szykuje się niezły Frankenstein :)
Ponoć zawsze pytasz czy będzie MapRAM. Da się zaimplementować w czymś takim, chociaż z tego co słyszałem, zaczęli ludzie używać nazwy XxlRAM, ze względu na kluczowego odbiorcę takiego rozwiązania ;)
BTW... Twój brat mnie wciągna do testowania gierki Tony. Sporo przegadaliśmy i z tego co mówił podrzucał pod koniec roku moje pomysły z wykorzystaniem Fujinetu.
serwus,
Piotr
Owszem :) Sprzęt już gotowy.
Jednakże testy z braku czasu odbędą się dopiero next week.
Daj znać czy SIDE3 działa :))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
serwus,
Piotr
Możliwe, że będzie hybryda tych procesorów, ale nie sprawdzałem dekoderów rozkazów i nakładania się ich, tak żeby np. zbudować 65C816 z illegalsami 6502C. Mogłoby być fajne, ale nie wiem czy możliwe.
Rozmawialiśmy już o tym i nie jest to możliwe, bo 65C816 ma wykorzystane wszystkie 256 opkodów z tablicy (ok, 255, bo 1 opkod jest zerezerwowany). Dajmy na to, opkody $xF, wszystkie nielegalne na 6502, na 65C816 są wykorzystane na tryby adresowania long abs ("długie", z 24-bitowym adresem, typu LDA $F00000).
Nawet gdyby zaryzykować rozróżnienie na tryb emulacji (z nielegalami) i natywny (bez), i tak jeden z opkodów musi być użyty do przełączenia trybu, zatem czciciele faktu, że kiedyś tam firma MOS Technology postanowiła zaoszczędzić kilka centów na krzemie per procesor i nie zrobić pełnego dekodera rozkazów, i tak będą płakać, bo ten jeden będzie działał inaczej. Poza tym nowe rozkazy - typu BRA, BRL, STZ, JSR (adr,X), TYX/TXY, PHX/PHY/PLX/PLY, BIT abs,X itp. - przydają się też, i to bardzo, w trybie emulacji. Dzięki temu, że działają zawsze, można mieć np. w systemie jedną procedurę SYSVBL działającą w obu trybach i jednocześnie korzystającą z nowych rozkazów, czyli zajmującą mniej czasu :)
Ogólnie, pomijając szczegóły, chciałbym napisać, że dla 65C816 i Atari jest całkiem dużo całkiem sprawnie działającej infrastruktury, z czego pewnie mało kto sobie zdaje sprawę. Istnieje rozszerzenie dla SpartaDOS X, które podłącza pamięć znajdującą się ponad adresem $FFFF do ogólnej mechaniki zarządzania pamięcią w SDX, a tym samym sprawia, że ta pamięć staje się widoczna dla loadera binarnego tego DOS-u. Tak samo działa obsługa błędów, symbole itp.
Można zatem, przy użyciu SDX, ładować programy bezpośrednio do wysokiej pamięci 65C816 i je uruchamiać. Działa to doskonale, póki co zostało najlepiej przetestowane z rezydentami rozszerzającymi funkcje SDX, ale zwykłe programy aplikacyjne też mogą z tego korzystać.
Jest asemblerek http://drac030.krap.pl/pl-elsa-pliki.php umiejący produkować relokowalne binaria dla SpartaDOS X, które można w ten sposób wykorzystać. Z przykrością nadmieniam, że MADS się do tego nie nadaje, bo np. nie generuje fixupów dla rozkazów typu JSL. Natomiast ELSA jak najbardziej. Pisałem w tej sprawie do tebego swego czasu, ale zostałem zignorowany - no trudno :)
peterkaczorowski napisał/a:Możliwe, że będzie hybryda tych procesorów, ale nie sprawdzałem dekoderów rozkazów i nakładania się ich, tak żeby np. zbudować 65C816 z illegalsami 6502C. Mogłoby być fajne, ale nie wiem czy możliwe.
Rozmawialiśmy już o tym i nie jest to możliwe, bo 65C816 ma wykorzystane wszystkie 256 opkodów z tablicy (ok, 255, bo 1 opkod jest zerezerwowany). Dajmy na to, opkody $xF, wszystkie nielegalne na 6502, na 65C816 są wykorzystane na tryby adresowania long abs ("długie", z 24-bitowym adresem, typu LDA $F00000).
Ok. Chciałem jeszcze potwierdzić dla własnego zrozumienia, ale teraz już to w pełni wyjaśniłeś.
Dzisiaj mi przyjdzie książka "Mikroprocesor 6502 i jego rodzina", także muszę się jeszcze dokształcić.
Póki co kończę projekt stabilizacji O2/BO2, który jest dla mnie prekursorem do tego projektu.
serwus,
Piotr
65C816 jest naprawdę git ale cena rozszerzenia już nie.
peterkaczorowski napisał/a:Możliwe, że będzie hybryda tych procesorów, ale nie sprawdzałem dekoderów rozkazów i nakładania się ich, tak żeby np. zbudować 65C816 z illegalsami 6502C. Mogłoby być fajne, ale nie wiem czy możliwe.
Rozmawialiśmy już o tym i nie jest to możliwe, bo 65C816 ma wykorzystane wszystkie 256 opkodów z tablicy (ok, 255, bo 1 opkod jest zerezerwowany). Dajmy na to, opkody $xF, wszystkie nielegalne na 6502, na 65C816 są wykorzystane na tryby adresowania long abs ("długie", z 24-bitowym adresem, typu LDA $F00000).
Zmiana trybu nie musi być wykonana rozkazem - może być sekwencja rozkazów, albo np. specyficzne odwołanie do jakiejś komórki pamięci. Nie musi to tak samo działać w obie strony, np. wyjście z trybu 6502 może być zrealizowane nielegalem który normalnie zatrzymuje kompletenie procesor.
Zmiana trybu nie musi być wykonana rozkazem - może być sekwencja rozkazów, albo np. specyficzne odwołanie do jakiejś komórki pamięci. Nie musi to tak samo działać w obie strony, np. wyjście z trybu 6502 może być zrealizowane nielegalem który normalnie zatrzymuje kompletenie procesor.
Co do zasady.. Na soft-corze można sobie zrobić dowolny procesor. Nawet się można przełączyć na 68000 albo na 8080, żeby obsługiwać CP/M'a "prawie natywnie". Nawet można zrobić tak, żeby Atari mogło zupdate'ować mikrokod i sobie samo wrzuciło co potrzeba.
Jednym z założeń projektu jest jednak wsteczna kompatybilność z Rapidsuem oraz DracoOS.
Zmiana trybu nie musi być wykonana rozkazem
Miałem na myśli przełączenie trybów w ramach 65C816. To przełączenie może i nie musi, ale jest realizowane rozkazem (XCE). To samo w sobie załatwia odmownie przedstawiony przez Piotrka pomysł ożenienia obu tablic rozkazów i zrobienia hybrydy.
Strony 1
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Sprzęt - 8bit » 6502 Teensy
Wygenerowano w 0.032 sekund, wykonano 52 zapytań