CP/M, karta CF i MCY7880

[Atlantis]

Ktoś z was ma może jakieś doświadczenia z portowaniem CP/M-a na własne urządzenia oraz obsługą kart CF na starych procesorach ośmiobitowych?
Próbuję obecnie uruchomić ten system na moim komputerze z polskim mikroprocesorem MCY7880 (https://hackaday.io/project/161333-polon-7880).
Udało mi się osiągnąć kilka niewielkich sukcesów, ale jest też sporo problemów do pokonania.
W wielkim skrócie:
1. Budując hardware nie wziąłem pod uwagę buforów pomiędzy kartą CF i magistralą systemową. Niektóre wpisy w Internecie zwracają uwagę na fakt, że może to być przyczyną problemów w przypadku systemów na starych CPU. I chyba faktycznie trafiłem na taki problem, bo z podręcznej kolekcji kart tylko jedna działa (względnie) stabilnie. Pozostałe co prawda przechodzą inicjalizację, ale nie chcą się czytać - odmawiają współpracy albo na etapie próby odczytania informacji o karcie, albo podczas odczytu MBR. Kilka kart niby czytało poprawnie MBR, ale już próba załadowania jakiegoś programy przez bootloader (kopiowanie do pamięci 16kB spod adresu pierwszej partycji) kończyła się przekłamaniami. Najczęściej gubione były bajty o wartości 0xFF. Tylko jedna karta działa na tyle stabilnie, że byłem w stanie załadować i uruchomić CP/M, który właśnie próbuję przeportować.
2. Udało mi się przygotować roboczą wersję BIOS-a. Dopóki procedury odpowiedzialne za operacje dyskowe były zastąpione prostymi stubami (za sprawa których system myślał, że ma do czynienia z pustym, niesformatowanym dyskiem) wszystko działało względnie stabilnie. Mogłem wpisywać polecenia do prompta, ale oczywiście niewiele byłem w stanie zdziałać w systemie pozbawionym dysków.
3. Problemy zaczęły się w momencie, gdy zacząłem dodawać procedury do obsługi dysku. Na chwilę obecną CP/M widziw zawartość partycji systemowej (przygotowanej pod linuksem za pomocą cpmtools) ale nic nie działa stabilnie. Czasem komenda "dir" wylistuje zawartość dysku, czasem pokaże tylko jeden plik, czasem kilka, a czasem komputer się podczas tej operacji zawiesi. Możliwe, że objawił się wspomniany wcześniej problem z niestabilnym odczytem karty, ale równie dobrze może to być coś innego, np. nadpisywanie pamięci przez stos.
4. Dodałem dodatkowe printy debugowe. Teraz widzę na przykład, że system po uruchomieniu przechodzi przez poszczególne sektory (zapewne sprawdzając segment DIR partycji) ale z jakiegoś powodu po dodaniu tych printów system zaczął się zawieszać (nie reaguje na klawiaturę) zaraz po wyświetleniu prompta...

Ktoś mógłby polecić jakieś podejście do debugowania takiego systemu? Czy faktycznie bufory na liniach karty CF mogą pomóc?

[tapy]

Najczęściej gubione były bajty o wartości 0xFF.

Ewidentne niedopasowanie sygnałów, tu tylko pomoże bufor i to w technologii HC. Pamiętaj, CF to CMOS z bardzo krótkimi czasami narastania, co powoduje kompletny bełkot dla powolnego NMOS.
Myślę, że powinieneś się skupić na tym elemencie, obsługa CF w CP/M jest trywialna, więc nie podejrzewam byś tam popełnił błąd skoro jesteś w stanie napisać własny BIOS CP/M.
Generalnie CF w systemach 8080/Z80 to temat rzeka i jeśli chcesz osiągnąć jak największą kompatybilność to polecam zapoznać się z moimi wypocinami na ten temat, które jak na razie najlepiej się sprawdzają w realnych systemach.

[Atlantis]

Ewidentne niedopasowanie sygnałów

No cóż... Trochę się tego obawiałem.

tu tylko pomoże bufor i to w technologii HC.

No cóż... Trzeba będzie usiąść i sklecić moduł z buforami.
HCT też może być? Takie układy chyba mam pod ręką, HC nie jestem pewien.

Pamiętaj, CF to CMOS z bardzo krótkimi czasami narastania, co powoduje kompletny bełkot dla powolnego NMOS.

To się odnosi ogólnie do procesorów NMOS, czy jest szansa, że niektóre są szczególnie narażone? Jakby nie patrzeć 8080 na tle nieco późniejszych CPU jest dość przestarzały technologicznie, przez co chociażby wymaga trzech napięć zasilających. Istnieje możliwość, że np. MC6802 albo MOS6502 będą sobie lepiej radziły z bezpośrednią komunikacją z kartą CF?
Pytam, bo mam na warsztacie kilka kolejnych komputerków, w których docelowo też chciałbym ładować dyskowy system z karty CF (np. CP-68 z epoki albo napisany ostatnio port CP/M pod 6502). Przygotowałem już płytki ze złączami karty, ale niestety wszędzie zapomniałem o tych nieszczęsnych buforach...
Zastanawiam się też na ile znaczenie ma sposób montażu - ten mój komputer na MCY7880 został zmontowany na dwóch płytkach prototypowych, przy pomocy dużej ilości kynaru i srebrzanki. To był pierwszy eksperyment z tego typu konstrukcją - dopiero w późniejszych poczułem się pewniej i zmontowałem je na trawionych PCB - ciągle jednak robionych własnoręcznie, jednostronnych, z mnóstwem mostków po stronie elementów. Tak więc i tutaj obciążenia pojemnościowe na liniach mogą się dawać we znaki...

Myślę, że powinieneś się skupić na tym elemencie, obsługa CF w CP/M jest trywialna, więc nie podejrzewam byś tam popełnił błąd skoro jesteś w stanie napisać własny BIOS CP/M.

Nie żeby to było jakoś bardzo skomplikowane.

Generalnie CF w systemach 8080/Z80 to temat rzeka i jeśli chcesz osiągnąć jak największą kompatybilność to polecam zapoznać się z moimi wypocinami na ten temat, które jak na razie najlepiej się sprawdzają w realnych systemach.

Generalnie najbardziej zależy mi na kompatybilności z MCY7880, MC6802 oraz MOS6502 - te komputerki mam już (przynajmniej częściowo) złożone i obecnie je uruchamiam, przygotowując stronę programową. Zaczynałem od jakichś prostych BASIC-ów i monitorów pamięci, jednak docelowo chciałbym mieć na nich pełnoprawne dyskowe systemy operacyjne. W kolejce czekają kolejne, podobne projekty na MC68008, 8085 oraz 8088. Te jak na razie istnieją tylko jako niedokończone projekty płytek w komputerze, więc tym razem już nie zapomnę o dodaniu buforów.

[tapy]

Generalnie, co model/producent karty CF to jest inaczej. Może się okazać, że również trafisz na taką kartę CF która takich buforów nie będzie potrzebować w Twoim systemie. Jest to suma efektów - jej wewnętrznej budowy i obciążeń pojemnościowych tak wykonanych połączeń. Mówiąc o niedopasowaniu CMOS-NMOS mocno uprościłem swoją wypowiedź, bo tak naprawdę nie chodzi o technologię wykonania a o problemy w trakcie podłączania bardzo szybkich urządzeń do powolnych (mam na myśli czasy narastania sygnałów). Bufory HC/HCT będą tu tak naprawdę spełniały rolę "spowalniacza" (podobny efekt można również osiągnąć za pomocą szeregowych rezystorów 10-33R i niewielkich pojemności <100pF do masy na każdą linię danych), a nie regeneracji sygnału. Jeśli dotarłeś do mojego wpisu to z pewnością zauważyłeś, że zbudowałem kilka modeli modułów CF dla systemów RC2014/RCBus by w jego ostatecznej wersji zrezygnować z buforów. Związane to było ze sposobem sterowania, problem odbić nadal w nim występuje, ale nie ma on wpływu ma cykle odczytu CPU które są dokonywane gdy szyna jest już ustabilizowana. Jak tu wspominałem, możesz nie dokonywać żadnych zmian w swoim projekcie, wymaga to jednak zalezienia takiego modelu karty CF która będzie w nim działać niezawodnie (tak jest zbudowana zdecydowana większość projektów 8-bitowych i nikt się tym tak naprawdę nie przejmuje).
PS. Bufor nie zawsze jest tym świętym Graalem, więc musisz podejść do tego tematu bardzo ostrożnie.

[krru]

Sorki za poprzednią treść, pomyliło mi się z kartą SD. Karty CF ogólnie są dość mało powtarzalne. Mam taką w Amidze - i też jeden rodzaj działa, inne nie. Kiedyś używałem takich kart w sterownikach PC104 i też trudno było wybrać typ który działał. Może prościej będzie z kartami SD.

[tapy]

Karty CF ogólnie są dość mało powtarzalne.

Nie jest to do końca prawda, jeśli sterowanie karty CF jest zgodne obowiązującym je standardem, to działają niezawodnie. Niektóre modele kart CF tolerują duże odchyłki od tego standardu co jest wykorzystywane w prostych amatorskich konstrukcjach. Tu obowiązuje zasada, "nie działa? - użyj innej karty". Z SD w retro systemach jest pewien problem, gdyż nie ma dla nich dedykowanego interface (nie licząc obecnie już egzotycznego TP3465) więc ich obsługa wymaga CPLD lub współczesnego mikrokontrolera. Dochodzi tu jeszcze jeden problem - zegara SD, który musi być minimum 120% zegara CPU dla Z80, by jego wydajność miała sens jako pamięć masowa dla systemu operacyjnego. Dla niewielkich częstotliwości CPU nie jest to kłopotliwe, problem się pojawia gdy ten zegar staje się wyższy, a prawdziwe wyzwanie pojawia się wtedy, gdy w grę wchodzi użycie DMA do transferów. Kompletnie pomijam różnice sterowania SD dla poszczególnych jej rodzajów.

[KWF]

@tapy: dziękuję za podzielenie się linkiem do Twojego artykułu o współpracy Z80 z kartami CF. Jest on bardzo rzeczowy i coraz trudniej znaleźć tak dobrze napisane artykuły techniczne. Na własnej skórze doświadczyłem "niezgodności" kart CF z Z80 oraz różnic w obsługach różnych typów kart SD.

Trzymam kciuki za opracowanie uniwersalnego rozwiązania dla kart CF i SD dla retro sprzętów obsługiwanego z poziomu CP/M.

[tapy]

Myślę, że problem z kompatybilnością kart CF jest już rozwiązany, mój projekt jest już powszechnie używany w środowisku RC2014/RCBus. Na tak skonstruowanym interface nie działają tylko karty CF które nie obsługują trybów PIO (generalnie to one nie powinny się nazywać CF, bo standard wymaga obsługi takich trybów), ale to jest margines dostępnych na rynku kart. Artykuł i cały projekt jest efektem posiadania przez mnie wyjątkowo upartego konwertera SD-CF, którego producent odrobił lekcje i zbudował go zgodnie z rygorami specyfikacji CF. Uznałem, że czas skończyć z doborem karty do posiadanego systemu komputerowego, bo mają tam działać wszystkie.
Inną alternatywą jest budowa pełnego 16-bitowego interface IDE (za pomocą 8255 lub projektu GIDE) gdzie dostępne konwertery do praktycznie każdego rozwiązania pamięci masowej. Więc w systemach retro można używać dysków IDE i SATA, kart CF i SD oraz nawet dysków SSD w standardzie MSATA. Poniżej przykładowe rozwiązania, które z powodzeniem stosowałem jako pamięć masowa dla systemów z rodziny CP/M w środowisku RC2014/RCBus:

[Atlantis]

Myślę, że problem z kompatybilnością kart CF jest już rozwiązany, mój projekt jest już powszechnie używany w środowisku RC2014/RCBus.

Mógłbyś powiedzieć czy moje założenia odnośnie buforowania magistrali karty CF są poprawne. Przeprojektowałem płytkę mojego modułu w ten sposób, by dodać do niej dwa układy 74HCT245.
Na chwilę obecną połączenia zamierzam wykonać w sposób następujący.

Pierwszy 74HCT245:

• A1..A8 - połączone z D0...D7 (od strony magistrali systemowej)
• B1..B8 - połączone z D0..D7 (od strony karty CF)
• DIR - połączony z IO_RD (od strony magistrali systemowej)
• OUTPUT ENABLE - połączony z linią CS karty (od strony magistrali systemowej)

Drugi 74HCT245:

• A1 - nieużywany i podciągnięty do masy
• B1 - nieużywany
• A2..A8 - podłącozne do linii A0, A1, A2, RST, IO_WR, IO_RD oraz CF_CS (od strony magistrali systemowej)
• B2..B8 - podłącozne do linii A0, A1, A2, RST, IO_WR, IO_RD oraz CF_CS  (od strony karty CF)
• DIR - podciągnięty do VCC
• OUTPUT ENABLE - połączony z linią CS karty (od strony magistrali systemowej)

Przy takich połączeniach będzie działało poprawnie?

[tapy]

Myślę, że drugi bufor nie jest konieczny i zakradł się tam pewien błąd - sygnał Reset jest niezależny od wyboru układu.

[Atlantis]

Myślę, że drugi bufor nie jest konieczny

Czyli jedyne co muszę buforować to linie danych? Linie adresowe, CS, RD i WR nie wymagają osobnego buforowania?

i zakradł się tam pewien błąd - sygnał Reset jest niezależny od wyboru układu.

Faktycznie, umknęło mi to. Dzięki za zwrócenie uwagi.

[tapy]

Czyli jedyne co muszę buforować to linie danych? Linie adresowe, CS, RD i WR nie wymagają osobnego buforowania?

Tak, szyna danych jest tu najważniejsza (z powodów opisywanych powyżej). Co do buforowania szyny adresowej, RD, WR,... to wszystko zależy od obciążenia tych sygnałów. Ważne by nie przekroczyć możliwości 8080 i taki bufor powinien znajdować się przy CPU, bo przy pojedynczym układzie I/O on obciąży je tak samo co dodatkowe bufory.

[Atlantis]

Ok, spróbowałem wykonać moduł karty z buforem 74HCT245 na liniach danych, ale coś jest nie tak...
Połączenia wyglądają u mnie następująco.

• Linie A1..A8 układu 74HCT245 (piny 2-9) -> magistrala danych od strony systemu.
• Linie B1..B8 układu 74HCT245 (piny 11-18) -> magistrala danych od strony karty, oczywiście z zachowaniem kolejności.
• Linia G/OUTPUT_ENABLE układu 74HCT245 (pin 1) -> linia CS karty CF. Oczywiście ta sama linia jest też cały czas podpięta do wejścia CS karty.
• Linia DIR układu 74HCT245 -> linia IO_RD z magistrali systemowej. Oczywiście linia ta jest też cały czas podłączona do wejścia RD karty CF.
• VCC (pin 20) -> oczywiście do +5V, z kondensatorem 100 nF w pobliżu.
• GND (pin 10) -> oczywiście do masy.

Niesttey po podłączeniu tego modułu komputerek w ogóle nie chce startować. Czasem po resecie na ekranie pojawiają się losowe znaki, czasem nic. Zupełnie jakby coś mieszało na magistrali. Jeśli wyjmę kartę z gniazdka, to efekt znika, komputer startuje normalnie, nie wykrywa karty (bo jej nie ma) i odpala się w trybie TinyBasica. Czyli raczej można wykluczyć uszkodzenie samego bufora.

Co zrobiłem nie tak?

[Atlantis]

Ok, okazuje się, że za powyżej opisywany problem była odpowiedzialna taśma sygnałowa, łącząca płytki.
Na chwilę obecną wiadomości są dwie, dobra i zła:

• Moduł z buforem 74HCT245 na liniach danych działa. Udało mi się za jego pomocą zmusić do pracy karty, które wcześniej działać nie chciały (chociaż jak na razie nie wszystkie testowane zadziałały).
• Nadal występuje problem z niestabilnością systemu, który albo wywala się na komendzie DIR, albo nie chce wylistować wszystkich plików.

Co jeszcze mogę zrobić? Powinienem dodać buforowanie jeszcze na jakichś innych liniach? A może zastosowanie 74HC245 zamiast 74HCT245 ma szansę poprawić sytuację? Czy może jednak powinienem uznać, że przyczyna leży gdzie indziej?

[tapy]

Myślę, że sprawy hardwarowe już ogarnąłeś, czas szukać błędu w software. Poprawne załadowanie systemu operacyjnego świadczy o tym że interface CF działa, to co dzieje się już po uruchomieniu CP/M to kwestia BIOS.