FLUXCOPY: Projekt zum fluxbasierten Kopieren von hard- und softsektorierten Disketten via USB

Zitat von frank128

Gibt es für die FluxTeen API via serial interface eine Beschreibung?

Siehe RE: FLUXCOPY: Projekt für Hard- und Software zum Kopieren von hard-sektorierten Disketten

PAW

FLUXCOPY in VirtualBox aufrufen

Zitat von PAW

Zitat

Zitat von runni Mach ich, für was brauche ich Windows? (Nicht das ich einer Virtuellen Maschine keines hätte )

Ich bin bis jetzt nur mit einem nativen Windows gefahren, habe aber nicht versucht über VM ein Windows dafür aufzurufen. Ein Problem könnte die Schnittstelle zum TEENSY sein. Wenn es Dir gelingt mittels Arduino IDE (mit TEENSY Erweiterung), welche im Internet gratis verfügbar ist, Verbindung mit dem TEENSY aufzunehmen, dann könnte auch das FLUXCOPY-Programm funktionieren. Der Rechner muss nur schnell genung sein.

Grüße, PAW

Wie ja bekannt ist, kann FLUXCOPY nur in Windows (WinXP, Win10) aufgerufen werden. Es stellte sich die Frage, ob das Windows auch in einer virtuellen Umgebung laufen kann.

Ich habe jetzt ein paar Experimente angestellt. Urlaubsbedingt kann ich derzeit nicht mit physischen Laufwerken testen. Deshalb habe ich eine Testversion gebaut, die ohne ein Laufwerk auskommt (wird quasi simuliert), aber den Datentransfer von und zum PC real testet.

Meine Testumgebung:

+++ FUJITSU Lifebook mit einem i7-3540M CPU@3.00GHz

+++ Windows 10 (64 Bit)

+++ Oracle VM VirtualBox 6.1 (plus Extension Pack 6.1.10.vbox-extpack) ... für USB2.0 und 3.0 nötig

+++ in VM: 1 x WinXP (32 Bit), 1 x Win10 (64 Bit)

+++ FLUXTEEN via USB am PC angeschlosen

Getestet wurde:

+++ READ von einer simulierten Diskette (mit diversen Fluxwechseln). Bei den Daten geht es nur darum die Datenblöcke für den Transfer zu füllen. Jeder Datenblock wird vor dem Senden mit einem CRC versehen, welcher nach dem Empfang abgeglichen wird. Bei dem Test sollten möglichst keine CRC-Fehler auftreten.

+++ WRITE von echten FLX-Images auf die simulierte Diskette (Empfangene Daten werden beim Schreiben verworfen). Wie beim READ werden auch hier die Datenblöcke auf CRC-Fehler geprüft.

Die Diskette wird beim Lesen oder Schreiben durch einen Delay von ca. 165msec simuliert, was ca. einer Umdrehung bei 360rpm entspricht.

Vorläufiges Ergebnis der Tests:

Die simulierte Datenübertragung FLUXCOPY/FLUXTEEN funktioniert nach diesen Tests:

+++ VM-WinXP und USB 1.1 oder USB 2.0

+++ VM-Win10 und USB 3.0

Abschließende Tests kann ich erst durchführen, wenn ich wieder Zugriff auf die physischen Laufwerke habe!

Die Tests lassen jedenfalls hoffen, dass FLUXCOPY auch in anderen virtuellen Konfigurationen funktionieren könnte. Ich denke dabei an native Liniux Systeme mit VMs und darin laufenden Windows. Da ich über keine Linuxmaschinen verfüge, möchte ich solche Tests gerne anderen Usern überlassen.

Grüße

PAW

Zitat von PAW

Abschließende Tests kann ich erst durchführen, wenn ich wieder Zugriff auf die physischen Laufwerke habe!

Ich konnte heute ein paar Tests mit physischen Laufwerken (3.5" und 5.25") durchführen. Die Transfertests verhalten sich genauso wie bei den simulierten Laufwerken. Ich konnte sowohl in VM-WinXP, als auch in VM-WIn10 Disketten mit FLUXCOPY fehlerfrei beschreiben, als auch wieder einlesen. Es traten bei der Datenübertragung keine CRC-Fehler auf.

Es könnte allerdings sein, wenn der Rechner nicht schnell genug ist, dass es zu Problemen kommen kann. Ebenso mit anderen Windos Emulatoren.

Bitte um Berichte, wenn jemand sowas (Test mit virtuellem Windows eventuell unter Linux) ausprobiert hat, egal ob Fehler aufgetreten sind oder nicht. Danke!

Grüße

PAW

Hallo FLUXCOPY-User!

es gibt wieder neue Testversionen, die seit einiger Zeit von den internen Testusern ausprobiert werden konnten.

Die letzten Versionen im Forum gab es im April: RE: FLUXCOPY: Projekt für Hard- und Software zum Kopieren von hard-sektorierten Disketten

FLUXCOPY Version 0.97

FLUXTEEN Version 0.80

FLUXCOPY097 and FLUXTEEN080.zip

ACHTUNG! Diese Versionen nur gemeinsam einsetzen.

So sieht die neue Version 0.97 aus:

Es hat sich an der Bedienung und Oberfläche nur wenig geändert, aber es gibt ein paar neue Features!

Suchen der COM-Port Adresse

Es gibt jetzt einen Button „List“ mit dem die vorhandenen Portadressen aufgelistet werden können. Man kann dann die Nummer des Ports direkt in der Message eintippen. Ist nicht klar, welches Port das richtige ist (meist steht etwas mit USB dabei), dann kann man in der FLUXCOPY Hilfe nachlesen, wie man es am Besten findet. (Hier war noch kein TEENSY angesteckt.)

Tests beim Installieren von FLUXCOPY/FLUXTEEN

Um die Konfiguration besser Testen zu können, besonders was den Datentransfer zwischen FLUXTEEN und PC betrifft, gibt es nun folgende Möglichkeit:

Es kann der Datentransfer getestet werden, ohne dass ein physisches Diskettenlaufwerk angeschlossen ist. Zu diesem Zweck wählt man bei „Drive select“ die letzte Option „No Drive (TEST)“ aus. Die physischen Laufwerke sollten bei diesem Test nicht angeschlossen sein (habe noch nicht probiert, wie sich das auswirken würde).

Beim Lesen werden von FLUXTEEN Pseudo-Fluxwechsel erzeugt, die anschließend an FLUXCOPY am PC gesendet werden. Der Datentransfer ist mit CRC-Prüfsummen abgesichert, sodass ein Fehler bei der Übertragung bemerkt und angezeigt würde. Die Menge der Daten kann mit „Num of Retries“ beeinflusst werden. Die erstellten Pseudodaten sind die 128 Byte FM-Daten eines Sektors einer 8“ Diskette, welcher pro Track 26 Mal wiederholt wird (immer die gleiche Track-/Side- und Sektornummer). Man kann die empfangenen Daten mit FLUXDUMP ansehen und sie sollten fehlerfrei sein (Einstellung FM und 8“).

Beim Schreiben können entweder die vorhin eingelesenen Daten wieder gesendet werden, es können aber auch andere softsektorierte FLX-Dateien (möglichst Standardformnat) versucht werden. Hier wird ebenfalls der CRC geprüft. Der Inhalt der Daten wird ignoriert.

Natürlich lassen sich die Tests auch mit physischen Laufwerken 1-4 durchführen.

Neues (und Altes) zum Thema „Flippy Disk“

Zu diesem Thema gibt es ja jede Menge Lesestoff. Dennoch möchte ich die Problematik hier noch mal kurz erläutern.

Flippy Disks wurden in Zeiten der noch einseitigen Floppy Laufwerke aus Kostengründen „erfunden“. Obwohl die meisten Datenträger beidseitig bespielbar waren, blieb die Rückseite oft ungenutzt. Bei Standardformaten (FM, MFM, etc.) war ein „Umdrehen“ (verkehrt ins Laufwerk stecken) nicht zielführend, da diese immer ein Signal vom Indexloch benötigten und nicht funktionierten. Steckte die Diskette verkehrt drin, dann ging der Lichtstrahl des Sensors nicht mehr durch das vorhandene Loch und die Diskette wurde nicht erkannt. Eine Möglichkeit war es, ein zusätzliches Loch in die Diskettenhülle zu stanzen (natürlich am richtigen Platz), sodass der Indexpuls auch bei verdrehter Diskette kam. Aber das waren dann keine „echten“ Flippy Disks.

Bei C64, Apple, etc. wurde eine GCR-Codierung verwendet, welche das Indexloch grundsätzlich ignorierte. Dies eröffnete die Möglichkeit eine Diskette verkehrt (also flipped) ins Laufwerk zu stecken und es funktionierte trotzdem. Lediglich für das Beschreiben musste eine Schreibschutzkerbe gestanzt werden, was aber auch mit einem handelsüblichen Bürolocher gemacht werden konnte.

Zum Lesen von Flippy Disks auf Flux-Basis gibt es prinzipiell zwei Möglichkeiten, wobei es immer um die Rückseite geht (die Vorderseite ist ja quasi Standard):

Methode 1 ... mit einem doppelseitigen Laufwerk die Seite 2 lesen. Die Diskette ist dabei standardmäßig im Laufwerk eingelegt. Dabei werden die Daten von Seite 2 aber revers (also verkehrt rum) gelesen und außerdem fehlen die ersten 8 Spuren (bei 96tpi), wegen dem Versatz der Köpfe (Seite 1 gegenüber Seite 2). Ist also nur sinnvoll, wenn die Diskette nicht ganz voll ist oder wenn das Laufwerk modifiziert wurde (Stichwort Track minus 8, FLUXCOPY ist aber derzeit dafür nicht ausgelegt). Bei FLUXDUMP (ab Vers. 065) muss man die Option „reverse“ einschalten, damit die Daten richtig interpretiert werden.

Methode 2 ... es wird die erste Seite gelesen, aber die Diskette verkehrt eingelegt (also geflippt). Bei echten Flippy Disks ist auf dieser Seite kein Indexloch vorhanden, wodurch soviel ich weiß z.B. Kryoflux diese überhaupt nicht einlesen kann, außer mit speziell modifizierten Drives, die ein Indexloch simulieren. FLUXCOPY ist nun in der Lage auch Disketten ohne Indexloch zu lesen (Einstellung Seite 0, liest dann Seite 1 ohne Index). Zu beachten ist, dass die Daten (alle ab Track 0) dann "normal" gelesen werden, also NICHT REVERS! Bei dieser Methode muss aber das Laufwerk entsprechend gejumpert (nicht aber modifiziert) sein, damit es auch Daten liefert, wenn die Diskette verkehrt drin steckt. Habe außer dem PANASONIC JU-475-5 (gejumpert) auch mein altes 720KB-Laufwerk von Philips (ungejumpert) getestet. Beide funktionieren gut! Die Daten können dann mit FLUXDUMP auch auf eine Binärdatei (Zwecks Weiterverabeitung) ausgegeben, derzeit aber nicht auf Diskette zurück geschrieben werden.

WICHTIG: Da FLUXCOPY nicht feststellen kann, wie schnell das Laufwerk tatsächlich dreht (300 oder 360 rpm) muss immer darauf geachtet werden, dass der in der Commandline angegebene Drehzahl-Parameter stimmt. Das heißt es muss DD für 300rpm oder HD für 360rpm angegeben werden, damit FLUXCOPY weiß, mit welcher Drehzahl zu rechnen ist. Daraus berechnet sich die Dauer der Aufzeichnung.

Hinweise zu Methode 2:

+++ Diese Methode funktioniert nicht mit jedem Laufwerk! Geht nur mit solchen, welche Daten auch ohne Indexpuls lesen können.

+++ Derzeit ist nur das Lesen der Disketten implementiert.

+++ Weitere Infos dazu finden sich im Help von FLUXCOPY.

Wie immer gilt: Die Verwendung der Programme erfolgt auf eigenes Risiko!

Aufgrund der Umbauten kann es natürlich vorkommen, dass irgendwas nicht funktioniert, was in einer früheren Version schon funktionierte. In diesem Fall mich bitte zu verständigen, damit ich den Fehler beheben kann.

Ich wünsche noch gutes Gelingen und freue mich auf Rückmeldungen!

Grüße

PAW

Die neueste Testversion von FLUXDUMP:

FLUXDUMP Version 0.65

FLUXDUMP 065.zip

Die Oberfläche hat sich ein wenig verändert.

Außerdem gibt es ein paar neue Features (siehe auch in der Hilfe)

HINWEIS! Wenn sich ein Format dumpen lässt, heisst das nicht gleichzeitig, dass es auch mit FLUXCOPY auf eine Diskette zurückgeschrieben werden kann.

Neue Features in FLUXDUMP 0.65:

+++ Es gibt beim Dump die Möglichkeit die Zeichen als ASCII oder EBCDIC darzustellen.

+++ Es gibt eine neue Option: Reverse

Mit dieser Option ist es möglich die Rückseiten von Flippy Disks zu dumpen. Flippy Disks (ohne zweites Indexloch für die Rückseite) sind meist im Bereich der GCR-Formatierung zu finden, wie C64 & Co. Zum Lesen wird eine Flippy Disk „normal“ in ein doppelseitiges Laufwerk eingelegt (also das Indexloch an der richtigen Position) und dann nur die Rückseite (also Side 2 in FLUXCOPY) eingelesen. Solche Images können mit der Reverse-Option gedumpt und auch als BIN-File ausgegeben werden. Dabei ist zu Beachten, dass die Schreib-/Leseköpfe der Vorder- und Rückseite gegeneinander um 8 Spuren (@96tpi) bzw. 4 Spuren (@48tpi) versetzt sind. In der Datei für Track0 sind z.B. die Daten von Track4 enthalten (@48tpi). Das bedeutet, dass hier die ersten 4 Spuren nicht gelesen werden können. Dafür werden am Ende 4 leere Spuren vorhanden sein. Oft werden aber solche Disketten nicht von Track 0 an bespielt, sondern beginnen irgendwo in der Mitte, sodass eine nicht ganz volle Disk ausreichend eingelesen werden kann.

+++ Es gibt zwei weitere Optionen: BIN-Sort und BIN-Unsrt.

Wenn man einen Dump auswählt, kann man damit zusätzlich zum Dump auch eine Binärdatei .BIN erzeugen, die alle Daten aus den Dumps binär enthalten (ohne diverse Zusätze wie Track/Side/Sektor, etc.). Diese könnte man dann beliebig weiterverarbeiten, z.B. mit BIN2IMD (aus dem IMD-Paket) auf .IMD umwandeln.

Der Unterschied von Sort und Unsort liegt darin, dass bei BIN-Sort die Sektoren in aufsteigender Reihenfolge gespeichert werden, bei BIN-Unsrt in der Reihenfolge, wie sie von der Diskette gelesen werden. Es beginnt aber immer mit dem ersten Auftreten des Startsektors. Dieser muss für jede Seite extra angegeben werden. Bei diversen Formaten am Besten im Dump nachsehen, was die niedrigste Sektornummer ist. Wird eine falsche Startnummer angegeben (eine die es nicht gibt), dann bleibt die BIN-Datei leer!

Zusätzlich zur .BIN-Datei wird auch eine .TXT-Datei ausgegeben, welche diverse strukturelle Daten enthält.

Mit der BIN-Option lassen sich auch Amiga Images exportieren. Die BIN-Datei entspricht dabei einer ADF-Datei von Amiga.

+++ Mit dem Button "Analyze Flux" kann man eine Analyse der Fluxwechsel durchführen (erzeugt eine Grafik).

Damit werden die vorhandenen Fluxlängen, nach Länge sortiert, angezeigt. Es bietet eine gute Übersicht bezüglich Qualität der Aufzeichnung. Sind die "Bäuche" scharf getrennt, dann ist es meist eine gute Qualität. Beim ersten Aufruf wird eine csv Datei erstellt. Falls sich etwas bei den Fluxfiles geändert hat, kann die csv-Datei mit "Recalc CSV-File" neu erstellt werden.

Obige Grafik zeigt eine 3.5“ PC HD-Diskette mit MFM Modulation. Es sind die typischen Fluxwechsellängen von 2, 3 und 4µsec zu sehen. Da die einzelnen „Frequenzen“ klar getrennt sind, lässt sich diese Diskette auch gut dumpen. In der oberen Zeile werden die Tracks/Seiten angezeigt. Es werden die Anzahl der gefundenen Fluxlängen je Track/Seite als Balken dargestellt.

Die neue Testversion von FLUXKRYOCONV

FLUXKRYOCONV Version 0.99d

FLUXKRYOCONV 099d.zip

Im Zuge des MUPID-Threads ergab sich ein Problem mit dem Schreiben von IMD-Images via Kryoflux. Die IMD-images wurden mittels HxC auf Kryoflux raw-Files umgewandelt. Die raw-Dateien ließen sich zwar mit Kryoflux auf Disketten schreiben, diese waren aber fehlerhaft. Der jeweils 10. Sektor war nicht lesbar. Das Problem lag bei der Erstellung der raw-Files durch HxC. Dort waren falsche Drehzahldaten angegeben, was dazu führte, dass der letzte Sektor unvollständig auf die Disketten geschrieben wurde.

Näheres ist den folgenden Links von gpospi zu Lesen:

Quelle für MUPID-Images

Problem aufgezeigt

Analyse durch PAW

Es gibt eine neue Option (RPM Adaption) für die Konvertierung von RAW nach FLX. Wird diese angehakt, dann wird die Summe der Fluxtimings mit der Zeit zwischen den Indeximpulsen verglichen. Reicht die Zeit nicht, dann wird Zeit für die Indexpulse auf den Wert der Fluxwechsel gesetzt.

Falls man nur Kryoflux zur Verfügung hat, kann man die adaptierte FLX-Datei wieder auf raw umwandeln. Funktioniert in den meisten Fällen. Könnte aber sein dass die Rückumwandlung scheitert, da beim Konvertieren eventuell Teile verloren gehen. raw-Dateien beginnen irgendwo im Datenfluss, FLX-Dateien starten immer mit einem Indexpuls. Bei der Rückumwandlung auf raw, beginnt dann die raw-Datei auch beim Indexpuls.

Hinweis: Umwandlung von Dateien ohne Index (also Flippydisks mit Side 0 in FLUXCOPY aufgezeichnet) sind derzeit nicht durchführbar und führen zu einer Fehlermeldung!

Wie immer gilt: Die Verwendung der Programme erfolgt auf eigenes Risiko!

Aufgrund der Umbauten kann es natürlich vorkommen, dass irgendwas nicht funktioniert, was in einer früheren Version schon funktionierte. In diesem Fall mich bitte zu verständigen, damit ich den Fehler beheben kann.

Ich wünsche noch gutes Gelingen und freue mich auf Rückmeldungen!

Grüße

PAW

P.S.. yalsi Ich musste den Beitrag zerteilen, weil ich das 10.000 Zeichen Limit überschritten hatte, Leider wird nicht bei "VORSCHAU" darauf hingewiesen. Erst beim Antworten kam die Meldung. War dann recht mühsam den Thread zu zerteilen, da ja die Bilder und Dateien nicht mehr passen.

Zitat von dr.zeissler

Hallo, nur für mich zur Einordnung:

- Fluxteen ist das Board

- Fluxcopy ist die Software

Korrekt! Zusätzlich zu FLUXCOPY (dient zum Lesen und Schreiben der Disketten), gibt es noch FLUXDUMP zum Anzeigen der gelesenen Inhalte (FLX-Dateien), sowie zum Ausgeben auf eine Binärdatei, die nur die reinen Daten enthält. Mit FLUXKRYOCONV lassen sich die FLX-Files auf raw von Kryoflux umwandeln und umgekehrt.

Lauft derzeit alles nur unter Windows. Es gibt aber Versuche mittels WINE Emulator dies auch unter Linux zu betreiben:

Beitrag

RE: FLUXCOPY: Projekt zum fluxbasierten Kopieren von hard- und softsektorierten Disketten via USB

Es stehen zwar noch einige Tests aus, aber man kann bereits sagen, dass man mit FLUXCOPY unter Linux über Wine Disketten-Images erstellen kann. Die Schreibfunktion muss noch getestet werden.

frank128

12. September 2023

Zitat von dr.zeissler

Was kostet ein fertiges Board? Kann man das irgendwo bestellen

Es gibt nur leere Boards (bei gpospi nachfragen). Bauteile muss man selber besorgen und zusammenlöten. Sind allerdings nur eine Handvoll. Das teuerste Bauteil ist dabei der TEENSY 4.1

Zitat von dr.zeissler

Welche Anforderungen hat das Board an die angeschlossenen Floppys?

34-polige Shugart Schnittstelle. Externe Stromversorgung für die Floppylaufwerke.

Zitat von dr.zeissler

Gibt es eine Kompatibilitätsliste die Laufwerke und Formate führt und müssen bspw. 525" Floppys modifiziert werden?

Gibt keine Liste. Bisher habe ich aber keine negativen Rückmeldungen erhalten. Bei mir laufen 3.5" und 5.25" Laufwerke (DD oder HD). 3.5" mit 2.88MB werden nicht unterstützt. 8" Laufwerke lassen sich mit einem entsprechenden 34/50-poligen Adapter ebenfalls betreiben.

Normalerweise ist keine Modifikation nötig, eventuell Jumper setzen.

Zitat von dr.zeissler

Läuft die Software auch auf Win2K mit USB 1.1

Kann ich nicht sagen. Vermutlich wird USB 1.1 zu langsam sein. Müsste man ausprobieren. Ich habe aber keine Möglichkeit dazu. Außerdem weiß ich nicht ob FLUXCOPY unter WIN2K läuft. Ist ein Visual Basic 6.0 Programm. Vielleicht kann das mal jemand ausprobieren.

Hast Du keine Möglichkeit auf einem neueren Windows und schnellerer Maschine zu fahren?

Grüße

PAW

Zitat von dr.zeissler

Gibt es eine Kompatibilitätsliste die Laufwerke und Formate führt

Die Frage zu den Formaten habe ich noch nicht beantwortet.

Hier ein Auszug aus der Hilfe in FLUXDUMP zeigt die dumpbaren Formate:

Filetype SOFT SECTOR synchron (one index hole, sectors synchron to index hole)
-----------------------------
MFM ...... soft sectored MFM formated disks (µPD765 and compatible).
           This format is typically for PCs and a lot of CP/M systems.
FM ....... soft sectored FM formated disks (µPD765 and compatible).
ISIS-II ...soft sectored MMFM formated 8" disks of ISIS-II

Filetype SOFT SECTOR asynchron (one index hole, sectors not synchron)
------------------------------
           These formats do not use the index hole!
GCR ...... soft sectored GCR formated 5.25" disks ... 
                C64, CBM, Salora (similar to Apple II) and Vicki
MFM-Amiga  soft sectored MFM Amiga-DOS formated 5.25" disks 

Filetype HARD SECTOR synchron (num of sector index holes = total holes minus one)
-----------------------------
         Sectors are synchron to index holes)
Bull MFM ......... hard sec (16) MFM formated DD 5.25"
AES-FM ........... hard sec (16) FM formated DD 5.25"
AES-MMFM ......... hard sec (32) MMFM formated 8"
WANG-FM .......... hard sec (10) FM formated DD 5.25"
WANG-FM .......... hard sec (32, but only 16 sectors) FM formated DD 8"
SMAKY6 MFM ....... hard sec (16) MFM formated DD 5.25"
VG MFM ........... hard sec (16) MFM formated DD 5.25" Vector Graphic - Micropolis
NSI Horizon FM ... hard sec (10) FM formated DD 5.25"
NSI Horizon MFM .. hard sec (10) MFM formated DD 5.25"

Grundsätzlich gilt, dass von allen Formaten ein FLX-Image gezogen werden kann, aber nicht alle Images wieder auf eine Diskette geschrieben werden können.

Geschrieben werden können im allgemeinen fast alle softsektorierten, an das Indexloch gebundene, FM und MFM Disketten. Dies gilt für DD und HD, bei 8" gibt es nur DD (entspricht einer 5.25" HD).

Zusätzlich können auch, die in FLUXDUMP aufgeführten hardsektorierten Disketten geschrieben werden. Nicht angeführte können nur gelesen, aber weder gedumpt, noch geschrieben werden.

Bei den indexunabhängigen GCR-Formaten können derzeit nur die in FLUXCOPY angeführten Formate wie C64 und Vicki geschrieben werden.

In FLUXDUMP sind die unterstützten Formate zu sehen. Es lassen sich fast alle Formate als BIN-Datei ausgeben und z.B. mit BIN2IMD (vom Image Disk Paket) in eine IMD-Datei umwandeln.

Alternativ kann man auch mit FLUXKRYOCONV die FLX-Images auf raw (Kryo) umwandeln und mit HxC weiter bearbeiten.

Siehe auch die Hilfe im jeweiligen Programm.

Hinweis: wenn man den Mauszeiger über die diversen Format-Buttons stellt, bekommt man Zusatzinfos.

Grüße

PAW

Zitat von schlika

First a HUGE thanks for your work, it seems really nice. I saw the "Smaky 6 MFM" in the fluxdump screenshot, is it working ? That is exactly what I am looking for !

Hallo schlika

at the SMAKY 6 MFM I have worked together with fishermansfriendtoo two years ago. Reading and dumping should work well. On writing back, there were sometimes troubles when read again with FLUXCOPY. May be that the write precompensation is not optimized. (Has to be set by command line parameters.) Because I have no SMAKY, so I couldn't make further tests. May be that fishermansfriendtoo can tell us a little bit more.

PAW

Hello schlika

I have sent you a PM (personal message). Please click "Konversationen" item in the menu on right side of the bell.

Hello schlika

I have sent you a PM (personal message) again. Please click "Konversationen" item in the menu on right side of the bell.

Please see also the hint in the PM, how to get a message, when a PM has been received:

PAW

Hallo FLUXCOPY-User!

es gibt wieder neue Testversionen, die seit einiger Zeit von den internen Testusern ausprobiert werden konnten.

Die letzten Versionen im Forum gab es im September 2023: RE: FLUXCOPY: Projekt zum fluxbasierten Kopieren von hard- und softsektorierten Disketten via USB

Hier die Neuen:

FLUXCOPY 0.98 und FLUXTEEN 082

FLUXCOPY 098.zip

FLUXTEEN082.ino.zip

ACHTUNG! Diese Versionen nur gemeinsam einsetzen.

So sieht die neue Version 0.98 aus:

Es hat sich an der Bedienung und Oberfläche nur wenig geändert, aber es gibt ein paar neue Features! Siehe z.B. Button WSyn (bei Disk Type).

WSyn … für Schreiben von "asynchronen" Disketten

Mit WSyn ist es nun möglich eine Reihe von Diskettenformaten zu schreiben, welche bisher nicht richtig ausgegeben werden konnten. Das betrifft im Prinzip Formate, die keinen Index-Puls brauchen, wie z.B. Apple, C64, etc. Diese Formate werden von den Ursprungssystemen ohne Berücksichtigung des Indexloches beschrieben. FLUXCOPY arbeitet im allgemeinen mit dem Indexpuls um die Position festzustellen und beginnt auch dort mit dem Schreiben. Sobald das Indexloch ein zweites Mal auftaucht wird der Schreibvorgang gestoppt. Damit wird sichergestellt, dass nicht der Anfang wieder überschrieben wird. Dort wo Anfang und Ende zusammenkommen entsteht ein so genannter Spleiß. Das ist ein Bereich in dem fehlerhafte Fluxwechsel Aufgrund der Überschneidung vorkommen. Dies darf unter keinen Umständen innerhalb eines Datensektors passieren, da dieser sonst nicht mehr lesbar wäre. Aus diesem Grund müssen die oben genannten Formate einer Spezialbehandlung unterzogen werden, d.h. sie müssen mittels FLUXDUMP refreshed werden. Bei diesem Vorgang wird eine Position zwischen den Sektoren ermittelt, die für einen Spleiß geeignet ist und in dem jeweiligen FLX-Header des Tracks eingetragen. Beim Schreiben mit FLUXCOPY wird dann diese Position benutzt um das Schreiben zu Starten.

Das C64-Format wurde schon vorher implementiert (Auswahl C64) und es braucht kein Refresh durchgeführt werden. Wurde dennoch ein Refresh durchgeführt, dann kann man beide Methoden verwenden.

Anzeige der aktuellen Command Line in der Hilfe

Im Helpscreen kann die aktuell verwendete Kommandozeile angezeigt werden.

Siehe: 2.1 Actual Command Line

Kopieren von NFA (No Flux Areas)

FLUXCOPY kann nun auch NFA’s kopieren. Das sind Bereiche auf einer Diskette, die keine Fluxwechsel an den Controller senden. (Siehe auch Hilfe). NFA wurde manchmal als Kopierschutz verwendet. Die Parameter sind für 3.5“ Laufwerke optimiert. Es kann vorkommen, dass es auf anderen Laufwerken nicht funktioniert.

Wie immer gilt: Die Verwendung der Programme erfolgt auf eigenes Risiko!

Ich wünsche noch gutes Gelingen und freue mich auf Rückmeldungen!

Grüße

PAW

Fortsetzung folgt …

FLUXDUMP 0.70

Anbei die neueste Testversion von FLUXDUMP.

FLUXDUMP 070.zip

Die Oberfläche hat sich ein wenig verändert. Es gibt neue Formate (Apple
II), sowie neue Export Features (siehe auch in der Hilfe).

HINWEIS! Wenn sich ein Format dumpen lässt, heißt das nicht gleichzeitig, dass es auch mit FLUXCOPY auf eine Diskette zurück geschrieben werden kann!

Neue Export Features

Nach Anhaken von "Export" werden die Optionen sichtbar.

Es gibt nun zwei weitere Export-Optionen. Zusätzlich zu BIN-Sort und BIN-Unsrt kann man bei allgemeinen FM und MFM-Formaten (Softsektor, PC-kompatibel) auch das DSK-Format als Ausgabe auswählen.

DSK-Files werden von SAMdisk (written by Simon Owen) benutzt und enthalten ähnlich der BIN-Dateien die Binärdaten, sowie Zusatzinformationen über Track, Seite, Sektor, Modulation, Länge und Reihenfolge der Sektoren. Eine DSK-Datei kann mittels SAMdisk am PC wieder auf eine Diskette geschrieben werden. (Gilt nur für PC/µPD765-kompatible Disketten.) Infos: http://simonowen.com/samdisk/

Dort ist auch das DSK-Format beschrieben. Benötigt man IMD-Dateien (Imagedisk), kann dies ebenfalls mittels SAMdisk geschehen. (Umwandlung von DSK auf IMD).

Die DSK-Datei kann auch mittels meinem SAMCONV.xls unter Windows zum Auslesen von CP/M-Dateien (verschiedenster Quellen) benutzt werden. SAMCONV.xls kann auch Dateien in eine neue DSK-Datei zurückschreiben.

Hinweis: Ein Schreiben von DSK-Dateien mittels FLUXCOPY ist derzeit nicht vorgesehen. Man kann aber mittels HxC die DSK-Datei einlesen und als Kryo-raw-Dateien ausgeben (eine Datei pro Track und Seite). Diese raw-Dateien können dann mittels FLUXKRYOCONV in FLX-Dateien umgewandelt und dann mit FLUXCOPY auf Diskette geschrieben werden.

Neues beim Refresh … Komprimierung der Daten

Hinweis: Eine Datei sollte nur dann refreshed werden, wenn sie fehlerfrei gedumpt werden konnte, ansonst kann es zu unvorhersehbaren Fehlern kommen.

Zusätzlich zu den bisherigen Eigenschaften des Refresh, werden nun die neuen Dateien etwas komprimiert. Die neuen Dateien haben dann meist eine Größe von weniger als 30 Prozent des ursprünglichen Files, ohne dabei Daten zu verlieren. Dies ist möglich, da beim Refresh die Fluxlängen standardisiert werden, also auf die nominalen Längen gesetzt werden. Wie gesagt, das geht nur wenn keine Fehler auftraten, also die Daten einwandfrei lesbar waren.

Aufgrund von größeren Umbauten in den Programmen kann es natürlich vorkommen, dass irgendwas nicht funktioniert, was in einer früheren Version schon funktionierte. In diesem Fall mich bitte zu verständigen, damit ich den Fehler beheben kann.

Wie immer gilt: Die Verwendung der Programme erfolgt auf eigenes Risiko!

Ich wünsche noch gutes Gelingen und freue mich auf Rückmeldungen!

Grüße

PAW

Fortsetzung folgt …

FLUXKRYOCONV 1.00

FLUXKRYOCONV 100.zip

Im Zuge der Änderungen beim FLX-Format (Komprimierung beim Refresh) war eine Anpassung nötig.

Hinweis: Umwandlung von FLX-Dateien ohne Index (also Flippydisks mit Side 0 in FLUXCOPY aufgezeichnet) sind wohl auf raw-Dateien umwandelbar, führen aber bei einer weiteren Verarbeitung, z.B. in HxC zu Fehlermeldungen, da kein Index vorhanden ist!

Wie immer gilt: Die Verwendung der Programme erfolgt auf eigenes Risiko!

Ich wünsche noch gutes Gelingen und freue mich auf Rückmeldungen!

Grüße

PAW