Wiem, że temat nie do końca związany z Atari, ale jest tu z pewnością kilka osób, które spotkały się z procesorem 65816, więc pozwolę sobie zapytać. Napisałem symulator tego procesora. Piszę "symulator", bo choć docelowo jest (lub przynajmniej taki jest cel) programowo zgodny z 65816 (symuluje też błędy tego procesora), to nie jest zgodny jeśli chodzi o zgodność cykli. Ale do rzeczy. Układ działa na STM32H750, takim jak ten: ->link<- . A teraz w związku z testami poszukuję odpowiedniego oprogramowania, które pozwoliłoby wykryć ewentualne błędy. Chodzi też o programy, dzięki którym mógłbym określić jaką wydajność ma ten symulator. Na razie sprawdziłem ten w wersji full z dodatkowymi testami arytmetyki BCD: ->link<- Układ przechodzi cały, nie wykrywając błędów symulacji. Jeśli ktoś zna podobne testy, to proszę o info.
Układ wciąż jest rozwijany, w tej chwili może współpracować ze wszystkim, co obsługuje konsolę VT-100 (czyli w praktyce port szeregowy, ekran i klawiaturę). Aktualnie pracuję nad dodaniem emulacji i8080 (z80) oraz systemem dla wykonywania programów w kodzie natywnym ARM-Cortex, a kolejnym etapem będzie dołączenie współpracy z magistralami komputerów 8-bit. Jeśli ktoś jest zainteresowany, to więcej info tutaj: ->link<-
Na razie jeszcze nie publikuję. W sumie rozwijam to, aby dla mojego Apple II i chcę zrobić coś w rodzaju akceleratora mogącego wykonywać kod 65816, i8080 (choć pewnie rozszerzę go na z80) i oczywiście natywny ARM Cortex7. Chcę, aby każdy emulowany core miał bezpośredni dostęp do hardwaru, ale też aby drive'y nie wykorzystywały RAM, tak że cały RAM jest dostępny dla emulowanych procesorów i widziany przez nie w taki identyczny sposób jak w oryginale, czyli RAM zaczyna się od $0000 i kończy zależnie od banku np. w stm32h750 na $7FFFF. Jeśli pojawi się np. układ z większym RAM lub np. z zewnętrznym, to będzie można go też uruchomić z dostępem do większej ilości RAM. W tej chwili zrobiłem już emulację 65816 i w zasadzie jestem na etapie jej testowania. I mam ok. 50% emulacji i8080. Z hardware mam sterowniki do obsługi portów szeregowych, w razie potrzeby można ich dodać nawet kilka, taktowania CPU i portów równoległych. W dalszej kolejności chcę ukończyć i8080 i uruchomić RTC. A potem być może USB. Myślałem też o uruchomieniu na innych platformach niż Apple. Wczoraj udało mi się uruchomić monitor systemowy dla 65816, miałem z nim trochę problemów, bo okazało się, że w kodzie źródłowym (nie moim) był błąd. W każdym razie udało się go zlokalizować i teraz już działa.
Pewnie by się dało, tyle że w przypadku Apple, czy nawet C64, istnieje możliwość odłączenia CPU i przejęcia magistrali co daje bezposredni dostep do pamieci i I/O. Dodatkowo istnieje jeden standard gniazd do tego, gdzie w Atari byłby problem. W każdym razie na pewno można by podłączyć się przez port szeregowy, czy nawet joysticka, gdzie Atari działałoby jako terminal. No chyba że od razu Atari 2600 ;) W każdym razie temat mógłby być ciekawy ;)
Troche to trwalo ;) Zalaczam nagranie z testu w BBC Basic2. Wedlug tej tabelki na 65C816 16MHz ten sam test wykonyje sie w 60,91 sek. u mnie nieco wiecej niz 2 min. benchmark
Moge sie podzielic, problem w tym ze nie ja jestem autorem, a jedynie zglaszalem autorowi poprawki do uzupelnienia testow. O ile chodzi o kod glowny to wiem ze byl opublikowany, ale nie wiem jaki jest status tego uzupelnianego. W kazdym razie mam zrodla i kod wynikowy i moge Ci go przeslac do wykozystnia ale wolalbym go nie upubliczniac jesli podasz mi jakis namiar to moge sie podzielic. W kazdym razie wersja bez poprawek jest dostepna tutaj,ta wersja nie sprawdza instrukcji BCD https://github.com/gilyon/snes-tests/tree/main/cputest
A co do bledow to jeszcze jest jeden dotyczacy adresowania w instrukcji lda ($F7,X).
To nie jest tak, że ja się martwię tym, czy ty to udostępnisz, czy nie. Zwracam tylko uwagę, że jest to kod, który może posłużyć do wygenerowania kodu ROM dla SNES, a to już Nintendo i wiadomo.;) Zauważ, że osoba udostępniająca na Githubie też nie dodała pliku licencji ;) Ja używałem kodu wygenerowanego dla i dzialajacego na ->Kowalski Symulator<- https://sbc.rictor.org/download/6502%20v1.4.1.0.zip [/] W jednym z trybow moj emulator jest zgodny z Kowalski Symulator. Tak wiec wszystko co na nim dziala powinno dac sie uruchomic i na moim.
Swoją drogą Kowalski Symulator po tym, jak "wymusiłem" poprawki, przynajmniej na dzień dzisiejszy emuluje 65c816 poprawnie. Możesz w ostatniej wersji używać go do porównań.
Dobrym testem jest uruchomić EhBasic, jest on napisany dla 65c02, a dokładnie w wersji 2.22 bez przeróbek. Długo myślano, że nie działa na emulatorach 65c816. O dziwo u mnie zadziałało i okazało się to dobrym argumentem do nakłonienia osoby zajmującej się Kowalski Symulator do jego aktualizacji. W każdym razie działa, daje Ci link do kodu źródłowego https://6502.org/users/mycorner/6502/ehbasic/index.html Ale nie próbuj kontaktować się z autorem, bo niestety zmarł kilka lat temu.
@gregor2 cokolwiek chcesz wiedzieć "na start" znajdziesz na ->link<-
z ciekawszych rzeczy to po próbie użycia układu Yamaha z najbardziej chyb zaawansowanym OPL powstał układ na bazie autorskiego tSU (autor Furnace zrobił swój fantasy układ dźwiękowy) a Smoku wziął go na warsztat i zrobił z tego SGU-1. jeszcze nie wiadomo jak to okiełznać ale wydaje się potężnym (w sensie unowocześnionym) SID z 9 kanałami gdzie masz również opcję użycia ficzerów z OPL.
"great minds think alike" dlatego świetny K65 od KK/Altari znalazł swoją kontynuację jako K816 w całości pisanego przez AI w Rust.
a z rzeczy osobliwych zegar w X65 nie jest synchroniczny ;)
dla Atarowców to w X65 jest układ graficzny wzorowany na ANTIC, obsługuje displaylist, ale ma więcej (a może sensowniejszych) trybów a także możesz ustawić go tak, że będzie działał jak C64 z mapą kolorów, dla zboczeńców jest coś jak HAM z Amigi ale też jeden tryb działający jak w SNES.
jak lubisz ciekawe współczesne rozwiązania to polecam się przyjrzeć.
Przeciez tam jest 65c816 wiec po co sprawdzac jego kompatybilnosc z samym soba ? Na tym schemacie brakuje kilku sygnalow np. SIO2 i SIO3 ;) https://x65.zone/news/2024/03/12/breadboard-schematic.html Rozumiem ze 65c816 z pamiecia laczy sie przez RP2040 i stad tak niska wydajnosc ¬1.84MHz , czy jest jeszcze jakis inny powod ?
chcę wiedzieć czy emulator działa tak jak prawdziwy 65c816.
tak, to jest powód, że procesor nie pójdzie na 20MHz bo musi czekać, ale ~1,84 to chyba stare dane, wydaje się, że udało się osiągnąć minimum w okolicach ~4MHz ale jak się wie co kiedy robi procesor to on potrafi działać szybciej w pewnych scenariuszach i można to wyzyskać, ale to trzeba poczekać aż wyjdzie kolejna wersja prototypu w naturze.
patrząc na przebiegi, wiedząc, że każda instrukcja potrzebuje co najmniej 28 us na dostęp do pamięci, a każda wymaga co najmniej jednego dostępu, to mi raczej wychodzi bliżej 35 kHz niż 1.84 MHz ;)
A co z oprogramowaniem? Jakbyście odpalili np. IntegerBASIC z AppleI lub II (appleII ma bardzo regolarny zegar bez hamowania wiec to dobry wzorzec dla okreslenia szybkosci) albo BBC Basic, to można by porównać i określić faktyczną szybkość.
W tablelce wyzej sa wyniki dla prawdziwego 65c816 z 16MHz, w razie czego sluze tymi testami ;)
@gregor2 spokojnie, prototyp 1 powstał już z ponad pół roku temu i działało na nim wszystko co masz tutaj ->link<- a prędkość pracy emulatora była brana z natury ;)
komputer był prezentowany na jakimś zlocie, i dzieciaki grały na nim w mój port Sokobana.
w nowej wersji ma być szybciej bo "coś" tam, już nie pamiętam ;)
Dzięki za link. Mam pytanie, dlaczego 65816 nie działa w trybie emulacji, jak twierdzi strona, którą podlinkowałeś? Czy w takim razie w trybie natywnym działają rozkazy z 8-bitowymi danymi, np. lda #$01? Kolejne pytanie: jak określaliście szybkość procesora? A i takie techniczne: czy stosowaliście pamięci ESP-PRAM64, a jeśli tak, to z jaką taktujecie je częstotliwością? Mam złe doświadczenia z chińską "elektroniką", więc zapytam, czy rzeczywiście działają one z częstotliwością 84/133 MHz bez przekraczania banków 1k, jak twierdzą w dokumentacji?
Do Poznania mam jakies 1500 km wiec raczej byloby trudno ;) A co do mojego projektu to jak najbardziej mozna go dolaczyc do wszystkiego co ma klawiature i ekran wiec tez do kazdego Atari i nie tylko. ;) Co ciekawe to wystarczy do pisania programow, w tej chwili emuluje 3 procesory (kilka dodatkowych jest w planie) tj., 65c816,65c02,i8080 no i oczywiscie natywnie ARM. W tej konfiguracji mozna tworzyc, debugowac, uruchamiac oprogramowanie dla tych CPU.
CommentTime22 Apr 2026 15:44 (6 dni temu) zmieniony
@gregor2 na AOL był chyba jakiś gość (a może na Area?) co nawet miał pomysł włożyć 6809 do ataryny ;) ale to chyba nie byłeś ty, ale mnie na starość już się kićka ;)
ps. moje sieć halucynuje, że to jednak była Area, ale na pomyśle się skończyło
CommentTime22 Apr 2026 20:28 (6 dni temu) zmieniony
Swego czasu wstawianie 6809 do komputerow mialo sens. Istanialo sporo oprogramowania glownie w kregach nauki , ale i przemyslowego dla tego procesora. Byl on np, dostepny jako dodatkowy second processor dla komputerow Acorna. Byl tez po Z80 chyba najczesciej wstawianym jako karta AppleII. Nawet Commodore probowalo zrobic z nim PET-a. Zreszta powstalo sporo ciekawych komputerow na bazie tego CPU. W kazdym razie byl szybszy nawet od 6502. Po gniotach w rodzaju 6800 i 68000 Motorola wreszcie sie spiela i zrobila calkiem dobry procesor ;) W sumie mam w planach dolaczyc jego emulacje do mojego zestawu, tyle ze wciaz nie moge sie zdecydowac od ktorego zaczac czy 65c832, 68000 czy 8086 ;) Dolaczam filmik z porownaiem mojego emulowanego rdzenia 65c816 z prawdziwym 65c816 wedlug autora 16MHz.
Ostatnio robilem benchmark na emulacji 8080 wyszlo ze program wykonujacy sie na ZXspectrum ponad 3 godziny wykonal sie w nieco ponad 6 min ;) Wydaj mi sie ze calkiem niezle jak na uklad w cenie kawy w Londynie ;)
CommentTime24 Apr 2026 00:19 (4 dni temu) zmieniony
Wiecej na raz czego ? Chyba ze chodzi o te 4 cykle potrzebne do dostepu do RAM zamiast 1 a wlasciwie nawet 1/2 cykla w 6502 co wykozystano np. w AppleII,c64 czy komputerach BBC aby w tym samym cyklu zapewnic dostep do pamieci CPU i kontrolera grafiki.
CommentTime24 Apr 2026 11:14 (4 dni temu) zmieniony
I tu byl pies pogrzebany, Z80 wymagal ok 3.5 - 4 razy szybszego taktowania aby dociagnac do 6502 co wymagalo drozszego i trudniejszego procesu produkcji i w zasadzie nigdy nie mogl dogonic 6502.
Inna sprawa ze 6502 tak naprawde byl blokowany glownie przez pamieci RAM ich wysokich cen niskich czasow dostepu a nawet niskiej jakosci przynajmniej w poczatkach komputeryzacji.
