Będzie mały elaborat, sorry.
Zacznijmy od początku. Znajomy kupił lata temu stację FDD3 (pudełkową, z układami EFGJ) na katowickiej giełdzie. Okazało się, że jest uszkodzona. Z powodu braku czasu, czy innego powodu, ta stacja przeleżała ładnych kilkanaście lat. Ostatecznie chcieliśmy ją ożywić - co się udało i usterkę opisałem w innym z Moich wątków.
Lecz jeszcze przed naprawą stacji pojawił się pomysł by na podstawie schematu zrobić zamienną płytę kontrolera stacji. Przecież po sieci dawno krążył schemat FDD3000 na układach TTL z pamięcią DRAM i nie było tam układu ULA. Pisałem o Moich wątpliwościach co do układu sterującego RAS/CAS pamięci jaki tam zastosowano, no ale jak nie wykonasz to się nie przekonasz...
I w taki sposób powstała tymczasowa płyta - taki
Proof of Concept - na podstawie tegoż schematu. Możecie ją zobaczyć na zdjęciu. Główna logika trafiła na dolną płytę, a DRAM plus multipleksery na dodatkowej płytce. Zadbałem o to by znaleźć układy z odświeżaniem 7 bitowym. Z80 jest dość wybredny.
Oczywiście nie odpaliło to od pierwszego włączenia. Najpierw myślałem, że to problem ze źle zrobioną logiką w układzie GAL (U2) i powstało kilka wersji. Jak już wszystkie możliwości się wyczerpały to zacząłem myśleć nad wymianą płytki DRAM na taką która zawiera 64KB ale na pamięci statycznej i taka płytka powstała. Widać ją leżącą na napędzie. Zawiera kości z cache starych płyt głównych i386 i i486 - bo miałem ich sporo z demontażu tych płyt - oraz prosty dekoder na 74HCT00.
Dalej stacja nie chciała współpracować. O ile układ WD1770 dawał jakieś oznaki życia, np. przesuwając głowicę na ścieżkę zerową, to TOS nawet nie próbował się wczytać. I dosłownie paręnaście dni temu mnie natchnęło.
Przecież my tu mamy do czynienia z FDD3000 a nie FDD3 i całkiem możliwe, że wgrany TFBOOT.BIN z Trójki nie pasuje.
Przeprogramowałem EEPROM na ten z FDD3000 i... TOS się wczytał, a nawet zgłosił chęć do pracy. Czyli problemem nie był ani RAM, ani GAL, tylko to, że TFBOOT próbował szukać sygnału DRQ nie na tym porcie co trzeba.
Ale nie uprzedzajmy faktów. Skoro działa z pamięcią SRAM to teraz pora na płytkę-zagadkę z DRAM. Po podmianie stacja nie ruszyła - czyli jednak cały układ przerzutnikowy jest wadliwy... No nie do końca. Przecież na symulacji w symulatorze logicznym to ma prawo działać!
Przyglądając się innym rozwiązaniom generacji sygnałów RAS/CAS to w 90% opóźnienia są robione na układach RC i z reguły są to bardzo krótkie czasy. W pewnym artykule dotyczącym spinania pamięci DRAM z Z80 przeczytałem o możliwości zrobienia tego synchronicznie, ale tam wykorzstano sygnał zegarowy sprzed podziału. Może taktowanie tego układu prędkością CPU to za mało? Bo przecież zanim pojawi się CAS to minie jakieś 2,5 taktu, a tam już Z80 niecierpliwie czeka na dane.
Przekrosowałem sygnał zegarowy na CLK8M, może tu jest "czeski" błąd na schemacie. Niestety niewiele to zmieniło, dalej TOS się nie wczytuje. Mamy do dyspozycji tylko jeszcze jeden sygnał zegarowy 16MHz prosto z tranzystora. Po przekrosowaniu... TOS się wczytuje. Czyli timingi są ważne, a ktoś w TIMEX projektując ten układ, albo go źle narysował, albo też mieli ten sam problem i taka wersja nie wyszła z fazy prototypu, i woleli użyć sprawdzonej ULA, która nie będzie wydziwiać co do bitowości odświeżania DRAM. Nie wiadomo...
Cóż. Nasz PoC zadziałał w końcu, ale czy na pewno działa dobrze. Nie mam wolnego układu UART więc tego przetestować nie mogę - bo nie będziemy "rwać" kontrolera z działającej stacji. Komunikacja z ZX działa. Stacja się przedstawia. Da się wykonywać polecenia systemu TOS z poziomu ZX BASIC. Nawet da się formatować dyskietki - zdjęcie kolejne.
Natchnęło mnie też by stacji zamontować tylko 8KB RAM. Na pająka zrobłem płytkę z inwerterem i jednym układem 6164, z zapasów kości cache a jakże. TOS próbował się wczytać, ale przy 3 ścieżce się poddał.
I teraz pojawiło się pytanie ile pamięci tak naprawdę widzi system w stacji? TOS zadowoli się 16KB RAM, ale do uruchomienia CP/M trzeba już 64KB. Zatem spróbujmy i CP/M 2.2.
Program terminala się wczytał i uruchomił, ale po wyświetleniu ponaglenia o dyskietce systemowej nic się nie dzieje. Mimo, iż użyłem dwóch różnych kopii, CP/M sie nie zgłasza. Ba! Nawet nie słychać by się ładował. Stacja po zresetowaniu się nie odzywa, a terminal zostaje z wyświetlonym komunikatem.
I tu zaczyna się właściwa część dlaczego powstał ten wątek. Skoro na FDD35 i na FDD-X działa zarówno TOS jak i CP/M, a to też są klony robione na podstawie wersji TTL, to coś dalej musi być nie tak z tym schematem/setupem.
1. Czy problemem może być brak zamontowanego układu UART? Osobiście nie sądzę by CP/M uważał go jako "must have". A przynajmniej do samego załadowania systemu.
2. Idąc za ciosem, wyciągnąłem sobie boot sektor z dyskietki systemowej CP/M i tam aktywnie wykorzystywane są przerwania z układu WD1770 - patrz dezasemblacja z moimi komentarzami. O ile mam sygnał INTRQ przepuszczony przez GALa - który tylko go neguje - i doprowadzony jest on do Z80, to zastanawiam się czy tam jeszcze nie ma jakiejś logiki z nim związanej. Przecież przepuszczanie go przez PALa tylko w celu inwersji byłoby marnowaniem termów, równie dobrze może to zrobić jeden z buforów - tak jak to robi z sygnałem RESET i CLK4M.
3. Czyżby płytka pamięci DRAM i o dziwo SRAM nie działała prawidłowo, i nie ma dostępnych pełnych 64KB? Był może jakiś program diagnostyczny do FDD3000, który uruchomiony w pamięci stacji mógłby to przetestować?
