Monat: April 2016

Spielkrams

Mittlerweile hab ich in mein Programm noch ein paar Features eingebaut, unter anderem eine Analyse des Timings der Transitionen auf dem gerade gelesenen Track, so etwas sieht dann in der Ascii Ausgabe so aus:

Transitions: 47166 Real Bits: 110011
0.25:0-146+
1.83:38-1
2.33:50-1
3.58:80-3
3.63:81-11
3.67:82-75
3.71:83-1134++++++++
3.75:84-5063+++++++++++++++++++++++++++++++++++++++
3.79:85-8495++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.83:86-8020++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.88:87-5470++++++++++++++++++++++++++++++++++++++++++
3.92:88-2809+++++++++++++++++++++
3.96:89-1693+++++++++++++
4.00:90-749+++++
4.04:91-360++
4.08:92-60
4.13:93-4
5.38:123-3
5.42:124-18
5.46:125-105
5.50:126-288++
5.54:127-638++++
5.58:128-1097++++++++
5.63:129-1500+++++++++++
5.67:130-1788+++++++++++++
5.71:131-1662++++++++++++
5.75:132-1343++++++++++
5.79:133-1066++++++++
5.83:134-624++++
5.88:135-389+++
5.92:136-179+
5.96:137-52
6.00:138-7
6.04:139-2
7.38:171-3
7.42:172-20
7.46:173-65
7.50:174-102
7.54:175-211+
7.58:176-271++
7.63:177-395+++
7.67:178-413+++
7.71:179-326++
7.75:180-260++
7.79:181-202+
7.83:182-118
7.88:183-61
7.92:184-11
7.96:185-1
8.42:196-1
OK

Wo die 146 Transitionen mit einer länge von 0,25µs herkommen hab ich keine Ahnung, kommen vielleicht aus dem Trackgap weil da in der Regel nur Müll steht bzw. die Diskette dort nicht formatiert ist, soll mir aber egal sein, ich werte nur Transitionen aus die länger als 1,5µs sind 😉
Da der Controller des Amiga mit maximal 500kbit/s arbeitet besitzt er eh nur eine Auflösung von 2µs, würde sowas also überhaupt nicht mitbekommen, bzw. falls er auch Filter vorgeschaltet hat sowas als Leitungsrauschen wegfiltern.

 

Erste Versuche mit dem Teensy 3.2

adf_01
Versuchsaufbau

So sieht der Versuchsaufbau mit dem Teensy aus, ich konnte die Floppy direkt mit einem Steckbrett und ein paar Dingsdakabeln verdrahten, keine lästigen Spannungsteiler oder Levelshifter da der Teensy 3.2 direkt TTL Pegel auf den Eingängen frisst.

#define _redwc 2     //2 density select IN 
#define _index 3     //8 index OUT
#define _drivesel 4  //12 drive select 1 IN
#define _motor 5     //16 motor1 on IN
#define _dir 6       //18 direction IN
#define _step 7      //20 step IN
#define _writedata 8 //22 write data IN
#define _writeen 9   //24 write enable IN
#define _track0 10   //26 track 0 OUT
#define _wprot 11    //28 write protect OUT
#define _readdata 22 //30 read data OUT (FTM0)
#define _side 14     //32 head select IN
#define _ready 15    //34 ready / disk change OUT

Die ganzen Floppy Pins gehen von oben nach unten an die Pins vom Teensy, bis auf die Read Data Leitung, die habe ich nach Studium des Datenblatt an GPIO 22 gelegt, dieser GPIO lässt sich nämlich als Input Capture Trigger für das FlexTimer Module 0 benutzen.

Der FTM0 ist ein 16 Bit Timer der mit maximal Bus Clock läuft, Bus Clock ist beim Teensy der halbe Coreclock, da ich auf 96 MHz takte sind das 48 MHz. Über den Prescaler halbiere ich den Takt nochmal auf 24 MHz, d.h. alle 41,6 Nanosekunden zählt der Timer einen Schritt hoch. Für den Eingang habe ich noch einen Filter im Timer eingestellt sodaß das Signal am Input Trigger für mindestens 12 Taktzyklen Busclock (250ns) stabil sein muss damit es erkannt wird. Wird nun über den GPIO 22, welches der Input Capture Trigger für FlexTimer Modul 0 ist, ein Flankenwechsel (in meinem Falle Falling Edge) detektiert findet folgendes statt:

  • der Inhalt des Counters (FTM0_CNT) wird in ein extra Register (FTM0_C0V) kopiert
  • der Interrupt Vector (ftm0_isr) des FTM0 wird angesprungen
  • die von mir geschriebene Interruptroutine setzt den Counter auf Null
  • der Inhalt des Registers FTM0_C0V wird ausgewertet wie lang die Transition dauerte, 4,6 oder 8 µs
  • entsprechende schreibe ich in eine Puffervariable eine ’10‘, ‚100‘ oder ‚1000‘, ich benutze dafür ein Longword (32bit) in dem ich die Bits sammel und wenn ich 8 Bit oder mehr komplett habe schreibe ich sie in den Steambuffer.
  • On the Fly prüfe ich ob das Longword den Inhalt 0xA4489448 enthält, das ist nämlich der Anfang des Syncwords eine Amiga Sektors und kann ensprechend dem Stream entsprechend ausrichten das genau ein Byte anfängt. Ebenso vermerke ich in einer Tabelle einen Pointer auf den Sektoranfang im Speicher, das macht das decodieren später einfacher.
  • wenn der Streambuffer voll ist oder ich 11 Sektoren gefunden habe schalte ich die Interrupt Generierung aus.
  • der Interrupt benötigt etwa 0,9 µs pro Transition, d.h. sie ist lange fertig bevor die nächste Transition kommt (4µs oder länger)

Währenddessen wartet meine Hauptroutine nur darauf das der Lesevorgang beendet ist und startet danach die decodierung des Tracks.

Der ganze Spass läuft mittlerweile recht zuverlässig, hat zwar bisher kaum Fehlerüberprüfungen aber spuckt erste brauchbare Ergebnisse aus:

Reading Track 0
Sectors start at: 172, 2067, 3155, 4243, 5331, 6419, 7507, 8595, 9683, 10771, 11859
Decode took 1631
Sectors found: 11 Errors found: 0
OK
Format Type: 255 Track: 0 Sector: 0 NumSec2Gap: 3 Data Chk: 4410155 Header Chk: 0
44 4F 53 00 C0 20 0F 19 00 00 03 70 43 FA 00 18 4E AE FF A0 4A 80 67 0A 20 40 20 68 00 16 70 00 DOS.. .....pC...N...J.g. @ h..p.
4E 75 70 FF 60 FA 64 6F 73 2E 6C 69 62 72 61 72 79 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Nup.`.dos.library...............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................................

Oben sieht man den Bootsektor einer Amiga Diskette, in den ersten vier Bytes steht „DOS“,0 für eine normale Diskette, dann folgt eine kurze Assemblerroutine die über die dos.library den Boot der Disk startet.

Got it!

Nach ein wenig rumsuchen bin ich auf den Teensy 3.2 gestoßen:

  • 32 Bit Arm Cortex M4 Kern mit 72 MHz, übertaktbar bis 96 MHz
  • 256kb Flash Speicher für Code
  • 64kb RAM
  • 34 Pins IO
  • sehr schnelle Serielle Schnittstelle über USB (1 Mbps ohne Fehler)
  • 5V tolerant auf den IO Pins

Perfekt! Warten auf den Postboten 😉

Amigafloppy, erste Versuche

Für erste Versuche habe ich einen Arduino Mega benutzt. Ansteuerung der Floppy Mechanik funktionierte recht schnell, das Lesen gestalte sich Problematisch und ich hab schnell festgestellt das der Mega einfach zu wenig RAM hat um einen kompletten Track zu puffern. Ein Track einer Amiga Diskette besteht aus 11 Sektoren á 512 Bytes, klingt erstmal wenig, zu den 512 Bytes pro Sektor kommen noch 28 Bytes an Verwaltungsinformationen hinzu. Ein Sektor ist folgendermaßen aufgebaut:

struct Sector
{
 unsigned char format_type; // Beim Amiga immer 0xff
 unsigned char track; // Zu welchem logischen Track dieser Sektor gehört (0-159)
 unsigned char sector; //Sektor Nummer (0-10)
 unsigned char toGap; //Wieviel Sektoren noch kommen bevor der Trackgap kommt
 unsigned char os_recovery[16];// 16 Bytes die der Amiga nie benutzt hat, sind i.d.R mit Null gefüllt, außer bei Kopiergeschützten Sachen
 unsigned long header_chksum; // Checksumme der Daten im Header, wird mit Exklusiv Oder der MFM Daten generiert
 unsigned long data_chksum; // Checksumme der Daten im Datenblock, auch XOR der MFM Daten.
 unsigned char data[512]; // 512 Bytes Nutzdaten
};

Vor dem eigentlichen Sektor kommt noch das Syncword, das ist eine Reihenfolge von Bytes in MFM Stream der niemals durch normale Kodierung entstehen kann, beim Amiga sind das mehrfach „10“ bzw 0xA hintereinander, gefolgt von 0x44894489. Daran erkennt der Controller im Amiga das nun ein Sektor anfängt.

Da ein wechsel der Magnetisierung, auch Transition genannt zu einer unterschiedlichen länge von Bits entschlüsselt wird muss man auf Bitebene prüfen ob man gerade einen Sync gefunden hat, erst wenn man den Sync hat weiß man wo im Bitstream ein Byte anfängt.

8 µs -> 1000
6 µs -> 100
4 µs -> 10

Bei MFM codierung ist jedes zweite Bit ein Clock Bit damit der Controller nicht den Takt verliert, d.h. es ist eine 2:1 codierung, das bedeutet die hälfte der Bits wird beim decodieren weggeschmissen. Da aber die Checksummen mit den MFM Daten arbeiten muss man den MFM codierten Track bzw. Sektor im Speicher vorliegen haben. Und hier war der Arduino Mega am Ende mit seinen 8k Ram, das reicht zwar für einen Track im decodierten Zustand (5632 Bytes), aber nicht für die MFM Daten (11968 Bytes ohne Trackgap). On the Fly Decodierung und Checksummen berechnen geht leider auch nicht mit 16 MHz.
Es hätte vermutlich funktioniert jeweils nur immer einen Sektor zu lesen, decodieren und über die Serielle Schnittstelle an den PC zu schicken, aber das würde dann ewig brauchen um einen Track zu lesen.

Es muss also was neues her.

Lesegerät für Amiga Floppies

Da ich letztens mal wieder meinen Amiga aktiviert habe kam mir die Idee mal ein paar Daten vom meine Amiga Disketten zu retten. Ich hatte damals ein paar Sachen programmiert, Unterlagen aus meiner Studienzeit und so weiter. Prinzipiell gibts da ja verschiedene Möglichkeiten, aber ich fand es interessant mit einem Handelsüblichen PC Laufwerk und einem Mikrocontroller Amiga Disketten zu lesen, und später vielleicht auch zu schreiben.

Es gibt halb kommerzielle Produkte dafür zu kaufen, z.B. das KryoFlux, das kost so um die 100€, aber irgendwie macht das selber bauen mehr Spass. Und wenn ich sehe wie voll die Platine des KryoFlux ist, denke ich mir das geht einfacher mit modernen Microcontrollern, man muss nur den richtigen finden.

Im Netz findet man einige Informationen zum Interface von Floppy Laufwerken, dem Shugart Bus, der Bus arbeitet mit TTL Pegeln, also 0-5V. Da ich aber Sachen besser begreife wenn ich sie „sehe“ hab ich mal meinen Logikanalysator an den Floppy Port des Amiga gehangen und eine Diskette formatiert:

logik01

In der Grafik hab ich leider die Signale WD (Write Data) und WE (Write Enable) verkehrt bezeichnet. Hier sieht man schön wie die Signale zusammenspielen. Mit einem kurzen Impuls auf /STEP wird zur nächsten Spur gesprungen. Quasi gleichzeitig wird die Seite der Floppy eingestellt auf der gearbeitet werden soll, das wird vom Ready Signal jeweils kurz quittiert. Nach einer gewissen Zeit wird dann wd (WE) auf low gezogen um einen schreibzugriff einzuleiten. Daraufhin wird eine Seite geschrieben we (WD), dann die Seite (SIDE) gewechselt und diese dann geschrieben. Später werden dann beide Seiten eingelesen und verglichen ob der Schreibzugriff fehlerfrei war.

Gut, das Schreiben ist mir erstmal egal, wichtig ist die Grundlagen wie MFM codierung und die Ansteuerung des Laufwerks zu programmieren.

 

Da die Informationen auf einer Floppy und anderen Magnetischen Medien durch eine änderung der Magnetisierungsrichtung gespeichert werden kann man da nicht einfach Nullen und Einsen raufschreiben. Der Floppy Controller würde irgendwann den Takt verlieren wenn zuviele Nullen oder Einsen hintereinander kommen. Deshalb wird die Information durch unterschiedliche Abstände zwischen der änderung der Magnetisierung gespeichert.logik02 Hier sieht man drei Unterschiedliche lange Abstände: 8 µs, 6 µs und 4 µs. Bei einer HD Floppy mit 1,440MB wären das 2,3,4 µs Abstände. Da der Amiga aber in der Regel nur DD Floppylaufwerke verbaut hatte interessiert mich nur DD Disketten zu lesen.