Eigenbau Speeder

Ich habe euch ein paar Fotos von den notwendigen Schritten zum Einbau des Speeders in die Floppy zusammengestellt.
Für den C64 gibt's nur das EPROM, das ihr in einen geeigneten Adapter oder eine Umschaltplatine stecken müßt.

Floppy Einbau:
Bild 1.
Hier seht ihr alle Teile des Speeders, die Floppy Platine, das EPROM für den C64 und das parallele Verbindungskabel zwischen der Floppy und dem User Port des C64. An diesem Parallelkabel hängt auch der Schalter für das Ein-/Ausschalten des Beschleunigers in der Floppy.

Bild 2.
Ein Ausschnitt der Floppy Platine. Der rot eingekreiste IC ist der 6502 Prozessor. Dieser Prozessor war meines Wissens eigentlich in allen 1541-1 Modellen gesockelt. Mit einem Schraubenzieher muß dieser 6502 Prozessor aus dem Sockel gehebelt werden (vorsichtig, damit die Anschlußbeinchen sich nicht allzu sehr verbiegen).
Die blauen Kreise markieren Stellen, an denen sich möglicherweise recht große Plattenkondensatoren zur Entstörung der nebenliegenden ICs befinden. Auf meiner Floppy habe ich diese mit einem Seitenschneider herausgezwickt, um Platz für den Einbau des Speeders zu schaffen.

Bild 3.
Der leere Sockel mit der darunter sichtbaren Bezeichnung "IC1" dient zur Aufnahme des aus der Floppy herausgehebelten 6502 Prozessors.

Bild 4.
Hier wird der Prozessor aus der Floppy in die Speeder Platine eingesetzt.
Wichtig - die Kerbe des Prozessors zeigt in die gleiche Richtung wie sämtliche Kerben der anderen ICs auf dem Speeder auch !

Bild 5.
Der Floppy Beschleuniger besitzt an der Unterseite der Platine einen 40 pol. Stiftadapter. Damit wird die Beschleuniger Platine in die Floppy an der Stelle des ehemaligen 6502 Prozessors eingesetzt.
Das Parallelkabel kann an einem der beiden vorgesehen IC Sockel Positionen (auf der Platine als CON2 und CON3 gekennzeichnet) eingesteckt werden, welcher von beiden verwendet wird ist egal.

Bild 6.
Das Parallelkabel muß am C64 derart angeschlossen werden, daß das Kabel den Stecker auf der rechten Seite verläßt.
Außerdem sieht man hier auch nochmal den Schalter für das Ein-/Ausschalten des neuen ROMs in der Floppy 1541. In der "Aus" Stellung entspricht das Kernal ROM und die Hardware Umgebung in der Floppy zu 100% dem Original.

Die neuen Speeder ROMs im C64 und der Floppy 1541 sind nicht aufeinander angewiesen, d.h. ihr könnt entweder nur im C64, nur in der Floppy oder natürlich in beiden Geräten die Beschleuniger ROMs aktiviert haben um Programme zu laden/speichern etc.. Auch bei abgestecktem Parallelkabel kann ein normaler Floppybetrieb stattfinden (z.Bsp. notwendig wenn am Userport ein anderes Gerät angesteckt wird).
Die volle Geschwindigkeit gibt's natürlich nur bei aktivierten Beschleuniger ROMs in C64 und Floppy sowie angestecktem Parallelkabel.

WICHTIG
Schaltet beim An-/Abstecken des Userport Kabels C64 und Floppy lieber ab, mir sind bei eingeschaltenen Geräten in den letzten beiden Wochen zwei 6522 Portbausteine kaputtgegangen.

Und hier noch schnell nach Durchforstung meiner Sourcen eine Auflistung der hinzugekommenen Kommandos bzw. Funktionen:

Goodies:
* Schneller Reset am C64 mit Autostartunterdrückung etc.
* Floppy Kommandos per @ Befehl
* Funktionstastenbelegung
* Floppymotor läuft beim Einlegen einer Diskette an (Zentrierung)
* 35/40/41/42 Spur Betrieb
* Korrigiertes @: (Save + Replace) Kommando beim Speichern
* Directory laden und anzeigen ohne Programmverlust (Funktionstaste)
* Load direkt aus dem Directory
* "Old" Kommando zur Wiederherstellung von Basic Programmen nach einem Reset
* Anhalten des Bildschirmscrollings (natürlich nur im Textmodus) bei Auflistungen (LIST, Directory etc.)
* Ausgabe von Start- und Endadresse eines Programms bei LOAD

Funktionstastenbelegung:
F1 ... Directory laden und anzeigen ohne Programmverlust
F2 ... Schreibt "SYS 4096*" in die Console
F3 ... LIST
F4 ... OLD
F5 ... LOAD, entweder direkt aus dem Directory, oder ohne Filename das erste Programm auf Diskette
F6 ... SAVE
F7 ... RUN

Weitere C64 Funktionen:
<SHIFT> + <RUN STOP> ... Laden und starten des ersten Programms auf Diskette
RESET + <RUN STOP> ... Unterdrückung des Autostarts eines angeschlossenen Moduls oder Programmes
RESET + <C> ... Löscht den Speicher (z.Bsp. um lästige Autostart Programme loszuwerden)
RESET + <T> ... Verschiebt den Inhalt der Zeropage auf die Adresse $7000 und kann nach dem Reset begutachtet werden
Scrolling + <linke SHIFT/SHIFT LOCK> ... Anhalten eines LIST oder DIR, mit <rechter SHIFT> kann fortgesetzt werden

Floppykommandos:
@ ... Floppy Statusabfrage
@<command> ... Einfache Möglichkeit zum Senden von Floppy Kommandos (entspricht OPEN 1,8,15; PRINT#1 ...), z.Bsp. @I zum Initialisieren der Floppy
@FL:<filemask> ... "Lock" der in <filemask> angegeben Files
@FU:<filemask> ... "Unlock" der in <filemask> angegebene Files
@V- ... Abschalten des Verifies für Schreiboperationen (Speichern, Formatieren)
@V+ ... Einschalten von Verify für Schreiboperationen (standardmäßig an)
@VF ... Abfragen der Verify Einstellung
@D+ ... Aktivierung des 40 Spur Betriebs (bei anschließendem Formatieren einer Diskette wird diese auf 40 Spuren formatiert)
@D++ ... Wie "D+" nur mit 41 Spuren
@D+++ ... Wie "D+" nur mit 42 Spuren
@D- ... Wiederherstellung des 35 Spurbetriebs
@DF ... Aktuellen Spurbetrieb abfragen

Danke für Deine Antwort Tim.

Du hast eigentlich eh schon alles gesagt, kennst ihn ja inzwischen auch schon ein wenig ;).

Danke für Deine Stellungnahmen x1541, hab' erst jetzt wieder einen Blick hier herein 'riskiert' ;).

@Hardware Kompatibilität
Als ich den Speeder Ende der 80er Jahre entwickelt habe, war ich nur in Besitz einer einzigen 1541-I Floppy und wurde nur darauf getestet (konnte mir auch nicht mehr leisten). Wie x1541 auch erwähnt hat, aufgrund des mangelnden Interesses von Firmen zu dieser Zeit das Teil noch zu vermarkten, ist der Speeder nun sehr lange Zeit auf Eis gelegen, bis ich vor wenigen Monaten meinen C64 wieder mal aktiviert und dieses Forum gefunden habe.

Wie sich nun durch Tests von Tim und x1541 gezeigt hat, gibt es leider mit den etwas älteren 1541-I Modellen noch Probleme, an denen ich gerade (wenn's die Zeit erlaubt) dran bin. x1541 war so nett und hat mir eine der Problem Platinen zu Testzwecken zukommen lassen, allerdings bin ich nach meinen bisherigen Versuchen noch am Grübeln, wie ich dem Problem auf die Schliche komme, das sich durch sporadische Schreib-/Lesefehler äußert.
Danke auch für das Lob in Deinem Absatz x1541 :).

@Parallelkabel / Port
Obwohl ich heute selber ein wenig an meiner Erinnerung zweifle, glaube ich, daß durch meinen eigenen IO Baustein, den ich mit 2 MHz während des Ladevorganges betreibe, ein klein wenig schneller wurde (ich schätze den Vorteil heute aber vielleicht auf 0.1 Sekunden ein, ich weiß es eben leider nicht mehr genau, aber ich wollte damals einfach unbedingt den schnellsten Direktlade Speeder bauen, den man bekommen kann).
Vielleicht wäre eine kleine Designänderung hin zum SpeedDOS kompatiblen Port gar kein Nachteil, denn die 6522 sind etwas Mangelware bzw. die verfügbaren Modelle von WDC nur in großen Stückzahlen lieferbar.

Ich halte euch aber am Laufenden was diese Fragen betrifft bzw. werdet ihr hier sicher einen Freudenschrei "lesen", wenn ich das Problem auf der ganz alten 1541-I gefunden habe ;).

Diagramme ? - Nein, sowas habe ich nicht mehr bzw. glaube ich nicht, daß ich irgendwelche hatte. Nachdem es damals einige Floppy Speeder gab und deren Funktionsweise ähnlich war, war wohl eher die Meßzeit ausschlaggebend. 1990 bzw. 1991 hätte mir aber sicher auch kein Diagramm mehr geholfen, den Speeder einer Firma anzupreisen - ich glaube 1992 kaufte ich mir dann meinen ersten PC ;(.

Du möchtest wissen wie mein Speeder funktioniert ? Zuerst mal muß man wissen, warum die 1541 Floppy im Original Modus so langsam ist. Folgende Punkte fallen mir dazu ein:

• Der serielle Bus (die Datenbits werden einzeln hintereinander ohne richtiges Handshake übertragen, d.h. die Floppy wartet nach jedem Bit bis der C64 es ganz sicher übernommen hat)
• Die GCR Codierung (die Floppy speichert die Datenbytes nicht 1:1 sondern wandelt 4 Datenbytes in 5 GCR Bytes um)
• Der geringe Speicher der Floppy sodaß die Sektoren einzeln gelesen, dekodiert und übertragen werden müssen
• Das ständige Warten auf den folgenden Sektor
• Die langsame Kopfbewegung und die daraus resultierende Zugriffszeit

Und genau an diesen Punkten setzen eigentlich alle Speeder an, die auch mit etwas mehr Hardware geliefert werden, so auch meiner.

Parallele Datenübertragung
Das war so ziemlich mein erster Punkt, den ich bei meiner Entwicklung einsetzte. Alleine durch den Einsatz eines parallelen Kabels mit richtiger Handshake Übertragung brachte ich die Ladezeit von 202 Blöcken schon auf ca. 20 Sekunden.

RAM
Um das ständige Warten auf den nächsten einzulesenden Sektor einer Spur zu vermeiden, setzte ich ein 8 kB RAM ein. Dadurch kann ich sämtliche Sektoren einer Spur in einer Umdrehung einlesen und die benötigten Sektoren bei Bedarf daraus abrufen.

2MHz + GCR Dekodierung
Der Prozessor arbeitet mit variabler Taktfrequenz 1 MHz / 2 MHz. Die 2 MHz benötige ich, um während des Einlesens der Sektoren einer Spur diese auch gleichzeitig von der GCR Codierung zu 'befreien'. Der Mechanismus arbeitet mit Codetabellen, d.h. ich muß mir während des Einlesens immer 5 bit so zurecht legen, damit mir diese als Index auf ein 4 bit Nibble dienen können.
Durch das Dekodieren während des Einlesens habe ich am Ende einer gelesenen Spur die Sektoren auch gleich alle dekodiert im Speicher und muß nicht einen extra Schleifendurchlauf dafür machen.
Zusätzlich kann ich durch die 2 MHz auch noch die Checksummen Berechnung während des Einlesens durchführen (alle Datenbytes eines Sektors werden untereinander EOR verknüpft und dieser Wert in einem Checksummenbyte abgelegt, welches auch auf der Diskette gespeichert wird - zur Erkennung von Lesefehlern).

Lesen der Sektoren on the fly
Bsp., zeigt die Sektorverkettung beim Laden eines Programmes auf Spur 1 Sektor 0, so bewege ich den Schreib-/Lesekopf auf Spur 1, warte aber mit dem Lesen der Spur nicht bis Sektor 0 vorbeikommt, sondern beginne mit dem Einlesen der Sektoren sogleich mit dem ersten, der am Schreib-/Lesekopf ansteht. Am Ende des Einlesens einer Spur sind aber alle Sektoren geordnet abgelegt, d.h. ab $8000 findet sich Sektor 0, ab $8100 Sektor 1 usw. (mein RAM blende ich bei Speicherstelle $8000 - 9fff ein).

Diese paar Punkte machen bei meinem Speeder eigentlich schon die ganze Geschwindigkeit beim Laden eines Programmes aus ;).

Explizit beschleunigt habe ich nur das Laden- und Speichern von PRG Dateien, die Beschleunigung bei SEQ, USR und REL Dateien resultiert aus verbesserten Block Lesen/Schreiben Routinen. D.h. diese Routinen verwenden auch das Prinzip des Lesens/Schreibens einer ganzen Spur und das Cachen von einzelnen Sektoren im RAM.

Extra beschleunigt habe ich dann noch die Formatier, Scratch und Validate Routinen, wobei mir im speziellen die Validate sehr gut gelungen sein dürfte ;).

Na ja, soweit mal das Wichtigste.

Ein paar Hardware Spielereien habe ich auch noch eingebaut, wobei ich aber hoffe, daß mir die nicht das Problem auf den älteren Floppies erzeugen.

Worf
Im C64 habe ich natürlich auch die ganzen Kernel Routinen modifiziert, damit die mit dem parallelen Kabel arbeiten können. Aus Kompatibilitätsgründen sind die seriellen Routinen nach wie vor vorhanden, und werden auch genutzt. Denn es ist durchaus denkbar, daß zwei Floppies am C64 hängen, wobei sich aber nur in einer ein Speeder befindet, d.h. die andere muß nach wie vor über den seriellen Bus bedient werden.
Dem zusätzlichen Code sind aber die Kassettenroutinen im C64 zum Opfer gefallen, denn irgendwo mußte ich die zusätzlichen Funktionen unterbringen.

Hoogo
Die GCR Kodierung ist nicht nur zum Ausgleich von Schwankungen in der Mechanik vorhanden. Die Drehzahlen zweier Floppies sind niemals so ident, daß eine Diskette von der einen aufgezeichnet auf der anderen ohne Schwierigkeiten lesbar wäre, gäbe es diese Synchronisierungsbits durch die GCR Kodierung nicht.

Wirklich, es gab auch Speeder oder Ladesysteme, die die GCR Dekodierung am C64 durchgeführt haben ? Hmm, aber zumindest die ersten Bytes eines Sektors müssen in der Floppy dekodiert werden, damit der Folgesektor erkannt wird. Die Checksummen Berechnung erfolgt eigentlich auch mit den dekodierten Daten, wurde dann auf die Erkennung von Lesefehlern verzichtet ?