On Wed, 22 May 2024 17:57:57 +0200, Atlantis wrote:
> Zrobiłem kilka dodatkowych testów i wyniki są... Zaskakujące...
> Po pierwsze dodałem do kodu hexdump pierwszych 32 bajtów pamięci po
> załadowaniu kodu z karty CF. Cały programik ma zaledwie 20 bajtów, więc
> jest to wystarczająca liczba.
>
> Zawartość binarnego pliku wygląda następująco: 21 FF 7F F9 C3 07 00 0E
> 20 CD 27 C5 3E FA CD B3 C5 C3 07 00
>
> Zawartość pamięci, gdy program printuje znaki szybko: 21 FF 7F F9 C3 07
> 00 0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31
> 45 43
>
> Zawartość pamięci, gdy program printuje znaki wolno: 21 7F F9 C3 07 00
> 0E 20 CD 27 C5 3E FA CD B3 C5 C3 07 00 37 30 30 30 45 32 30 43 44 31 45
> 43 35
>
> Już na pierwszy rzut oka widać, gdzie leży sedno problemu - pomijany
> jest drugi bajt o wartości 0xFF. Wbrew mojemu oryginalnemu założeniu, to
> szybkie printowanie jest poprawnym wynikiem. Wolniejsze działanie
> (chociaż występuje znacznie) częściej stanowi efekt działania błędu.
>
> Wbrew moim podejrzeniom, błąd nie miesza w pętli opóźniającej, ale
> sabotuje początkowe ustawienie wartości stosu:
>
> 0000 ORG 0000H
> 0000 21 ff 7f START: LXI H,STACK
> 0003 f9 SPHL
> 0004 c3 07 00 JMP LOOP
>
> Wygląda więc na to, że w wyniku błedu do pary rejestrów HL trafia
> wartość 0x7ff9, ale rozkaz SPHL nie jest wykonywany (bo kod interpretuje
> jego wartość jako parametr instrukcji LXI). Wskaźnik stosu pozostaje
> więc taki, jakim ustawił go bootloader. Dlaczego powoduje to wolniejsze
> działanie programu? Nie mam pojęcia.

Masz też przestawiony program o cały bajt. Wiec choćby ten LOOP, jest
teraz pod adresem 0006, a skok jest nadal do 0007, czyli pomijasz
pierwszy bajt pętli. Co tam jest istotnego, to sam musisz zobaczyc.

> Dlaczego ładowanie danych z karty
> odbywa się z tak zadziwiająco powtarzalnym błędem? Też nie wiem...
>
> Poeksperymentuję jeszcze z kilkoma kartami. Jeśli jednak nie uda mi się
> znaleźć takiej, która będzie działała w 100% poprawnie, to trudno będzie
> myśleć o eksperymentach z CP/M. Pomyślałbym, że to faktycznie wina
> poziomów napięć i braku bufora. Tylko ta powtarzalność... Problem z
> niedopasowaniem poziomów napięć mógłby powodować losowe przekłamania
> bitów, ale nie konsystentne pomijanie całego bajtu...

A jak czytasz? Spodziewam się, ze po ustawieniu numeru sektora i
komendy odczytu go, wystarczy już odczytać kolejne bajty.
Takie zniknięcie bajtu może być spowodowane:
-karta zobaczyła fałszywą informacje o odczycie bajtu, i przeskoczyła
na następny. A to może być spowodowane właśnie poziomami napięcia,
zakłóceniami elektrycznymi, itp. Ale czemu tylko pod drugim bajtem?
A może wcale nie tylko pod drugim, i więcej bywa zgubione?

A wpisz tam inną wartość, np C0, w koncu możesz ustwic stos na
7FC0, zobaczysz czy to wartosc FF jest wredna.

-przeskoczenie licznika/indeksu w bootloaderze? Ale jaki mógłby być
powód, i czemu tylko na drugim bajcie.

Zrobiłbym też długi dump.
I moze dodał do programu kilka tablic po 256B o kolejnych wartosciach
- zobaczysz na dumpie czy się poprawnie wczytują.

J.