CRC bei einem FDC 1791 nachrechnen

    • Offizieller Beitrag

    Datenblaettern muss man immer etwas tolerant sein.

    Manchmal nur einfache Tipfehler, Widersprueche oder Unklarheiten aus mehreren Aussagen gibt's auch immer gerne.

    Oder wie in diesem Beispiel was alles in die CRC eingerechnet wird.


    Vor allem wurden Datenblaetter frueher nicht so oft korrigiert wie heute.

  • CRC Berechnungen - SOFTWARE

    Inzwischen habe ich etwas mit der SOFTWARE-Seite zum Thema "CRC's berechnen und bewerten" hantiert.


    Aus den vielen FORUM- Beiträgen (Dank an alle Verfasser) habe ich mir ein C- Programmteil ( Function) gesucht und mit dem cp/m 8080 AZTEC C-compiler in ein .ASM File erzeugt.


    Also Basis hier das c-file:


    /* updated CRC - Helmut Wiertalla -helwie44 */

    /* G-polynom = x^16 + x^12 + x^5 +1 to CTTII */

    /* G used with crc ^= 0x1021 */

    /* for floppy WD 1791 FDC calc. CRC 15-apr-2019*/

    /* static Variable for best code generation */


    static c; /* 16 bit Variable c */

    static crc; /* 0xFFFF for WD 1791 */

    static i; /* local loop Variable */


    unsigned u17crc()

    {

    for ( i = 0 ; i < 8 ; i++)

    crc = (crc << 1) ^ ((((crc >> 0x8) ^ (c << i)) & 0x0080 ) ? 0x1021 : 0);

    return crc;

    }


    Der 8080 CODE von Hand nachgearbeitet.

    Vom Grundsatz sind STATIC Variablen von der Laufzeit günstiger gegen dynamische Variablen ( STACK - Frame). Als Loop Variable i wird hier mit dem Register C verwendet. Auch die sonst üblichen clib.rel ( subroutinen) für die C-Sprachkonstrukte wie schieben links oder recht schieben und die logischen Funktionen exklusive OR oder AND sind als direkter 8080 CODE jeweils direkt eingesetzt worden. Damit benötigt man nicht die C-libery die oft einiges an Overhaed beinhaltet für die Laufzeit!

    So braucht man nicht den CALL und auch nicht die RET (8080) Befehle.

    Sicher könnte sich jemand noch etwas an Laufzeit raus holen - wer Lust und Zeit hat...

    CRC Voraussetzungen im WD17xx FDC

    Bei Address MARK (AM) oder Data Mark (DM) sind immer drei 0xA1 Byte erforderlich!


    Für den CRC-Wert von einer AM ( 0xFE ) Address MARK sind immer mit

    3 mal 0xA1, 0xFE und die Track, Side, SectorNr, key-lng erforderlich! Das sind also acht byte, dann gefolgt der CRC-WERT (16 Bit)! Im Grundzustand muss auf das CRC Register mit 0xFFFF belegt werden.


    Mit dem CRC - Startwert 0xCDB4 (bei mir) sind schon drei 0xA1 byte vorberechnet , weil ich aus meinen RAW Leseversuchen nur real in dem RAW-Buffer zwei 0xA1 byte vor der AM oder der DM (0xFB) gefunden habe!

    Es wäre interessant - ob jemand mit einem cp/m Rechner schon mit dem RAW read track gearbeitet haben - und wie z.B. bei verbreiteten 5 1/4 Zoll Floppy-Disks, mit 40 Track und 16 Sectoren zu je 256 Byte - Erfahrungen haben?


    Vorbelegung im CRC-REGISTER (zur Nachrechnung):

    LXI h,0CDB4h ;special crc start with 3 x A1 calc.


    Weitere Ergebnisse und Infos folgen.

    • Offizieller Beitrag

    Vom Grundsatz sind STATIC Variablen von der Laufzeit günstiger gegen dynamische Variablen ( STACK - Frame).

    Das mit C üben wir aber nochmal.


    An der Stelle sind das ganz normale Variablen und haben nichts mit dynamischem und Stack zu tun.


    Und wenn du static Variablen innerhalb einer Funktion benutzt, sind es wieder normale Variablen, nur aussrhalb der Funktion nicht sichtbar.

    • Offizieller Beitrag

    dynamische Variablen ( STACK - Frame).

    Du hast damit angefangen.


    Code
    int test1(int parameter1, int parameter2)
    {
        int dynVar1;
        float dynVar2;
    
        mach_nichts();
    
        return 0;
    }

    Das sind Variablen, die auf dem Stack landen und "dynamisch" beim Eintritt in die Funktion angelegt werden und ebim Verlassen ungueltig werden.


    "dynamisch" in Anfuehrungsstrichen, weil man von dynamischen Variablen / Speicher in Verbindung mit malloc() etc spricht.