09.04.2019 22:29
[#1]
Amiga i ARM czyli Amiga ARM Accelerator Development Board
Jakiś czas temu narodził się pomysł podpięcia procesora ARM do Amigi.
W związku z tym zostały połączone siły moje, mschulz oraz KaiN w celu realizacji tego projektu.
Na chwilę obecną został stworzony sprzęt posiadający kontrolę nad elektroniką znajdującą się na płycie Amigi 500.
Założeniem projektu jest wykorzystanie ARM-a (w tym przypadku STM32) jako głównego procesora i użycie emulacji programowej (JIT) procesora m68k w celu uruchomienia systemu oraz dostępnego oprogramowania na procesory rodziny m68k.
Urządzenie poza możliwością podpięcia się do szyny Amigi 500 ma możliwość uzyskania dostępu do 64MB pamięci SDRAM oraz peryferiów oferowanych przez sam procesor STM32.
To na tyle, a oto i sam winowajca tego zamieszania
W związku z tym zostały połączone siły moje, mschulz oraz KaiN w celu realizacji tego projektu.
Na chwilę obecną został stworzony sprzęt posiadający kontrolę nad elektroniką znajdującą się na płycie Amigi 500.
Założeniem projektu jest wykorzystanie ARM-a (w tym przypadku STM32) jako głównego procesora i użycie emulacji programowej (JIT) procesora m68k w celu uruchomienia systemu oraz dostępnego oprogramowania na procesory rodziny m68k.
Urządzenie poza możliwością podpięcia się do szyny Amigi 500 ma możliwość uzyskania dostępu do 64MB pamięci SDRAM oraz peryferiów oferowanych przez sam procesor STM32.
To na tyle, a oto i sam winowajca tego zamieszania
09.04.2019 22:52
[#3]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@spidi, post #1
To trochę szersze info:
- w pracy czytając datashity STM32 okazało się że ma coś takiego jak Flexible Memory Controller, co pozwala podpięcie natywnie, bez emulacji, zewnętrzną pamięć z 24-bitową szyną adresową... na przykład CHIP RAM + amigowe rejestry. Tutaj o tym bąknąłem ale przeszło bez większego echa. Ostatnio bąknąłem o tym znowu i Spidi podchwycił temat. ;)
- Mschulz pracując nad AROSem/ARIXem dla raspi opracował JIT tłumaczący instrukcje 68k na kod ARMowy, z czego ten projekt ma zamiar skorzystać. Co prawda raspi używa innego zestawu instrukcji niż STM (ten drugi rozumie tylko thumb-2), ale idzie JITa pod tę architekturę przerobić, co Mschulz uczyni. A jak nie to będę musiał się na coś w tym projekcie przydać. Tu macie prawdziwą emulację, nie to co wampir, który reaguje na instrukcje 68k natywnie. ;)
- To gdzie ten projekt ma okazję lśnić to przełączanie się między wykonywaniem instrukcji emulowanych 68k a natywnym kodem ARMowym - coś na zasadzie WOS tylko bez dwóch CPU. A nawet lepiej - można na tym puścić ARMowego AROSa, który będzie odpalał aplikacje 68k na żywym chipsecie.
JIT Mschulza to póki co największy ficzer tego projektu, a jest on open source. Dlatego jest pomysł by cały projekt uczynić otwartym. Jak dojrzeje to pewno Spidi to będzie sprzedawał, a zawsze ci co lubią sobie podłubać to będą mogli złożyć to dziadostwo na uber-pająku ;)
- w pracy czytając datashity STM32 okazało się że ma coś takiego jak Flexible Memory Controller, co pozwala podpięcie natywnie, bez emulacji, zewnętrzną pamięć z 24-bitową szyną adresową... na przykład CHIP RAM + amigowe rejestry. Tutaj o tym bąknąłem ale przeszło bez większego echa. Ostatnio bąknąłem o tym znowu i Spidi podchwycił temat. ;)
- Mschulz pracując nad AROSem/ARIXem dla raspi opracował JIT tłumaczący instrukcje 68k na kod ARMowy, z czego ten projekt ma zamiar skorzystać. Co prawda raspi używa innego zestawu instrukcji niż STM (ten drugi rozumie tylko thumb-2), ale idzie JITa pod tę architekturę przerobić, co Mschulz uczyni. A jak nie to będę musiał się na coś w tym projekcie przydać. Tu macie prawdziwą emulację, nie to co wampir, który reaguje na instrukcje 68k natywnie. ;)
- To gdzie ten projekt ma okazję lśnić to przełączanie się między wykonywaniem instrukcji emulowanych 68k a natywnym kodem ARMowym - coś na zasadzie WOS tylko bez dwóch CPU. A nawet lepiej - można na tym puścić ARMowego AROSa, który będzie odpalał aplikacje 68k na żywym chipsecie.
JIT Mschulza to póki co największy ficzer tego projektu, a jest on open source. Dlatego jest pomysł by cały projekt uczynić otwartym. Jak dojrzeje to pewno Spidi to będzie sprzedawał, a zawsze ci co lubią sobie podłubać to będą mogli złożyć to dziadostwo na uber-pająku ;)
10.04.2019 07:58
[#7]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@poweredjj, post #6
Pisałem przecież, że żartuję :) 64MB RAM to nie jest tak bardzo dużo, chciałbym mieć też RTG, pewnie nie będzie też MMU - nie jestem pewien, czy finalny produkt będzie mi odpowiadał. Ale bardzo podoba mi się pomysł wrzucenia ARM'a zamiast m68k.
A coś się w ogóle dzieje w sprawie tego JIT'a? W repozytorium GIT od dłuższego czasu całkowita cisza...
Lista:
1. PoweredJJ (wersja dla A500)
A coś się w ogóle dzieje w sprawie tego JIT'a? W repozytorium GIT od dłuższego czasu całkowita cisza...
Lista:
1. PoweredJJ (wersja dla A500)
10.04.2019 08:08
[#8]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@lukzer, post #5
Jakiej wydajności vs real 68k sie spodziewacie ? btw. Gratuluje pomyslu i trzymam kciuki aby udalo sie dokończyć projekt.
Obecny procesor to ledwie ponad 200MHz, ale zdecydowaliśmy się na taki ze względów na niskie koszty startu projektu. Gdy osiągniemy wszystkie zamierzone cele na tym procesorze będziemy myśleć o przesiadce na coś mocniejszego i lepszego. Co do wydajności obecnego rozwiązania w tej chwili nie ma co się wypowiadać, wszystko wyjdzie w nadchodzących testach.
10.04.2019 13:28
[#14]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@aszu, post #13
A1200 będzie kłopotliwa. STM32 którym się bawimy ma tylko 16-bitową szynę danych - trzeba by dorobić jakiś układ do konwersji podwójnych odczytów 16-bitowych na jeden 32-bitowy. Jest to do zrobienia, ale najpierw projekt będzie męczył jedyny słuszny OCS/ECS. ;)
Ostatnia aktualizacja: 10.04.2019 13:29:01 przez teh_KaiN
Ostatnia aktualizacja: 10.04.2019 13:29:01 przez teh_KaiN
10.04.2019 18:57
[#19]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@Adinfo, post #18
To nie jest jeszcze do końca pewne. Cytując Spidiego:
Wydaje mi się, że przy odrobinie hakierzenia dałoby radę tego CPLD pominąć ale trzeba by trochę pohakierzyć i popatrzyć jak bardzo to wpływa na zależności zegara używanego w ARMie. Bo w CPLD możesz sobie ładnie wszystko dopasować i zsynchronizować.
UDS/LDS to prawdopodobnie 1:1 sygnały NBL1/0, NWAIT - być może da radę podpiąć wprost do pinu DTACK, tak samo NE1 w roli AS, a NWE w roli RW. Pozostaje kwestia VPA/VMA. Co do zegara E - STM chyba umie wyrzucić z siebie zegar, pytanie czy dałoby radę go ładnie podzielić do 700kHz potrzebnego dla CIA. A jak nie to coś zaimprowizować na PWMie albo dodać jakiś zewnętrzny dzielnik.
Trochę za wcześnie jest w tym projekcie by podać odpowiedź przeczącą, tym bardziej twierdzącą. ;) Za to na pewno wtedy potrzebujesz na tych liniach zrobić konwersję napięć.
Ostatnia aktualizacja: 10.04.2019 18:57:47 przez teh_KaiN
CPLD teraz generuje E,VPA,VMA, AS, UDS,LDS, RW i obrabia to co przychodzi z DTACK
Wydaje mi się, że przy odrobinie hakierzenia dałoby radę tego CPLD pominąć ale trzeba by trochę pohakierzyć i popatrzyć jak bardzo to wpływa na zależności zegara używanego w ARMie. Bo w CPLD możesz sobie ładnie wszystko dopasować i zsynchronizować.
UDS/LDS to prawdopodobnie 1:1 sygnały NBL1/0, NWAIT - być może da radę podpiąć wprost do pinu DTACK, tak samo NE1 w roli AS, a NWE w roli RW. Pozostaje kwestia VPA/VMA. Co do zegara E - STM chyba umie wyrzucić z siebie zegar, pytanie czy dałoby radę go ładnie podzielić do 700kHz potrzebnego dla CIA. A jak nie to coś zaimprowizować na PWMie albo dodać jakiś zewnętrzny dzielnik.
Trochę za wcześnie jest w tym projekcie by podać odpowiedź przeczącą, tym bardziej twierdzącą. ;) Za to na pewno wtedy potrzebujesz na tych liniach zrobić konwersję napięć.
Ostatnia aktualizacja: 10.04.2019 18:57:47 przez teh_KaiN
10.04.2019 21:12
[#21]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@teh_KaiN, post #19
Nad czymś w tym stylu zastanawiałem się już kilka lat temu, w zamyśle był CPLD do międzymordzia z amigą i jej sygnałami, a do tego jakiś SoC Allwinnera, ewentualnie FPGA Cyclone V z wbudowanym Cortex A7 (bodajże 600MHz). MCO w STM32 z tego co kojarzę można przez dzielnik podać ...
10.04.2019 23:41
[#22]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@teh_KaiN, post #14
To nie jest problem, możesz robić 16bitowe zapisy i odczyty, trzeba tylko dorobić układ, który będzie multipleksował linie D0-D15<->D16-D31 w zależności od stanu linii A2, ale tracisz wtedy na przepustowości do CHIP dwukrotnie.
Można też zrobić automat, który będzie czytał i zapisywał dane 32-bit, najlepiej by było gdyby z ARM wychodził wtedy sygnał, który by sygnalizował chęć dokonania zapisu/odczytu większego niż 16-bit, byłby on w sumie konieczny jeśli chodzi o zapis danych 32-bit. To byłby taki quasi-dynamic-bus sizing który 020 i 030 mają na wyposażeniu fabrycznie, umożliwiał by on np. czytanie słów z adresów parzystych.
Można też zrobić automat, który będzie czytał i zapisywał dane 32-bit, najlepiej by było gdyby z ARM wychodził wtedy sygnał, który by sygnalizował chęć dokonania zapisu/odczytu większego niż 16-bit, byłby on w sumie konieczny jeśli chodzi o zapis danych 32-bit. To byłby taki quasi-dynamic-bus sizing który 020 i 030 mają na wyposażeniu fabrycznie, umożliwiał by on np. czytanie słów z adresów parzystych.
11.04.2019 12:11
[#24]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@spidi, post #1
W sumie pomysł mi się podoba - jeśli dobrze zrozumiałem to całkowicie zastępuje procesor? Jeśli tak to wolałbym(nie wiem ile osób uważa podobnie), żeby było w postaci karty do A2000, a na karcie (np. na tylnym panelu obudowy) przełącznik między realnym 68000 a nowiutkim procesorem. W A2000 jest sporo miejsca. Nawet kiedyś myślałem o przerobieniu otwartego projektu A2000 copro, ale nie wiem czy nie skończyłoby się brakiem masy czy innego ważnego elementu 
.
. 11.04.2019 17:32
[#26]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@abcdef, post #25
Wszyscy tak piszą przy wielu akceleratorach, a potem okazuje się, że coś w jakimś przypadku jest nie tak...
Poza tym to też kwestia subiektywna - ja wolę mieć komputer który jednym przełącznikiem można wrócić do stanu niemalże początkowego, zabytkowego. M. in. dlatego, że to pokazuje jak dalece można rozbudować zabytkowy komputer. Oczywiście można polemizować czy to ma sens, ale wtedy wdamy się w dyskusję czy nie lepiej używać po prostu smartfona podłączonego do ekranu i z działającą myszką i joystickiem(na moim działa)...
Poza tym to też kwestia subiektywna - ja wolę mieć komputer który jednym przełącznikiem można wrócić do stanu niemalże początkowego, zabytkowego. M. in. dlatego, że to pokazuje jak dalece można rozbudować zabytkowy komputer. Oczywiście można polemizować czy to ma sens, ale wtedy wdamy się w dyskusję czy nie lepiej używać po prostu smartfona podłączonego do ekranu i z działającą myszką i joystickiem(na moim działa)...
11.04.2019 18:37
[#27]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@pgru2, post #26
Hmm... przy jakich konkretnie? Bo każdy akcelerator wykorzystujący fizyczną motorolkę automatycznie skreśla kompatybilność wsteczną z 68000@7MHz chyba, że jest na 68000 i ma dość swobodną możliwość regulacji taktowania. Żaden nie ma cycle exact, bo żaden nie emuluje 68000 :) Vampire też nie emuluje 68000. Vampire to implementacja procesora zgodnego z listą 68000+020+030+040+060+więcej, z 32bitową przestrzenią adresową, z cache i kontrolerem DDR SDRAM. I do tego jest wyżej taktowany.
O ile mi wiadomo ten akcelerator o którym tu mowa jest jedynym, którego idea bazuje na stworzeniu na innym procesorze wirtualnego środowiska uruchomieniowego dla aplikacji 68k. Innymi słowy firmware mikrokontrolera zapisany w instrukcjach Thumb2 monitoruje GPIO i dekoduje sygnały wychwytując instrukcje 68k, które wydzielony fragment firmware tj. właściwy emulator JIT przetwarza korzystając z zasobów Cortex M4/M7 (pewnie). Później mikrokontroler odpowiednio ustawia GPIO tak jakby to zrobił fizyczny procesor ze swoimi liniami sygnałowymi. Co prawda tryb cycle exact nie był przez autorów poruszony (i mnie to nie dziwi, bo raczej nie o to chodzi w akceleracji ;) ) niemniej teoretycznie jest możliwy.
O ile mi wiadomo ten akcelerator o którym tu mowa jest jedynym, którego idea bazuje na stworzeniu na innym procesorze wirtualnego środowiska uruchomieniowego dla aplikacji 68k. Innymi słowy firmware mikrokontrolera zapisany w instrukcjach Thumb2 monitoruje GPIO i dekoduje sygnały wychwytując instrukcje 68k, które wydzielony fragment firmware tj. właściwy emulator JIT przetwarza korzystając z zasobów Cortex M4/M7 (pewnie). Później mikrokontroler odpowiednio ustawia GPIO tak jakby to zrobił fizyczny procesor ze swoimi liniami sygnałowymi. Co prawda tryb cycle exact nie był przez autorów poruszony (i mnie to nie dziwi, bo raczej nie o to chodzi w akceleracji ;) ) niemniej teoretycznie jest możliwy.
11.04.2019 23:29
[#28]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@teh_KaiN, post #19
UDS/LDS to prawdopodobnie 1:1 sygnały NBL1/0, NWAIT - być może da radę podpiąć wprost do pinu DTACK, tak samo NE1 w roli AS, a NWE w roli RW. Pozostaje kwestia VPA/VMA. Co do zegara E - STM chyba umie wyrzucić z siebie zegar, pytanie czy dałoby radę go ładnie podzielić do 700kHz potrzebnego dla CIA. A jak nie to coś zaimprowizować na PWMie albo dodać jakiś zewnętrzny dzielnik.
Nie można sobie od tak podłączać sygnałów sterujących wprost do Amigi, wymagana jest emulacja cyklu procesora w miejsce którego jest podłączany każdy akcelerator, to się tyczy każdego procesora, nawet tego samego, ale taktowanego wyższym zegarem. E, VPA i VMA to archaiczna szyna, już w A600 jej obsługą zajmuje się sam chipset zamiast procesora (procesor dostaje dtack), procesory 020 w górę w ogóle nie obsługują tej szyny. Obsługę tych sygnałów zrealizuje najtańszy CPLD i jeszcze zostanie miejsca na co innego. W dodatku, popraw mnie jeśli się mylę, jeśli FMC jest rodzajem pamięci, który można podpiąć pod procesor obsługiwać ją natywnie, to znaczy, że przy próbie odczytu, procesor po prostu się zatrzyma, przez co trzeba będzie dodać jakieś przerwania (pytanie, czy procesor jest w stanie zareagować na przerwanie w środku natywnego cyklu odczytu/zapisu).
Pojawienie się sygnału DTACK nie oznacza w każdym przypadku pojawiania się prawidłowych danych na szynie, pojawia się on celowo wcześniej, aby procesor nie wykonywał stanów oczekiwania. ARM z powodu swojej prędkości będzie chciał zczytać stan linii danych praktycznie w tym samym czasie. Nawet taki 68EC020 taktowany 7MHz wymaga dodatkowej logiki i opóźniania DTACK, gdy podłącza się go w miejsce 68000 7MHz, bo ma trochę inne timingi i jego cykl trwa 3 okresy zegara zamiast 4-ch.
Ostatnia aktualizacja: 11.04.2019 23:35:40 przez sanjyuubi
12.04.2019 08:33
[#29]
Re: Amiga i ARM czyli Amiga ARM Accelerator Development Board
@sanjyuubi, post #28
Tak, ARM będzie wisiał do momentu pojawienia się DTACKa - jak przerwania w tym wszystkim działają pozostaje do tej pory niesprawdzone.
To nie jest tak że wpinam sobie sygnały między Amigę a STMa i patrzę co wyjdzie. Trochę posiedziałem nad timingami cyklu z dokumentacji 68k, poczytałem też trochę dokumentację STMa. Jesteś w stanie w pewnym stopniu w STMie konfigurować opóźnienia przed/po sygnałach w cyklu zapisu/odczytu, dlatego ten kontroler pamięci nazywa się flexible. ;)
Oczywiście najłatwiej było to zrobić przy użyciu CPLD i się nie pierdzielić, unikając tym samym wielu problemów, jednak ja się jeszcze w późniejszym stadium projektu chętnie pobolcuję żeby zmusić samego STMa do gadania z Amigą - jeśli się uda to raz że będzie schludniej, dwa że taniej w produkcji, trzy że łatwiej dla hobbystów. Ale faktycznie, może na coś się przydadzą te wszystkie CPLDki co mam po niedziałających proteinach... ;)
To nie jest tak że wpinam sobie sygnały między Amigę a STMa i patrzę co wyjdzie. Trochę posiedziałem nad timingami cyklu z dokumentacji 68k, poczytałem też trochę dokumentację STMa. Jesteś w stanie w pewnym stopniu w STMie konfigurować opóźnienia przed/po sygnałach w cyklu zapisu/odczytu, dlatego ten kontroler pamięci nazywa się flexible. ;)
Oczywiście najłatwiej było to zrobić przy użyciu CPLD i się nie pierdzielić, unikając tym samym wielu problemów, jednak ja się jeszcze w późniejszym stadium projektu chętnie pobolcuję żeby zmusić samego STMa do gadania z Amigą - jeśli się uda to raz że będzie schludniej, dwa że taniej w produkcji, trzy że łatwiej dla hobbystów. Ale faktycznie, może na coś się przydadzą te wszystkie CPLDki co mam po niedziałających proteinach... ;)