CRC bei einem FDC 1791 nachrechnen

    Für später brauche ich eine Software Nachrechnung der CRC (Cyclic Redundancy Check) Werten bei den AM "address mark" und/oder der "data mark" -Bereiche. Hier handelt es sich um eine 5.25 Zoll Floppydisk wie bei einer Alphatronic P2 oder ähnliche Disketten/ Maschinen wie diese im Einsatz sind. Als Basis ist ein FDC Floppy Disk Controller CHIP vom Typ 1791 bei den P2 verbaut.


    Ein AM -Feld ist folgend aufgebaut aus 4 byte:

    1. byte := TRACK , 2.byte := SIDE, 3.byte := SECTOR, 4.byte := KEY-länge.

    Nun folgt das CRC mit zwei byte also 16 Bit.


    Generatorpolynom:

    Aus den Datenblätter vom 1791 steht das folgende Polynom.

    CRC-CCITT (CRC-16) für Disketten G(x):: = X16 + X12 + X5 +1


    Es geht hier um die Berechnung / Überprüfung der CRC-Werte vom 1791 CHIP.

    Eine kleine PDF Abhandlung zum Thema , mit Hintergrund und Rechenbeispiele und nützliche Links

    (leider bisher ungleich dem CHIP 1791 CRC - von meinen CRC Rechenschema!) unten sind beigefügt.


    Wer kann mir hier zum richtigen Beispiel- CRC16 ERGEBNIS, konkret bei einem AM-Feld CRC zum Rechenvorgang helfen.

    Klar - mit den BITs und den Rechnungen mit Polynomen ist kein Problem. Nur irgenwas (Anfangswert,

    Randwerte, Rechenschritte ... oder) scheint hier zu fehlen.


    Vielen Dank vorab und Grüße

    Helwie44




    • Official Post

    Bei den Adressmarken wird ein "fehlerhaftes" Byte geschrieben, auf jeden Fall bei MFM. Ein oder 2 Clockbits werden weggelassen.

    Wenn du es gauer wissen willst/musst, muss ich nochmal nachschauen.


    Aber vielleicht ist das der Grund fuer deine unterschiedlichen Ergebnisse.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)

    Mit den „fehlerhaften Schreiben von bytes“ -kenne ich mit bestimmten Steuerbytes. Ich meine beim Formattieren wird z.B. vor den AM‘s mit einem F5 /hex CMD wird an den Controller gesendet - aber dann ( als 3 x A1 h ) geschrieben. Das wird auch vor dem Data Mark- Feld verwendet.


    Ist mir nicht im Moment klar, wie innerhalb der Nettodaten gewisse Informationen verfälscht werden. Also nach den CMD MARK‘s wie die AM als FE h CODE geschrieben und auch identisch ausgelesen wird.



    Oder wie könnten die fehlende CLOCK‘s sich auf den Datenbereich ( AM-Bereich und/ oder Data Mark- Bereich) auswirken?

    Nach dem Hinweis von rfka01 habe ich mit dem Tool das probiert. Zuvor noch als Demonstration mit dem Tool und meinen Rechnungen von Hand.

    Von dem Online-Tool - das identisches CRC- ERGEBNIS bei 0000h wie von Hand helwie44 †.




    dazu mit der Anfangsbelegung des CRC-Register mit 0FFFF h - nach rfka01 - als Versuch.


    Hier kommt 0733E h als CRC raus.?!?

    Das ist nicht dem von FDC Chip 1791 zu 2EE2 h.

    Evtl. könnten Hardware - Entwickler oder -Experten zum Rechenablauf im FDC CHIP mehr etwas erklären.


    Vielen Dank

    Helwie44

    ... muss da nicht das address-mark byte 0xFE mit in die CRC einbezogen werden?

    Im Datenblatt steht starting with und nicht starting after ?


    CRC Logic - This logic is used to check or to generate the 16-bit Cyclic Redundancy Check (CRC). The polynomial is:
    G(x) = x16 + x12 + x5 + 1.
    The CRC includes all information starting with the address mark and up to the CRC characters. The CRC Register is preset to ones prior to data being shifted     through the     circuit

    Danke vorab an Martin Hepperle für den Hinweis. Ich probiere das 0xFE byte "ID-AM" mit zu bewerten / rechnen.

    Quote from Martin Hepperle

    The CRC includes all information starting with the address mark and up to the CRC characters.

    Also die Hexa Bytefolge : "0xFE, 0x0F,0x00,0x01,0x01" dann wären symbolisch "ID-AM, TRK, SiD, SEC, Key" diese beinhalteten bytes.


    Bei dem Anfangswert CRC-Register 0xFFFF ist hier das Ergebnis::= 0x160C.

    Bei einem Anfangwert CRC Reg. mit 0x0000 wird bei diesen sonst identischen Eingaben ein Ergebnis ::= 0x0700.


    Was würde auf der CHIP-Hardware-Ebene (1791 FDC) bedeuten, mit dem zweiten Satz aus dem o. Zitat?


    The CRC Register is preset to ones prior to data being shifted through the circuit.

    Frei nach einem Translater:

    CRC-Logik - Diese Logik wird verwendet, um den 16-Bit-Cyclic Redundancy Check (CRC) zu prüfen oder zu generieren.

    Das Polynom ist:    G (x) = x16 + x12 + x5 + 1.

    Die CRC enthält alle Informationen, beginnend mit der Adressmarke und bis zu den CRC-Zeichen.
    Das CRC-Register ist auf diejenigen voreingestellt, bevor Daten durch die Schaltung verschoben werden.


    Hier habe ich den Link zu dem OnlineTool beigefügt.


    Auf den 0x2EE2 CRC für diese ID-AM komme ich nicht, leider.

    • Official Post

    Oder du schaust hier:

    https://info-coach.fr/atari/ha…d.php#CRC_Logic_in_WD1772


    The CRC is processed beginning with the first $A1 byte which presets the CRC register,...

    Heurika .. funkenzupfer ... aber das muss ich erstmal verstehen!!!


    Der Knaller !!!



    Etwas Licht im Tunnel. Vorab danke für die Varianten. Es ist wohl auch der Tipp von rfka01 , Martin Hepperle und funkenzupfer beteiligt! Und allen anderen die sowas gelesen haben. Danke! - wie einfach es auf einmal das Problem möglich gelöst werden könnte ??

    Da werde ich intensiv auf den Bereich ID-Data und diverse Beispiele testen. - kommen noch -


    ( aber in den RAW Daten finde ich bisher real 2 x A1 bytes im Buffer !! ? evtl. das erste Byte mit den ohne CLOCK's ??? ist anders als A1 - mal sehen !!!)


    Grüße

    Helwie44

    • Official Post

    In o.g. Quelle habe ich noch folgendes PDF gefunden:

    http://info-coach.fr/atari/documents/_mydoc/WD1772-JLG.pdf


    Sehr interessant, S28, "CRC computation / verification in MFM".

    Genau dein Thema.


    Viel Erfolg.

    Ich hab' den Thread nur kurz überflogen, also z.B. nicht eruiert, was Du vor hast, bin aber über diesen Satz gestolpert.

    Code
    Mit einem READ-TRACK command an den FDC 1791 werden die RAW (binärroh) Daten ausgelesen.

    Das funktioniert, soweit ich mich erinnere, mit der Alphatronic P2 (vermutlch sogar mit den meisten FD-Controllern, die den FD1791 benutzen) nicht.


    Da ich mich noch erinnerte, das der FD1791 beim READ-TRACK Kommando irgendein Pin nicht betätigt wird, hab' ich mal die Scans meiner Aufzeichnung überflogen und die folgende Seite gefunden:



    "RG wird während des Read-Track-Kommandos nicht aktiviert"

    Das sollte lt. meiner Erinnerung dazu führen, dass keine saubere Read Clock gewonnen werden kann.

    Ich konnte jedenfalls mit diesem Kommando nie eine komplette Spur einlesen.

    Edited once, last by dlchnr ().

    Genau dlchnr vielen Dank - mit einer standard Alphatonic P2 oder ähnliche Baugruppe mit dem 1791 Chip habe ich klar nie keine vernünftige RAW Daten geliefert.


    TA hatte wohl damals einen Seiten-Effekt (unvollständige Entwicklung bei TA der FD-Karte ) bewusst eingeplant.


    Aber dafür habe ich zum TEST (Probebetrieb) die FD-Baugruppe des DS 2069 von der Fa. Dr. Ing. R. HELL, Kiel - dafür in eine Alphatronic P2U eingesetzt. Dabei müssen aber 2 BUS-Signale vom 96 VG Feld geändert und ein Signal getrennt werden. Damit ist in einem DS2069 Sichtdatengerät ( ist die Basisentwicklung von damals sks, Karlsruhe ) sofort ein READ TRACK richtig möglich. HELL hat aber alle Baugruppen überarbeitet und divese Komponenten zusätzlich entwickelt.


    Wie und warum - kommen noch später in einem kleinen Beitrag - nur zum Hintergrund.

    RAW Buffer einer Floppydisk-Spur


    Waren die HEXA Ausdruck Werte von dlchnr ( ? ID's) damals real von einer Floppydisk gelesen - oder mit einem Tool berechnet und auf diese Liste übertragen?

    Oder ging real bei einer Alphatronic P2 das FDC CMD "READ ADDRES" ? Das habe ich noch gar nicht getestet - schaue das mir noch an.


    zum RAW Buffer:

    Bei meinem Beispiel (Auszug Hexa-Dump unten) sehe ich nur maximal zwei A1 h SYNC im RAW Buffer. Durchweg bei den ID-AM und den ID DM (Data Mark).

    Weil wir jetzt (ich nun auch) wissen, sind drei A1 in die CRC Berechnung erforderlich! Das wären acht bytes für eine ID-AM benötigt (z-B.).


    00 A1 A1 FE 0F 00 01 01 2E E2

    CRC Softberechnung:


    Bei einer Softwareberechnung zum CRC sind nicht (immer) exakt 3 A1 vorhanden. Mit dem Beitrag vorher funkenzupfer ( Dank) wird das CRC Register mit dem 0xB230 (für verarbeiteten 3 0xA1 und hier für 0xFE ) vorgeschlagen/ belegt.

    Quote from funkenzupfer

    Versuch's mal mit dem Anfangswert 0xB230!

    Nur die 4 Bytes 0x0F, 0x00, 0x01, 0x01

    Fexibler ist für mich nur eine Vorbelegung mit den 3 0xA1 Zeichen - also damit 0xCDB4 im Start CRC Register.
    Mit dem prima ONLINE- CRC TOOL habe ich daher schon etwas vorgearbeitet (berechnet) für mich.

    Quote from helwie44

    Waren die HEXA Ausdruck Werte von dlchnr ( ? ID's) damals real von einer Floppydisk gelesen

    Ja, stammen von einer kopiergeschützten CPM-Diskette einer Alphatronic P2 (bzw. im Fall Spur 1, Side0, Sektor 16 von einer frisch formatierten Floppy).

    Hier mal alle vier Seiten, die ich diesbezüglich habe.





    Edited 2 times, last by dlchnr ().

    Konnte mittlerweile einige Stellen im Netzt finden, die die drei 0xA1 in die CRC-Berechung einbeziehen,

    u.a. http://www.moria.de/~michael/floppy/floppy.pdf.


    Scheint also tatsächlich so zu sein, auch wenn ich das aus dem Datenblatt nicht nachzuvollziehen vermag - dort steht eigentlich, dass ein 0xF5 während des WRITE TRACK Kommandos eine 0xA1 schreibt und den CRC Generator auf 0xFFFF initialisiert - da erwartet man doch, dass das dann auch bei dem zweiten un dritten 0xF5 passiert.


    @Martin Hepperle : woher hast Du Deine Info zu den 3 x 0xA1 - auch nur aus den schon hier zitierten Stellen im Internet oder doch aus einem "offiziellen" Datenblatt?

    Edited 2 times, last by dlchnr ().

    • Official Post
    Quote from funkenzupfer

    In o.g. Quelle habe ich noch folgendes PDF gefunden:

    http://info-coach.fr/atari/documents/_mydoc/WD1772-JLG.pdf


    Sehr interessant, S28, "CRC computation / verification in MFM".

    Diese A1 F5 Geschichte ist hier gut beschrieben.

    Allerdings auf Seite 18. Sorry.

    Yep - "However in practice the internal CRC logic is preset to CDB4 (the CRC value for three A1) each time an F5 is received. It is useful to know this information when more or less than 3 sync are used and you want to check the written CRC value,"!


    Also nix von wegen "preset to ones"!

    Edited 2 times, last by dlchnr ().

    • Official Post
    Quote from dlchnr

    Also nix von wegen "preset to ones"

    Doch, aber vor den A1.

    Und keiner weiss wieviel. Also besser mit jedem A1 das CDB4 setzen.

    • Official Post

    Genau das ist auch meine Interpretation.

    Das F5 schreibst du in den FDC, beim Lesen ist es das A1.


    BTW: In dem Dokument sind noch mehr blaue Anmerkungen wegen CRC.

    Quote from Martin Hepperle

    Wenn ich das richtig verstehe, ergibt sich daraus, die CRC je nach Sektorlänge über die rot umrandeten Bytes gebildet wird. Ist aber wirklich kaum alleine aus der Dokumentation zu verstehen...

    Die Tabellen sind aus dem Datenblatt aus Nachricht #3, wonach der F4 Befehl 3 Bytes mit je A1 schreibt.

    Quote from helwie44

    Oder ging real bei einer Alphatronic P2 das FDC CMD "READ ADDRES" ? Das habe ich noch gar nicht getestet - schaue das mir noch an.

    Da ich anscheinend ein entsprechendes Programm hatte, sollte das ohne Probleme funktionieren - soweit ich mich entsinne, hatte ich für alle FD1791-Kommandos entsprechende Unterroutinen - nur das READ-TRACK-Kommandos funktionierte nicht.


    Auf dem static RAM im MOS 1800h bis 1BFFh habe ich immer bei zeitkritischen Routinen dort hin verschoben (dynamisch von meinen kleinen Routinen eingenistet) .


    Untersuchung RAW Buffer:

    Nach einem kleinem Zwischen-TEST - arbeite ich immer mit den 3 0xA1 im ID-AM Feld zur Berechnung des CRC's.

    Sind nur 2 0xA1 vorhanden - setze ich im Buffer immer auf 3 drei 0xA1, somit starte ich mit dem CRC-Register auf 0xFFFF und dann berechne über 8 byte. Also A1 A1 A1 FE tr sd sc ky (c1 c2) .

    Damit finde ich zunächst immer das im Buffer stehendes CRC (hier c1 c2) mit dem selbst berechneten CRC-Wert überein. Erst mal gut - soweit.


    Aber selbst bei der DS2069 Floppy Controller Baukarte in der Alphatronic P2U eingestzt - scheinen nicht immer die identischen CRC-Werte von den ID-DM (data mark) RAW Sectorenbereiche zu liefern.


    Das teste ich noch gegen die DS2069 ( CPU wird mit 8 MHz betrieben) originale Bestückung der Baukarten.

    Hier im Beitrag #15 von Martin Hepperle ist das Layout beim MFM-Format (Sector - Track) vorhanden.

    Für einen Daten-Sector 256 Byte hinter den Daten befindet sich wohl richtig mit 0xF7 zum speichern des CRC's. Offenbar ist aber der dazu stehende TEXT -Bedeutung falsch ( Druckfehler?).


    Kleiner Druck (Text - Bedeutung )-Fehler

    Es sollte dort nach den 256 Byte bei F7 (2 CRC's written) stehen.

    Nicht kleinig - aber bei ungeübten Lesern wird man in die Irre geschickt.

    Bei dem 179x von der NSM in den Datenbättern stehen dieses MFM Layout offenbar korrekt.