On 22.05.2024 18:40, J.F wrote:

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

Masz rację. Jakoś mi to umknęło. ;)


> A jak czytasz? Spodziewam się, ze po ustawieniu numeru sektora i
> komendy odczytu go, wystarczy już odczytać kolejne bajty.

Dokładnie tak. Całośc odbywa się względnie bezobsługowo. Po prostu
zgłaszamy karcie ile sektorów chcemy odczytać i zaczynając od którego, a
potem w pętli czytamy sprawdzając flagi ustawiane przez kartę.

LOAD_PARTITION1:
; Pod LOAD_BASE znajduje się już odczytany MBR
LXI D, LOAD_BASE+446+8
LDAX D
OUT CFREG3 ;LBA 0
INX D
LDAX D
OUT CFREG4 ;LBA 1
INX D
LDAX D
OUT CFREG5 ;LBA 2
INX D
LDAX D
ANI 0FH ;FILTER OUT LBA BITS
ORI 0E0H ;MODE LBA, MASTER DEV
OUT CFREG6 ;LBA 3
MVI A, 32 ;READ 32 SECTORS (16kB)
OUT CFREG2
CALL CFWAIT
MVI A, 20H ;READ SECTOR COMMAND
OUT CFREG7
LXI D, LOAD_BASE
CALL CFREAD
CALL CFCHERR
RET

CFREAD:
CALL CFWAIT
IN CFREG7
ANI 08H ;FILTER OUT DRQ
JZ CFREADE
IN CFREG0 ;READ DATA BYTE
STAX D
INX D
JMP CFREAD
CFREADE:
RET

CFCHERR:
IN CFREG7
ANI 01H ;MASK OUT ERROR BIT
JZ CFNERR
LXI D, CFERRM
CALL PRTSTG
IN CFREG1
MOV L, A
MVI H, 0H
MVI C, 4H
CALL PRTNUM
CFNERR:
RET

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

Też o tym pomyślałem. Tym bardziej, że szukając na szybko trafiłem w
Internecie na taką wypowiedź:

"From CPU speed of 7Mhz to 20MHz, the CF disk is generally fast enough
that no wait state is needed. Slowing down or speeding up the CPU clock
does not change the CF interface characteristic. The 'fast' or 'slow' CF
disk refers to the rising and falling edges of the CF output signals.
When the eight data lines of a fast CF disk simultaneously drive
capacitive loads such as a backplane with many boards, especially from
all 0's to all 1's, a large instaneous current is flowing out of the CF
disk, which cause its ground to sink lower than the system reference
ground. The ground negative spike is too brief to affect Z80 and older
TTL technology, but the CF_read line see a brief positive spike when
CF's ground is spiking down. The CF_read controls a FIFO, so a spike can
cause the FIFO to advance to next data byte thus discarding current byte
of data thus corrupt the data packet. In short, the data corruption is
self inflicted that only 'fast' CF can generate the fast ground spike
that the 'fast' CF_read can react to. For the 'slow' CF, the ground
spike is of insufficient magnitude or duration to cause its 'slow'
CF_read to skip a byte of data."



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

Też o tym pomyślałem, zrobię taki test.


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

Mało prawdopodobne. Instrukcja INX wykonuje się po każdym zapisanym
bajcie. Musiałby ten jeden raz nie przeskoczyć, powodując nadpisanie
tego 0xFF.

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

Będę musiał zmodyfikować kod hexdumpa, żeby wywalał to na RS232, bo na
razie korzystam z ekranu. ;)