Mach ich gern
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 (
-
-
Dann machen wir das so - vorausgesetzt, die ED Disketten halten das, was sie versprchen. Ich erwarte deren Lieferung für die kommende Woche.
-
Hallo markusC64,
ich hätte hier für Dich eine ED Diskette, mit 4x1581 angelegten Partitionen. Alle Partitionen sind mit Geowritedokumenten bestückt.
Wenn Du möchtest, würde ich sie Dir gerne zu "Testzwecken" zur Verfügung stellen.

Liebe Grüße,
Jojo
-
Das ist wohl das berühmte Angebot, welches man nicht ablehnen kann - wenn man weiterkommen will?!
Wobei es mir eigentlich wichtig ist, dass der Disketteninhalt veröffentlichbar ist, damit der Dump von allen, die es brauchen, intensiv analyisert werden kann.
-
wie auch immer
- falls ich noch etwas machen soll => PN -
Also......
der Inhalt besteht aus zusammenkopierten Dokumenten aus allen möglichen Geos Pd Disketten. Habe diese Disk vor geschätzten 15-20 Jahren mal zusammengestellt. Eben noch mal geschaut, da ist, meiner Meinung nach, nichts Kommerzielles drauf.
Disk eben nochmal unter MP3 Geos validiert (alle Partitionen). Läuft in meiner FD4000, wie es soll.

Wenn Du möchtest, Adresse bitte per PN.

Gruß Jojo
-
Ich habe zwischenzeitlich an meinem Aufbau weitergemacht. Wie erwähnt steht mir ein ein ED PC-Diskettenlaufwerk zur Verfügung und ED-Disketten. Passenden PC-Unterbau gesucht und beschafft und dann konnte ich die Teile endlich aufbauen und testen: Funktioniert zum Glück. Beim Laufwerk war einiges an Recherchen und Lesen von Dokumenten und Infos aus dem Internet erforderlich, um die richtige Jumper-Konfiguration herauszubekommen.
Genau pünktlich kam dannn auch das GreaseWeazle F7 Lightning Plus hier an.
Mein Vorgehen:
- Mit Vice-Emulator (v 3.6.1) eine d4m-Datei in einer emulierten FD-4000 erstellt: @"n:viced4m 2 eddisk,00,edn"
- Native CMD ED-Disk Partition
- Extension: EDN
- Dichte: ED 3.2M
- Partitionen: SYSTEM, 1 CMD NATIV
- In diese d4m-Datei mit Vice die folgenden drei Dateien reinkopiert
- random64k.bin, random128k.bin und random256k.bin
- Dieses Datei-Image created_by_vice361_+random-file.d4m auf meinem "Floppy-PC" mit dem Programm SAMdisk (in der Version 3.8.11) und dem dort als A: angeschlossenem ED-Floppylaufwerk auf eine ED-Diskette geschrieben
- samdisk "created_by_vice361_+random-file.d4m" a:
- Die ED-Diskette mit dem GreaseWeazle F7 Lightning Plus und den aktuellen GreaseWeazle Tools v0.38 ausgelesen
- gw read gw_sample_ed-disk-2.88m_edn-format-fd-4000_rand-files.scp
- das erzeugt eine 173 MB große Ausgabedatei
- Mit SAMdisk die scp-Datei in eine d4m-Datei konvertiert:
- samdisk gw_sample_ed-disk-2.88m_edn-format-fd-4000_rand-files.scp gw_sample_ed-disk-2.88m_edn-format-fd-4000_rand-files.d4m
Die im Schritt 5 entstandene d4m-Datei ist völlig identisch mit derjenigen aus dem Schritt 3 (sie haben übereinstimmende Prüfsummen/Hash-Werte). Interessant wäre einen anderen Weg und andere Programme zu testen, um aus der scp-Datei weiter d4m-Dateien zu erstellen. Nur um zu Vergleichen, ob auch diese komplett gleich wären. Habe aber momentan keine weiteren Konvertierungsmöglichkeiten probiert.
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.
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
CodeKryoFlux DiskTool Console, v3.00_Win64, uiv.1, Apr 15 2018, 23:44:54 (c) 2009-2018 KryoFlux Products & Services Ltd. Developed by The Software Preservation Society, www.softpres.org Licensed for private, non-commercial use only. 00.0 : The streaming device reported a buffering error 00.0 : Error reading stream device 00.0 : Error reading stream deviceHier im Anhang beigefügt die random-Dateien, das Datei-Image created_by_vice361_+random-file.d4m.
Die vom GreaseWeazle erzeugte scp-Datei kommt im Anschluss in weiteren Beiträgen (aufgeteilt auf mehrere Beiträge wegen der 173 MB Größe der scp-Datei). markusC64: Bis deine ED-Ausstattung vollständig da ist, kannst du mit diesen Dateien vielleicht schon was anfangen.
- Mit Vice-Emulator (v 3.6.1) eine d4m-Datei in einer emulierten FD-4000 erstellt: @"n:viced4m 2 eddisk,00,edn"
-
Hier Teil 1 von 5 der aufgeteilten scp-Datei
-
Teil 2 von 5
-
Teil 3 von 5
-
Teil 4 von 5
-
Teil 5 von 5
-
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.
Bis deine ED-Ausstattung vollständig da ist, kannst du mit diesen Dateien vielleicht schon was anfangen.
Danke. Das ist ja das "all you can wish" Paket. Außer ED Disketten habe ich jedoch alles. Auch wenn mein GreaseWeazle V4 vielleicht nicht reicht, meine SuperCard Pro tut es auf jeden Fall - weil der Hersteller sich sicher ist, dass ED funktioniert. Und im simulierten Test das auch ging (ich habe per FlashFloppy den eine IBM PC 2.88 MB Diskette in emulierter FOrm vorgesetzt).
-
Ach ja, offiziell geht "ED" auch mit dtc.exe nicht. Wenn man aber schon die Streams hat - beispielsweise aus dem GreaseWeazle - die GreaseWeazle Tools können ja Kryoflux Streams erzeugen - , dann kann dtc.exe die sehr wohl dekodieren. Einfach die Option "v150" zusätzlich geben - dann klappt das.
-
Wie erwartet:
scp2kryoflux gw_sample_ed-disk-2.88m_edn-format-fd-4000_rand-files.scp raw\fd4000_.raw
dtc -m1 -fraw\fd4000_ -i0 -z3 -oo4 -v150 -fkryoflux_sample_fd-4000_hdn-formated_rand-files.d4m -i4
und schon habe ich die .d4m.
Edit: Statt "scp2kryoflux" kann man natürlich auch "gw convert" nehmen. "scp2kryoflux" ist nur etwas angenehmer zu benutzen.
-
und schon habe ich die .d4m.
Sehr gut!
Die resultierende d4m-Datei ist auch völlig identisch zu der ursprünglichen d4m-Datei.
-
Ich habe mal einen Track daraus dekodiert - einen von weit innen, damit der keine Daten hat und deswegen jungfräulich ist, so wie er formatiert worden ist. Da sieht man recht gut, wie die FD 4000 den Track aufgebaut hat.
Edit: Nicht wundern, ist mit g64conv dekodiert, deswegen sind da G64 typische Header mit drin. Damit könnte ich jetzt den Luxus machen, ein CMD FD 4000 Image im G64 zu haben - garantiert nutzlos und mit keinen Programm kompatibel.
-
"scp2kryoflux" ist nur etwas angenehmer zu benutzen.
Google kennt das Tool nicht... Ist das was eigenes von dir oder öffentlich verfügbar?
-
Damit könnte ich jetzt den Luxus machen, ein CMD FD 4000 Image im G64 zu haben - garantiert nutzlos und mit keinen Programm kompatibel.
Für manche von uns wäre das sicher - und dennoch - sehr interessant.
-
Ist eine Koproduktioon von Keir und mir. Ich habe einfach Keirs scp und kryoflux Klassen mitsamt Abhängigkeiten aus dem GreaseWeazle Code genommen und dazu ein Minihauptprogramm gebastelt.
Auch wenn Keirs Lizenz es nicht notwendig macht, ihn zu benennen, so tue ich das doch gerne.
Edit: Aber der Quelltext ist kurz genug, den packe ich hier mal dran. Auch wenn oder gerade weil ich nicht vorhabe, das Tool weiter zu warten.
-