Eigenbau Speeder

Es gibt 162 Antworten in diesem Thema, welches 46.244 mal aufgerufen wurde. Der letzte Beitrag (31. Mai 2021 um 14:27) ist von ACDC.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

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

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

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

    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.

  • oder Software: Open1541


    OT: Das erinnert mich daran, dass das Board immer noch nicht da ist. Ich warte noch eine Woche, dann klingle ich wiedermal durch.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Bitte melde dich an, um diesen Link zu sehen. | Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

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

    Zitat

    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.

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

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

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

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

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • 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".

    10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    20 forj=1to5:printchr$(rnd(1)*16+70);:next
    30 printint(rnd(1)*328)-217

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich hatte den mal, aber kannst Du ja im Thread lesen.

    Code: Floppy Fehlerkanal abfragen - Ausserdem kann ich bei "drive not ready" den I: und N: Befehl verwenden und notfalls den Kopf manuell zurückschieben. Und Finger weg vom Stepper!
    10 open1,8,15                   : rem 8 ist die Geräteadresse und das kann man bei Bedarf natürlich anpassen
    20 get#1,a$:?a$;:ifst<>64goto20 : rem Das CLOSE 1 am Ende kann man sich sparen, weil beim RUN automatisch ein CLOSE ALL ausgeführt wird.
    RUN
  • Schade das der Thread eingeschlafen ist, gerade vor dem Hintergrund, dass die Professional DOS Platine gerade neu aufgelegt wird.
    Wenn das Projekt von Bitte melde dich an, um diesen Link zu sehen. kompatibler und schneller als das Professional DOS ist, haette man ja die Energie besser da hinein stecken koennen.
    Es waere schoen, wenn Bitte melde dich an, um diesen Link zu sehen. seine Entwicklungsdaten der Oeffentlichkeit zur Verfuegung stellt, damit man damit weiter machen kann. Damit koennte sich dann jeder Interessierte ein Sunrise nachbauen.
    Oder wenn Bitte melde dich an, um diesen Link zu sehen. 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