On Tue, 9 Jul 2024 09:15:22 +0200, Atlantis wrote:
> On 8.07.2024 20:05, J.F wrote:
>> a) przerwania tam masz? Prawidłowo odzyskują rejestry przy powrocie?
>
> Hmm... Jednak wygląda na to, że przerwania też najwyraźniej są jednym z
> czynników, które muszę wziąć pod uwagę. W ramach eksperymentu dodałem
> instrukcję DI na wejściu procedur BIOS-a oraz EI tuż przed powrotem z
> nich. Oczywiście tam, gdzie mogłem - w przypadku procedur związanych z
> klawiaturą nie mogłem sobie na to pozwolić, bo pobieranie kodów
> wciskanych klawiszy odbywa się w przerwaniach.
> Efekt jest taki, że teraz DDT działa w sposób znacznie bardziej
> konsystentny - teraz kolejne polecenia "D" powodują dumpowanie pamięci,
> nie mam już pustych linijek. Niemniej DIR nadal nie printuje całości, a
> TYPE zwraca tylko pierwszy znak z pliku.

Postęp duży, ale - prawidłowo odtwarzasz rejestry po przerwaniu?

Pamieci video tam nie masz, to jest RS na terminal ?

> Generalnie odnoszę wrażenie, że system działa na tyle stabilnie, że
> byłem w stanie spokojnie napisać i przetestować na nim BIOS-a, opierając
> się na printach debugowych. Zachowanie pisanego kodu było na tyle
> jednoznaczne, że byłem w stanie wyszukiwać i poprawiać pojawiające się w
> nim błedy. Wczoraj przykładowo dodałem obsługę procedury WBOOT. Myślę,
> że spokojnie mógłbym dodać obsługę WRITE oraz optymalizację
> odczytów/zapisów (żeby nie czytać z/pisać do cztery razy do tego samego
> sektora karty CF, jeśli już ma się jego zawartość w buforze).
>
> Wygląda to tak, jakby BIOS działał zgodnie z założeniami, ale coś psuło
> funkcjonowanie wyższych warstw. I jasne, nie mogę wykluczyć problemu z
> przekłamaniem podczas ładowania, tylko byłoby to dziwne, żeby problem
> wyjątkowo konsystentnie dotykał CCP/BDOS, nie wprowadzając chaosu do BIOS.a
>
> Wygląda to trochę tak, jakby coś w moim kodzie psuło działanie wyższych
> warstw, tylko nie jestem w stanie stwierdzić co...

przerwania, stos, bufory danych ...

J.