1541Emul:Lösung1
Inhaltsverzeichnis
Lösung mit SD2IEC + Xilinx CPLD
Ein SD2IEC als Ausgangsbasis bietet sich förmlich an:
- AVR Controller - IEC Interface - SD Karten Slot
Es fehlt nur noch etwas, das die Lese- Schreibelektronik bzw. den Datenträger (Diskette) emuliert. Es kommt ein zeitlich kontinuierlicher, sich stetig wiederholender Datenstrom von der Lese Elektronik. Diese Aufgabe ist gut geeignet für einen CPLD, an dem ein Speicher (SRAM) angeschlossen ist.
Die Hardware besteht nun aus einem normalen SD2IEC und einem CPLD mit 128KB RAM:
modifiziertes SD2IEC
Pollin CPLD Board
SD2IEC Teil
Der AVR Controller im SD2IEC emuliert die 6502 Umgebung der 1541 Floppy. Der Code dafür kommt großteils aus dem großartigen [Projekt]. Die SD Routinen kommen aus der **AVR MMC Lib**. Der Code für die Behandlung von D64 Images kommt aus dem [[1]].
Das DOS einer 1541 ist im Flash Speicher des Atmega gespeichert. Das Floppy RAM wird durch internen RAM des Controller emuliert. Zugriffe auf das VIA werden durch IO Routinen behandelt.
Die IO Routinen für IEC greifen direkt auf die IEC Hardware des SD2IEC zu.
Die Steuerung des Steppers wird von der IO Routine umgesetzt in eine virtuelle Spurnummer (track). Aufgrund der aktuellen Spur werden die entsprechenden Sektoren direkt von der SD gelesen (aus einem D64 Image) und in die CPLD Karte übertragen.
Die Ansteuerung der LED wird direkt auf eine der SD2IEC LED umgesetzt.
Die restlichen IO Leitungen werden zum CPLD geführt. Der sendet laufend die Daten aus der aktuellen (virtuellen)) Spur zum Controller. Die emulierte 6502 CPU bekommt diese Daten wie bei einer echten 1541 Hardware.
CPLD Hardware
Eine Diskette für eine 1541 Diskettenstation hat 35 Spuren. Jede Spur ist unterteilt in bis zu 21 Sektoren, das ist aber für uns irrelevant. Wir betrachten zunächst nur eine Spur einer Diskette. Jede Spur enthält bis zu 8 KB Daten. Es ist ein Kreis und daher werden die Daten in einer endlosen Folge gelesen …
Eine scheinbar endlos wiederholende Folge an Datenbytes. Perfekt für einen Ring Buffer, perfekt für unseren CPLD. Der CPLD liest das statische RAM und schiebt die Bytes sequentiell raus. Schon haben wir die Lese Elektronik einer 1541 emuliert.
Rein technisch ist es einfach ein Zähler, der bis zu einem bestimmten Wert (Länge der Spur in Bytes) zählt. Der Zählwert ist die Adresse in das RAM. Dazu gibt es einen weiteren Zähler für die Bitfolge (8 Bits - 0 bis 7). Das RAM wird gelesen in ein Schieberegister am Begin von Takt 0. Dann wird Bit für Bit aus dem Schieberegister raus geschoben.
Verwendet wurde das preisgünstige [[2]] der Firma Pollin (Xilinx 95144, 128x8 kB SRAM).
Die Logik im CPLD erfüllt folgende Aufgaben:
- Datenstrom lesen (Diskette --> 6502)
- Datenstrom schreiben (6502 --> Diskette)
- Datenstrom übertragen zwischen RAM und AVR Controller
Die Funktion Datenstrom lesen ist ein simpler Adresszähler, der mit einem bestimmten Takt inkrementiert wird. Die Adresse des Zähler liegt am Adressbus des RAM an. Das Byte aus der RAM Zelle wird in einem Register gebuffert. Der virtuelle 6502 kann das Byte aus dem register auslesen. Bei jedem Takt bekommt der virtuelle 6502 ein Signal, das sein V Bit setzt.
Das Schreiben funktioniert auf identische Art und Weise, nur dass der Takt vom AVR kommt.
Bei jedem Spurwechsel muss das RAM mit Daten von der SD Karte befüllt werden. Dazu wird der synchrone Takt abgeschaltet und durch einen Takt vom AVR Controller ersetzt. Der Controller kann so sehr rasch die Daten ins RAM der CPLD Karte schreiben.
Wenn die Spurdaten von der virtuellen 6502 CPU verändert wurden, dann muss vor dem Spurwechsel die aktuelle Spur aus dem RAM auf die SD Karte übertragen werden.
\\
- __Erklärung__:**
Eine Diskette ist in Spuren und Sektoren unterteilt. Der Schreib- Lesekopf der Floppy wird auf eine Spur positioniert, danach werden die Sektoren dieser Spur der Reihe nach gelesen. Dadurch ensteht ein stetiger Datenstrom im Lesemodus.
Eine Spur einer Diskette in einer 1541 hat zwischen 17 und 21 Sektoren. Jeder Sektor hat 256 Bytes. Jeder Sektor hat zudem einen Kopfteil, damit der Sektor gefunden werden kann. Zudem werden jeweils 8 Bit in 10 Bit kodiert (GCR Kodierung). Zwischen den Sektoren und zwischen Sektor und Kopfteil sind Sync Bytes. So kommt man zirka auf **8KB Daten pro Spur**.
Die Diskette rotiert mit 5 Umdrehungen pro Sekunde. Daher werden die maximal 8KB fünf mal pro Sekunde übertragen (40KB pro Sekunde). Der Takt des Adresszähler im CPLD ist so eingestellt, dass der Strom an GCR Daten von einer Diskette perfekt simuliert wird. Zudem erzeugt der CPLD das Sync Signal für den virtuellen 6502.
Das Sync Byte zwischen den Sektoren wird durch 255 simuliert. Wenn die RAM Zelle 255 enthält, dann erfolgt kein Sync Signal zur virtuellen 6502 CPU. Die Zahl 255 kommt in einem GCR Datenstrom nicht vor.
Fazit
Das Lesen funktioniert tadellos mit einem ROM aus einer 1541-II. Schreiben wurde bislang nicht implementiert, es sollte aber technisch kein Problem sein.
Da jedes GCR Bytemuster erlaubt ist und jede Kombination an Bytes im Kopfsatz, kann auch jeder Lesefehler exakt emuliert werden. Dadurch ist jeder Kopierschutz von der Hardware emulierbar. Allerdings unterstützt die D64 Image Datei keine defekten Sektoren, dazu müsste man auf ein anderes Image Datei Format ausweichen (G64, X64 ...).
Die Floppy Emulation läuft soweit tadellos. Das DOS meldet sich über den IEC Bus. Es können beliebige D64 Images gelesen werden. Auch alle speziellen Dinge wie Floppy Programme (morsecode, filereader, blockreader ...) laufen tadellos.
Leider ist die Kompatibilität nicht so gut wie erhofft. Wenn eigene Programme in die Floppy geladen werden, die ein spezielles IEC-Bus timing erfordern, dann hakt es an der zuwenig exakten Emulation der 6502. Es funktionieren nur Speeder, die ein ordentliches Bus Protokoll implementiert haben, wie zb. die OpenCBM Routinen. Wenn sich die Datenübertragung auf zeitlich exakte Protokolle stützt (zB. Jiffy), dann läuft es leider noch nicht sauber.
Offene Aufgaben
Eine taktgenaue Emulation würde vermutlich alle Kompatibilitätsprobleme lösen.
Das zweite Ziel wäre, das CPLD Board durch Software im Controller zu ersetzen. Anstatt des Atmega-644 Controller im SD2IEC müsste man natürlich einen Atmega-1284 zum Einsatz bringen. Mit dem 1284er wäre genug RAM vorhanden um die GCR Daten einer ganzen Spur zu cachen.
\\ Am schönsten wäre natürlich, wenn man eine vorhandene Hardware wie das **[[c64wiki>SD2IEC|SD2IEC]]** verwenden könnte. Der verwendete Atmega-644 hat aber leider zu wenig RAM. Wenn man jedoch ein **SD2IEC** mit DIL Sockel hat, dann kann man sehr einfach auf den pinkompatiblen **Atmega1284** mit 128KB Flash und 16KB RAM wechseln ...
