Procesor NMOS i karta CF

Ok, udało mi się załadować do pamięci (prowizorycznie) działający CP/M. Na razie jeszcze nie dostarczyłem pełnych wersji procedur odpowiedzialnych za obsługe dysku, więc system nie widzi zawartości partycji, jednak mam dostępny prompt. Poza tym będę musiał jeszcze dopracować obsługę klawiatury, bo mam drobnego buga. Tak czy inaczej - tym razem bootloader ładuje do pamięci 32 sektory z karty CF (16kB) i za każdym razem mam powtarzalny efekt. Można więc chyba założyć, że dobrana karta CF działa prawidłowo. Przy tym stopniu złożoności oprogramowania przeskoczenie choćby jednego bajtu powodowałoby kompletny chaos.

Tym niemniej te wczesniejsze cuda są warte diagnozy.

P.S. Zapisz na karcie program, który będzie ładował 32 sektory pod inny adres i porównywał.

Zabootuj, zmien kartę, wystartuj program :)

J.

Niewykluczone, że świętowanie mogło być przedwczesne. Właśnie testuję pierwszą wersję do odczytu sektorów z karty CF i tłumaczenia ich na 128 bajtowe sektory CP/M. System plików został przygotowany wcześniej na Linuksie, za pomocą cpmtools. Niestety w chwili obecnej działanie jest niestabilne. "DIR" nieraz zwraca całą zawartość partycji, nieraz tylko jej część, a innym razem zawiesza komputer na nieskończonym odczycie. Niestety nie wyskakują przy tym żadne błedy BDOS-a, wiec będę musiał dodać dodatkowe printy debugowe żeby wiedzieć, co się tak właściwie dzieje z perspektywy BIOS-a. Możliwe, że to kwestia jakiegoś buga w moim kodzie, ale mógł też powrócić problem z kartą.

To może być kwestia Twojego podejscia do programu. Masz przeczytać 512 bajtów, to odbieraj 512, z zabezpieczeniem czasowym, a nie wysyłaj komendę odczytu, a potem odbieraj póki są dane.

Oscyloskp by się przydał, i to szybki, 2 czy więcej kanałowy, żeby zobaczyc co się tam na pinach karty wyrabia, łącznie z masą i zasilaniem ...

J.

Prawdę mówiąc nie bardzo rozumiem co mi da takie podejście. Karta otrzymuje komendę wysłania określonej liczby sektorów i wysyła je ustawiając flagi. Jeśli w pewnym momencie to się rozjedzie i karta z jakiegoś powodu wyśle więcej (lub mniej) danych niż ją o to poproszono, to i tak jest unrecoverable error. A już na pewno CP/M nie jest na tyle inteligentny, żeby z takiej sytuacji się wywinąć i jedynym rozwiązaniem będzie reset. Tak więc tak czy inaczej, niezależnie od podejścia mamy ten sam wynik - niedziałający system.

Wyjście jest jedno - trzeba będzie namierzyć przyczyną i ją usunąć. Przy czym na chwilę obecną nie jestem nawet pewien czy oryginalny problem z przeskakiwaniem bajtów faktycznie jest przyczyną obecnych kłopotów ze stabilnością.

Te nowe problemy pojawiły się dopiero wtedy, gdy zacząłem dodawać do BIOS-a procedury odpowiedzialne za operacje dyskowe. Gdy początkowo w ich miejscu były tylko podstawowe stuby (za sprawą których system myślał, że ma do czynienia z pustym, niesformatowanym dyskiem) wszystko działało poprawnie i stabilnie, chociaż oczywiście niewiele dało się w takim systemie zrobić. ;)

Teraz dzieją się rzeczy dziwne - system czasem wylistuje zawartość dysku, czasem pokaże tylko część plików, a czasem się zawiesi podczas tej operacji. Dodałem trochę printów debugowych, ale to wprowadziło kolejne problemy. Bo teraz na przykład widzę, że podczas wstępnego sprawdzania dysku ładowane są kolejne sektory, ale z jakiegoś powodu po ukończeniu tej operacji system zawiesza się zaraz po wyświetleniu prompta i przestaje reagować na klawiaturę - ale tylko jeśli włączę te debugi.

Oczywiście możliwe, że jest to winą tego oryginalnego problemu z kartą (bo np. dodatkowy kod zwiększa prawdopodobieństwo, że gdzieś jednak przeskoczy ten bajt) ale równie dobrze może to być coś zupełnie niezwiązanego, np. przepełnienie stosu.

Więc chyba najlepiej byłoby faktycznie zrobić moduł z buforami i zobaczyć czy ogólnie poprawi to sytuację. Jeśli dotychczas niedziałające karty nagle zaczną działać będę wiedział, że przyczyna leży gdzie indziej. Bo faktycznie dość dziwnie wygląda fakt, że tylko na jednej karcie CP/M w ogóle chce się bootować i nijak nie daje mi to gwarancji, że jej działanie jest w 100% poprawne.

W wolnej chwili spróbuję się podpiąć i zobaczę.

Coś dzisiaj wolno myślę, bo dopiero teraz dotarło do mnie co masz na myśli. Jeśli polegam tylko na flagach, to nie mam gwarancji, że faktycznie odbiorę dokładnie 512 bajtów. Co prawda do tej pory miałem do czynienia tylko z sytuacją, kiedy bajty były tracone, ale przecież nie mam gwarancji, że nie dojdzie do przekłamania skutkującego wysłaniem nadmiarowych bajtów. I w takiej sytuacji wskaźnik bufora będzie nadal inkrementowany, co doprowadzi do nadpisania innych obszarów pamięci. To może tłumaczyć niestabilność i zawieszenia. No cóż... Na chwile obecną jedynym sensownym wyjściem będzie zrobienie buforów na liniach.

Ok, w końcu znalazłem trochę czasu, żeby się za to zabrać. Wykonałem nową wersję modułu karty CF, tym razem z buforami (układ

Główny problem nie został wyeliminowany - system nadal wywala się (na kilka różnych sposobów) przy próbie wylistowania zawartości dysku.

Aby mieć większą pewność, że system ładuje się poprawnie dodałem prostą procedurę, która po załadowaniu CP/M liczy CRC16 obszaru pamięci, w którym przechowywany jest jego kod wykonywalny (CCP+BDOS+BIOS). Na chwilę obecną widzę, że wartość ta jest powtarzalna przy każdym rozruchu systemu oraz zmienia się, jeśli wprowadzę jakąś modyfikację do BIOS-a. Jeszcze nie porównywałem z obrazem źródłowym na dysku PC - muszę poszukać jakiegoś programu, który pozwoli mi wyliczyć analogiczną sumę kontrolną z pliku bin generowanego podczas budowania systemu.

Sporo zaczyna wskazywać, że mój problem może jednak mieć programowy charakter.

Dodałem do programu printy debugowe, które informują o wejściu w poszczególne procedury BIOS-a oraz zrzucają zawartość poszczególnych parametrów odpowiedzialnych za operacje dyskowe, które są w nich ustawianie.

Z szybkiej analizy tych logów wynika, że przy starcie systemu:

1. Cyklicznie są wołane procedury SETDMA, SELDSK, SETTRK, SECTRN, SETSEC i READ.
2. Parametr TRACK ma na początku wartość 0x0000, a potem jest sukcesywnie podbijany o jeden w zakresie od 0x0020 do 0x003F.
3. Parametr SECTOR przyjmuje wartości od 0 do 3, przechodząc jeden cykl na jedno podbicie parametru TRACK.
4. Parametr DMA przyjmuje albo adres bufora DISK_BUFFER (0x0080) albo DIRBUF.
5. Odbywają się sukcesywne odczyty z karty CF, a wartość LBA jest liczona poprawnie (adres początku partycji + parametr TRACK).

Printy debugowe mogą być włączane i wyłączane dyrektywą budowania warunkowego. I tutaj jest jedna rzecz, która mnie zastanawia - kod zachowuje się inaczej po dodaniu tych printów.

Jeśli je włączę, system wchodzi w procedurę BOOT, zaczyna czytać kartę i zrzuca powyżej wymienione logi. Potem wyświetla prompt i zawiesza się - klawiatura przestaje reagować.

Jeśli logi WYŁĄCZĘ system się uruchamia, czyta kartę (nie mam oczywiście logów, ale widzę świecenie diody aktywności) po czym wyświetla prompt i pozwala mi wypisywać polecenia. Zwykle wtedy dzieje się jedna z dwóch rzeczy:

- System zawiesza się po wykonaniu komendy DIR.

- System zwraca niepełna zawartość dysku po wpisaniu komendy DIR, ale pozwala na wpisywanie kolejnych komend.

Ktoś ma pomysł co może być nie tak i jak to dalej debugować?

W dniu 2024-07-03 o 08:10, Atlantis pisze:

Co nie tak to nie wiem, ale bym zaczął usuwać printy debugowe po jednym aż dojdziesz do stanu bez nich - wtedy będziesz miał winnego zawieszenia po prompcie.

Pozdrowienia, MKi

To chyba normalne - potrzebne do czytania danych.

Chyba też normalne - czyta katalog, a potem plik.

To też w miare normalne - czytasz kolejne sektory. Tylko ... nie za mało? 4 sektory na ścieżce? Sektory po 128 czy 512B

Moze implementacji na karcie CF tak najprosciej.

Nie pamietam ... ale gdzie masz ustawiony wskaźnik stosu? Byc może z logiem zużywa parę bajtów więcej i zajeżdza cos poniżej ? Juz nie pamietam, ale czy shell (CMD ?) nie ładował się do góry pamięci?

Ewentualnie - czytane dane zajeżdzają stos.

To już chyba moze być objaw gubienia bajtów z sektorów.

J.