speccy.pl
Facebook Like


WIKI SPECCY.PL

[WIKI SPECCY.PL]
Zaprzyjaźnione serwisy

PIXEL HEAVEN 2019
Forum ZX Spectrum
[RÓŻNOŚCI] Odp: Turbo XT w ładnej obudowie wysłana przez tooloud Dzisiaj o 01:21:11
[WSPÓŁCZESNE KLONY] Odp: A to co? Spectrum Next. wysłana przez tooloud Dzisiaj o 01:08:48
[RÓŻNOŚCI] Odp: ZX Spectrum issue 3b 2018 remake wysłana przez Maryjan Wczoraj o 23:18:34
[POWITANIA] Odp: Dobry ;) wysłana przez PABB Wczoraj o 22:16:46
[RÓŻNOŚCI] Odp: ZX Spectrum issue 3b 2018 remake wysłana przez PABB Wczoraj o 21:47:29
[RÓŻNOŚCI] Odp: ZX Spectrum issue 3b 2018 remake wysłana przez andy Wczoraj o 21:44:05
[HARDWARE] Odp: Stacja P.Z APINA wysłana przez Klaud Wczoraj o 21:41:04
[POWITANIA] Odp: Dobry ;) wysłana przez Michał olo Wczoraj o 21:36:48
Archiwum plików ZX Spectrum
[Demoscena] Dodano "Silence of the AY" z roku 1995 dla komputera ZX Spectrum 48K Autorzy: Kriss, Drozol, Pyza, Bigyo. Dodany przez Pyza^Illusion, 2019-11-13 10:05:34
[Demoscena] Dodano "The Ravers Paradise" z roku ???? dla komputera ZX Spectrum 48K Autorzy: Maniu, Kriss, Angelo, RadXcellent, Pyza. Dodany przez Pyza^Illusion, 2019-11-10 12:45:43
[Demoscena] Dodano "Judgment Day 3" z roku 1993 dla komputera ZX Spectrum 48K Autorzy: Muad'dib, Drozol. Dodany przez Pyza^Illusion, 2019-11-10 12:30:35
[Demoscena] Dodano "Coca-Cola Demo" z roku 1990 dla komputera ZX Spectrum 48K Autor: Frank Dux. Dodany przez Pyza^Illusion, 2019-11-10 12:28:55
[Demoscena] Dodano "Constant II - The Second Voice Preview" z roku 1994 dla komputera ZX Spectrum 48K Autor: Ilyad. Dodany przez Pyza^Illusion, 2019-11-10 12:17:12
[Demoscena] Dodano "Xeniusaurus Rex" z roku 2019 dla komputera ZX Spectrum 48K Autor: Joker. Dodany przez John Dalthon, 2019-09-25 21:54:45
[Demoscena] Dodano "Strange Movements of Sandkings" z roku 2018 dla komputera ZX Spectrum 48K Autor: Joker. Dodany przez John Dalthon, 2019-09-25 21:52:44
[Demoscena] Dodano "Salvador" z roku 2018 dla komputera Autor: Joker. Dodany przez John Dalthon, 2019-09-25 21:50:34
Więcej...
Nawigacja
Kulisy powstawania emulatora FDD3000

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

rogerjowett
rogerjowett dnia 29.11.2013 14:30:14

https://www.youtube.com/watch?v=zsjTpFR0oYQ

no one is working on patches for 3d vecotr programmes or freescape
4mhz80 with 64kb of ram is going begging in the fdd3000 - we even have bbc basic now for the 48k machines - that must surely be able to use a coprocessor even if unlike in the bbc it was not intended to

can anyone help get lcd's bmp2scr to convert 512x384 interlaced and hmpr bit 5&6 clut modifications for more than 16 colours per scan line please

Dodaj komentarz
Nick:

Kod potwierdzający:
Kod potwierdzający


Oceny
Tylko zarejestrowani użytkownicy mogą oceniać zawartość strony
Zaloguj się , żeby móc zagłosować.

Brak ocen. Może czas dodać swoją?