Seria niefortunnych zdarzeń.

Emulator FDD3(000) z początku wcale nie miał być emulatorem. Jak wiadomo, takiego emulatora po prostu nie da się napisać - więc po co próbować. FDD3000e miał być symulatorem stacji. Symulatorem, czyli czymś co z punktu widzenia użytkownika zachowuje się (niemal) dokładnie jak oryginalna stacja, ale tak naprawdę działający ‘po swojemu’. A prawdę mówiąc, symulatora też miało nie być, ale...

...ale w piwnicy dokopałem się ponad setki wypełnionych po ostatnie sektory dyskietek z Dawnych Dobrych Czasów. Szybki research po pudłach i pudełkach ujawnił dwie stacje dysków. Jedną, pracującą oryginalnie z FDD (czyli stary, podwójnej wysokości jednostronny, 40-to ścieżkowy napęd produkcji bodaj IBM) i młodszy napęd 1,2M. Staruszek odmówił współpracy z nowym komputerem, ale młodsza wiekiem stacja dziarsko zamrugała diodą po podłączeniu. Dalej było czyszczenie stacji i dyskietek, rycie netu za programem do zrzucania obrazu dyskietki i kolejne popołudnia wypełnione brzęczeniem silników krokowych.

Jeśli chcesz coś mieć zrobione dobrze...

 Zrzucone obrazy dyskietek przez długi czas leżały odłogiem na dysku. Nie pojawiały się żadne programy ani emulatory które by potrafiły zrobić z nich użytek. W dodatku niemal wszystkie (o ile nie wszystkie) zapisane na tych dyskietkach gry zostały przerobione tak, by korzystały ze stacji do zapisywania rekordów, ustawień, wczytywania leveli itp. więc dla ‘gołego’ Spectrum były nieprzydatne. Do napisania ‘czegosia’ który by obsługiwał obrazy z FDD podchodziłem kilka razy - za każdym razem jak pies do jeża :) Koniec końców uznałem, że tak naprawdę nie potrzebuję emulacji całej stacji. Moje zmiany w grach zawsze korzystały z procedur Timex Interface.  Spectrum odwołuje się wyłącznie do TI, a TI nie musi wiedzieć co ma ‘po drugiej stronie drutu’ i jeśli procedura symulatora będzie gadała zgodnie z protokołem, interfejs nawet nie zauważy różnicy. Był plan.

 Następnym krokiem było kolejne rycie netu, tym razem za literaturą. Schematy, noty katalogowe, wsady do ROMów, wszelkie możliwe informacje o TI, TOS, FDD. W ruch poszły disasembler i edytor txt. Zanim opadł pierwszy entuzjazm, miałem gotową procedurę obsługującą protokół transmisji FDD<->TI. W sensie - mogłem odbierać i wysyłać bajty danych z i do TI. Teraz trzeba było nadać im jakiś logiczny sens... Zatem mozolna implementacja kolejnych funkcji TOS - od tych najbardziej podstawowych (otwarcie i zamknięcie kanału/pliku) po bardziej zaawansowane (czytanie i pisanie całych bloków danych, obsługa poleceń LOAD/SAVE). W zasadzie w tym momencie mogłem przestać. Wprawdzie spora część poleceń nie działała (głównie dlatego, że była mniej lub bardziej interaktywna, a bez działającej stacji pod ręką po prostu nie mogłem sprawdzić jak wygląda odpowiedź stacji na polecenia) ale samo ładowanie programów, zarówno z poziomu BASICa jak i kodu maszynowego działało poprawnie.

Bo z tym cały jest ambaras...

 Napisanie emulatora FDD jest niemożliwe nie dlatego że jest niemożliwe. Bo jest. Jest wręcz niemal banalne. Niemal niemożliwe (a już na pewno szelenie trudne) jest zsynchronizowanie transmisji pomiędzy emulatorem komputera a emulatorem stacji. Protokół transmisji zakłada że procesory obu urządzeń pracują z określoną prędkością. Co jest założeniem poprawnym w stosunku do fizycznego sprzętu, ale nie do emulatora. W skrócie - procesor emulatora (w znanych mi przypadkach) pracuje z pełną prędkością komputera-hosta przez określoną liczbę cykli, a zaoszczędzony na różnicy prędkości obu urządzeń czas oddaje emulatorowi na obsługę peryferii i ekranu. W jeszcze większym skrócie - procesor działa skokowo. Co delikatnie mówiąc, rozkłada całą komunikację (próbowałem nawet takich karkołomnych kombinacji, jak uruchamianie ‘procesora’ FDD  wyłącznie na czas pracy procesora emulatora Spectrum. Wyniki były... mierne...)

Wtedy przyszła chwila olśnienia - protokół transmisji jest idealnie ‘parzysty’ - TI inicjuje transmisję, określa jej długość, po czym wysyła bajt - odbiera bajt (a w zasadzie nibble) aż prześle ich założoną wcześniej liczbę. Zawsze, bez wyjątków. Skoro nie można zsynchronizować procesorów obu ‘urządzeń’, to może da się wymusić synchronizację na poziomie transmisji?

Emulator Frankensteina

 Dalej było już z górki. Z wcześniejszych prób miałem gotowy szkielet emulatora. Wykorzystałem w nim bibliotekę z80ex do emulacji  procesora, a do obsługi obrazów dyskietek użyłem procedur z biblioteki EMULib Marata Fayzullina (nb. są one pełne błędów i mają bardzo nieprzyjemną licencję). Jako sposób komunikacji wybrałem kolejki systemowe, które okazały się strzałem w dziesiątkę. Godzinę później Fuse połączył się bez problemu z emulatorem FDD (~300 linijek kodu w C).

 Cały pomysł był banalnie prosty - stacja zawiesza się na procedurze odczytu z TI i czeka aż TI zechce z nią rozmawiać. Działa to bezproblemowo, z kilkoma wyjątkami. Jest niestety nieodporne na przerwanie transmisji - np. reset Spectrum w trakcie transmisji może zawiesić oba emulatory. Nie działa CPM. Nie działają procedury ładowane i uruchamiane wewnątrz stacji. To być może jest do przeskoczenia. Natomiast wszelkie ‘hakierskie’ programy nie dbające o zachowanie poprawnego protokołu (‘bo samo się zsynchronizuje’) nie zadziałają nigdy w obecnej postaci emulatora.

Okno na świat

 Emulator uruchamiany z konsoli bez możliwości wyboru dyskietki to żaden emulator :) Następnym krokiem było tworzenie GUI w Qt i pozbycie się resztek kodu EMULib (dużo nużącego stukania w klawisze). W ten sposób powstała jako tako wyglądająca i funkcjonalna wersja emulatora. Działająca tylko pod linuksem... Windows nie ma kolejek wiadomości które zastosowałem, ponieważ nie jest on systemem POSIXowym. Wymusza to stosowanie natywnych dla windows rozwiązań. A że na świecie chwilowo wciąż panuje windows, więc trzeba było jakoś ten problem rozwiązać.... Uparłem się, by wersje lin i win korzystały z tego samego sposobu komunikacji (żeby nie pisać dwóch diametralnie różniących się procedur komunikacji, tylko jedną różniącą się w kilku szczegółach - jest wtedy o połowę mniej miejsc do szukania błędów :) Ile metod komunikacji między procesami wypróbowałem? Chyba większość. Ile zadziałało? Chyba wszystkie. Pod linuksem. Pod windą większość rozbijała się o kwestie uprawnień. Koniec końców udało mi się wypracować działające stabilnie rozwiązanie oparte na pamięci współdzielonej i semaforach (Sprawdzone dla xp i win7. Nie wiem czy zadziała pod win8 i następnymi). Instalacja crosscompilatora (testy procedur były robione pod windowsem, ale kompilacja obu emulatorów odbyła się już pod linuksem), kompilacja Qt, fuse, fdd... I jest. Działa. Uff...

Co dalej.

 Nic. Znaczy, chwila oddechu. W następnej kolejności chciałbym wprowadzić możliwość wyboru języka komunikatów (co prawdopodobnie pociągnie za sobą konieczność dodania opcji wyboru czcionki), jest do opracowania pomysł na zmianę wyglądu emulatora. Muszę sprawdzić co blokuje CPM i uruchamianie procedur ładowanych do stacji. Gdy to wszystko szczęśliwie zadziała, emulator można będzie uznać za wersje beta. Potem prace u podstaw - możliwe że zmiana emulatora CPU na obiektowy, na pewno dużo poprawek w procedurach obsługi obrazów dyskietek.

 W tak zwanym międzyczasie pojawiła się idea (d)opracowania procedur obsługi obrazów dyskietek TOS, co otworzyłoby drogę do realizacji kilku ciekawych pomysłów (pod linuksem :) oraz do dokończenia symulatora FDD3000, który dla większości użytkowników byłby absolutnie wystarczający. I od którego się w zasadzie wszystko zaczęło.

Stojąc na barkach gigantów...

 Czyli podziękowania. Korzystałem z efektów pracy kilku osób. Największe podziękowania należą się autorom cyklu “TOS bez tajemnic” którymi byli Wojciech Jabłoński i Jacek Trojański. Bez tych artykułów nawet bym nie pomyślał o pisaniu emulatora. Niewiele bym mógł zrobić bez plików które zebrał i udostępnił José Leandro Novellón. Bardzo także pomogły informacje zebrane na stronach Jarka Adamskiego oraz Johnny’ego Red i stronie spectrum.8bit.pl.

steev