Hello, Guest the thread was called25k times and contains 162 replays

last post from ACDC at the

Eigenbau Speeder

  • Warum wird nicht ein SD2IEC so modifiziert das es anstatt IEC Bus eben GRC Daten für die Floppyelektronik liefert? Man hätte damit 100% Kompatibilität, die Displaysache würde sich durchsetzen und die Schlabberscheiben endgültig aussterben.

  • Warum wird nicht ein SD2IEC so modifiziert das es anstatt IEC Bus eben GRC Daten für die Floppyelektronik liefert? Man hätte damit 100% Kompatibilität, die Displaysache würde sich durchsetzen und die Schlabberscheiben endgültig aussterben.


    Ich will ja nicht nur daherlabern,aber gerade letzteres, so hoffe ich persönlich, wird hoffentlich nicht so schnell passieren. Die neuen Medien in allen Ehren,aber ne 5,25" Disk ist mir doch lieber.

  • Warum wird nicht ein SD2IEC so modifiziert das es anstatt IEC Bus eben GRC Daten für die Floppyelektronik liefert?


    Weil das nicht mit einer kleinen Modifikation gemacht ist sondern ein komplett anderes Projekt wäre? Von technischen Problemen wie zB dem nicht für einen kompletten Track ausreichenden Speicher ganz zu schweigen.


    Wenn du unbedingt sowas bauen willst nimm ein HxC oder einen ähnlichen Floppyemulator als Ausgangsbasis, die sind näher am Problem dran als sd2iec.

  • Hmm.. also wenn schon Gewaltansatz, dann aber bitte auch parallel, also mit SpeedDos/Dolphin-kompatiblem Kabel. Das nutzt die CB1/CA2 Leitungen, kann also hardware-handshaking und muß somit den Bildschirm nicht abschalten. Wenn man die Hardware so auslegt, dass sie 8K Ram da ablegt, wo Dolphin sie auch erwartet, könnte man sich nen multi-Speeder bauen, also ne Floppy mit Kernal-Umschaltung: Speeddos, Dolphin-Dos und eben unser neues Ding. Damit dürfte in Sachen Kompatibilität zu existierender Software so ziemlich alles abgedeckt sein. Wenn man schonmal dabei ist, findet man sicher auch Platz für ein Jiffy-Kernal.


    Um dann die Geschwindigkeit von Dolphin zu toppen, würde ich noch eine GCR-Dekodierhilfe in den CPLD setzen, also etwas, was die ekelige bit-Shifterei vereinfacht.


    Könnte außerdem noch jemand was zu meiner masked-write-Idee sagen?


    Jens

  • Hmm.. also wenn schon Gewaltansatz, dann aber bitte auch parallel,

    Nein, nein, kein Parallelkabel :)
    Ich möchte doch nur einen schnellen seriellen Speeder, der mit wenig Umbauarbeiten/Zusatzhardware installierbar ist.







    Und ein Pony.

  • Könnte außerdem noch jemand was zu meiner masked-write-Idee sagen?


    Jens



    Was erwartest Du? Meine Beiträge werden oft auch nicht beachtet ;)


    Ich finds doch recht genial, nur hatte ich irgendwie den Eindruck das Bytes zusammensetzen übernimmt sowieso der CPLD.


    aber trotzdem, so ganz klar ist es mir noch nicht. Wie verhindere ich, dass die anderen 4bit auch geschrieben werden? Ein 8Bit SRAM schreibt ja auf jeden Fall ein ganzes Byte, egal wieviel gültige Bits anliegen?

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

  • Dieses masked write schön und gut, aber vielleicht geht es noch besser?



    Ich bin eine totale Elektronik Niete und mit CPLD habe ich erst etwas rein geschnuppert. Aber meine Hoffnung würde eher in folgende Richtung gehen:



    GCR Dekoder CPLD powered:


    + CPU schreibt 5 Bytes und liest 4 Bytes


    write(8), write(16), read(6), write(14), read(4), write(12), read(2), write(10), read(0)


    In Klammern steht die Anzahl Bits die der CPLD buffern muss.





    GCR Enkoder CPLD powered:


    + CPU schreibt 4 Bytes und liest 5 Bytes


    write(10), read(2), write(12), read(4), write(14), read(6), write(16), read(8), read(0)


    In Klammern steht die Anzahl Bits die der CPLD buffern muss.

  • aber trotzdem, so ganz klar ist es mir noch nicht. Wie verhindere ich, dass die anderen 4bit auch geschrieben werden? Ein 8Bit SRAM schreibt ja auf jeden Fall ein ganzes Byte, egal wieviel gültige Bits anliegen?


    Die Schaltung verhindert es nicht wirklich, sondern macht zwei Zugriffe: Zuerst einen Read aus dem Ram, da werden vier Bits im CPLD gespeichert, dann erst den write, den die CPU gerade angefangen hat. Das alles kann man machen, während die CPU glaubt, dass nur ein einziger Zugriff stattfindet, weil dieser CPU-Zugriff so langsam ist. Speicher lesen dauert keine 100ns, aber der phi2=1 Zugriff dauert 500ns.


    Die acht Datenbits des Ram dürfen natürlich dann nicht direkt am Datenbus hängen, sondern werden komplett durch den CPLD geschleift.


    Jens

  • Dieses masked write schön und gut, aber vielleicht geht es noch besser?


    Ist ne Idee, ja, aber dafür müsstest Du, wie Du schon selbst geschrieben hast, bis zu 16 Bits im CPLD zwischenspeichern. Da Ihr ja so viel Speicher haben wollt, werden die Makrozellen wahrscheinlich schnell knapp. Ich versuch's lieber auf die "elegante" Methode, also in Nibbles, denn die kleine Nibble-Tabelle bekomme ich vielleicht sogar in dem CPLD selbst unter.


    Vielleicht gelingt ja anstelle eines "masked write" ein "translated, shifted write" auf das Ram? Etwa so:


    1.
    Byte von VIA holen, CPLD lauscht mit und speichert 8 Bits (ein einziger LDA)


    2.
    Byte in spezielle Ram-Spiegelung schreiben, die gleichzeitig übersetzt. Hier würde das Ram-Byte gelesen, vier Bits verändert mit den Daten, die aus den 5 bereits nutzbaren GCR-Bits bekannt sind und im Speicher abgelegt (einzelner STA). Der CPLD zählt intern mit, wo er gerade ist, am Ende dieses Zyklus wird der Status des Übersetzers um 1 erhöht.


    3.
    Byte von VIA holen, CPLD lauscht wieder mit und hat jetzt insgesamt 11 Bits im Speicher


    4.
    Byte in die Decoded-write-Spiegelung schreiben - das wird ein bischen enger, denn die 11 Bits im CPLD-Speicher ergeben ein ganzes Byte. Das ganze Byte muss aber auf zwei Bytes im Speicher aufgeteilt werden, das wären insgesamt vier Zugriffe - was aber zeitlich auch kein Thema ist, denn wir haben 500ns. Der CPLD liest also das Byte von eben, modifiziert das andere Nibble, schreibt's zurück. Dann liest er das folgende Byte, modifiziert das erste Nibble und schreibt den Wert zurück. Jetzt wird wieder der Status des Übersetzers um 1 erhöht, außerdem liegt nur noch 1 Bit im Zwischenspeicher des CPLD.


    5.
    Byte von VIA holen, CPLD lauscht wieder mit und hat jetzt insgesamt 9 Bits im Speicher


    6.
    Byte in die decoded-write-Spiegelung schreiben - das ist ähnlich Schritt 2, denn es wird nur ein Nibble verändert - also lesen-modifizieren-schreiben, während die CPU nur einen STA macht. Und wieder wird der Status des Übersetzers erhöht, jetzt liegen noch 4 Bits im Zwischenspeicher des CPLD


    7.
    Byte von VIA holen, CPLD lauscht wieder mit und hat jetzt insgesamt 12 Bits im Speicher


    8.
    Byte in die decoded-write-Spiegelung schreiben - jetzt wird's ganz leicht, denn im CPLD-Speicher liegt ein ganzes Byte, das an eine feste Stelle im Ram kommt, ohne dass irgendwas in Sachen read/modify/write gebastelt werden muss. Am Ende dieses STA sind noch 2 Bits im CPLD-Zwischenspeicher


    9.
    Byte von VIA holen, CPLD lauscht wieder mit und hat jetzt insgesamt 10 Bits im Speicher


    10.
    Ähnlich Schritt 8, denn es ist wieder ein ganzes Byte entstanden.


    Wenn man sich die state machine dafür aufschreibt, wird wahrscheinlich die eine oder andere Aktion wieder in die Software rücken, so könnte man der state machine bzw. dem Decoder/shifter noch zusätzliche Informationen zuschieben, indem man die VIA an Spiegelung A, B oder C ausliest. Beim Lauschen auf den Datenleitungen lauscht der CPLD auch an den nicht auskodierten Adressleitungen mit und legt die 8 Bits dementsprechend in den internen Bits ab.


    Ähnlich natürlich für's encoden, da hätte ich noch eine ganz abgefahrene Idee, die man nur in NMOS-Schaltungen einsetzen kann. Das würde darauf basieren, dass man in NMOS eine digitale 1 immer zu einer 0 machen kann, ohne dass dabei ein schädlicher Strom fließt. Wenn man der VIA also die Daten fürs Schieberegister zuschiebt, schreibt man mit der CPU immer ein $ff, aber der Hardware-Decoder kippt die notwendigen Bits auf 0, die er in vorherigen Schritten zwischengespeichert hat. Auf die Weise hätten wir eine Menge Schieberei und load/store-Overhead gespart. Das Encoden eines GCR-Byte wäre reduziert auf zwei Reads im autodecode/encode-Bereich und einen $ff-write auf die VIA.


    Jens

  • Das klingt ein bisschen wie die Methode die das Prof-DOS einsetzt, nur dass im Prof-DOS auch noch Tabellen verwendet werden (etwas weniger Intelligenz in der Elektronik, etwas mehr im 6502).


    Wobei ich das Verfahren beim Prof-DOS ehrlich gesagt nciht ganz checke, obwohl es WoMo eh so schön auseinander geklaubt hat.

  • 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.

  • 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.

    Irgendwie läuft das alles doch darauf hinaus, dass man eine Speichererweiterung mit direkter Anbindung an den Schreib-/Lesekopf der Floppy baut. Dann würde ich die Speichererweiterung auch wirklich an den Expansionsport des C64 anschließen und nicht in die Floppy packen; dann kann z.B. auch DMA benutzt werden. Trotzdem wäre das wohl relativ einfach zu bauen (da wenig Kabelei).


    Die anderen Varianten (Zwischenspeichern nur eines Tracks in RAM etc.) klingen nach netter Fingerübung, aber bringen's doch vermutlich von der Geschwindigkeit her nicht - schon ein reiner Softwarespeeder liest einen Track in zwei Umdrehungen ein, also kommt man trackbasiert nicht auf mehr als etwa die doppelte Geschwindigkeit (also rund 40fach).


    Letztendlich bleibt auch die Frage, was der Vorteil gegenüber z.B. einem sd2iec sein soll? Das schafft ähnliche Geschwindigkeiten und ist ähnlich kompatibel ;) .


    Wenn sowas gehen würde wie "CPLD liest vom Schreib-/Lesekopf und schreibt direkt dekodiert auf die Serielle" (inkl. Übertragung eines Tracks in einer Umdrehung) wäre nett (da einfach zu bauen, wenig Kabelei, braucht kein RAM, und immerhin doppelt so schnell wie die besten Softwarespeeder). Dafür ist die C64-Seite der Seriellen dann aber soweit ich mich erinnere doch zu langsam.

  • Wenn sowas gehen würde wie "CPLD liest vom Schreib-/Lesekopf und schreibt direkt dekodiert auf die Serielle" (inkl. Übertragung eines Tracks in einer Umdrehung) wäre nett (da einfach zu bauen, wenig Kabelei, braucht kein RAM, und immerhin doppelt so schnell wie die besten Softwarespeeder). Dafür ist die C64-Seite der Seriellen dann aber soweit ich mich erinnere doch zu langsam.


    Wenn es "nur" um Speed geht dann gibt es zig Lösungen die nix kosten und funktionabel sind .



    Es geht in erster Linie um 99,99% Kompatibilität!


    Deshalb brauch ich die 6502, die alten DOS Roms an der richtigen Stelle im Adressraum, deshalb brauch ich auch den mistigen IEC Bus.



    Der beste Speeder ist ein Emu (per Hardware: 1541u, oder Software: Open1541). Wenn es was anderes sein soll dann gibt es nur die klassischen Möglichkeiten:

    • Optionale schnelle GCR Kodierung/Dekodierung
    • Beschleunigte Übertragung zum C64 (parallel Kabel, serielle Turboroutinen, Burst)
    • Cachen mit zusätzlichen RAM



    Insofern liegen Wiesel und auch Retro super im Rennen mit ihren Lösungen, wenn man es richtig in die bestehende 1541 integriert. Wichtig ist, dass trotz aller Zusätze auch noch alles so funktioniert wie vorher (langsam).

  • Bei Kompatibilität wirds interessant. Hier reicht es mitnichten aus, dass die originale Hardware weiterhin vorhanden ist, oder die originalen ROMs (möglichst) unverändert bleiben. Sobald eine schnelle Übertragung stattfindet, kann dies die Kompatibilität mit vorhandener Software gefährden.


    Retro hat hier mit seinem Sunrise gezeigt, dass er das sehr gut im Griff hat und weit vorne dabei ist. Speeddos war hier deutlich schlechter, und bei Dolphindos und Prologic DOS konnte man zwar mehr Software zum laufen bekommen, aber war dafür bei jedem Titel am Experimentieren mit den Ladeoptionen. Die dann natürlich den Speed reduziert haben. So gesehen war das Sunrise schon ziemlich optimal was das Verhältnis Speed zu Kompatibilität angeht.

    Zuletzt repariert:
    21.2. Logitech M570 Microschalter ausgetauscht - geplante Obsoleszenz durch Billigtaster?
    19.11. Toshiba 3,5" Floppy defekter Elko durch Kerko getauscht auf Motorplatine
    27.11. 1541B Dauerlauf, Elko im Resetschaltkreis defekt, nicht der 7406 wie zuerst verdächtigt!

  • Retro hat hier mit seinem Sunrise gezeigt, dass er das sehr gut im Griff hat und weit vorne dabei ist.


    Dann lass' uns doch genau da ansetzen, denn alles Andere gehört in die Abteilung "das Rad neu erfinden".


    Retro, kannst Du mal die innere Ladeschleife posten, die das GCR-Decoding macht? Wenn ich den Assemblercode vor Augen habe, fällt mir vielleicht noch was Einfacheres ein, um die Speed auch auf einem 1MHz-Prozessor zu schaffen (eben mit ein bischen Hardwareunterstützung).


    Ich bevorzuge weiter einen CPLD, weil wir damit etwas bauen können, was die Leute zuhause nachbauen können. Außerdem erschaffen wir damit gleich etwas, was in Form einer Hardware-Beschreibungssprache vorliegt, also wird es für Besitzer von 1541u und Chameleon nutzbar, und das ganz ohne Lötkolben. Merke: Neue Plattform schaffen ist Kacke, lieber vorhandene Dinge nutzen, so dass möglichst viel existierende Software (auch andere Speeder-Roms!) laufen.


    Auch gegen die 512K wehre ich mich noch, denn 256K sollten ausreichen. Es gibt am Markt haufenweise 128K S-Rams, die für ein paar Groschen daherkommen. Halber Speicher, drittel Kosten, mehr Eleganz - Einwände? Für das Banking in 6K-Schritten habe ich auch schon eine Idee, die nur sechs Makrozellen (intern, ohne Pins) und sechs Pins am CPLD "kostet" (insgesamt 12 Makrozellen). Dennoch würde ich einen 8K-Bereich zum Einblenden des Speichers benutzen, denn dann kann man noch Dolphin nutzen. Bei Änderung des Banking-Registers bleiben 2K des 8K-Bereiches "ungebankt", können also als "common"-Bereich genutzt werden (good-sector-map, vielleicht auch ne schnelle Verkettungs-Map?).


    Beim CPLD würde ich mal die Kostengrenze bei 2,- EUR ziehen. Dafür bekommt man bei Altera 64 Makrozellen, bei Xilinx wären es sogar 72 Makrozellen. Für den einfacheren Nachbau würde ich natürlich die ISP-Varianten benutzen, damit die Lötkolbenschwinger unter Euch kein extra-Equipment kaufen müssen, sondern einfach mit dem Parallelport des PC den Code in den CPLD übertragen können.


    Jetzt warte ich aber erstmal auf die innere Ladeschleife von Sunrise, damit mir (hoffentlich) eine vernünftige Hardware-Optimierung dafür einfällt.


    Jens