-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!.POSTED.cdk152.neoplus.adsl.tpnet.pl!no
t-for-mail
From: Atlantis <m...@w...pl>
Newsgroups: pl.misc.elektronika
Subject: Re: Procesor NMOS i karta CF
Date: Wed, 22 May 2024 19:10:32 +0200
Organization: ICM, Uniwersytet Warszawski
Message-ID: <v2l8u8$2os56$2@news.icm.edu.pl>
References: <v2ka94$2ncku$1@news.icm.edu.pl> <v2l4m6$2onvc$1@news.icm.edu.pl>
<m...@4...net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 22 May 2024 17:10:32 -0000 (UTC)
Injection-Info: news.icm.edu.pl;
posting-host="cdk152.neoplus.adsl.tpnet.pl:83.30.160.152";
logging-data="2912422"; mail-complaints-to="u...@n...icm.edu.pl"
User-Agent: Mozilla Thunderbird
Content-Language: en-US, pl-PL
In-Reply-To: <m...@4...net>
Xref: news-archive.icm.edu.pl pl.misc.elektronika:791930
[ ukryj nagłówki ]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. ;)
Następne wpisy z tego wątku
- 22.05.24 19:14 Atlantis
- 22.05.24 22:08 Atlantis
- 23.05.24 10:09 Atlantis
- 23.05.24 10:54 J.F
- 23.05.24 11:09 Atlantis
- 23.05.24 13:52 J.F
- 23.05.24 15:18 Atlantis
- 23.05.24 17:47 J.F
- 23.05.24 18:15 J.F
- 23.05.24 20:33 Atlantis
- 23.05.24 21:51 J.F
- 24.05.24 19:02 Atlantis
- 24.05.24 19:15 Atlantis
- 04.06.24 10:58 Atlantis
- 04.06.24 20:15 J.F
Najnowsze wątki z tej grupy
- Fejk muzyczny czy nie fejk
- Raspberry Pi 3 Model B+
- Kuchenka elektryczna
- test
- Cewka elektrozaworu
- zapytanie o chip r5f21275nfp
- nie naprawiam więcej telewizorów
- Zrobił TV OLED z TV LCD
- Zasilacz USB na ścianę.
- Gniazdo + wtyk
- Aliexpress zaczął oszukiwać na bezczelnego.
- OpenPnP
- taka skrzynka do kablowki
- e-paper
- 60 mA dużo czy spoko?
Najnowsze wątki
- 2025-03-16 Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- 2025-03-16 Nowa ustawa o ochronie praw autorskich - opis problemu i szkic ustawy
- 2025-03-16 Najlepszy akumulator 12V
- 2025-03-16 Co powinno spotkać "adwokatów dwóch" uczestniczących w przesłuchaniu świadka do którego nie dopuszczono adwokata świadka?
- 2025-03-16 Przednich p-mgielnych nie wolno bez mgły
- 2025-03-16 Co w KANADZIE wolno komercyjnie (na razie się nie czepili?)
- 2025-03-16 silnik-chwilówka
- 2025-03-16 Prokurator Wrzosek "Bezstronna" nie przyczynia się do śmierci (dowodnie) - oświadcza bodnatura [Dwie Kacze Wieże]
- 2025-03-15 kraje nieprzyjazne samochodom
- 2025-03-15 parking Auchan
- 2025-03-15 Art. 19.1 ustawy o ochronie praw autorskich
- 2025-03-15 przegląd za mną
- 2025-03-15 Na co komu okna
- 2025-03-15 Mój elektryk
- 2025-03-15 Fejk muzyczny czy nie fejk