Monat: Mai 2016

Funzt :)

Da der Schreibmodus mittlerweile funktioniert und auf dem trockenen schwimmen keinen Spass macht hab ich mal meinen Amiga 4000 aufgebaut, einige Disketten geschrieben und am lebenden Objekt getestet. Da ich ja auch ein Diagnoseprogramm brauchte hab ich mit dem Amiga Emulator (WinUAE) ein ADF erstellt und dort das Programm DiskSalv4 von Dave Haynie aufgespielt, dann mit meinem ADF Writer auf eine Disk geschrieben und in den Amiga geworfen.

Die Diskette hat der Amiga mit seinem 20 Jahre alten Laufwerk ohne murren gelesen :)

Mit Hilfe von Disksalv hab ich dann einige andere Disketten die ich geschrieben hatte überprüft, lies sich alles ohne Probleme lesen, kein einziger Retry bei einem Track, ich bin zufrieden.

Einzig HD Disketten die ich als DD beschrieben hatte waren teilweise unlesbar, ich hatte natürlich das HD Loch abgeklebt. Ich hab dann mal so eine Diskette mit zugeklebten Loch mit meinem ADF Writer beschrieben, und siehe da, einwandfrei lesbar. Scheinbar verhält sich das Floppy Laufwerk unterschiedlich wenn das HD Loch zu oder offen ist, aber wenn man das weiß kann man darauf achten.

Jetzt gehts daran das Frontend auf dem PC etwas aufzuhübschen und Nutzerfreundlicher zu machen, und vielleicht Verify einzubauen :)

Spannung ist spannend…

Gestern lief alles und heute geht nichts mehr. Beim Lesen und Schreiben fing der Schreib/Lese Kopf einfach mittendrin an in die falsche Richtung zu wandern, d.h. wenn er einen Track richtung Innen fahren sollte fuhr er einen Schritt richtung Außen, oder bewegte sich mehrere Schritte anstatt einem, wtf?

Nach stundenlanger Suche nach Timing Problemen bei der Ansteuerung des Schrittmotors, oder ob mir irgendwas in die Serielle Kommunikation spuckt fiel mir ein das ich das Netzteil für die Floppy über Nacht angelassen hatte und kontrollierte mal die Spannung. Ich hatte es auf 5V eingestellt, nun zeigte es 4,96V an, sollte eigentlich kein Problem sein… oder? Die Spannung wird über ein Poti eingestellt, ist halt ein billiges Labornetzteil, wird wohl das Poti über Nacht etwas gedriftet sein wegen Wärme, Wetter oder einer Fischschwarmwanderung im Pazifik. Hab es dann auf 5,01V gestellt und hossa, keine Probleme mehr!

Das Laufwerk scheint eine echte Diva zu sein das 0,05V soviel ausmachen. Meine Vermutung mittlerweile ist das das billige Labornetzteil kurz in der Spannung einknickt wenn der Schrittmotor einen Step macht, laut Datasheet eines Samsung Laufwerks zieht sowas 0,7A, und das es mit den 0,05V Unterschied dann genau unterhalb der zulässigen Grenze sinkt. Nun steht es auf 5,2V, das sollte genug Luft sein.

 

Nur eine handvoll Bits

Ich hab mich in den letzten Tagen damit beschäftigt den Schreibmodus zum laufen zu bringen… mit einigen Hürden.

Da auf der Magnetscheibe einer Floppy die Daten ja im MFM Format gespeichert sind muss man die Daten die da rauf sollen vorher in MFM codieren.
Zur Decodierung hab ich einige Beispiele im Netz gefunden, das war nicht so schwierig, aber für die Encodierung findet sich sehr wenig. Irgendwann bin ich dann auf eine MFM Codierungroutine des Win Fellows Amiga Emulators gestoßen, hab diese dann auch ausprobiert und es kam nur Grütze bei raus :(

Nachdem ich mich dann doch durch mehrere Kapitel im Buch „Amiga Disk Drives: inside & Out“ von Grote Gelfland Abraham erschienen bei Abacus/Data Becker 1988 gekämpft habe (wer schon mal ein Hardware Buch von Data Becker in der Hand hatte weiß das die schwierig zu lesen waren, und dazu kam noch das hier in Englisch war) hab ich festgestellt das die Routine nicht vollständig MFM codierung implementiert hatte, sondern nur soweit das der Amiga Emulator das als MFM gefressen hat, es waren also die Clock Bits nicht korrekt berechnet. Auch bei der Checksummenberechnung stimmte auch irgendwas nicht.
Hab also das meiste über Bord geworfen und selbst geschrieben. Nach vielen Versuchen lief dann die Codierung eines Sektors.

Ein Sektor mit 512 Datenbytes wird zu 1024 MFM codierten Bytes, dazu kommen noch Informationen über die Nummer des Sektors, Track, Abstand zum Gap, zwei Checksummen und ein ungenutzter 16 Byte Bereich, am Ende sind es dann 1088 MFM Bytes. 11 Sektoren passen auch einen Track und dann kommt die Track Gap, ein Bereich einer Spur in den kein kompletter Sektor mehr passen würde, der aber gefüllt sein muss um alte Daten auf der Spur zu überschreiben.

In der Routine des Emulators wird die GAP nach den Sektoren geschrieben, das kam mit aber unlogisch vor da man ja nicht genau wissen kann wie lang die Spur wirklich ist, da ein Laufwerk ja auch gewissen Schwankungen unterliegt. Also schreibe ich zuerst eine etwas längere Gap und dann die Sektoren sodaß der letzte Sektor etwas von der Gap überschreibt und ich sicher gehen kann das keine alten Daten überleben und kein Sektor einer vorherigen beschreibung auch nur teilweise überlebt. Weil ein Sektor wird zu beginn durch eine reihe von MFM Bytes (4x 0xAA gefolgt von 2x 0x4489) gekennzeichnet die durch die Kodierung von Datenbytes niemals zustanden kommen können, somit eindeutig sind. Und wenn sowas von einer vorherigen beschreibung der Spur überlebt würde man plötzlich 12 Sektoren finden und wüsste nicht welches die richtigen 11 sind, oder müsste mehr Aufwand beim Lesen betreiben.

Bei einer späteren Analyse eines Logikanalysatormitschnitts eines Schreibzugriffes an einem echten Amiga stellte ich fest das die es genauso machen, darüber haben sich natürlich die Bücher ausgeschwiegen, aber egal, ging ja auch mit nachdenken :)

Irgendwann lief dann auch die Schreibroutine und ich konnte ADF Images auf Disketten schreiben, Eureka! Nur gab es eine Menge unslesbare Tracks, aber je nach Image mal mehr mal weniger, und wie ich feststellte immer an den selben Stellen. Komisch gelle? Ich zweifelte erstmal meine MFM codier routine an. Hab da aber nichts finden können. Später stellte ich dann fest das immer beim letzten Sektor das letzte Byte fehlerhaft war… Lange rede kurzer Sinn: Denkfehler in der Schreibroutine.

void diskWrite()
{
 if (writeActive == false) return;
 digitalWriteFast(_writedata, !(dataByte >> 7));
 dataByte = dataByte << 1;
 writeBitCnt++;
 if (writeBitCnt == 8) {
 writePtr++;
 dataByte = stream[writePtr];
 writeBitCnt = 0;
 }
 if (writePtr >= writeSize) {
 writeActive = false;
 digitalWriteFast(_writedata, HIGH);
 }
}

Hier meine Schreibroutine, wird im 2µs Takt aufgerufen und shiftet die Bits aus dem MFM Puffer an die Schreibleitung der Floppy. Ich habe den Fehler mal rot markiert… Ich hab den Schreibvorgang beendet bevor das letzte Byte rausgeshifted wurde… Narf! Es fehlten also von letzten Byte die 4 ungeraden Bits, das erklärte auch warum manche Tracks in Ordnung waren und viele nicht.

richtig lautet die Zeile:
if (writePtr > writeSize) { … usw}

Anfängerfehler :-P

Frontend für den PC

 

Nachdem es nun eine Wochen ruhig waren hier ein weiteres Update, ich war ja nicht untätig, nur zu faul zum bloggen ;)frontend01

Da ich mich irgendwie mit keiner IDE für C++ anfreunden konnte und ich unter Windows eigentlich noch nie was mit C++ und GUI gemacht habe hab ich zu Processing 3.0 gegriffen, damit hatte ich schon mal ein Frontend für ein Projekt geschrieben und Erfahrungen gesammelt. Processing ist ein Java Dialekt mit kompletter IDE, vielen Grafikbefehlen und einer großen Library Base. Ich bin zwar kein JAVA Spezialist, aber passt schon, Google ist mein Freund, und während meines Studiums hatte ich viel mit Modula zu tun und irgendwie sind sich ja alle Imperativen Programmiersprachen sehr ähnlich :)

Das Interface brauch noch ein bischen Liebe, aber für erste Ergebnisse reichts.

  • „getName“ liest den Volumename der Diskette
  • „Save As“ öffnet einen Requester um den Speicherort und Namen festzulegen
  • „Dump“ liest von Start Track bis End Track eine Amigadisk ein und speichert sie als .adf
  • „Abort“ bricht den Lesevorgang ab.
  • „Read“ liest einen Track und zeigt im Infofenster an wieviel Sektoren gefunden wurden, ist noch zu Debugzwecken drinne
  • Im Infofenster wird angezeigt bei welchem Track gerade gelesen wird, Fehler usw.

Unten wird die Häufung der Transitionen angezeigt, je heller desto mehr, hier kann man sehen das die Transitionen in der Regel etwas kürzer sind, bzw. die alte Flinte ganz schön streut. Ob ich da irgendwo einen Rechenfehler gemacht habe, sodaß die Transitionen oft kürzer als die Norm sind, keine Ahnung, vielleicht kümmer ich mich später nochmal darum. Man sieht hier auch viele Streubits, ich vermute das das Murks aus dem Trackgap ist.

Die Einstufung der Transitionen mache ich momentan wie folgt:

  • unter 1,5µs wird verworfen
  • 1,51µs bis 4,83µs ist eine ’10‘
  • 4,84µs bis 6,70µs ist eine ‚100‘
  • 6,71µs bis 8,58µs ist eine ‚1000‘
  • alles darüber wird verworfen

Die magenta Linien im Graph zeigen an das mehrere Leseversuche nötig waren um den Track zu lesen, ich prüfe ob ein Track 11 Sektoren enthält, dann ob die beiden Checksummen stimmen. Wenn etwas davon nicht stimmt wird der Track nochmal gelesen. Maximal macht der Mikrocontroller bisher 10 Versuche einen Track zu lesen, wenn der 10te auch fehlschlägt wird der Track so übertragen wie er ist und dem Frontend gemeldet in welchen Sektoren welche Checksummen nicht stimmen.

Wie man sieht ist diese Diskette ziemlich an der Grenze und besitzt schon einige Weak Tracks, wurde aber noch „korrekt“ ausgelesen. Da die Checksummen aus den MFM Daten per XOR generiert werden können sich hier natürlich Fehler einschleichen die nicht erkannt werden, von daher ist das „korrekt“ mit Vorsicht zu geniessen. Auf DOS Ebene gibt es noch mehr Checksummen, aber viele Spiele benutzen gar keine Filesystemfunktionen sondern benutzen das Trackdisk.device direkt. Damals gab es Kopierschutzverfahren die die Checksummen absichtlich falsch geschrieben haben, in den ungenutzten 16 Bytes im Header Informationen speicherten oder sonstwie am Header manipuliert haben, ein normales Copytool oder die Workbench konnte so eine Disk nicht kopieren. Ebenso gab es Spiele die ein andere Syncword benutzten, Sachen in die Trackgap schrieben, in GCR codiert waren, Laserlock benutzten, Track 80-82 benutzten usw., es gab ne Menge was sie machen konnten um die Piraten auf Abstand zu halten. Irgendwann wurde alles irgendwie geknackt, aber nicht jeder Normalo konnte mal eben ein Spiel im Laden kaufen und zig Kopien an seine Freunde auf dem Schulhof verteilen.

Aber ich will eh kein Kopierprogramm für geschützte Software schreiben sondern nur für Disketten die ohne Kopierschutz daher kommen, selbst nach 20 Jahren könnte das Eis dünn sein auf dem man sich da bewegt da es in Deutschland ja mittlerweile Strafbar ist einen Kopierschutz zu umgehen. Das war die subtile Maßnahme unserer Regierung das Recht auf Privatkopie im Urhebergesetz  § 53 Absatz 1 Satz 1 auszuhebeln ohne es anzufassen. Sie haben einfach ein neues geschaffen was die Umgehung technischer Schutzmaßnahmen §§ 95a ff. UrhG (DE) unter Strafe stellt. Allerdings lässt sich über die Formulierung „Wirksame technische Maßnahmen“ streiten :) Naja, sie treiben die Kohle ja eh über GEMA und ZPÜ ein, darüber kann man sich aber auch den Mund fusselig reden wenn man für die Digicam eine SD-Karte kauft und ZPÜ abdrücken muss weil man damit ja Urheberrechtlich geschütztes Material kopieren könnte, auf wiedersehen Unschuldsverdacht. :P