eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaProcesor NMOS i karta CFRe: Procesor NMOS i karta CF
  • 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. ;)

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: