1541Emul:Lösung2

Aus
Wechseln zu: Navigation, Suche


Lösung mit SD2IEC und Atmega 1284

Wie beim ersten Lösungsansatz wird ein SD2IEC als Ausgangsbasis verwendet:

 * AVR Controller
 * IEC Interface
 * SD Karten Slot

Um die Lese- Schreibelektronik bzw. den Datenträger (Diskette) zu emulieren, benötigt man einen größeren Controller mit mehr RAM. Da bietet sich der Pin kompatible Atmega 1284 an.

Die Hardware besteht nun aus einem normalen SD2IEC bei dem der Atmega 644 durch einen Atmega 1284 ersetzt wird:


{{gallery>:1541emu:1541-emul.jpg?lightbox&direct&showtitle}}

Ablauf

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 2KB des internen RAM im 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 den Spurbuffer übertragen. Der Spurbuffer sind 8KB des internen RAM im Controller.

Die Ansteuerung der LED wird direkt auf eine der SD2IEC LED umgesetzt.

Der virtuelle CPU Befehl BVS löst eine Routine aus, die den Datenstrom von der Diskette emuliert. Je nach Timerwert und Floppy Situation (Modus) wird das V Flag gesetzt. Die IO Routine des VIA errechnet die Adresse des Byte im GCR Datenstrom aufgrund des Zeitpunkt (Timerwert) und liefert das Byte aus dem Spurbuffer. Die emulierte 6502 CPU bekommt diese Daten wie bei einer echten 1541 Hardware.


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.

Es gibt noch keine Tests, ob der Fake mit dem simulierten Datenstrom von der Diskette irgendwelche Auswirkungen auf die Kompatibilität hat. Es könnte sein, dass bestimmte Kopierschutz Mechanismen nicht laufen weil der Datenstrom nicht exakt synchron läuft. Die CPLD Lösung ist bestimmt besser und schöner, von der wirtschaftlichen Seite gesehen, ist diese Lösung aber wesentlich günstiger.


Offene Aufgaben

Eine taktgenaue Emulation würde vermutlich alle Kompatibilitätsprobleme lösen.