On 8.07.2024 20:05, J.F wrote:

> A to sugeruje problemy z odczytem dysku.

Absolutnej pewności mieć nie mogę, ale wygląda na to, że karta CF jest
czytana poprawnie. Wcześniej (przed buforem na liniach danych) miałem
problemy na niektórych kartach, głównie w przypadku odczytu wartości
0xFF. Teraz te problemy zniknęły.


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

Printowałem sobie wyrywkowo zawartość buforów i porównywałem je z
obrazem karty na dysku - wszystko było ok. Teraz DDT działa u mnie na
tyle dobrze, że też wyrywkowo porównałem sobie bajt po bajcie kilka
fragmentów pamięci z plikami lst. I też nie widzę przekłamań.
Będę musiał dodać liczenie sumy kontrolnej z fragmentu obrazu i
porównywać je z wartością liczoną z zawartości pamięci po załadowaniu.
Wtedy będę miał pewność, że wszystko jest ładowane poprawnie.


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

Jeśli chodzi o TYPE, to po prostu wraca do prompta i pozwala na
wydawanie kolejnych poleceń. Ale w międzyczasie zauważyłem jeszcze jedną
rzecz. ten średnik to po prostu pierwsza litera obydwu plików, które
chciałem wyprintować (to pliki źródłowe, zaczynające się od komentarza).
Żeby to potwierdzić, wrzuciłem na kartę jeszcze jeden plik tekstowy i
faktycznie wyprintowała się tylko jego pierwsza litera.
Czyli z jakiegoś powodu TYPE poprzestaje na tym jednym znaku. Jasne, to
może być problem wynikający z jakiegoś przekłamania (chociaż byłoby to
wyjątkowo konsystentne przekłamanie) ale może to też być powodem tego,
że mój bios psuje coś w działaniu wyższych warstw. Tyle tylko, że parę
razy już sprawdziłem, czy przypadkiem któryś z rejestrów nie jest
permanentnie nadpisywany i nie mogę się dopatrzeć takiej sytuacji.


> A to jest potrzebne? nie pamiętam juz.

Pewien nie jestem. Może wyższe warstwy już to robią. Jednak w przypadku
BIOS-a nie mam pewności co się działo na chwilę przed jego zawołaniem,
więc chyba dobrą praktyką jest zrobienie kopii zapasowej na stosie
jakiegoś rejestru, jeśli mam zamiar wykorzystać go w roli "pola
roboczego". Oczywiście nie odnosi się to do tych rejestrów, w których
finalnie i tak zwracany jest wynik operacji.


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

BDOS ma swój własny stos. Gdy jest wołany tymczasowo podmienia na niego
stos użytkownika. Ponieważ stos ten jest relatywnie niewielki, a
niektóre z operacji w moim BIOS-ie zrzucają trochę bajtów, w swoim
kodzie robię to samo - przy wejściu do niektórych procedur zapisuję
wartość SP, podmieniam na swój stos BIOS-a, po czym po skończonej
robocie przywracam oryginalną wartość.


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

Tak, przerwania są. Inicjowane są jeszcze przed CP/M-em i wykonują kilka
niskopoziomowych operacji I/O. Patrzyłem na ich kod, ale nie widzę
niczego podejrzanego. Zresztą TinyBasic nie miał żadnych problemów ze
stabilnością, a przerwanie mieszające w rejestrach procesora dość szybko
by go zmasakrowało.


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

Wyprintowałem wartości i wszystko się zgadza. Sektory zmieniają się w
zakresie 0..3, a liczony adres początku danych w buforze to
adres_bufora_cf + (sektor * 128)


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

Pamiętasz jak to się robiło?


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

Na chwilę obecna nie jest używane. System korzysta w tej chwili tylko z
32kB pamięci zmapowanej na stałe na fragment przestrzeni adresowej. Mam
jeszcze drugie 32kB w postaci dwóch banków po 16kB, ale one nie są w tej
chwili wykorzystywane. Gdy uda mi się rozwiązać ten problem, pewnie
poupycham w nich różne bufory pomocnicze (np. do odczytu/zapisu CF albo
przewijania ekranu)..