Beiträge von Georg

    Inzwischen bin ich sicher, dass es sich doch alles um Disketten für den Northstar Horizon handelt.

    Nachdem ich mein Programm noch etwas "gehärtet" und ein paar Stellschrauben optimiert habe kann ich fast alles lesen. Gut erkennbar ist das immer an der ersten Spur - bei meinen vorigen Tests hatte ich mehr oder weniger wahllos auch schon mal Spur 1 oder 2 angesehen. Zusammen mit einigen Lesefehlern (die offensichtlich auch dabei sind) hatte ich das zunächst nicht erkannt (und mich auch von den Beschriftungen etwas verführen lassen).


    Wegen der Lesefehler muss ich mal prüfen, ob das ein Problem der Disketten ist oder ob mein MFM-Dekoder noch etwas getuned werden muss. Auf einer Diskette sind eine Reihe Spiele mit vielen Texten; ich habe den Eindruck, dass man dort den einen oder anderen Fehler bitgenau identifizieren kann.


    Noch ein paar Informationen zum Diskettenformat:


    10 Sektoren á 512 Byte

    Einseitig, 35 Spuren

    MFM-Kodierung

    Ein Prüfbyte im Anschluss an jeden Sektor (nur XOR und Rotation)


    PAW: Wenn Du das Format implementieren möchtest, kann ich Dir gerne ein Image und weitere Informationen zum Aufbau und Prüfalgorithmus zukommen lassen. Ich weiß allerdings nicht, ob das wirklich Sinn hat - ich kenne keinen Besitzer eines solchen Rechners, und da das DOS offenbar auch etwas Spezielles ist, wird es wohl auch wenig Sinn haben, wenn man versucht, die einzelnen Programme zu isolieren.

    Bei mir gibt es auch etwas Neues.


    Ich habe vor Ewigkeiten von Toast_r einen Haufen hartsektorierte 5,25" Disketten für meine Wang übernommen, aber die meisten bisher nicht genutzt.

    Gestern habe ich mir vier rausgepickt, die mit verschiedenen Labeln beschriftet waren:

    * Nascom

    * Eigenbau

    * Horizon

    * MC/CPM


    Auslesen mit Fluxcopy hat zunächst bei allen gut funktioniert. Ich habe mich dann erst mal auf die "Horizon" gestürzt, weil die offensichtlich von einem Northstar Horizon stammt, der relativ gut dokumentiert ist (hat ja auch funkenzupfer weiter oben schon erwähnt).

    Im Gegensatz zu den Wang-Disketten sind die Daten hier MFM kodiert, was eine ganze Ecke aufwendiger in der Dekodierung und Synchronisierung ist. Inzwischen habe ich es aber hinbekommen und kann bereits halbwegs sinnvolle Inhalte lesen:



    Ich muss allerdings deutlich später mit dem Synchronisieren anfangen, als es in der Beschreibung steht; dort ist die Rede von 96us, nachdem das Indexloch erkannt wurde - ich muss mindestens 400us warten, bevor die erwarteten Bitmuster (20 * 0x00, 2 x 0xFB) zum Synchronisieren auftauchen.


    Beflügelt von dem Erfolg habe ich mein Programm dann auch auf die anderen Images losgelassen. Das klappt aber nur halbwegs. Die mit "MC CP/M" beschriftete Diskette geht überraschend gut - aber nach einem Textfragment zu urteilen sind da auch nur Horizon-Daten drauf.

    Beim Nascom musste ich die Sync-Verzögerung fast auf 1ms setzen, um den Sektoranfang eindeutig finden zu können. Bisher habe ich da aber nur ein paar Textfragmente und Andeutungen eines Monitors gefunden. Allerdings habe ich noch nicht sehr viel angeschaut; meine Programme sind noch recht unkomfortabel ;) Vielleicht hat der auch ein ganz anderes Sektorformat, und was ich gesehen habe war nur Zufall.

    Erstaunlicherweise stimmt aber auffällig häufig die Checksumme - nur leider nicht immer. Muss ich alles mal genauer prüfen.


    Mit dem "Eigenbau" stehe ich noch ganz am Anfang. Bei einem schnellen Dump erkennt man ein paar Textfetzen, aber das kann Zufall sein. Ich bin noch nicht sicher, ob die Sektorstruktur überhaupt ähnlich zum Horizon ist.


    Es gibt also noch eine Menge zu tun ...

    Trotzdem immer wieder großes Lob an PAW für ein gelungenes Werkzeug!

    Mit den Andruckrollen habe ich bisher keine Probleme gehabt, aber die Riemen lösen sich gelegentlich in eine teerartige Masse auf. Ist dann eine große Sauerei, aber in der Regel reparabel.

    Ja, die Konsole "an sich" ist ganz brauchbar, wenn man eine alte 2200 CPU hat. Da kann auch nicht allzuviel kaputt gehen - ist ja nicht viel drin.

    Aber denk an den "Wackelkontakt" :)

    Ich glaube, die kenne ich. Die standen schon vor 16 Jahren in Remscheid in einem Schaufenster. Irgendwie hatte ich das mitbekommen und mir die mal angesehen. Damals war aber ein Verkauf kein Thema (oder falsche Preisvorstellung, weiß ich nicht mehr).

    Das rechte könnte tatsächlich ein Rechner sein (2200 Workstation) wegen des Lüftungsgitters. Das mittlere ist - so weit ich sehen kann - eine reine Konsole (Tastatur und Bildschirm), und links steht ein serielles 2236 Terminal. Beides sinnvoll nur am Original Rechner zu benutzen.

    Vor 16 Jahren schien zumindest die 2236 noch zu laufen. Allerdings dürfte die Tastatur wie üblich tot sein und neue Pads brauchen. Hier mein Bild von 2015:


    Edit: Und über 100% Funktion brauchen wir nicht ernsthaft zu reden...

    Mensch, Antikythera, ein super Fang!


    Wenn mein Keller nicht so voll wäre, würde ich glatt neidisch werden - so kann ich Dir ganz entspannt einfach nur gratulieren und mich für Dich freuen. 8-)

    Ich warte schon drauf, Dich im blauen WANG-Kittel zu sehen, mit einer WANG-Tasse in der einen Hand und dem WANG-Schraubendreher in der anderen ...

    Für die WANG ist das aber doch nicht wirklich relevant.

    Das ist wohl wahr, zumal auf der von Dir zitierten Seite auch nur das MFM-Format beschrieben wird. Zumindest habe ich jetzt eine Ahnung, woher diese Differenz F5/A1 kommt: Beim Formatieren werden spezielle Zeichen (0xF5, 0xF6 und 0xF7) vom Controller uminterpretiert - auf der Diskette erscheinen dann die spezielen Markierungen mit fehlenden Takten oder es werden die CRC-Werte geschrieben.


    Tatsächlich ging es mir aber auch nur um die Frage, ob diese "Störungen", die beim Aktivieren des Write Gates entstehen, auch bei den integrierten FDCs entstehen, und ob auch dort beim Schreiben eines Sektors die notwendigen Synchronisationsbytes jeweils neu geschrieben werden.


    Bevor ich diese Problematik bei der Wang-Diskette erstmals im Detail gesehen habe, bin ich recht blauäugig davon ausgegangen, dass beim Schreiben eines Sektors nur die 256 (bzw. 128/512/1024) Datenbytes (plus die neuen CRC-Werte) geschrieben werden. Aus Sicht des Programmierers werden auch tatsächlich nur die Datenbytes angeliefert; tatsächlich schreibt der Controller aber neben den CRC-Bytes auch einiges im Vorfeld der Nutzdaten auf die Diskette, um die Synchronisation beim späteren Lesen zu ermöglichen.

    Dieses "A1" gibt es bei FM aber nicht, wenn ich die Grafik oben und auch die Tabellen im Datenblatt richtig verstehe.


    Allerdings habe ich eben gesehen, dass nach dem Gap2 noch ein 0xFB (Data Address Mark) kommt - das wird allerdings als Bestandteil des Datenblocks aufgeführt, und taucht deshalb beim Gap nicht auf. Damit könnte m.E. dann die Synchronisation erfolgen.


    Btw: Dieses ominöse A1 bei MFM ist mir auch nicht ganz klar: Ist das eine Bezeichnung, oder ein Wert? In der Grafik sieht es eher wie Bezeichnung aus (wie "GAP 2") zusammen mit dem Hinweis, dass zwischen Bit 4 und 5 ein Takt ausgelassen wird (wie auch immer das aussieht; mit MFM habe ich mich jetzt noch nicht beschäftigt). In den Tabellen tauchen beim IBM-Format an der Stelle drei 0xF5 auf, bei den Non-IBM-Formaten liest sich das so, als wenn da drei mal 0xA1 geschrieben werden.

    Hier die Info zum Gap beim FD179x:

    Explizit steht dort, dass die Umschaltung auf Schreiben in diesem Gap nach 11 Bytes (ich bleibe bei FM) erfolgt.

    Auf der nächsten Seite ist beschrieben, dass dieses Gap2 aus 11 mal 0xFF und 6 mal 0x00 besteht. Dieses A1 mit "missing clock transition between bits 4 and 5" (ich nehme an, dass sind die "exotischen" AddressMarks von funkenzupfer) gibt es bei FM nicht.


    Von daher würde ich erwarten, dass auch hier in dem Gap2 beim Umschalten von lesen auf Schreiben ungültige oder falsche Bits entstehen. Damit die beim späteren Lesen keine Probleme machen und man den Byte-Anfang sauber identifizieren kann hätte ich allerdings erwartet, dass die Umschaltung innerhalb der ersten 11 Bytes erfolgt, so dass man den Wechsel von FF zu 00 zur Synchronisierung verwenden kann. Ich werde mir mal ein FM formatierte Softsektor Diskette mit Fluxcopy ansehen müssen...


    Zurück zur Wang: beim Formatieren wird jeweils ein Sektor geschrieben. Track- und Sektor-Index werden afaik per Hardware separiert und liefern eigene Signale. Der Track Index startet die Formatierung des Tracks. Das Schreiben der einzelnen Sektoren wird jeweils mit dem Sektorindexpuls gestartet. Die Sektornummer wird dabei per Software hochgezählt.

    Der Aufbau des Sektors wurde bereits oben beschrieben:


    20 x 00, 03, track, sector, 20 x 00, 03, 256 x Daten, crc1, crc2


    Zwischen den Sektoren gibt es nichts, jedenfalls nichts Sinnvolles. Ist anders als bei Soft Sektor hier nicht nötig, weil der Sektorindex sowohl beim Formatieren als auch beim Lesen den Startschuss gibt.


    Und beim Schreiben werden definitiv die Track /Sektor gelesen und geprüft. Jedenfalls steht es so in der Doku (Punkt 16 und 17, ich hoffe, dass man es lesen kann)

    Ich habe auch gedacht, dass man ja die Indexlöcher zählen kann - das tut die Wang aber wohl nicht. Das sagt einerseits die Doku, andererseits gibt es nicht so etwas wie ein Sektorregister (das die Sektoren zählt).

    Der Controller muss per Software Track und Sektor prüfen; deshalb dauert es hier auch deutlich länger bis er mit dem Schreiben anfängt. Möglicherweise gibt er in der Zeit sogar noch eine Rückmeldung an die CPU - da müsste ich das Protokoll noch mal prüfen.


    Was die Gaps bei den integrierten FDC angeht: leider fehlt auf @funkenzupfer's Ausschnitt deren Aufbau, und die Datenblätter, die ich jetzt auf die Schnelle gefunden habe sind da von schlechter Qualität. Aber diese Gaps scheinen ähnlich aufgebaut zu sein wie das, was ich bei mir als Synchronisationsblock bezeichne: Eine Reihe gleichartiger Bits, gefolgt von eindeutigen Synchronbytes. Und die Umschaltung von lesen auf Schreiben sowie das Abschalten des Schreibens erfolgt jeweils innerhalb dieser Gaps. Ein Teil des Gaps und insbesondere die Synchronisationsbytes vor dem Datenblock werden also bei jedem Schreibvorgang neu geschrieben.

    Hier noch mal ein Status zu dem Synchronisationsproblem mit meinen Wang-Disketten:


    Zunächst: Wie oben schon geschrieben wurde, sollten bei FM nur Flusswechsel im Abstand von 4us und 8us auftreten. Weiterhin sollten die kurzen Abstände immer nur im Päärchen auftreten. Jede Abweichung davon ist ein Fehler.


    Auf den Disketten finden sich solche Fehler zunächst im Umfeld der Indexlöcher, dort also, wo beim Formatieren mit dem Schreiben angefangen wird und dabei irgendwelche Reste von früheren Aufzeichnungen überschrieben werden. Die nächste Fehlerhäufung findet sich nach den abschließenden CRC-Bytes - dort also, wo mit dem Schreiben aufgehört wird und Reste von früheren Aufzeichnungen beginnen.


    Bei den Nutzdaten zwischendurch gibt es keinerlei Fehlstellen - mit Ausnahme der Fehler im zweiten Synchronisationsteil. Die ersten 160 Synchronbits sind fehlerfrei, bei der zweiten Gruppe kommt ziemlich regelmäßig eine kurze Sequenz mit Fehlern etwa ab dem 120. Bit.


    Der Witz dabei ist: Je intensiver die Diskette nach dem Formatieren genutzt (beschrieben) wurde, desto wahrscheinlicher sind diese Fehler und auch die Länge des Fehlerbereichs nimmt zu. Ein Sektor, der nach dem Formatieren nie mehr beschrieben wurde, ist dagegen völlig fehlerfrei.


    Meine Schlussfolgerung: Beim Schreiben eines Sektors muss der Diskettencontroller zunächst die Daten lesen, die gerade den Lesekopf passieren, um mitzubekommen, wann der richtige Sektor erreicht ist. Der erste Synchronblock (166 x Null, dann 2 Einsen) hilft ihm dabei, den Anfang der für ihn relevanten Information (Tracknummer und Sektornummer) zu finden.

    Um die Nutzdaten zu schreiben muss dann auf Schreiben umgeschaltet werden, und das geht offenbar nicht schnell genug, um im bestehenden Rhythmus weiter zu schreiben. Es besteht also immer die Gefahr, am Beginn der Nutzdaten einen Fehler von ein paar Mikrosekunden zu erzeugen, der dann beim Lesen Schwierigkeiten macht.

    Also erfolgt die Umschaltung früher - d.h. während des zweiten Synchronblocks, nach ca. 120 Bits oder einer knappen Millisekunde. Er schreibt dann noch 7 Null-Bytes (=56 Bits) und das Synchronbyte (3) neu und kann dann ohne Unterbrechung die Nutzdaten schreiben.


    Ein weiteres Indiz für dieses Szenario ist die Datenlänge des zweiten Synchronblocks: : Ein frisch formatierter Sektor enthält dort 165 Nullbits vor dem Synchronbyte (woher die 5 zusätzlichen Bits kommen kann ich bisher nicht erklären - es sollten eigentlich 20x8=160 sein).

    Bei einem beschriebenen Sektor kommen zunächst 120 Nullbits, dann ein paar Mikrosekunden "Störsignale", dann weitere 56 Nullbits und das Synchronbyte. Macht 176+X Bits - ein Beweis, dass beim Schreiben dieser zweite Synchronblock zumindest in Teilen neu geschrieben wird.


    Was mich jetzt interessiert: Macht ein normaler FDC das genauso, oder kann der "übergangslos" von Lesen auf Schreiben umschalten, d.h. dabei den bisher gelesenen Takt halten? Bei der Wang wird das ja alles in Software (plus ein paar Monoflops) erledigt - da gibt es eben die Störungen beim Umschalten.


    Für das Lesen der Disketten gilt nun einfach: Beim zweiten Synchronblock mindestens (120 * 8 + X) Mikrosekunden = ca. 1ms warten, bevor auf die beiden Eins-Bits zum Synchronisieren gewartet wird.

    Nanosekunden, GEIL !!! :)

    Das wären Übertragungsraten gewesen.

    Tja, war schon was spät am Abend/früh am Morgen. :fp:


    Über den Rest kann ich nicht viel sagen - ich bekomme vom uController nur die nackten Zahlen (afaik die Anzahl von 25MHz-Takten zwischen zwei Flusswechseln). Nach meinem Verständnis von FM wird dabei jede Flanke berücksichtigt, und die gemessenen Zeiten entsprechen der Dauer der dabei entstehenden positiven und negativen Impulse.

    Code
     __    _   __
    |  |__| |_|  |_
     0  0   1  0  

    Du darfst also niemals 2 Eins-Bits bekommen. Sonst ist der Sektor nicht lesbar und sollte von der Checksum aussortiert werden.

    Exakt. Nur im konkreten Fall habe ich so unsaubere Werte, dass je nach Interpretation 2 Eins-Bits gelesen werden können.

    Statt der erwarteten Impulse von 8ns kommen hintereinander vier Impulse mit Längen von ca. 6, 4, 5 und wieder 4ns. Zwei Impulse von 4ns machen eine Eins - ergo kann man das als zwei Einsen interpretieren. Oder man interpretiert den 6er und den 5er Impuls als lang, d.h. Null, hat dann aber zwei einzelne kurze Impulse, die bei FM nicht vorkommen dürfen, und wo dann wieder die Frage auftaucht, wie man damit umgeht.


    Man könnte angesichts dieser Unsauberkeit den Sektor als fehlerhaft zurückweisen - deshalb interessiert mich brennend, was der Original Controller in dem Fall macht. Ich müsste aus der Flux Datei also wieder eine Diskette erzeugen und die in den Rechner stecken.

    Ich habe inzwischen die CRC-Prüfung selber drin. Dabei bekomme ich in den gleichen Sektoren CRC-Fehler wie Dein Programm - ich sehe auch das Problem:


    in den 20 Null-Bytes vor dem zweiten Synchronisationsbyte (3) habe ich immer wieder einen Glitch drin; d.h. ich lese gelegentlich statt der erwarteten langen Impulse auch mal zwei kurze. Das würde die Synchronisation kaputtmachen; deshalb habe ich die Zahl der benötigten Null-Bytes etwas reduziert, um das Sync-Byte sicher erkennen zu können. Mit anderen Worten: Ich suche nicht nach 20 Null Bytes, gefolgt von der 3, sondern z.B. nach 6 Null-Bytes, denen eine 3 folgt.


    Ich gehe mal davon aus, dass Du das ähnlich machst, weil die Testdisk sonst nicht gelesen werden könnte.


    Bei der zweiten Disk, die mir Probleme macht, taucht zwischen den rund 160 langen Impulsen folgende Sequenz auf:


    ... 208,206,208,205,209,157,102,135,108,202,210,205,210 ...


    Impulslängen von ca. 200 stellen ein 0-Bit dar; zwei Impulslängen von ca. 100 ein 1-Bit. DIe Werte 157, 102, 135, 108 passen nicht in dieses Raster rein, und man hat nun Interpretationsspielraum. Wenn man festlegt, dass alles, was deutlich kleiner als 200 ist, ein kurzer Impuls ist, sind das zwei 1-Bits, und das Programm erkennt fälschlicherweise ein Synchronisationsbyte und setzt falsch auf.


    Anscheinend stolpern beide Programm darüber, aber in unterschiedlicher Weise, denn die erwarteten und berechneten CRC-Werte unterscheiden sich - und stimmen in beiden Fällen nicht mit dem tatsächlichen CRC überein.


    Natürlich kann man die Synchronisation auch anders gestalten, z.b. in der Art "18 Bytes oder 144 Bits überlesen, dann die erste 3 suchen". Das würde im aktuellen Fall helfen - aber natürlich ist nicht auszuschließen, dass so ein Fehler auch ganz knapp vor dem "echten" Synchronisationsbyte auftritt.


    Ich schätze, ich muss die Diskette noch mal einlesen und sehen, warum er in dem Bereich so gerne Fehler liest - und warum der physikalische Controller damit dennoch zurecht kommt. Das wird aber etwas dauern...

    Hallo,


    feine Sache!

    Ich habe es eben mal ausprobiert (mit Wine bekomme ich das auch unter Linux ans Laufen) und direkt mal meine zwei Wang-Disketten, die ich per Fluxteen/Fluxcopy ausgelesen habe, damit bearbeitet.


    Die Testdisk wurde fehlerfrei verarbeitet; bei meiner Programmdisk tauchen gelegentlich CRC-Fehler auf. Das muss ich noch etwas genauer prüfen - momentan kann ich nicht sagen, ob die Diskette falsch/schlecht gelesen wurden oder ob vielleicht doch noch ein Fehler im CRC-Algorithmus ist.



    Ich habe am Wochenende meine eigene Version von FluxDump programmiert; es sind zur Zeit drei kleine Konsolenprogramme in C, die in drei Schritten

    • die Flux-Dateien interpretieren,
    • die Impulslängen per FM in Bitfolgen dekodieren und schließlich
    • die Wang-Struktur analysieren.

    Also im Grunde das Gleiche, was Fluxdump in einem Rutsch macht.


    Mir ging es weniger darum, systemunabhängige Software zu haben, sondern auch um das Verständnis des Formats und der Zusammenhänge. Mein eigentliches Ziel ist ja der umgekehrte Weg: Aus einem bestehenden Binär-image einer Diskette eine Flux-Datei zu generieren, die dann mit Hilfe von Fluxteen/Fluxcopy auf physikalische Disketten geschrieben werden können.


    Leider habe ich aus Zeitgründen in das letzte Programm die CRC-Prüfung noch nicht eingebaut - deshalb kann ich auf die Schnelle die Frage von oben nicht beantworten. Ich hoffe, aber, dass ich das im Laufe des Abends noch fertig bekomme.



    Noch eine Anmerkung zur aktuellen Version von FluxDump: Bei der Auswahl des Ordners für die Fluxdateien mag das Programm offensichtlich nur einen direkten Unterordner. Wenn ich mit Linux-Pfaden und damit mit "/" arbeite, beschwert er sich über ungültige Pfadangaben und schmiert ab; wenn ich einen mehrstufigen Pfad mit "\" verwende, meldet er, dass ":" oder "\" im Zielpfad nicht erlaubt sind.


    Davon abgesehen: Tolle Sache! Ich habe jetzt nur die WANG-Variante getestet, aber die Möglichkeiten des Projekts sind ja wirklich grandios.

    Auch Klasse!


    Die Seite hatte ich auch schon mal in den Fingern, aber das war noch zu der Zeit, wo ich nur von den 256 Nullbytes ausgegangen bin. Nachdem ich mir dann die Theorie zu den CRC-Generatoren angesehen hab hatte ich den Eindruck, dass das nie und Nimmer irgend ein Standard sein könnte.


    Ich habe jetzt mal nach diesem CRC/BUYPASS gesucht und bin beim CRC-16/UMTS gelandet. Angeblich mit dem Erzeugerpolynom 8005 - das passt ganz gut zu der Anordnung der XOR-Gatter in der Schaltung, aber da gibt es eben auch eine Abweichung, die ich bisher noch nicht verstanden habe. Muss ich mir noch mal durch den Kopf gehen lassen.


    Auf jeden Fall auch Dir ein herzliches Dankeschön!

    Ich habe mal versucht, den CRC-Generator aus dem Schaltbild in Software zu simulieren. Keine Ahnung, ob ich das richtig gemacht habe, aber der liefert mir auch bei Hinzunahme des Synchronbytes (0x03) nicht den gewünschten CRC-Code. Dabei habe ich schon alle denkbaren Varianten berücksichtigt: Vorwärts, rückwärts, positive Logik, negative Logik.


    Wegen der Ausgangsleitungen des Schieberegistes bin ich leicht überfordert. Die Ausgänge gehen zu vier Datenselektoren, deren Ausgänge dann wieder über weitere Stufen weiter verarbeitet werden. Etwas unübersichtlich. Und da ich von WANG weiß, dass dort gerne mindestens die Nibbles vertauscht wurden, und man auch an dem Schieberegister gut sehen kann, dass die mitnichten die Flipflops der Reihe nach benutzt haben (wenn man die FF in den Chips von 1 - 15 durchnummeriert, hat man etwa folgende Reihenfolge: 3,2,4,5,6,...15,16,1) habe ich noch keine Vorstellung, in welcher Reihenfolge die Bits dann tatsächlich abgelegt werden.


    Dadurch ist natürlich auch der o.g. Test mit dem Synchronbyte eigentlich wertlos - allerdings stimmt schon die Bit-Verteilung nicht: Der tatsächlich auf der Diskette befindliche CRC-Code hat 12 0-Bits und 4 1-Bits (12:4). Alle meine Versuche liefern Verteilungen von 5:11, 6:10 oder 8:8.

    Aber nochmal: Dieser CRC-Simulation traue ich noch nicht wirklich.


    Falls es jemand interessiert, der darin besser ist als ich, habe ich zum Studium den mir vorliegenden Schaltplan des Controllers angehängt. Das Schieberegister findet sich auf der zweiten Seite, Mitte links, L27-L30.

    7279.pdf

    Frage: woher weißt du dass es ein CRC sein soll und keine einfachen Checksummen. War das irgendwo zu lesen, oder ist das nur eine Annahme von dir?


    Frage: hast du einen Schaltplan vom Floppycontroller mit den Schieberegistern. Wäre vielleicht hilfreich für mich bei der Suche nach dem CRC.

    Das steht in der mir vorliegenden Doku, und ist auch im Schaltplan erkennbar:


    Allerdings gibt es da noch ein paar Ungereimtheiten - so sollte der abgebildete CRC-Generator bei einem Sektor voller 0-Bits auch einen CRC von 0 erzeugen. Tatsächlich findet sich auf der Diskette aber etwas wie 0x0A88 afair.


    Ansonsten habe ich mir ein Programm geschrieben, das aus den von Dir dekodierten Bitfolgen die Sektorinhalte komplett automatisch rausliest. Die Fehler im Header stören dabei nicht, weil ich von den je 20 Nullbytes nur 6 prüfe (d.h. ich synchronisiere auf die Sequenzen 0 0 0 0 0 0 3) . In den echten Nutzdaten gibt es dann tatsächlich keine Lesefehler.

    Umgekehrt könnte ich nun beliebige Disketten erstellen - da fehlt mir nur der CRC.


    Ich muss mal nach weiteren Schaltbildern suchen oder ggfs. die Originalschaltung prüfen um zu sehen, wie es zu den Diskrepanzen kommt.


    Nachtrag: Damit Ihr Euch nicht durch alle 79 Seiten arbeiten müsst: das Thema CRC findet sich im zitierten Dokument auf Seite 66.

    Hier ein neuer Zwischenstand zu meinen hartsektorierten 5,25" Wang-Disketten.


    Ich habe das Format inzwischen verifiziert: Die Daten werden mit FM kodiert, pro Sektor werden folgende Informationen geschrieben:


    20 x 0x00h

    0x03h

    Tracknummer

    Sektornummer

    20 x 0x00h

    0x03h

    256 Byte Nutzdaten

    2 Byte CRC


    Physikalisch liegen die 10 Sektoren sequentiell auf der Diskette, d.h. in den Headern finden wir der Reihe nach die Sektornummern 0, 1, 2,.. 9.

    Der Inhalt wird dagegen offenbar versetzt geschrieben:

    Nach dem abschließenden CRC und vor dem nächsten Sektorheader (d.h. im Bereich der Sektorindexlöcher) liest FLUXTEEN irgendwelchen Mist, den man getrost ignorieren kann. Teilweise habe ich auch Fehler in den Synchronbytes (die zwei mal 20 Nullbytes im Header) gefunden. Ob die beim Lesen Probleme machen oder ob der Floppycontroller einfach nur auf das nachfolgende 0x03h wartet muss ich noch testen.


    Ein Knackpunkt auf dem Weg, Disketten zu erstellen dürfte noch der CRC werden. Der wird im Controller per Hardware mit einer Kombination von Schieberegister und Flip-Flops mit diversen Rückkopplungen erzeugt, und da fehlt mir die Durchblick, um daraus den Algorithmus zu bestimmen.


    Davon abgesehen bin ich mit den Ergebnissen bereits sehr zufrieden. Schönes Projekt!

    Gehe ich richtig in der Annahme, dass das Indexloch der 10-Sektor Disks wie bei den 16-Sektor Disketten genau mittig zwischen den Sektorlöchern ist ?

    Sorry für die späte Antwort, aber ich wollte sicherheitshalber noch mal einen Blick auf die Diskette werfen.

    Das 11. Indexloch ist tatsächlich genau in der Mitte zwischen zwei Sektorlöchern.

    Noch zwei Fragen zum Thema:


    Gibt es irgendwo eine Dokumentation des .FLX-Formats, damit ich mich auch selber mal an das Rätsel der Dekodierung setze kann? Im bisherigen Thread habe ich dazu m.E. nichts gefunden.


    Außerdem: Das Programm FLUXCOPY kommuniziert mit dem Teensy vermutlich über die gleichen Befehle wie ich sie auch im Arduino Monitor verwende. Mit welchen Befehlen könnte ich per Terminal die Fluxdaten auslesen?

    Leute, ich bin platt!


    Irgendwie mag ich nicht glauben, dass es so einfach sein sollte, aber ich finde gerade keinen Fehler, den ich gemacht haben könnte. Es sieht wirklich so aus, dass ich mit dem FLUXCOPY/FLUXTEEN-Projekt eben eine Kopie einer WANG-2200 PS-II Diskette erstellt habe. :S


    Der Reihe nach:


    Wie berichtet habe ich am Freitag die Platine zusammengelötet und den Teensy programmiert. Gestern habe ich dann ein Doppellaufwerk, dass ich eigentlich für den MFA zusammengestellt habe, an die Platine angeschlossen, und auch erste Erfolge erzielt. Es handelt sich um Mitsubishi M4853 96tpi DDLaufwerke, und ich konnte mit dem Arduino-Monitor die ersten Zugriffe machen (Selektieren, Tracks anfahren etc.). Mit einer softsektorierten Diskette habe ich dann auch die ersten Drehzahlmessungen gemacht (Measured RPM: 291.2037rpm MaxDiff: 0.003%), was schon sehr erfreulich war.


    Heute morgen habe ich dann eine hartsektorierte Diskette von meiner PCS-II raufgeholt und damit weiter getestet. Auch das hat anstandslos funktioniert. Hier die Parameter der Diskette:


    10 Sektoren hartsektoriert (d.h. 11 Indexlöcher) á 256 Byte, einseitig, 35 Spuren => rund 89KB pro Diskette


    Für die Anwendungen von PAW musste ich mir erst mal einen Windows-Rechner suchen; ich habe mir flugs (8o) das Notebook von der Firma geschnappt und die Tests damit gemacht. FLUXCOPY 0.90 aufgespielt, FLUXTEEN per USB angeschlossen, Diskette ins Laufwerk, Parameter eingestellt (Seite 1, Double-step, Track 0-34) und auf READ DISK gedrückt.


    Das Laufwerk hat brav die Tracks abgeklappert, auf dem Bildschirm war ein munteres Treiben, und anschließend hatte ich 35 .FLX-Dateien auf der Platte. Natürlich habe ich direkt mal mit dem Hexeditor reingeschaut - aber ich konnte beim besten Willen keine Struktur oder Muster erkennen, auch nicht an den Stellen, wo die Diskette eigentlich leer und langweilig sein müsste.


    Naja, und dann bin ich übermütig geworden: Schnell eine funkelnagelneue 10-Sektor-Diskette (Dank hierfür nochmal an funkenzupfer ) geholt, ins Laufwerk gesteckt, und auf WRITE DISK gedrückt. Auch hier wieder das erwartete Geklapper, keine auffälligen Meldungen auf dem Bildschirm - naja, das hat nichts zu sagen. Mit der Diskette runter in den Keller an die WANG PCS-II gedackelt, Maschine gestartet, Diskette ins Laufwerk gesteckt - und oh Wunder - der hat die auf Anhieb gelesen, Programme geladen und ausführen können.


    Wie gesagt, ich bin platt! Das ist doch Zauberei! Großes Lob an das Projektteam, vorneweg PAW! :anbet:


    Natürlich ist das nur der erste Schritt, denn bei mir geht es weniger darum, Disketten zu kopieren (das kann ich mit der Maschine selber auch, und leider habe ich für diese Maschine so gut wie keine Disketten mit Software) - wichtiger ist es, die Kodierung zu entschlüsseln und evtl. irgendwann mal Disketten aus vorhandenen Binär-images zu erstellen. Dazu habe ich ja bereits zwei Disketten an gpospi geschickt - inzwischen könnte ich ja auch direkt FLUXCOPY-Daten zur Verfügung stellen.

    Die zweite Diskette, so wie du vorgeschlagen hast, mit allen Zeichen in einem Sektor und wenn das geht, auch ein paar Dateien mit Text, sowie ein paar Basicprogramme.

    Mit "Dateien" werde ich zunächst nicht anfangen; das Dateisystem der Wang ist uninteressant und im Zweifel relativ gut dokumentiert.

    Da die Wang im Grunde nur Sektornummern 0 bis Max kennt, wäre eigentlich schon gewonnen, wenn die Sektoren identifiziert und gelesen werden können.


    Ich werde ein paar Sektoren mit dem gesamten Zeichensatz machen, dann einen Track mit Sektoren, die der Reihe nach mit aufeinanderfolgenden Zeichen gefüllt sind (d.h. je 256 mal 0x01, dann 0x02 etc, um den Interleave herauszubekommen), und dann noch ein paar lesbare Texte. Ich hoffe, das reicht für den Anfang.

    PAW hat mich gebeten, eine hartsektorierte Testdiskette von meiner WANG 2200 PCS-II (10 Sektoren) zur Verfügung zu stellen.

    Die Diskette ist bereits formatiert - jetzt stellt sich die Frage, welche Daten Ihr für die Analyse drauf haben wollt.

    Wir reden von 35 Spuren mit 10 Sektoren zu je 256 Byte. Ich kann jedes einzelne Byte beliebig setzen; also zum Beispiel einen Sektor komplett mit einem Wert füllen, oder den gesamten Zeichenvorrat als aufeinanderfolgende Werte in einem Sektor, oder auch spezielle Inhalte ("the quick brown fox...")

    Was wäre für euch am hilfreichsten?

    Georg: Stell doch mal ein Foto ein, wenn's nicht zuviel Aufwand ist. Entscheidend ist dann auch das Netzteil. Das sollte so einen externen mechanischen Netzschalter haben, wie er bei den XT's üblich war.

    Gab's auch noch AT's mit diesem Schalter? Ich weiß das gar nicht mehr.

    Ich war gerade im Lager und habe nach dem Gehäuse gesucht. Aber sorry, habe es nicht gefunden :(

    Ich habe im Moment keine Ahnung, wo es geblieben sein könnte.

    Offensichtlich werde ich alt :fp:

    Aus dem Bauch heraus würde ich sagen, dass der den Schalter hinten am Netzteil hat.

    Aber ich werde morgen mal versuchen, das Teil auszugraben - dann gibt es auch Bilder und mehr Infos zum Zustand.

    So ein Klappgehäuse müsste ich noch haben, allerdings war da damals ein 286er im afair "Baby-AT-Format" drin. Dürfte also nicht ganz so breit sein wie ein XT-Board.

    Das waren relativ simple Gehäuse, dünnes Blech, mit einfachen Rastverschluss.

    Board müsste noch drin sein.

    Zustand ist aktuell unbekannt, schlimmstenfalls ausgelaufene Batterie und Flugrost am Gehäuse. Wenn Du trotzdem Interesse hast schau ich die Tage mal nach.