ok, w BBC było łatwiej bo ma jakoś tam wyprowadzone odpowiednie sygnały. Być może jednak za pomocą przejścówki/FPGA dało by radę podłączyć RPI do złącza procesora.
Z tego co rozumiem, reszta po stronie RPI jest już gotowa.

@Sikor, no tak, z tym że dorobienie obsługi Halt to kwestia modyfikacji oprogramowania po stronie RPi.

dla tego w pierwszym poście napisałem "ktoś coś słyszał?", bo być może ktoś zaczął już to podgryzać.

Swoja drogą to jest taki projekt RPI z emulacją 68000 dla Amigi i niebawem też Atari ST.

Panowie,

Nie chciałbym tu "gasić światła", bo to jest do zrobienia z Atari 8-bit, ale nie w ten sposób. Tube Port w BBC micro to nie jest po prostu czysta/pełna szyna danych... po drodze jest logika z kilkoma FIFO, mechanizm wymiany danych jest bardzo uproszczony. Sam kod dla Tube Pi obsługujący to złącze jest naklepany w ASM i rezerwuje dla siebie jeden z rdzeni, aby wyrobić się w sensownym czasie. ROM BBC wspiera dodatkowe CPU, więc realizacja tego projektu bez dodatkowej logiki była możliwa. W przypadku JIL da się to zrobić jednak trzeba dołożyć trochę glue-logic, ale to wszystko to jest najmniejszy problem... bez softu który by wykorzystał te możliwości to rozwiązanie jest nic nie warte, a tego softu trzeba napisać sporo...

Takim rozwiązaniem powiedzmy podobnym do tego był cart Zenona z 65816 (Weronika)... czy ktoś napisał jakiś kawałek sotfu na to? Doskonale wiecie że nie powstało dla tego rozwiązania zbyt dużo oprogramowania... wokół takiego rozwiązania musi powstać cały ekosystem, dobrze udokumentowany i zachęcający ludzi do tworzenia. Z masą przykładów pokazujących że warto zaangażować swój czas i siły w dane rozwiązanie.

Należy pamiętać również o tym że będzie bardzo trudno zachować odpowiednie zależności czasowe jeżeli chce się zastąpić oryginalny CPU, takim emulowanym w rasp-pi + glue logic. Tu jest wymagane 100% cycle exact, a wiadomo ile czasu zajęło uzyskanie jako-takiej zgodności autorowi chociażby Altirra. Ale zastosowanie rasp-pi jako dodatkowy co-processor pozwoliło by na zachowanie 100% zgodności ze starym softem oraz uruchamianie nowego softu, specjalnie stworzonego dla tego konkretnego rozwiązania...

Sądzę że kolejnym przykładem mógłby tu być Rapidus... no ale tutaj jest ten sam problem co z weroniką... ile powstało softu który wykorzystywałby możliwości tej dopałki? Nawet mimo tego że jest Sparta i całe środowisko dostosowane do tego rozwiązania (DracOS, etc.) nie widzę jakoś aby powstawała masa softu wykorzystująca możliwości Rapidusa. Za to są spory i wojenki przy każdej możliwej okazji.

Nie chcę tu nikogo zniechęcać do niczego i mówić że to niemożliwe, lecz uświadomić że to wszystko wymaga pewnych nakładów pracy i współpracy większej grupy ludzi.

W moim przypadku robiłem eksperymenty z innymi MCU/CPU i efekty były obiecujące, odłożyłem na półkę bo nie mam obecnie czasu/możliwości aby zaimplementować wymaganą funkcjonalność (chociażby podrasowany BASIC który korzystałby z dobrodziejstw FPU).

macie wrażenie że sprzęt wyprzedza oprogramowanie ?

A gdyby tak wykorzystać dwu-portową pamięć jako bufor pomiędzy rpi? Podobnie jak w tym projekcie:
http://www.smbaker.com/pi-powered-atari … -multicart
ale z dwukierunkową komunikacją?
Przyznam, że jestem lajkonikiem w temacie sprzętu, więc tak tylko gdybam.

seban ma 100% racji. Osobiście byłbym w stanie podłączyć prawie cokolwiek do Atari - serio, ale czy to ma sens i jakąś przyszłość? Bez oprogramowania każdy sprzęt jest tylko kupką piasku. Można robić to na zasadzie "sztuka dla sztuki, bo mogę i chcę "

To może lepiej założyć wątek życzeń gdzie by wyrażali swoje chęci i oczekiwania użytkownicy a sprzętowcy i programiści odpowiadali by w miarę składnie - czy by to było realizowalne, w jaki sposób i czy byłoby to sensowne bez powielania innych rozwiązań, itd.

:)

@tebe: a to wielki problem przemapować na inną stronę?