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

last post from ACDC at the

Eigenbau Speeder

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

    Inwiefern wäre denn die von mir skizzierte Lösung inkompatibel? Der Speeder wäre eine Art Chameleon (kam das mit RAM-Erweiterung?) mit wenigen Pins Anschlüssen an die Floppy, um direkt Daten vom Schreib-/Lesekopf ins RAM zu holen. Die Software dazu ist z.B. eine Kernal-Erweiterung (evtl. könnte man das dann sogar per Traps umsetzen, sodass der eigentliche Kernal überhaupt nicht geändert werden muss). Die Programme, die nicht über die Kernalroutinen gehen oder an seltsamen Stellen dort einspringen, benutzen ganz normal IEC weiter - da kann man eh' nichts beschleunigen, ohne eine spezielle Anpassung des Speeders zu machen.

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


    DMA? Speichererweiterung an den Expansionsport des C64?


    Wenn im C64 irgendeine fremde Software läuft, wie soll die mit der hardware klar kommen??! Der C64 soll möglichst nicht mit bekommen dass was 'anderst' ist! Natürlich muss man die Routinen für IEC-In und IEC-Out ändern um schneller zu sein.



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


    Dein Software Speeder liest vielleicht dann in zwei Umdrehungen ein, wenn er sich weder um GCR noch um Sektor Reihenfolge kümmern muss.



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


    Ein SD2IEC ist nicht kompatibel. Es emuliert keinen 6502 und hat keinen 6502 drauf.



    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.


    Du willst immer die Intelligenz aus der Floppy raus ziehen, das ist nicht der 'Commodore way of life' und bringt zwangsweise Inkompatibilität.

  • Posting 121 nicht gelesen?


    Doch, deshalb habe ich ja geantwortet auf "die von mir skizzierte Lösung".



    RAM am Expansionport, - Man müsste das ganze DOS im C64 nachimplementieren!


    Mal ganz abgesehen vom abartigen Aufwand dieser Operation, wie bitte willst du das kompatibel kriegen???! Es geht nicht nur darum Daten so schnell wie möglich von 1541 zum C64 zu bekommen. Man muss auch ALLE anderen Dinge kompatibel halten, inklusive M-E Kommandos.

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

  • Man müsste das ganze DOS im C64 nachimplementieren!

    Naja, nachimplementieren muss man da nichts, man kann einfach das DOS der 1541 portieren, ist ja zufälligerweise der gleiche Prozessor :) . Das Steckmodul kann das alles recht gut vor dem normalen C64 verbergen; die 1541U macht das ja auch so.

    wie bitte willst du das kompatibel kriegen???! Es geht nicht nur darum Daten so schnell wie möglich von 1541 zum C64 zu bekommen. Man muss auch ALLE anderen Dinge kompatibel halten, inklusive M-E Kommandos.

    Das ist ja nur eine Frage einer guten Erkennung des richtigen Abschaltzeitpunkts. M-W und M-E sind sicherlich schonmal gute Kandidaten zum Abschalten des Speeders, da ja offensichtlich ein eigener Speeder gestartet oder anderes esoterisches Zeugs gemacht wird.


    Aber ich höre mal auf, den Thread hier zu hijacken :) .

  • Das Steckmodul kann das alles recht gut vor dem normalen C64 verbergen; die 1541U macht das ja auch so.


    Die 1541U lässt ein unverändertes 1541-Rom auf einer komplett nachgebildeten 1541-Hardware laufen. Oder meinst du den Teil der direkte SD-Zugriffe erlaubt? Der ist den Sourcen nach reimplementiert.


    Quote

    Das ist ja nur eine Frage einer guten Erkennung des richtigen Abschaltzeitpunkts. M-W und M-E sind sicherlich schonmal gute Kandidaten zum Abschalten des Speeders, da ja offensichtlich ein eigener Speeder gestartet oder anderes esoterisches Zeugs gemacht wird.


    Dann wird das Ergebnis bei mancher Software deutlich langsamer sein als notwendig, es gibt einiges was in der Floppy nur die normalen Jobcodes plus eigene Transferroutinen verwendet.

  • Die 1541U lässt ein unverändertes 1541-Rom auf einer komplett nachgebildeten 1541-Hardware laufen. Oder meinst du den Teil der direkte SD-Zugriffe erlaubt?

    (ok, letztes Posting ;) ) Ich meinte noch was anderes, nämlich dass die 1541U 6502-Code laufenlässt (soweit ich weiß - das Freezer-Menü etc.), ohne dass der C64 was davon mitbekommt. Ähnlich könnte man das Ramdisk-DOS verstecken, ohne es komplett neu implementieren zu müssen. Ist aber natürlich trotzdem ein Haufen Arbeit und wohl eher nicht vom Stil her etwas, was hier im Thread interessiert, das sehe ich ja ein ;) .

  • Bei dem Ansatz bleibt die Frage, warum dann nicht eine Laufwerksmechanik per Shugart Interface direkt an der 1541U anzukoppeln und dann den ganzen Speeder in der 1541U zu implementieren. Die Idee hatte ich schon vor längerem mal :)

    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!

  • Ich meinte noch was anderes, nämlich dass die 1541U 6502-Code laufenlässt (soweit ich weiß - das Freezer-Menü etc.), ohne dass der C64 was davon mitbekommt.


    Ja, aber Gideon hat da die für seine Hardwarebasis einfache Route gewählt: Der 6510 im C64 wird via DMA-Leitung angehalten und der Code läuft im FPGA. Es gibt ein kurzes Dokument welches erläutert wie man unter den Randbedingungen den C64-Prozessor in einem "günstigen" Zustand anhält und später synchron zum VIC-Bildaufbau weiterlaufen lässt, google mal nach "Safely freezing the C64 on an asynchronous event".

  • Schade das der Thread eingeschlafen ist, gerade vor dem Hintergrund, dass die Professional DOS Platine gerade neu aufgelegt wird.
    Wenn das Projekt von @Retro kompatibler und schneller als das Professional DOS ist, haette man ja die Energie besser da hinein stecken koennen.
    Es waere schoen, wenn @Retro seine Entwicklungsdaten der Oeffentlichkeit zur Verfuegung stellt, damit man damit weiter machen kann. Damit koennte sich dann jeder Interessierte ein Sunrise nachbauen.
    Oder wenn @Retro selber weitermacht, ggf. auf Bausatzbasis, damit jeder Interessierte dann seinen Speeder selbst zusammenbauen kann.
    Ich denke es gibt noch einige Interessierte, die bereit sind Geld fuer einen Speeder auszugeben.
    Ein grosser Vorteil von veroeffentlichten Plaenen und Daten waere die Weiterentwicklung auch fuer andere Floppys, wie es gerade auch beim Professional DOS passiert. Da ist die Entwicklung mittlerweile so weit, das die Platine in alle Floppys passt und betrieben werden kann.



    Gruss
    marty