Bin mal gespannt auf die ED Diskette aus der echten CMD FD 4000. Manche Details darf man ruhig falsch machen, und trotzdem erkennen gewisse Floppycontroller den Inhalt noch. Daher gibt das einen spannenden Vergleich. Einer der Gründe, warum ich oben einen Beispieltrack mal dekodiert habe.
Fluxengine liest und schreibt D81-Images für die VC 1581 via PC-Floppy-Laufwerk
-
emulaThor -
14. Januar 2021 um 22:41 -
Erledigt
Es gibt 99 Antworten in diesem Thema, welches 13.559 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Auch ich bin gespannt und interessiert was für Erkenntnisse dabei rauskommen werden.

-
Von der echten mit der CMD FD 4000 bespielten Diskette hier das .scp Image: Bitte melde dich an, um diesen Link zu sehen.
Bei den Tracks 71 bis 78 hat sich telweise ein Lesefehler vorgefunden - der Track 79 ist jedoch lesefehlerfrei noch komplett so, wie er formatiert worden ist. Also ohne Änderung durch nachträgliches Daten schreiben. Daher denke ich, dem Image kann man alles entnehmen was man dem entnehmen muss.
-
Wow, die per SAMDISK geschriebene Diskette weicht im Detail ja ziemlich stark von der per CMD FD 4000 geschriebenen ab:
Hier die Gap der SAMDISK (exemplarisch, dort sind nicht alle gleich):
mfm-bytes 4e 4e 4e 4f 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 84 87 ff ff ff ff ff ff ff ff ff ff ff
bits 01010101010
und hier zum direkten Vergleich die GAP der CMD:
mfm-bytes 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 4e 00 00 00 00 00 00 00 00 00 00 00 00
Anbei Track 79 als dekodierte Textdatei - wieder via g64conv (mit dem Bugfix von heute).
-
fluxengine erkennt das ED-Laufwerk leider gernicht (es verhält sich so, als ob kein Laufwerk angeschlossen wäre) und daher gibt es in diesem Fall leider auch nichts weiter zu berichten.
Okay... Kann an allem und nichts liegen - besagt aber nicht, ob fluxengine die Datenrate könnte.
KryoFlux gibt beim Leseversuch gleich einen Fehler aus. Der Aufruf dtc -fkryoflux_sample_ed-disk-2.88m_edn-format-fd-4000_rand-files_ -i0 -i4 ergibt
Ich weiß. Ich bekam exakt das selbe in meinem Test. Und eine Recherche im Kryoflux Forum hat ergeben, dass deren USB 1.1 Anbindung zu langsam ist für jene Datenrate. ED werden die nicht unterstützen, und es gibt auch keine konkreten Pläne, dass Kryoflux das mal unterstützt.
Was die Benutzung und Erkennung von Extra-High Density (ED) Disketten und Laufwerken mit den Flux-Tools angeht, habe ich heute einen weiteren Testdurchgang machen können. Ich dokumentiere es hier gerne in einer Übersicht.
Oben wurde ja bereits erwähnt, dass KryoFlux für Extra-High Density nicht geht.
GreaseWeazle F7 Lightning Plus mit Greaseweazle Tools v0.38 funktioniert mit ED-Medien problemlos. Auch das wurde oben bereits mitgeteilt.
FluxEngine Software (dev build vom 4.2.2022) mit FluxEngine Hardware: Funktioniert nicht.
FluxEngine Software (dev build vom 4.2.2022) mit FluxEngine Hardware funktioniert leider zur Zeit nicht für ED-Anwendung. Es kommt zu (zum Teil verschiedenen) Fehlermeldungen:
Code./fluxengine.exe rpm Using FluxEngine ... No index pulses detected from the disk. Common causes of this are: - no drive is connected - the drive doesn't have an index sensor (e.g. BBC Micro drives) - the disk has no index holes (e.g. reversed flippy disks) - (most common) no disk is inserted in the drive!oder auch
Code./fluxengine.exe rpm Error: no devices found (is one plugged in? Do you have the appropriate permissions?Es gab auch kurioses wie bspw. dieses hier
Code./fluxengine.exe rawread -s drive:0 -d fe_dump_ed-disk-d4m_with_2.88M-drive.flux Using FluxEngine .... Measuring rotational speed... 199ms 0.0: 200 ms in 53184 bytes 0.1: 200 ms in 48000 bytes ... 78.0: 200 ms in 45312 bytes 78.1: 200 ms in 45312 bytes 79.0: 200 ms in 45312 bytes 79.1: 200 ms in 45312 bytesbei dem die ED-Diskette scheinbar eingelesen wird. Aber der Schreib- Lesekopf des ED-Laufwerks bewegte sich dabei gar nicht! Die erzeugte Datei ist mit ca. 7M auch recht klein und besteht größtenteils aus 3F Bytes (am Anfang auch andere Bytes noch dabei, weiter hinten aber fast ausschließlich 3F).
Fazit: FluxEngine-Software und FluxEngine-Hardware ist zumindest zur Zeit mit dem Aufbau hier nicht in der Lage meine ED-Diskette mit meinem ED-Laufwerk zu lesen.
FluxEngine Software (dev build vom 4.2.2022) mit Greaseweazle v4 Hardware (Firmware 1.0): Funktioniert nicht.
Es gibt die folgende Fehlermeldung
Code./fluxengine.exe rawread -s drive:0 -d gw_dump_ed-disk-d4m_with_2.88M-drive.flux Using GreaseWeazle .... on COM4 Measuring rotational speed... 197ms 0.0: 200 ms in 177315 bytes 0.1: Error: GreaseWeazle error: Overflowund danach scheint die Kommunikation zwischen Software und Hardware "durcheinander" geraten zu sein:
Code./fluxengine.exe rpm Using GreaseWeazle .... on COM4 Error: unable to determine disk rotational period (is a disk in the drive?)Greaseweazle Tools (v0.38) mit Greaseweazle v4 Hardware (Firmware 1.0): Funktioniert.
Die v4 des Greaseweazle hat im Test keine Probleme gemacht. Hardware und Software können mit ED-Medien bzw -Laufwerken offenbar umgehen:
Code
Alles anzeigen./gw.exe read gw_dump_ed-disk-d4m_with_2.88M-drive.scp Reading c=0-81:h=0-1 revs=3 T0.0: Raw Flux (556840 flux in 738.41ms) T0.1: Raw Flux (586397 flux in 647.72ms) T1.0: Raw Flux (569115 flux in 756.74ms) T1.1: Raw Flux (590599 flux in 784.15ms) ... T80.0: Raw Flux (700300 flux in 731.73ms) T80.1: Raw Flux (712295 flux in 744.41ms) T81.0: Raw Flux (315430 flux in 616.48ms) T81.1: Raw Flux (349198 flux in 642.27ms)Die erzeugte Ausgabedatei ist wie erwartet recht groß, 173MB, und kann mit SAMdisk in eine D4M-Datei konvertiert werden und hat danach auch den erwarteten Inhalt (dieser entspricht also den Daten auf der ausgelesenen ED-Disk).
-
Ja, die modernen Geräte wie GreaseWeazle, Kryoflux, SuperCard Pro und Extra-High Density sind ein schwieriges Thema.
Mit dem GreaseWeazle klapte das Lesen auf Anhieb...bei der SuperCard Pro müsste ich nochmal schauen.
Aber das Schreiben will mir überhaupt nicht gelingen. Eventuell so eine Sache, dass dem Laufwerk irgendwie signalisiert werden muss, dass ich in ED zu schreiben gedenke. Möglilcherweise irgendeinen PIN des Busses auf Low oder High ziehen. So wie zwischen DD und HD per PIN 2 unterschieden wird.
Ich habe ein Mitsubishi MF356F-252MG. Dort ist Stromversorgung und Shugartbus getrennt (was bei IBM 2.88 MB Laufwerken wohl nicht der Fall ist) - und der Shugartbus hat auch die normale Pinanzahl. Und leider nichts zu dem Themenbereichen Shugart-Busbelegung, Jumper gefunden... bin an der Stelle also nicht weiter gekommen.
-
Zusatz: Mit der SuperCard Pro klappt es [das Lesen] auch - wenn man den Mode "Index" verwendet. Mit Mode "Splice" geht es nicht.
-
Aber das Schreiben will mir überhaupt nicht gelingen. Eventuell so eine Sache, dass dem Laufwerk irgendwie signalisiert werden muss, dass ich in ED zu schreiben gedenke. Möglilcherweise irgendeinen PIN des Busses auf Low oder High ziehen. So wie zwischen DD und HD per PIN 2 unterschieden wird.
Ich habe ein Mitsubishi MF356F-252MG. Dort ist Stromversorgung und Shugartbus getrennt (was bei IBM 2.88 MB Laufwerken wohl nicht der Fall ist) - und der Shugartbus hat auch die normale Pinanzahl. Und leider nichts zu dem Themenbereichen Shugart-Busbelegung, Jumper gefunden... bin an der Stelle also nicht weiter gekommen.
Die korrekte Jumperung ist in der Tat ein leidiges Thema. Für meine Laufwerk musste ich dazu auch einiges recherchieren und ausprobieren. Zum Glück waren für das von mir verwendete Modell Teac FD-235J zumindest einige Informationen im Internet zu finden. Und eine für meine Tests soweit passende Konfiguration scheine ich eingestellt zu haben. Die Einstellungen beschreibe ich gleich noch, etwas weiter unten. Wie in einem Beitrag weiter oben erwähnt, kann ich damit über den PC-Floppycontroller sowohl lesen als auch schreiben. Lesen über Greaseweazle geht auch. Ich habe eben auch das Schreiben mit Greaseweazle v4 getestet. Auch das funktioniert erfreulicherweise!
Ich habe eine PC formatierte 2.88MB Diskette genommen (mit irgendwelchen IBM-PC Daten darauf) und habe darauf dann die scp-Datei aus den Beiträgen Bitte melde dich an, um diesen Link zu sehen. bis Bitte melde dich an, um diesen Link zu sehen. hier aus dem Thread geschrieben (GW4 mit raw write). Die scp-Datei entstand ja aus einem D4M-Image, wie weiter oben mal erläutert. Den Inhalt der so beschriebenen ED-Diskette habe ich dann wieder mit GW eingelesen und nach D4M gewandelt. Der so resultierende D4M Inhalt (siehe unten Screenshot von DirMaster) stimmt überein mit dem Inhalt der ursprünglichen Ausgangsdatei.
Code
Alles anzeigen./gw.exe write gw_dump_ed-disk-d4m_with_2.88M-drive.scp Writing c=0-81:h=0-1 T0.0: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T0.1: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T1.0: Writing Track (Flux: 199.7ms period, 219.7 ms total, Terminate at index) T1.1: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) ... T79.0: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T79.1: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T80.0: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T80.1: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T81.0: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) T81.1: Writing Track (Flux: 199.7ms period, 219.6 ms total, Terminate at index) No tracks verified (Reason: Verify unavailable)Code
Alles anzeigen./gw.exe read gw4_sample_ed-disk-d4m_2.88mb_d4m-ed-d4m_with_teac-drive.scp Reading c=0-81:h=0-1 revs=3 T0.0: Raw Flux (578414 flux in 765.69ms) T0.1: Raw Flux (611116 flux in 672.18ms) T1.0: Raw Flux (542269 flux in 719.72ms) T1.1: Raw Flux (502076 flux in 665.24ms) T2.0: Raw Flux (595602 flux in 790.59ms) ... T79.1: Raw Flux (709015 flux in 739.19ms) T80.0: Raw Flux (678109 flux in 706.95ms) T80.1: Raw Flux (699506 flux in 729.75ms) T81.0: Raw Flux (342680 flux in 717.34ms) T81.1: Raw Flux (324381 flux in 658.17ms)Code./SAMdisk.exe gw4_sample_ed-disk-d4m_2.88mb_d4m-ed-d4m_with_teac-drive.scp gw4_sample_ed-disk-d4m_2.88mb_d4m-ed-d4m_with_teac-drive.d4mBitte melde dich an, um diesen Anhang zu sehen.
Die Jumperstellungen bei meinem Diskettenlaufwerk:
- DS1 (Drive selected as DRIVE 1 on pin 12): on
- EIS (ED set automatically by the ED sensor): on
- HIS (HD set automatically by the HD sensor): on
- FG (Drive ground connected to PCBA ground): on
- der Rest ist "off" (keine Jumper gesetzt)
-
Danke. Das ist ja zumindest mal ein Ergebnis. Auch wenn sich das auf andere Floppies nur schwer übertragen lässt. Laut verlässlicher Quelle (Intel) haben bei 2.88 MB Laufwerken die Hersteller sich noch nicht einmal auf eine einheitliche Belegung des Shugat-Anschlusses geeinigt...

-
David Given hat überraschenderweise einen anderen (angeblichen) 1581 Dump, welcher irgendwie anders aussieht. Bekommen wir es hin, einen Fluxdump von einer mit einer 1581 formatierten Diskette hinzubekommen, um da Klarheit hinzubekommen?
Nicht, dass ich meiner Testdemodiskette von Ebay nicht trauen würde (die Sektorheader genauso wie bei FD 2K und FD 4K, aber eben gebnau umgekehrt wie beim PC sind eigentlich eindeutige Indizien, was stimmen wird
), jedoch ist es vermutlich besser, jeden Restzweifel auszulöschen. -
Deine Formulierungen erscheinen mir in vielen Aspekten unscharf. Ich weiß ungefähr, was Du willst, aber Vieles bleibt mir derzeit unklar. Ich formatiere eine Diskette in meiner Original-1581. OK. Dann lese ich die am PC mit Fluxengine (Software und Hardware, kein Greaseweazle im Spiel) ein. Davor kompiliere ich die neueste Fluxengine-Software. OK. Aber in welchem Dateiformat soll der Dump dann sein? .flux oder .scp oder was Anderes?
-
Ich habe an exakt das selbe Vorgehen wie mit der CMD FD 2000/4000 in diesem Thread gedacht. Siehe Bitte melde dich an, um diesen Link zu sehen. und folgender. Wobei es egal ist, ob per Kryoflux, Fluxengine oder GreaseWeazle eingelesen. Man kann die Formate eh konvertieren.
Da der MFM Controller auf der 1581 die Seiteninformationen im Sektorheader ignoriert, könnten die von einer 1581 tatsächlich anders geschrieben werden, ohne dass es mit einer 1581 auffällt. Wie das nun mal so ist: Was eine 1581 lesen kann, wird gerne als Referenz weitergegeben...
-
Habe unter Ubuntu den aktuellen Source kompiliert, sogar mit der neuen GUI! Jetzt muss ich noch das Cypress-Ding flashen mit einer aktuelleren Firmware, das geht aber nur unter Windows....

(Ich hatte mich hier eingeigelt auf einem Build, der super funktioniert für meine Ansprüche (d81 und d64).)
Bitte melde dich an, um diesen Anhang zu sehen.
-
Habe alles auf dem neuesten Stand und es läuft hier nicht mit d81 in beide Richtungen. Die allerneuesten Änderungen habe ich auch schon getestet. Das Lesen und Schreiben von d81 war schon mehrmals kaputt und ich habe dann Pull Requests erstellt mit Korrekturen. Da der Code sich seitdem wieder stark verändert hat, muss ich mich da erst einlesen.
-
Ja, da fehlt eindeutig die swap sides Sache.
Und zumindest bei dem gestrigen Stand vor dem zweiten Fix war der .scp Header auch hinüber, was eine Prüfung der erzeugten .scp Datei erschwert.
Was man machen kann:
gw convert om.d81 out.d81 -out-track hswap
tauscht innerhalb des d81 die Seiten. Man kann somit prüfen, ob abgesehen vom fehlenden Seitenwechsel noch was shiefgeht. Nach dem Lesen bzw. vor dem Schreiben die Seiten tauschen und man weiß Bescheid.
Nein, außer GreaseWeazle kenne ich keine andere Software, die im D81 mal eben die Seiten tauschen kann. Geht auch ohne GreaseWeazle Hardware.
-
Ich kann bestätigen, dass das die einzigen Probleme sind von Fluxengine mit d81:
* Seiten müssen getauscht werden.
* Header des erzeugten .scp defekt: Endtrack (Byte $7) und Seiten (Byte $A) müssen korrigiert werden.
Sorgt man (fälschlicherweise) durch den Tausch der Seiten in der D81 für einen schlechten Workaround, so ist beim Lesen das erzeugte reparierte D81 okay und beim Schreiben die erzeugte .scp Datei (Header per Hexeditor korrigiert) ist in Ordnung.
-
Der aktuelle Git-Stand von heute Abend funktioniert für mich. Ich habe erfolgreich zwei D81-Images geschrieben auf reale DD-Disketten und die laufen in meiner 1581. David Given hat ganze Arbeit geleistet!

Das Schreiben von D64 auf reale 5.25" habe ich eben auch erfolgreich getestet mit einem 35-Track-Image. Die neue GUI ist schon cool!
-
Ja, er ist richtig motiviert (gewesen) bei der Erledigung des Bugreports. Vier (?) Versuche in so kurzer Zeit, das macht nicht jeder.
Ich muss die generierte .scp Datei mit der neusten Version prüfen, da war ja noch der Defekt im Header.
-
Es geht rasant weiter, David Given hat gerade CMD FD2000 Support eingebaut. Leider wird beim Imagedateinamen noch nicht die Endung .d2m akzeptiert, aber das ist sicherlich nur eine Frage der Zeit.
Wer testen will, kann statt dessen die Endung .img nehmen, dann sollte es gehen.
-
Hat länger gedauert, aber jetzt habe ich auch von der CMD FD4000 ein hochkomprimiertes Sampleimage fertig. Gegenüber der Diskette (mit vernachlässigbaren Lesefehlern) habe ich eine korrekte nicht beschriebene Spur als Vorlage genommen und exakt genauso sämtliche Spuren erzeugt.
-