Arduino Amiga Floppy Disk Reader/Writer (V2.2)

Apps und Onlinedienste

Arduino-IDE

Über dieses Projekt

Dieses Projekt setzt die Arbeit meines vorherigen Disk-Reader-Projekts bei fort https://create.arduino.cc/projecthub/projects/485582/

Weitere Informationen finden Sie unter http://amiga.robsmithdev.co.uk

• Mein Ziel: Um einen einfachen, kostengünstigen und Open Source-Weg zum Wiederherstellen und Neuschreiben von Daten von und auf Amiga DD-Disketten von Windows 10 aus zu schaffen.

• Meine Lösung: Eine Arduino-Skizze + eine Windows-Anwendung (die auf andere Betriebssysteme portiert werden kann ) das funktioniert tatsächlich!

• Warum: Um Daten von diesen Datenträgern für die Zukunft zu bewahren. Außerdem kann ein normaler PC aufgrund der Schreibweise keine Amiga-Disketten lesen/schreiben.

Schreiben von Daten - Versuch 1

Nachdem ich erfolgreich Datenträger lesen konnte, dachte ich, wenn Sie das ursprüngliche physische Medium behalten möchten, möchten Sie die Datenträger möglicherweise wieder zurückschreiben. Ich dachte mir, ich würde das umgekehrt machen, beginnend mit der Software (d.h.:Konvertieren der ADF-Diskdateien in MFM-Daten, damit die Schnittstelle irgendwie schreiben kann ).

Also begann ich damit, Klassen hinzuzufügen, um eine ADF-Disk zu lesen und alle Sektoren als eine Spur zu codieren. Da ich wusste, dass ich die von mir erstellten Daten möglicherweise testen könnte, indem ich sie wieder in den Dekodierungsteil einspeist, begann ich mit der Arbeit daran. Während ich daran arbeitete, beschloss ich, herauszufinden, was mit meinem Amiga nicht stimmte. Schließlich kann ich keine von mir erstellten Datenträger testen, wenn ich nichts echtes habe um sie zu testen.

Als ich meinen A500+ auseinander nahm, bemerkte ich, dass er eines der häufigsten Probleme hatte, die Batterie der Uhr war überall ausgelaufen. Also entlötete ich dies von der Platine und machte mich daran, die Platine zu reinigen. Währenddessen zog ich die gesamte Maschine heraus und machte mich daran, 20 Jahre Staub und Schmutz aufzuräumen. Ich habe sogar das Diskettenlaufwerk auseinander genommen, um es zu reinigen.

Beim Reinigen entschied ich, dass es an der Zeit ist, die Vergilbung loszuwerden, also habe ich die Informationen über Retr0brite befolgt und es ausprobiert.

Ich habe dann alle Verbindungen auf der Hauptplatine überprüft und eine lockere Verbindung am Stromanschluss festgestellt, ein paar Nachbesserungen mit dem Lötkolben und so gut wie neu. Ich wartete, bis ich mit dem Retr0brite-Prozess zufrieden war, bevor ich den Computer wieder zusammenbaute.

Währenddessen arbeitete ich weiter am Code zum Schreiben von Disketten. Ich wollte den Status der Schreibschutzleitung lesen, aber egal, was ich einstellte, schien sich die Spannung nicht zu ändern. Also zog ich das Laufwerk auseinander und folgte den Spuren von den kleinen Schaltern, die den Schreibschutzstatus erkennen, bis zu einem kleinen IC. An dieser Stelle habe ich vermutet, dass die Ausgabe wahrscheinlich nur verfügbar ist, wenn Sie tatsächlich Daten schreiben möchten.

Nach viel des Experimentierens habe ich festgestellt, dass Sie das /WRITE_GATE . ziehen müssen Pin LOW, bevor Sie das Laufwerk hochfahren, um das Schreiben zu ermöglichen. An dieser Stelle können Sie den Schreibschutzstatus abrufen. Mir ist auch aufgefallen, dass während des /WRITE_GATE niedrig war, schaltete sich das Laufwerk nicht wie früher aus, bis dieser Pin in seinen Standard-HIGH-Zustand zurückgekehrt war.

Der Amiga würde einen ganzen Track auf einmal schreiben. Ein Track im Speicher ist 11*512 Bytes (5638 Bytes), aber nach der MFM-Kodierung und dem korrekten AmigaDOS-Format ergibt der Track 14848 Bytes. Nun, es gibt keine Möglichkeit, in die 2k Speicher des Arduino zu passen, noch in die 1k EEPROM. Ich brauchte eine alternative Methode.

Ich beschloss, dass ich versuchen würde, die Daten jeweils 1 Byte in einem Thread mit hoher Priorität zu senden und auf ein Antwortbyte vom Arduino zu warten, bevor ich das nächste sende. Ich habe die Baudrate auf 2M geändert, um die Verzögerung zwischen den Zeichen zu reduzieren. Das bedeutete, dass es ungefähr 5,5 uSek dauerte, jedes Zeichen zu senden und 5,5 uSek, um eines zurückzubekommen. Der Arduino müsste 8 Bit mit 500 kHz ausgeben, also würde er alle 16 uSek ein neues Byte benötigen. Es sollte also Zeit sein, vorausgesetzt, die Codeschleife ist eng genug und das Betriebssystem verzögert das Senden und Empfangen nicht zu sehr.

Dies war ein völliger Fehlschlag. Der gesamte Lese-/Schreibzyklus dauerte viel zu lange, weit über eine Umdrehung der Platte hinaus. Die Arduino-Seite war wahrscheinlich schnell genug, aber das Betriebssystem reagierte nicht genug. Das Lesen von Disketten funktioniert, weil das Betriebssystem (in meinem Fall Windows) die eingehenden Daten puffern würde, aber beim Schreiben würde Windows alles auf einmal senden, aber weil die Geschwindigkeit, mit der ich sende, viel schneller ist, als das Arduino es braucht, Daten würden verloren gehen. Aus diesem Grund habe ich mich für diesen zweiseitigen Anerkennungsprozess entschieden.

Schreiben von Daten - Versuch 2

Die Softwareflusskontrolle für diese Anwendung war einfach nicht schnell genug. Ich beschloss, die Hardwareflusskontrolle zu untersuchen. Ich habe bemerkt, dass auf dem FTDI-Breakout-Board CTS- und DTR-Pin vorhanden sind. Diese stehen für Clear To Send und Datenterminal bereit . Mir ist aufgefallen, dass, während das Breakout-Board angeschlossen war, das Arduino-Board das CTS mit GND verband.

Ich wusste auch nicht, in welche Richtung diese Pins tatsächlich waren, aber nach einigen Experimenten stellte ich fest, dass der CTS-Pin vom Arduino signalisiert und vom PC zur Steuerung des Flusses verwendet werden konnte. Normalerweise geschieht dies mit einem Ringpuffer, aber in meinem Fall konnte ich dies nicht zulassen, also setze ich es einfach auf '1', wenn ich keine Daten haben möchte, und '0', wenn ich dies tue.

Das bedeutete jetzt, dass ich das Betriebssystem einfach bitten konnte, die Bytes als einen Block zu senden, und hoffen, dass alles auf Kernel-Ebene gehandhabt wurde, damit es nicht unterbrochen wurde.

Ich hatte eine innere Schleife, die jedes Bit aus den 8 Bits ausgab, entschied aber, dass es vom Timing wahrscheinlich besser war, es stattdessen in 8 Befehlssätze aufzuteilen.

Dies hat nicht funktioniert. Wenn ich den Code laufen ließ, ohne den Disk-Writing-Teil auszuführen, wurden alle Bytes korrekt empfangen, aber beim Ausführen des Codes war dies nicht der Fall und die empfangenen Bytes gingen verloren.

Ich vermutete, dass das Ändern des Status der CTX-Leitung den Datenfluss nicht sofort stoppte und der Computer möglicherweise immer noch ein oder zwei Zeichen sendet. Als ich die CTX-Leitung signalisiert hatte, war sie möglicherweise bereits dabei, das nächste Zeichen zu senden.

Schreiben von Daten - Versuch 3

Ich wollte keinen seriellen Interrupt haben, da ich nicht wollte, dass die Schreibzeiten verzerrt werden. Mir wurde klar, dass zwischen dem Schreiben jedes Bits auf das Diskettenlaufwerk eine Reihe von CPU-Zyklen in der nächsten while-Schleife sitzen würde. Ich beschloss, zwischen jedem Bit-Schreiben zu überprüfen, ob ein weiteres Byte empfangen wurde, seit CTX hoch gegangen ist, und es zu speichern.

Meine Theorie war, dass, als Sie CTX erhöht haben, der Computer wahrscheinlich schon mitten in der Übertragung des nächsten Bytes war und da Sie es nicht mitten im Stream stoppen können, würde es nach diesem halben. Das bedeutet, dass ich während der Schleife nur nach einem zusätzlichen Byte suchen und es verwenden muss, wenn es gefunden wird, anstatt erneut auf den seriellen Port zu schauen.

Dies schien also zu funktionieren, und der Arduino schloss den Schreibvorgang ab, ohne Daten vom Computer zu verlieren. Die einzigen Fragen waren jetzt:wurden tatsächlich Daten geschrieben und wenn ja, sind irgendwelche davon gültig?

Zu diesem Zeitpunkt hatte ich nur einen Track codiert, also beschloss ich, den gesamten Algorithmus auszuführen, um alle 80 Tracks zu codieren. Etwas Seltsames geschah. Der Antriebskopf bewegte sich überhaupt nicht. Beim Lesen war es immer noch so, aber beim Schreiben nicht.

Ich habe festgestellt, dass Sie, um den Antriebskopf hin und her zu bewegen, zuerst den /WRITE GATE-Pin anheben mussten, ich vermutete, dass dies auch zum Ändern der Oberfläche erforderlich war. Nachdem ich dazu Code hinzugefügt hatte, bewegte sich der Laufwerkskopf wie erwartet. Dies war sinnvoll und würde ein versehentliches Schreiben von Tracks beim Bewegen des Kopfes verhindern.

An diesem Punkt habe ich also ein Disk-Image geschrieben, das ich zuvor erstellt hatte, und dann versucht, es zurückzulesen. Es konnte nichts festgestellt werden! Entweder waren die von mir geschriebenen Daten ungültig oder meine Schreibweise war falsch.

Ich beschloss, die codierten MFM-Sektordaten, die ich erstellte, in meinen Sektordecodierungsalgorithmus einzugeben, der vom Leser verwendet wird, um zu überprüfen, ob das, was ich generierte, richtig und gültig war, und das war es auch. Offensichtlich stimmte etwas nicht mit dem Schreiben der Daten auf die Diskette.

Schreiben von Daten - Versuch 4

Da keine Daten richtig gelesen wurden, entschied ich mich, ein paar verschiedene Ansätze auszuprobieren. Ich war mir nicht sicher, ob der /WRITE DATA-Pin gepulst werden sollte (und wenn ja, wie lange), umgeschaltet oder einfach auf den Rohdatenwert gesetzt werden sollte. Meine aktuelle Implementierung hat den Pin gepulst. Ich konnte online keine Informationen darüber finden, wie die Schreibnadel beim Schreiben physisch manipuliert werden sollte.

Der Lesekopf würde uns bei jeder Flussumkehr einen Impuls senden. Ich beschloss, die Implementierung so zu ändern, dass WRITE DATA nur auf den Wert des Bits gesetzt wurde. Das hat auch nicht funktioniert. Also habe ich den Code geändert, um den aktuellen Status des Pins umzuschalten. Immer noch kein Glück.

Offensichtlich muss einer dieser Ansätze der richtige gewesen sein. Also beschloss ich, das vertraute Oszilloskop wieder herauszuholen, um zu sehen, was los war. Ich beschloss, das MFM-Muster 0xAA kontinuierlich in jedes Byte einer Spur zu schreiben. 0xAA in binär ist B10101010, also würde mir dies eine perfekte Rechteckwelle geben, die ich auf die erforderliche Frequenz überwachen könnte.

Wenn es bei der gewünschten Frequenz keine perfekte Rechteckwelle sah, wusste ich, dass es ein Timing-Problem geben musste.

Ich habe das Zielfernrohr angeschlossen, war aber überrascht zu sehen, dass die Timings waren perfekt. Da ich jedoch ein altes Zielfernrohr bin, konnte ich nicht mehr als ein paar Impulse sehen. Das Zielfernrohr hatte diesen wunderbaren x10 "Mag"-Modus. Beim Drücken wurde die Zeitbasis um 10 erhöht, aber was noch wichtiger ist, dass Sie durch alle Daten blättern können, ähnlich wie auf einem modernen digitalen Zielfernrohr.

Hier stimmte etwas nicht. Es sah aus wie alle 12 Bit oder so, ich hatte eine Periode von nur "hoch" .

Entweder waren die von mir gesendeten Daten in irgendeiner Weise ungültig, oder es gab etwas, das alle 12 Bit oder so eine Pause im Schreibprozess verursachte. 12 ist eine seltsame Zahl, wenn man bedenkt, dass ein Byte nur 8 Bit hat.

Nachdem ich darüber nachgedacht hatte, fragte ich mich, ob ich mit einem Problem mit der Flusssteuerung zurück war. Die Art und Weise, wie ich die Schleife entworfen hatte, bestand darin, alle verstreuten zusätzlichen Bytes aufzufangen, die empfangen wurden, nachdem wir auf eins gewartet hatten. Aber es war nicht intelligent genug, um das Warten auf jedes zweite Byte zu verhindern. Ich hatte zwei Möglichkeiten:etwas verschieben in einen Interrupt oder patchen Sie die Schleife.

Ich beschloss, zuerst die Funktionsweise der Schleife zu korrigieren. Das Problem war auf eine Verzögerung zurückzuführen, die durch das Warten auf das nächste Byte vom Computer verursacht wurde. Wenn wir CTX gesenkt und auf ein Byte gewartet haben, war bereits ein weiteres Byte unterwegs, als wir CTX wieder erhöht haben.

Ich ändere die Schleife so, dass der Arduino, wenn das zweite empfangene Byte verwendet wurde, CTS kurzzeitig auf Low und dann wieder High zog, damit ein weiteres Zeichen gesendet werden kann. Dies bedeutete, dass wir bei der nächsten Schleife bereits das nächste Byte erhalten hätten, sodass kein Warten erforderlich war.

Dieser Test ergab eine perfekte Rechteckwelle:

Das bedeutete, dass das Timing für das Schreiben eines Tracks perfekt war, es lag nur an der tatsächlichen Daten, die geschrieben wurden. Ich beschloss, dies für ein paar Tracks und Seiten laufen zu lassen und dann noch einmal zu lesen, um zu sehen, ob es richtig geschrieben war. Ich habe den /WRITE_DATA-Pin auf den entsprechenden Bitwert aus den empfangenen Daten gesetzt.

Beim Zurücklesen der Daten sah es so aus, als ob nichts kodiert worden wäre, aber dann habe ich auf die andere Seite der Diskette gesprungen. Sicher genug, da war mein Muster. Ich wusste nicht, warum es nur auf eine Seite der Diskette geschrieben wurde.

Nach einigem Nachdenken begann ich mich zu fragen, ob der /WRITE GATE-Pin nicht wirklich so funktionierte, wie ich dachte. Es stellte sich heraus, dass durch Ziehen des Stifts nach unten möglicherweise der Löschkopf auf dem Laufwerk aktiviert wird. Wenn dies der Fall ist, sollte ich dies nur tun, wenn ich tatsächlich schreibe, oder es könnte zu Rauschen auf der Festplatte kommen, wenn sie sich dreht und löscht.

Ich habe den gesamten Code so geändert, dass das /WRITE GATE nur beim ersten Start des Laufwerks und später nur buchstäblich während der Schreibschleife verwendet wurde. Das hat funktioniert! Ich habe jetzt Daten auf beide Seiten der Festplatte geschrieben!

Also habe ich es noch einmal mit einem echten ADF-Disk-Image versucht und es komplettieren lassen. Ich habe dann den Leserteil verwendet, um zu sehen, ob ich ihn zurücklesen könnte. Es funktionierte! Aber aus irgendeinem Grund hat es einige Zeit gedauert, diese Diskette zurückzulesen. Ich habe keine MFM-Fehler erhalten, aber ich hatte Schwierigkeiten, alle Sektoren zu finden.

Für mich gab es jetzt zwei Möglichkeiten:Erstens, die Daten tatsächlich rechtzeitig genug geschrieben haben; und zweitens, würde die Platte tatsächlich in einem echten Amiga funktionieren?

Zu aufgeregt von der Idee, dass ich vielleicht tatsächlich eine Diskette geschrieben habe, die ich jetzt funktioniert hochgefahren habe A500+ und legen Sie die Festplatte ein. Augenblicke später wurde die Festplatte gestartet und zeigte dann die berühmte Prüfsummenfehlermeldung an. Also habe ich etwas geschrieben gültig, aber nicht konsistent.

Ich entschied, dass es sinnlos war, eine Diskette zu schreiben, wenn ich die Daten nicht mit einer viel genaueren Geschwindigkeit zurücklesen konnte.

Daten lesen (wieder)

Ich wollte die Lesequalität verbessern, da ich mit der aktuellen Implementierung nicht zufrieden war. Die aktuelle Implementierung ließ nicht genügend Flexibilität zu, damit die Impulse zu etwas ungeraden Zeiten ankommen. Ich brauchte einen neuen Ansatz.

Zuerst entschied ich mich, den Messwert mit dem /INDEX-Impuls zu synchronisieren. Es wird vom Amiga nicht benötigt, kann mir aber später beim Testen, Schreiben und Lesen nützlich sein.

Mehrere Leute in den Kommentaren zur ersten Hälfte dieses Projekts schlugen vor, dass ich das Timing zwischen den Pulsen aufzeichnen sollte, anstatt die Methode, die ich implementiert hatte. Das einzige Problem dabei war, diese Daten schnell genug auf den PC zu bekommen. Wenn ich für jedes Bit ein Byte senden müsste, könnte ich die maximalen 2M Baud leicht überschreiten.

Ich entschied, dass es am besten wäre, zu versuchen, die Daten ein wenig zu verstehen. Also beschloss ich, den Zähler, den ich ursprünglich verwendet habe, freilaufen zu lassen, bis auf 255. Dann habe ich den Code in eine Schleife gesteckt und auf einen Impuls gewartet, und an diesem Punkt sah ich, wie viel Zeit vergangen war.

Im Idealfall wäre der kleinstmögliche Minimalwert 32 (entspricht 2 uSek). Mit MFM konnte man immer nur maximal drei Nullen hintereinander haben, also sollte dieser Wert maximal 128 erreichen. Das bedeutete, dass es maximal 4 mögliche Kombinationen hintereinander gab.

Ich habe mehrere Festplatten abgetastet, um zu sehen, wo die meisten dieser Frequenzen liegen, und die Ergebnisse sind unten zu sehen:

Wenn ich mir das anschaue, finde ich die meisten Punkte um einen Zähler von 52, 89 und 120 herum. Diese waren jedoch etwas spezifisch für meinen Antrieb und daher keine gute Richtlinie. Nach einigen Experimenten habe ich die folgende Formel verwendet:value =(COUNTER - 16) / 32 . Bei einer Beschneidung zwischen 0 und 3 erhielt ich die erforderliche Ausgabe. Alle 4 davon und ich könnte ein Byte ausschreiben.

Mir ist aufgefallen, dass ich mit Sicherheit davon ausgehen konnte, dass alles für den ersten Wert ungültig war und als eine andere '01'-Sequenz behandelt werden konnte, da Sie nicht zwei "1"en zusammen in einem MFM-codierten Bitstrom haben konnten. Der nächste Teil bestand darin, diese vom PC empfangenen Daten zu entpacken und wieder in MFM-Daten umzuwandeln. Dies war einfach, da 00 nicht passieren konnte, eine 01 bedeutete '01' schreiben, eine 10 bedeutete '001' schreiben und eine 11 bedeutete '0001' schreiben. Ich habe es ausprobiert und zu meiner Überraschung waren meine Ergebnisse zu 100% erfolgreich. Ich habe es auch mit ein paar weiteren Festplatten versucht, 100%! Ich hatte jetzt einen sehr zuverlässigen Disk-Reader.

Da dieser neue Ansatz viel toleranter gegenüber den Daten von der Festplatte ist, benötigte ich keine Phasenanalyse oder so viele Wiederholungen mehr. Die meisten meiner Disketten lesen jetzt perfekt. Einige erforderten ein paar Wiederholungen, kamen aber am Ende ans Ziel. Der letzte Teil bestand darin, die Daten statistisch zu analysieren und zu sehen, ob sie repariert werden können. Allerdings waren 99% der eingehenden schlechten Daten völlig unerkennbar und daher wenig hilfreich.

Schreiben von Daten - Versuch 5

Da ich nun mit hoher Genauigkeit überprüfen konnte, was ich geschrieben hatte, war es viel einfacher, den Autor zu testen.

Ich machte mich daran, den Code zu analysieren, um zu sehen, was schief gelaufen war. Ich habe eine 0x55-Sequenz für einen ganzen Track geschrieben und dann wieder eingelesen. Von Zeit zu Zeit hatte sich ein bisschen in den zurückkommenden Daten verschoben, was bedeutete, dass es beim Schreiben ein Timing-Problem gab.

Es stellte sich heraus, dass dies teilweise an der Art und Weise lag, wie ich mit der seriellen Schnittstelle umging, und teilweise an der Verwendung des Timers. Ich habe gewartet, bis der Timer den Wert 32 erreicht, das Bit geschrieben und es dann zurückgesetzt. Ich habe es geändert, damit ich den Timer-Zählerwert nicht ändern musste.

Ich würde das erste Bit schreiben, wenn der Zähler 16 erreicht, dann das nächste, wenn es 48 (16+32) erreicht, und das nächste, wenn es 80 (16+32+32) erreicht und so weiter. Timer2, der nur 8-Bit ist, rollt nach dem 8. Bit auf Null zurück, genau dann, wenn wir es brauchten. Dies bedeutete, dass wir, solange wir das Bit mit dem erforderlichen Timer-Wert schreiben, bei genau 500 kbps wären.

Ich habe mir auch angeschaut, wie ich die Daten von der seriellen Schnittstelle ausgelesen habe. Dies wurde zwischen jedem Bit gelesen, aber auch dies musste so kurz wie möglich sein. Nach ein wenig Experimentieren habe ich den kürzesten Arbeitsblock erreicht.

Nachdem ich den Windows-Code geändert hatte, um die Überprüfung zu unterstützen, war ich nun bereit, es erneut zu versuchen. Diesmal wusste ich, dass, wenn die Festplatte richtig verifiziert wurde, sie im Amiga richtig funktionieren sollte.

Also habe ich versucht, eine andere Diskette zu schreiben. Mit verifizieren hat es länger gedauert. Mit dem neuen Algorithmus haben etwa 95 % der Tracks die Verifikation auf Anhieb bestanden, nur die restlichen 5 % müssen noch einmal geschrieben werden. Ich war damit zufrieden und steckte die Diskette in den Amiga. Es hat perfekt funktioniert!

Schreiben von Daten - Versuch 6

Nach einigen Rückmeldungen von einigen Leuten, die dies verwendet haben, war klar, dass selbst mit Überprüfung auf dem Laufwerk nicht immer vollständig lesbare Datenträger hergestellt wurden. Die Software konnte sie einwandfrei zurücklesen, aber die Amiga-Computer meldeten hier und da ein paar Prüfsummenfehler.

Ich habe mir den Code noch einmal angesehen, mich gefragt, ob es sich um ein Timing-Problem handelt, und habe nachgeschaut, ob er Interrupt-gesteuert werden könnte, aber leider ist bei der geringen Zeit zwischen den einzelnen Bits einfach nicht genug Zeit für Interrupts, um erreichen Sie dies, indem Sie die von Ihnen geänderten Register usw. beibehalten.

Dann habe ich mir den Schreibcode angeschaut. Es besteht die geringe Möglichkeit, dass der Code nach dem Schreiben eines vollen Bytes eine Schleife durchlaufen hat, um mit dem Schreiben des nächsten Bytes zu beginnen, bevor der Timer wieder auf 0 übergelaufen war, wodurch das erste Bit früher geschrieben werden konnte.

Ich habe eine kleine Schleife hinzugefügt, um sicherzustellen, dass dies nicht passieren kann, was hoffentlich für jeden mit diesem Problem behoben wird.

Schreiben von Daten - Versuch 7

Nachdem ich viele Berichte über Prüfsummenfehler für beschriebene Datenträger erhalten hatte, begann ich mit der Untersuchung. Ich dachte zuerst, ich müsste mir die MFM-Daten von der Festplatte ansehen, aber das Problem war eigentlich viel einfacher

Betrachtet man XCopy Pro, um die Prüfsummenfehler zu sehen, wurden die Codes 4 und 6 gemeldet, was Prüfsummenfehler in den Sektor-Headern und Datenbereichen bedeutet. Wenn es nur der Datenbereich gewesen wäre, hätte ich angenommen, dass es nur darum ging, die letzten paar Bits des Tracks zu schreiben, aber das war es nicht.

Ich fing an, mir den Schreibcode und das Padding, das ich um jeden Track herum hatte, anzuschauen, und fragte mich, ob ich ab und zu den Beginn eines Tracks überschrieb, also habe ich das Padding nach dem Track massiv von 256 Byte auf 8 reduziert. Zu meiner Überraschung meine Überprüfung dann eine Menge Fehler rausgeschmissen.

Ich habe mich gefragt, ob das eigentliche Problem darin besteht, dass ich nicht genügend Daten schreibe. Ich machte mich daran, dem Arduino einen Track Erase-Befehl hinzuzufügen, der das 0xAA-Muster in die gesamte Spur schreibt und dann meine Spur danach schreibt. Zu meiner Überraschung gab XCopy ihm einen 100%igen Daumen nach oben. Das Problem ist damit hoffentlich behoben.

Diagnose

Ich habe viele Rückmeldungen von Leuten bekommen, die dieses Projekt erfolgreich gemacht haben, sowohl voll funktionsfähig als auch nicht. Ich beschloss, ein Diagnosemodul in den Code zu integrieren, um jedem zu helfen, der seines nicht zum Laufen bringen kann.

Die Diagnoseoption besteht aus ein paar zusätzlichen Befehlen, die der Arduino verarbeiten muss, sowie einer ganzen Reihe von Ereignissen, die durchlaufen werden, um sicherzustellen, dass alles richtig verdrahtet ist.

Was kommt als nächstes?

Das gesamte Projekt ist frei und Open Source unter GNU General Public License V3. Wenn wir eine Hoffnung haben wollen, den Amiga zu erhalten, dann sollten wir uns nicht gegenseitig für das Privileg übers Ohr hauen. Außerdem möchte ich der besten Plattform, auf der ich je gearbeitet habe, etwas zurückgeben. Ich hoffe auch, dass die Leute dies weiterentwickeln und weiterentwickeln und weiter teilen.

Die aktuelle Schreiblösung ist auf dem Arduino UNO keine Option, es sei denn, Sie verwenden ein separates FTDI / serielles Breakout-Board. Meine nächsten Aufgaben bestehen also darin, es zum Laufen zu bringen (möglicherweise mit dem 23K256-IC, um die Spur zu puffern, bevor Sie sie in die schreiben Datenträger).

Ich möchte mir noch andere Formate ansehen. ADF-Dateien sind gut, funktionieren aber nur für AmigaDOS-formatierte Disketten. Es gibt viele Titel mit benutzerdefiniertem Kopierschutz und nicht standardmäßigen Sektorformaten, die von diesem Format einfach nicht unterstützt werden können. Ich habe einige sehr nützliche Informationen dazu erhalten, habe aber derzeit nicht viele Festplatten zum Testen.

Laut Wikipedia gibt es ein weiteres Festplattendateiformat, das FDI-Format. Ein universelles Format, das gut dokumentiert ist. Der Vorteil dieses Formats besteht darin, dass es versucht, die Trackdaten so nah wie möglich am Original zu speichern, damit hoffentlich die oben genannten Probleme behoben werden!

Ich bin auch auf die Software Preservation Society gestoßen, genauer gesagt CAPS (ehemals die Classic Amiga Preservation Society ) und ihr IPF-Format. Nach ein wenig Lesen war ich sehr enttäuscht; Es ist alles geschlossen und es fühlte sich an, als würden sie dieses Format nur verwenden, um ihre Hardware zum Lesen von Festplatten zu verkaufen.

Mein Fokus wird also auf dem FDI-Format liegen. Mir geht es hier nur um die Datenintegrität. Es wird keine Prüfsummen geben, mit denen ich überprüfen kann, ob der Lesevorgang gültig war, aber ich habe ein paar Ideen, um das zu beheben!

Code

Skizze und Windows-Anwendungsquelle

Schaltpläne