On Mon, 8 Jul 2024 19:26:53 +0200, Atlantis wrote:
> Nadal walczę z projektem przeportowania CP/M 2.2 na mój komputerek
> oparty o polski mikroprocesor MCY7880.
>
> W ciągu ostatnich kilku tygodni udało mi się osiągnąć kilka mniejszych i
> większych sukcesów:
> - Dodałem bufor na liniach D0..D7 karty CF, co najwyraźniej zniwelowało
> (a przynajmniej ograniczyło) problemy z komunikacja pomiędzy procesorem
> i kartami. teraz system stał się kompatybilny z dużo większą liczbą kart.
> - Udało mi się dodać logi zrzucane po RS232. Dzięki temu mogłem
> sprawdzić, że parametry związane z operacjami dyskowymi (disk, track,
> sector, dma) są ustawiane poprawnie.
> - Poprawnie jest też liczony adres 128 bajtowego sektora (0..3) wewnątrz
> 512 bajtowego bloku odczytanego z karty.
> - Zawartość odczytywana z karty jest konsystentna z jej obrazem,
> wygenerowanym na komputerze (przynajmniej była w przypadku wszystkich
> wyrywkowych testów)
> - Sektory są poprawnie kopiowane do miejsca docelowego (wskazywanego
> przez parametr ustawiany w procedurze SETDMA) z bufora karty CF.
> - Po rozruchu systemu dosteję prompta i jestem w stanie wykonywać komendy.
>
> Niestety, system wciąż nie działa stabilnie. Najważniejsze problemy
> wyglądają następująco:
> - Wykonanie komendy DIR daje niekonsystentne zachowanie. Czasem (rzadko)
> wyprintuje ona zawartość dysku. Zwykle jednak printowany jest tylko
> jeden plik (ASM.COM) albo następuje zawieszenie systemu.

troche dziwaczne. Gdyby był problem z dyskiem rzadko, to by IMO więcej
potrafił pokazać.

> - Polecenie TYPE z parametrem w postaci pliku tekstowego (np. ASM)
> printuje tylko średnik, zamiast jego zawartości.

A to sugeruje problemy z odczytem dysku.

Albo ... masz CCP wczytanego błędnie do pamięci.

A co się dzieje dalej - działa dalej z błędami, czy restartujesz?
Może coś uszkadza CCP w pamięci?


> - Mogę załadować niektóre mniejsze programy, jednak nie działają one do
> końca poprawnie (o ile działają w ogóle). Np. taki DDT czasem wywala się
> przy starcie (wyświetlając w pętli tekst powitalny) albo tylko raz na
> kilka(naście) wydanych poleceń "D" printuje kolejnego hexdumpa.
>
> To co zrobiłem do tej pory:
> - Upewniłem się czy stos jest wszędzie prawidłowo podmieniany i
> przywracany oraz czy wszystkie PUSH-owane wartości rejestrów są
> poprawnie z niego zdejmowane. Faktycznie po drodze znalazłem kilka
> błędów, ale wydaje mi się, że wszystkie one zostały usunięte.
> - Upewniłem się czy wartości rejestrów są przed użyciem zachowywane na
> stosie i przywracane po użyciu. Tu też znalazłem kilka problematycznych
> fragmentów, ale wydaje mi się, że wszystkie udało mi się wyeliminować.

A to jest potrzebne? nie pamiętam juz.

> - Dodałem print sprawdzający wwartość SP. Nie wygląda na to, żeby gdzieś
> był problem z nadpisywaniem czegoś przez stos.

A gdzie ten stos wskazuje? Niestety zapomniałem, gdzie powinien.

> Dodatkowo nie sądzę, żeby problem był sprzętowy - komputerek był w
> stanie stabilnie obsługiwać TinyBasic-a.
>
> Ktoś ma pomysł jak to dalej debugować?

a) przerwania tam masz? Prawidłowo odzyskują rejestry przy powrocie?

b) ta konwersja sektorów 512/128 na pewno poprawnie działa?

c) napisałbym pare krótkich programów testujących poszczególne funkcje
BIOS/BDOS. Moze nawet wpisac hex do pamięci przez RS232/DDT.

d) policzylbym na PC sumy kontrolne wszystkich sektorów, zapisał
gdzieś w pamięci, i dodał sprawdzenie w procedurach dyskowych.

e) albo odczytywać sektor dwa razy, porównać, jak są błędy, to
powtarzać.

e) mozesz chyba przesledzic przez DDT co się dzieje w CCP po wpisaniu
DIR czy TYPE

f) ... bankowanie pamięci na pewno działa poprawnie?

J.