Posts by Retro

    In mir werden wieder Erinnerungen an meine ersten Entwicklungsschritte wach, an 1987, als ich damals mit dem Zeug begonnen habe. Mein allererster Gedanke war die GCR Dekodierung mittels Hardware umzusetzen. Ich habe ewig überlegt wie ich es machen könnte, irgendwo die GCR Bytes reinzuschreiben und dann die fertig dekodierten Bytes wieder ohne Aufwand irgendwo abzuholen.


    Später wurde mir dann klar, daß ich dadurch eigentlich keinen Vorteil gegenüber einer Softwarelösung erhalte, wenn ich dazu den 6502 während der schnellen LOAD Operation mit 2MHz takte. Und mit der GCR Dekodierung alleine ist der schnelle LOAD ja noch nicht vollendet, da fehlt dann noch ein bissal was.


    Der Ansatz mit dem CPLD führt im Endeffekt wie weit - max. bis zum Level eines Professional DOS. D.h. in einem Spezialmodus, wenn die Daten mit Sektor Interleave 1 gespeichert werden, und mit ausgeschaltenem Bildschirm kann ich lesen, dekodieren und übertragen.
    Im Normalmodus (ohne Sektor Interleave 1, Bildschirm an) gewinne ich genau nichts. Weil die gewonnene Zeit durch das Hardware De-/Coding nicht ausreicht um die Sektor Verkettung zu verwalten und eine Handshake Übertragung von aktuellen und aufgestauten Daten während des Lesens vom Schreib-/Lesekopf nebenbei laufen zu haben.
    D.h. um über das bereits von Professional DOS bekannte Limit hinauszukommen, wird man das Rad doch ein wenig anders definieren müssen.


    Auf 2MHz beim 6502 würde ich auch nicht mehr umsteigen, was damit zu tun hat, warum ich z.Bsp. auch die 512k RAM Variante anstelle der 2 x 128k RAM bevorzuge. Ich habe nämlich auch ein paar 1541 II rumstehen und hätte es gerne, wenn der Speeder auch dort reinpaßt, d.h. so wenig Bauteile wie möglich verwenden um die Platine so klein wie möglich zu bekommen. Deshalb nehme ich auch die 256k zuviel in Kauf (reine 256k Bausteine findet man ja keine mehr), und vielleicht würde sich damit auch wirklich was Vernünftiges machen lassen.


    Bez. jeder sollte so ein Teil selber zusammenbasteln können - ja klar, das ist eine Bedingung. Auch wenn ich einen HC08 im Einsatz hätte, das Teil muß ohne Spezialhardware "In System Programmable" sein. Sobald eine Art "Boot Loader" im Flash des HC08 etabliert ist, steht der Programmierung im eingebauten Zustand in der Floppy ohnehin nichts mehr im Wege.
    Ich möchte ihn dann zur Neuprogrammierung aber auch nicht mehr ausbauen müssen, sondern einfach eine Diskette mit einem Spezialprogrammerl rein und den Speeder updaten, sowohl den eingebauten HC08 als auch das Floppy ROM für den 6502.


    Wiesel
    Da Du an Deine Idee glaubst habe ich Dir den Gefallen gemacht und meine alten Sourcen ausgegraben - allerdings gibt's nur Screenshots aus dem Hypra ASS. Natürlich verwendet mein GCR Dekodierungsalgorithmus Codetabellen, eh klar.
    Der Lademechanismus verwendet die in den Screenshots gezeigte Funktion für das Lesen einer kompletten Spur (mit ... Makros dazwischen), wobei der Lesevorgang mit dem Sektor beginnt, der nach einer Kopfbewegung als erster beim Schreib-/Lesekopf vorbeikommt. Die GCR Bytes werden on the fly dekodiert und in einem 8k RAM ab $8000 abgelegt, wobei die Sektoren dann schon geordnet dort liegen, d.h. Sektor 0 bei $8000, Sektor 1 bei $8100. Auch die Checksummenberechnung wird schon on the fly ausgeführt und die Ergebnisse gespeichert - ausgewertet werden diese erst, wenn die Sektordaten auch wirklich an den C64 übertragen werden müssen, dann erst wird auch auf Lesefehler reagiert.
    Und zu beachten, der Code funktioniert nur, weil der 6502 bei der Ausführung mit 2MHz läuft, bei 1MHz rennt der nicht mehr.


    Wiesel
    Eine Frage habe ich an Dich - wie sehen Deine weiteren Umsetzungsideen aus, wenn Du die GCR Dekodierung durch einen CPLD gelöst hättest?

    Hmm, die Idee mit dem CPLD klingt recht abenteuerlich. Ich werde/würde mir das nicht antun.


    Warum:


    • Soweit ich die Idee verfolgt habe, ist der CPLD "nur" für die GCR Dekodierung (Codierung?) da.
    • Die Taktung des 6502 bleibt bei 1MHz = ok.
    • Ein RAM soll eingesetzt werden für die Zwischenspeicherung.
      8k ist wohl nicht mehr zeitgemäß für nur eine einzige Spur wärend des Lesens.
      128k = warum, damit kann man wieder keine komplette Diskettenseite cachen?
      512k sind bei einem Preis von 3 EUR zumutbar würde ich meinen - wie manch anderen gefällt mir die Idee des Cachens einer ganzen Diskettenseite (oder vielleicht zwei).
    • "Nebenbei" soll auch noch eine Übertragung der Daten an den C64 erfolgen?
      Bei eingeschaltenem Bildschirm - wird nicht laufen.
      Bei ausgeschaltenem Bildschirm - nur wenn die zu ladenden Daten zuvor schon speziell gespeichert wurden. Bei einer Standarddisk nicht möglich bzw. sinnvoll, da die Organisation rund herum mehr kosten wird als die direkte Übertragung bringt (woher weiß ich ob der gerade gelesene Sektor auch wirklich zu meinen Programmdaten gehört und welche vielleicht noch davor kommen?).
    • Hinzu kommt, wer übernimmt die Ansteuerung/Banking des großen RAMs? Der CPLD? Welcher Typ von CPLD soll dafür eingesetzt werden bzw. wie sieht's mit dem Preis dann von dem Ding aus?


    Meine Idee des HC08 ist anscheinend nicht ganz rübergekommen? Das Ding ist nicht nur für die Datenübertragung eingeplant. Das Ding ist natürlich für die GCR De-/Codierung vorgesehen und steuert als einziger das große 512k RAM an. Nebenbei übernimmt er natürlich beim Ladevorgang die Übertragung zum C64, sobald der nächste verkettete Sektor dekodiert vorliegt (bei eingeschaltenem Bildschirm).


    Der 6502 selber sieht kein 512k RAM und benötigt daher auch kein Bank Switching. Der schaufelt nur mehr dem HC08 Kommandos und GCR Daten beim Laden rein bzw. holt bereits fertig codierte GCR Bytes beim Speichern ab.


    Bez. Eleganz, na ja, jeder wie er mag, aber für mich gibt's da nicht viel Unterschied ob ich mit einem "größeren" CPLD das Rennen mache oder mit einem 3 EUR HC08 - für mich zählt am Ende auch der Speed der Floppy :D.

    Leistbar - das RAM hab' ich bei Reichelt um die 2 - 3 EUR gesehen, der Flash bei RS auch um 2 EUR, der HC08 um 2 - 3 EUR, das GAL auch bei 2 EUR - sollte sich ausgehen :D.


    Der HC08 kriegt die Taktung vom 6502 (der hat ein Phi Out wenn ich mich recht erinnere). Intern im HC08 wird per PLL der Takt bis auf 40 MHz hochgepushed. Wobei ich glaube die Taktsynchronisierung ist nicht unbedingt Pflicht, da man bestimmt per "einseitigem Handshake" die Daten zwischen 6502 und HC08 austauschen könnte.


    Den 6502 mit dem HC08 zu emulieren würde ich nicht versuchen, wäre mir zu aufwendig. Könnte sich zeitlich vielleicht sogar ausgehen, da der Befehlssatz ja ähnlich ist. Aber der 6502 soll mit dem HC08 über ein paar Ports kommunizieren, Kommandos und Daten rüberschaufeln bzw. abholen, wäre von meinem Gefühl her recht brauchbar.


    Quote


    x1541:
    Retro: der eine Prototyp ist hier noch bei mir. Wenn ich nun nur wüsste in welcher Floppy der steckt :rotwerd:

    Ich würd' sagen, schau' einfach, welche Floppy beim Laden als erste fertig ist, dort müßte er drinnen stecken :D


    1541U: Da muß ich wohl was nachschlagen, bin nicht mehr ganz am Laufenden.

    Wobei die GCR De-/Codierung schon im alten Speeder rein durch Software gelöst wurde. Die TTLs hatten nur Steuerlogik Aufgaben.


    Kurz ein paar Ideen, die ich zum neuen Speeder hatte:


    • Flash Speicher anstelle von Eproms, Updatemöglichkeit des Systems in eingebautem Zustand (Diskette mit neuem System in's Laufwerk schieben und ein Update Programm anwerfen)
    • 256k RAM für's Cachen einer ganzen Diskettenseite, bzw. aufgrund Verfügbarkeit und Preis eher 512k
    • Original 6502 Prozessor bleibt erhalten und wird weiterhin mit 1 MHz betrieben (wollte hier zuerst eine andere schnellere Variante einsetzen, aber aufgrund der Kompatibilität laß ich den lieber)
    • Und nun der Booster - eine HC08 Controller Variante als Coprozessor für die rechenintensiven Aufgaben (40MHz, 16k Flash um ca. 2 - 3 EUR). Nur dieser hat Zugriff auf das 512k RAM, ein paar Ports sollen als Interface zum 6502 herhalten, wie ich jedoch dessen Flash in eingebautem Zustand aktualisiere ist noch die Frage (der allererste Flashvorgang ist eine Herausforderung, möchte den HC08 nicht vor dem Einlöten programmieren müssen)
    • Der Datentransfer von Floppy zum Rechner wird ebenfalls über den HC08 erledigt (erfolgt während der 6502 die Spuren einliest, dadurch kontinuierlicher Einlesevorgang ohne Pausen für die Datenübertragung)
    • Da mich das Flachbandkabel stört (und die Fertigung desselben) - Ethernet Patchkabel als Datenleitungen, zur Übertragung wird die SPI/SCI Schnittstelle des HC08 genutzt (seriell 3 bzw. 2 Draht, dann reichen auch die 8 Leitungen des Ethernetkabels), das alte serielle Kabel bleibt natürlich vorhanden
    • Anschluß am C64 am Expansion Port mit eigener Platine, ist auch unbedingt notwendig durch die serielle Übertragung
    • Ein GAL als Steuerlogik für den alten Steuerbus der 1541

    So ein Zufall. Ich hab' tatsächlich vor einigen Wochen mal wieder hier hereingeschaut und auch heute wieder, dürfte damit vermutlich auf ca. 2 Besuche in den letzten 12 Monaten gekommen sein :roll:.


    Als ich hier einen Thread mit Eigenbau Speeder ganz vorne gereiht sah, dachte ich, "hey da probiert anscheinend noch jemand selber einen Speeder zu basteln". War dann erstaunt, daß es sich doch tatsächlich um meinen alten Beitrag handelt:@1@:.


    Zum Status - leider gibt es nicht wirklich einen. D.h. ich hatte und habe zwar ein paar Ideen und sie auch manchmal für ein paar Stunden verfolgt, aber wirklich entstanden ist daraus bisher noch nichts. Dem Speeder Fortschritt nicht gerade fördernd kommt noch hinzu, daß ich mich nebenbei auch noch mit einem anderen Projekt beschäftige, bei dem es allerdings nur um reines Codieren geht.


    Meine letzte Hardware Entwicklung ist nun auch schon wieder über 1 Jahr zurück, was die Lust nach dem Lötkolben zwar "anheizt", aber mehrere Projekte parallel zu machen ist eigentlich nicht so ganz in meinem Sinn.


    Die Absicht ist also nach wie vor vorhanden, nur wann sie in die Tat umgesetzt wird, kann ich noch nicht sagen.


    Manchmal geschieht es jedoch, daß ich eine zündende Idee bekomme und dann einfach von heut' auf morgen loslege :D.

    Ähem, vergiß mal was ich da unten geschrieben habe, denn ich habe Deinen Eintrag nur aus den ungelesenen heraus gesehen und geantwortet in der Überzeugung, Du suchst für den C64 eine solche Routine. Hab's erst später bemerkt, daß Du es für einen anderen Rechner suchst :rotwerd:


    Frage, kann ich eigentlich meinen eigenen Beitrag in der Zeit in der er editierbar ist auch wieder löschen ?


    ------------


    Habe mir mal aus meinen "alten Werken" einen Auszug für's Speichern geholt. In meinem Beispiel wird der Speicherbereich von $0801 - $1000 gespeichert, hoffe Du kannst was damit anfangen.



    Für's Laden gibt es die Funktion bei $ffd5, allerdings kannst Du dort nur die Startadresse beeinflussen (X=Low Start Address, Y=High Start Address), die Endadresse wird durch die Dateilänge bestimmt.


    Ciao, Bruno

    Na dann will ich mich mal versuchen ob ich die Funktionsweise der Handshake Signale noch hinbekomme ;)


    Zuerst mal ja, mit den 10 Leitungen des Parallelkabels ist ein relativ bequemer Handshake Betrieb möglich ohne daß der serielle Bus benötigt wird.


    Das Prinzip des Handshake Betriebs zwischen C64 und Floppy ist etwas trickreich.
    Auf beiden Seiten gibt es Ports, auf die 8 Bits gelesen oder geschrieben werden können (8 Leitungen). Eine weitere Leitung vom C64 zur Floppy (PC2 -> CB1) liefert dabei ein Signal, wenn am C64 Port ein Zugriff passiert. Umgekehrt gibt es von der Floppy eine Signalleitung zurück zum C64 (CA2 -> FLAG2) die anzeigt, wann auf den Floppy Port zugegriffen wird.


    D.h. am C64 wird über den FLAG2 Pin festgestellt, wann die Floppy eine Portaktivität durchgeführt hat, umgekehrt erkennt die Floppy über ihren CB1 Pin, wann der C64 auf seinen Port zugegriffen hat. Diese Statusregister sind am C64 über $dd0d (nicht $dc0d) und in der Floppy über $180d abrufbar.


    Eine Datenübertragung würde daher wie folgt aussehen:


    • Der C64 wartet durch Abfrage von FLAG2 ($dd0d) bis die Floppy ein Byte auf ihren Port schreibt
    • Die Floppy schreibt auf ihren Port auf $1801 (CA2 liefert dabei ein Handshake an FLAG2) und wartet, bis dieses Byte vom C64 abgeholt wird (durch Prüfen von CB1 in $180d)
    • Durch FLAG2 erkennt der C64 ein anliegendes Byte, eine Leseoperation auf $dd01 holt dieses Byte (und gibt dadurch über PC2 eine Rückmeldung an die Floppy an Pin CB1)
    • Aufgrund dieser Rückmeldung kann nun die Floppy mit dem nächsten Byte der Übertragung fortfahren


    Noch eine Ergänzung:
    Die Flags FLAG2 am C64 und CB1 in der Floppy werden automatisch zurückgesetzt, sobald ein Zugriff auf ihre Ports passiert.
    D.h. wartet der C64 in einer Schleife bis FLAG2 gesetzt wird, so wird dieses FLAG2 automatisch zurückgesetzt, sobald der C64 einen Zugriff auf $dd01 unternimmt (Lese- oder Schreiboperation).


    Eine Besonderheit gibt es allerdings auf der Floppy Seite:
    Zum parallelen Port A auf $1801 (im VIA 6522 wird $1800 als Port B und $1801 als Port A bezeichnet) gehören normalerweise die Handshake Leitungen CA1 und CA2. Da an CA1 aber auch die ATN IN Leitung des seriellen Busses angeschlossen wurde, wurde anstelle von CA1 die Handshake Statusleitung CB1 des Port B verwendet.
    D.h. wenn in der Floppy über die CB1 Leitung gewartet wird bis der C64 auf seinen Port zugegriffen hat, so muß für das Rücksetzen dieses Flags auch dummyhalber auf $1800 zugegriffen werden um dieses CB1 zurückzusetzen. Ein Lesen oder Schreiben auf $1801 alleine reicht nicht aus.


    Das war auch mit ein Grund, warum ich in meinem Speeder einen eigenen Portbaustein eingesetzt habe, weil es durch den kastrierten Handshake geringe Verzögerungen in der Übertragung gab - hab' dies allerdings auch erst vor kurzem wieder registriert ;)

    @Luigi
    Ich werde das Projekt neu anrollen lassen, d.h. die Hardware modernisieren. Die Bauteile von damals (EPROMS) werde ich wohl durch neue FlashROMs ersetzen und auch andere RAMs verwenden. Nach meiner jetzigen Vorstellung könnte ich auch den eigenen VIA weglassen und den SpeedDOS kompatiblen Port verwenden. Vielleicht gelingt es auch den Speeder zugleich kompatibel zur 1541-II zu bauen, damit man nicht nur auf die alte 1541-I beschränkt ist.


    Vom Speeder in der alten Form existieren drei Prototypen, wobei tischuer und x1541 schon Gelegenheit hatten, ihn zu testen. Laut Tim funktionieren auf dem Speeder mehr Programme als auf SpeedDOS, für meinen Geschmack damals war er auch ausreichend kompatibel ;).


    In dieser Variante werde ich ihn also nicht weitergeben, d.h. es wird bei den drei Prototypen bleiben. Wann die modernisierte Variante mal verfügbar sein wird kann ich leider nicht abschätzen, genauso wenig wie einen möglichen Preis.

    Der Speeder in der jetzigen Ausführung ist schon im Zeitraum von ca. 1988 bis 1991 entstanden, allerdings war er nur in Fädeltechnik vorhanden. Die Platine (wie in meinem Logo) gibt es erst seit wenigen Wochen.


    Eine Weiterentwicklung wäre natürlich sehr interessant, vor allem auch in Richtung zusätzlichem Speicher und noch einigen anderen Dingen.


    Zur Zeit versuche ich aber den Speeder noch verträglicher zu machen, und nach meiner jetzigen Erkenntnis dürfte der MMU Baustein sogar entfallen.

    Ein Bild sagt mehr als 1000 Worte, hier also der Ausschnitt meines MMU Bausteines vom Schaltplan.


    An A0-A11 des MMUs ist der obere Teil des Adreßbusses angeschlossen (A4-A15).
    An A12 hängt der Ein-/Ausschalter des Speeders (dadurch werden auch die zweiten 4k im Eprom verwendet hogoo).
    Die Datenleitungen D0-D4 bilden die neuen Adreßleitungen (A11-A15) und führen zurück in den Prozessorsockel der Floppy Platine.
    D5 ist der Selektor für 1/2 MHz.
    D6 und D7 führen in einen Multiplexer und wählen die drei Bausteine meiner Erweiterung aus (RAM, ROM, VIA oder keinen).


    Kommt etwas Licht in das Dunkel ;)?


    x1541
    Bin neugierig, welchen Eindruck ihr alle beim Usertreffen von dem Ding bekommt ;)

    Ein paar Details von dem Speeder kann ich ja bekannt geben ;)


    hoogo hat schon allgemein beschrieben, was es mit einem Bus etc. auf sich hat. Nun im Detail zu meinen Bauteilen:


    4 TTL ICs
    Die sind einerseits verantwortlich zur Erzeugung des Prozessortaktes (1 und 2 MHz, über FlipFlops) und zur Adreßdekodierung auf dem Speeder selber (RAM, ROM, 3. VIA).


    VIA 6522
    Der eigene Portbaustein zur Übertragung, und ja hoogo, eine Überlegung war, daß man so wenig wie möglich Arbeit beim Einbau des Speeders hat.


    8kB RAM 6264
    Der zusätzliche Speicher für das Cachen aller Sektoren einer kompletten Spur.
    Der Adreßbereich geht von $8000 - $9fff.


    16kB (EP)ROM 27128
    Hier befinden sich meine neuen Floppy Routinen und teilweise die Original Kernel ROMs. Teilweise wegen der Funktionsweise meines MMU Bausteins.
    Die neuen Funktionen stehen ab Speicheradresse $a000 zur Verfügung, auch Teile des Original Floppy ROMs von $c000 - $ffff werden hier überblendet.


    MMU 2764
    Der MMU Baustein übernimmt das Aktivieren (setzen von ChipSelect Leitungen) der einzelnen Bausteine auf meiner Erweiterungsplatine aufgrund der aktuellen Adresse. Außerdem gibt er auch Scheinadressen an die Original Floppy Platine weiter, nämlich immer genau dann, wenn ein Baustein auf meiner Erweiterung angesprochen werden soll (diese Scheinadresse aktiviert keinen Baustein auf der Original Floppy).
    Der Speicher wird in 16 Byte Blöcken reorganisiert, d.h. ich kann in 16 Byte Schritten bestimmen, welcher Baustein eingeblendet wird. Damit "strecke" ich den 16kB Inhalt meines 27128er Eproms auf einen Datenbreich von 24kB ($a000 - $ffff). D.h. großteils ist bei eingeschaltenem Speeder noch immer der Originalcode in den Original ROMs der Floppy aktiv, nur bei den modifizierten Routinen wird mein 27128 Eprom durch diese MMU eingeblendet (aus Kostengründen habe ich damals nur einen 16kB Eprom verwendet, der durch diesen MMU Trick einen Bereich größer 16kB abdeckt).
    Meinen >35 Spur Betrieb habe ich z.Bsp. mit dem Trick hinbekommen, daß ich 16 Bytes meines RAMs an der ROM Adresse einblende, an der die max. Spurnummer steht (somit brauche ich nur die max. Spurnummer an diese Stelle zu schreiben und kann die Funktionen zum Spurhandling dem Original Floppy Code überlassen ;)).
    Außerdem übernimmt der MMU auch noch die automatische Taktumschaltung, d.h. aufgrund der Programmadresse läuft der Prozessor mit 1 oder 2 MHz (die 2 MHz sind nur im Adreßbereich von $8000 - $bfff aktiv).
    Und auch die hardwaremäßige Deaktivierung des Speeders erfolgt über diese MMU.


    Zur Beschaltung, bis auf den MMU werden die Speicher standardmäßig zusammengeschalten.
    Am MMU sind die Adreßleitungen von A4 - A15, die Datenleitungen bilden teilweise die neuen Adreßleitungen, die zurück in den Prozessorsockel führen bzw. die CS und Taktumschalt Leitungen für die eigenen Bausteine.


    (Wenn dir das zuviel wird sag bescheid) ;)

    In der Floppy wird am Prozessor angesetzt, d.h. Prozessor raus, auf meine Speederplatine raufstecken und die Speederplatine in den Prozessorsockel reingeben. Den Ansatz haben meines Wissens nach alle größeren Hardware Speeder verwendet (Prof.DOS, Dolphin DOS, Prologic DOS).


    Der Prozessorsockel ist der beste Ansatzpunkt wenn man viel abändern will.

    Bei meinem C64 mußte ich damals den Kernel auslöten, dann kam ein Sockel rein mit einer Kernelumschaltplatine. In ein Eprom wurde dann der Original Kernel mit meinen Änderungen gebrannt. Beide Bausteine, also sowohl Original Kernel und Eprom kamen auf die Umschaltplatine, und ich konnte somit im C64 zwischen beiden um- und damit den Speeder abschalten ;).
    Für die Floppy habe ich einen extra Schalter vorgesehen mit dem man den Speeder hardwaremäßig deaktivieren kann (sieht man auch auf den Einbaufotos weiter oben).


    Die Kommunikation zwischen C64 und Floppy wird über das serielle Kabel initiiert, d.h. es gibt ein Protokoll für den seriellen Bus, dessen Beginn ich genau einhalte. Antwortet die Floppy nur über den seriellen Bus, bleibt die Kommunikation auf die serielle beschränkt, ansonsten wird auf die parallele ausgewichen - verständlich ist etwas anderes oder ;)?


    Es bedeutet einfach, auch wenn das parallele Kabel angesteckt ist, wird ein geringfügiger Teil der Kommunikation nach wie vor über die serielle Schnittstelle durchgeführt. Ist kein paralleles Kabel vorhanden, wird natürlich alles über die serielle Schnittstelle abgewickelt.

    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 ?

    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.

    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 ;).

    Nachdem es x1541 schon anklingen ließ, ich habe ein paar Muster von den WDC 65C02s und 65C22s bekommen.


    ad 65C22s:
    Ich habe mit den WDC 65C22s mal in einer 1541-I Floppy nacheinander die beiden originalen VIAs ersetzt, aber an keiner der beiden Positionen hat der WDC Typ funktioniert, d.h. die ganze Floppy lief nicht mehr.
    Auf meinem Speeder hingegen scheint der WDC Typ brauchbar zu sein, allerdings verwende ich den VIA nur als reinen Portbaustein.


    ad 65C02s:
    Auch der WDC 65C02s ist nicht so ohne weiteres einsetzbar. Das bloße Austauschen des bestehenden 6502 in der Floppy funktioniert nicht. Laut Datenblatt hat der WDC Typ den Pin 36, der in den alten MOS und Rockwell Varianten als "NC" geführt wurde, mit einem neuen Anschluß "BE" (Bus Enable) belegt. Dieser Pin muß auf High Potential gelegt werden, damit der WDC 65C02s seine Steuersignale (Adreß-/Datenbus, R/W) freischaltet.
    Allerdings habe ich noch nicht ausprobiert, ob mit BE=High der WDC Prozessor dann in der Floppy funktioniert.