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. 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...