MLC64 - najszybsze na świecie Commodore 64

[zyga]

W skrócie emulator 6510 na kicie Teensy 4.1 (ARM Cortex M7 600MHz).
https://www.hackster.io/news/ted-fried- ... 30915d888d
https://microcorelabs.wordpress.com/202 ... modore-64/

Zasłyszane na forum atariarea http://atarionline.pl/forum/comments.ph ... =1#Item_20

To chyba popularny ostatnio trend. Na amidze hitem jest PiStorm32.

Plusem jest to że Teensy 4.1 jest póki co dostępny w odróżnieniu od Raspberry Pi.

[ytm]

W końcu znalazłem trochę czasu, żeby opublikować wyniki moich zabaw z MCL64 sprzed ponad roku:

https://github.com/ytmytm/teensy64

Co działa:
- bez przyspieszeń to cycle exact emulator 6510, zastąpi zepsuty CPU
- firmware diagnostyczny: https://github.com/MicroCoreLabs/Projec ... L64_Tester
- wybrany szybki tryb jest włączany przez bit 0 z $d030; tak samo, jak tryb 2MHz na C128; w $d0f0-f2 umieściłem prototyp rejestrów do sterowania: włączenie/wyłączenie przyspieszeń, emulacji REU itp
- ładowanie z kasety jest przechwycone: SHIFT+RUN/STOP ładuje browser do ładowania plików z karty SD, podobnie jak TapeCart. Browser jest wbudowany w firmware Teensy, na karcie wystarczy mieć same pliki. Ładowanie programów działa tak samo jak DMA z U2+ - bezpośrednio do RAM 1 bajt na cykl CPU
- na konsoli serial USB jest prototyp linii poleceń do zdalnej kontroli/debugowania
- jest też prosty emulator REU na 256K, do 512K trzeba by wlutować dodatkowy RAM na płytce Teensy
- czterokrotne szybkie wciśnięcie RESTORE też jest przechwycone przez firmware, docelowo to miałby być sposób na dostęp do menu i łatwej zmiany opcji z poziomu C64 bez używanie POKE

Co nie działa:
- port Tape - te piny nie są w ogóle wyprowadzone z Teensy
- Sonic - rozpoznaje, że to nie C128 i nie próbuje korzystać z szybkiego trybu oraz nie ładuje się do końca - coś nie działa w emulatorze REU

Nie wiem jak szybkie to jest - wiele zależy od wyboru opcji w Arduino IDE i samego programu na C64. Zgaduję, że powinno być 10-20x szybsze od C64 w najszybszym trybie, czyli rzędu SCPU. Ograniczeniem jest też dostęp do I/O. Np. koloru ramki nie można zmieniać częściej niż co cykl i Teensy zatrzyma program aż faktycznie zapis się dokona:

mode2.jpg (263.8 KiB) Przejrzano 3814 razy

Tu wygląda jak 1/2 cykle na czarny i biały kolor - ciężko stwierdzić czy Teensy nie nadąża czy mój dziadowski grabber robi deinterlace.

Oryginalny kod nie używa przerwań do synchronizacji z szyną C64 - w szybkich trybach działa więc wolniej niż gdyby kolejkował zapisy/odczyty, gubi cykle i potrafi się zawiesić. Planowałem to przepisać i to był główny powód przez który na razie porzuciłem ten projekt.

Jeśli ktoś chce spróbować to powinienem mieć jeszcze 2-3 gotowe płytki z elementami SMD. Do przylutowania będą piny i podstawka pod Teensy.

[zyga]

Noooo ! To już jest bodziec, żeby sobie polutować. Jakby co zgłaszam się na betatestera

[Cyprian]

Nie wiem jak szybkie to jest - wiele zależy od wyboru opcji w Arduino IDE i samego programu na C64. Zgaduję, że powinno być 10-20x szybsze od C64 w najszybszym trybie, czyli rzędu SCPU. Ograniczeniem jest też dostęp do I/O. Np. koloru ramki nie można zmieniać częściej niż co cykl i Teensy zatrzyma program aż faktycznie zapis się dokona:

mode2.jpg

Tu wygląda jak 1/2 cykle na czarny i biały kolor - ciężko stwierdzić czy Teensy nie nadąża czy mój dziadowski grabber robi deinterlace.

Z tego co widzę to tu zmiana koloru jest co 8 pikseli Hires, czyli co 1 cykl 6510. Jeśli się nie mylę, to szybciej się nie da zmieniać kolorów.

Oryginalny kod nie używa przerwań do synchronizacji z szyną C64 - w szybkich trybach działa więc wolniej niż gdyby kolejkował zapisy/odczyty, gubi cykle i potrafi się zawiesić. Planowałem to przepisać i to był główny powód przez który na razie porzuciłem ten projekt.

chodzi o to że przy dostępie do szyny C64, teensy64 nie działa ok? A nie powinien wtedy po prostu zwalniać do prędkości szyny C64?

[hobocti77x_]

Chetnie zobacze wyniki jakiegos testu szybkosci.

[ytm]

Z tego co widzę to tu zmiana koloru jest co 8 pikseli Hires, czyli co 1 cykl 6510. Jeśli się nie mylę, to szybciej się nie da zmieniać kolorów.

Grabber mi to rozmywał - w rzeczywistości zmiana była co 2 cykle, nie co jeden. Tak, optymalnie byłoby co 8 pikseli (znak).

Oryginalny kod nie używa przerwań do synchronizacji z szyną C64 - w szybkich trybach działa więc wolniej niż gdyby kolejkował zapisy/odczyty, gubi cykle i potrafi się zawiesić. Planowałem to przepisać i to był główny powód przez który na razie porzuciłem ten projekt.

chodzi o to że przy dostępie do szyny C64, teensy64 nie działa ok? A nie powinien wtedy po prostu zwalniać do prędkości szyny C64?

Później to trochę poprawiłem i działało bardziej stabilnie, ale nadal suboptymalnie.

Chodzi o to, że oryginalny kod został napisany w taki sposób, że teensy czeka na dostęp do szyny w busy loop i nie robi w tym czasie nic innego. Z tego samego powodu nie dało się zrobić dwóch zapisów w dwóch kolejnych cyklach.

Stąd w trybie zapis na szynę/odczyt z cache jest tylko 3.6x szybciej. Gdy odczyty i zapisy były tylko w pamięć teensy (cache), dostałem 40x przyspieszenie.

Niedługo po w/w wiadomościach na githubie umieściłem klipy z benchmarkami.

ytm

[hobocti77x_]

Aby uzyskac zapis w dwoch kolejnych cyklach emulator musialby wykonac w praktyce dwie symulowane instrucje w czasie do 0.5us.
Ja szybkosc emulacji poszczegolnych instrukcji sprawdzalem za pomoca taniego analizatora z ali.
Na emulacji 65816 jest to mozliwe w trybie Native, kiedy procesor dziala na danych 16 bitowych w trybie 3 cykle 2 zapisy przy nawet nizszej niz Teensy czestotliwosci taktowania STM32 (480MHz).
Z ciekawosci zrobilem test o ktorym pisalem wczesniej tutaj
https://www.c64scene.pl/viewtopic.php?p=51559#p51559.
Wyszlo 3us vs. 5us.