Interface FDD nie robi nic innego, tylko gada ze stacją po porcie $ef.
Są jakieś przeciwwskazania, żeby wydawać komendy stacji poprzez polecenia exDOSu?
Sprzętowo wystarczy dowolny wolny 8 bitowy port (lub dwa. tak, wiem że nie wszystkie bity są wykorzystane)
Protokół jest rąbnięty, ale dość prosty.
Tak, ale... nie. Chodzi o zachowanie dotychczasowych funkcjonalności, a są one obsługiwane przez RST 8 w obu urządzeniach. Najlepiej by było, jakby ktoś napisał wspólny ROM M397+esxDOS, ale jakoś w to nie wierzę.
Listy poleceń wewnętrznych TOS ktoś kiedyś zamieszczał w Bajtku, niech sobie przypomnę...
Serio?
Tak na szybko, więc raczej źle (o CP/M 3 czytałem dawno temu) to mogła by zadziałać konfiguracja :
ZX128 (można wykolegować obszar pamięci ekranu z przestrzeni adresowej), interface z ALLRAM i bios CP/M napisany praktycznie od nowa (żeby wykorzystywał ile się da ROM divMMC i być może Spectrum, opcjonalnie umieszczony w pamięci divMMC - nie trzeba będzie wtedy swapować pamięci ekranu)
Nie tyle BIOS, co BDOS przepisany w ten sposób, by zamiast procedur BIOS wołać procedury w ROM esxDOS.
Zachowanie zgodności na poziomie BIOS to pogodzenie się z wszystkimi ograniczeniami danej implementacji CP/M.
Prostszy pomysł to wziąć ZX+3 (który ma CP/M 3) i spatchować BIOS tak, by korzystał z divMMC (lub samej karty via porty i/o) jako dysku (do 512M zdaje się)
Tu największym problemem będzie zapewne zdobycie źródeł BIOSu. Pewnie skończyłoby się na deasemblacji 
Ale ten temat rozumiem, że załatwia ROM +3e (w przypadku wewnętrznego adaptera CF) lub divXXX z driverem z hiszpańskiej strony, którą linkowałem. Tylko - jak pisałem - nie podoba mi się do końca to rozwiązanie z przyczyn praktycznych (kłopotliwe przygotowanie, specjalna partycja tylko na start CP/M itp.) i technicznych (brak hires).
A nie lepiej nową wersję FDD3 z 1M RAM i stronicowaniem skrojonym pod CP/M?
Spec niech się zajmuje tym co robił do tej pory, czyli obsługą klawiatury i ekranu
Tak, ale... nie
Po pierwsze - mnoży się byty, bo większość z nas ma jakiś divXXX, a tu trzeba jego odpowiednik wkładać do FDD3000. Po drugie - spiralny kabel pozostaje wąskim gardłem, czyli można zapomnieć o jakichś żwawszych zastosowaniach typu animacje z karty pamięci itp. Ale może to po prostu z definicji nie ma sensu, nie wiem, może faktycznie wypasiony FDD3000, ale znów pojawiają się problemy - karta pamięci FAT? Katalogi? Limit plików? Co to obsłuży? Jakiś port esxDOS doklejony do CP/M 3.x? Ile osób będzie zainteresowanych taką konfiguracją, dziesięć? Pięć? Dwie?...
Jakiś czas temu, w ramach ćwiczenia wiotczejącego umysłu, zacząłem badać studium wykonalności scalenia FDD3000 z klonem Spectrum w ten sposób, by oba światy korzystały z jednego procesora i jednej puli stronicowanej pamięci. O ile technicznie byłoby to dość skomplikowane, o tyle logicznie rozwiązuje większość problemów, o których wspominałem (z wyjątkiem ostatniego - tzn. liczby zainteresowanych potencjalnych użytkowników
).
Działałoby to mniej więcej w następujący sposób:
- linia NMI sterowana byłaby albo przyciskiem (jak w divXXX), albo timerem, albo dostępem do określonych portów (np. #EF). Wszystkie możliwości maskowalne z poziomu portu konfiguracji.
- nowy port I/O trzymałby informację o bieżącym kontekście procesora (Spectrum/FDD3000/możliwe inne, nawet dla poszczególnych aplikacji).
- urządzenia we/wy miałyby oddzielne mechanizmy adresowania dla Spectrum i FDD, zrealizowane przy użyciu dwóch oddzielnych linii /IORQ1 i /IORQ2 - tak, by w obu kontekstach nie właziły sobie w paradę. Podobnie można zrobić z ROM i RAM, choć nie trzeba.
- pamięć RAM stronicowana w blokach 16KB, ile, 512KB? Może być 512. Może być użytkowana przez divXXX w razie potrzeby.
- pamięć ROM podobnie.
- wywołanie NMI włącza specjalny ROM, który zapamiętuje bieżący kontekst i ładuje docelowy (np. zapis do portu #EF przełącza na kontekst FDD3000). Trochę jak przełączanie procesów w systemach z multitaskingiem, ale... trochę więcej
- na potrzeby wirtualnego M397 dodajemy dwukierunkowy port, widziany od jednego końca jako #EF, a od drugiego - jako #2F, jeśli mnie pamięć nie myli.
No i jeszcze na koniec, niekoniecznie potrzebny bajer:
- CPU z programowo przełączanym CLK 3,5/7/14/... MHz.
Jak to działa? Na przykład - wydanie jakieś komendy TOS (CAT*...) spowoduje wywołanie odpowiedniego kodu w pamięci ROM wirtualnego interfejsu M397, co doprowadza do wysłania komendy TOS do portu #EF. Dane te są zatrzaskiwane w rejestrze i jednocześnie następuje przełączenie kontekstu na FDD3000. Tam pętla oczekiwania na komendę odczytuje dane z rejestru (tym razem pod adresem #2F) i wykonuje polecenie, po czym zapisuje dane wynikowe do portu, przełączenie kontekstu, odczyt danych.... i tak w kółko. W tak prostym przypadku użytkownik nie odczuwa żadnych lagów, bo komunikacja przez M397 to tak naprawdę pętle oczekiwania.
I w to wszystko wkomponowujemy divXXX, które dla każdego kontekstu ma inne adresy I/O i inny ROM - ale po żadnej stronie nie mamy wąskich gardeł, bo danych z/na kartę pamięci nie trzeba przepychać przez port #EF/#2F. Tak naprawdę komunikację przez ten port można przyspieszyć, przełączając CLK na szybszy - a timeouty i tak przecież nie grożą
. Można też przerobić ROM M397 i TOS (oraz CP/M), by zamiast tego portu używały jakiejś lokacji we współdzielonej pamięci. I to nie 4 bitów czy całego bajtu, ale nawet dużego bufora.
Łomatko... Jak człowiek nie pracuje, to nadmiar mocy obliczeniowej swojej sieci neuronowej przeznacza na jakieś nieużyteczne dziwactwa
