Hallo Besucher, der Thread wurde 7,8k mal aufgerufen und enthält 36 Antworten

letzter Beitrag von WalkThatWay am

Floppy Speeder auf Basis FE3

    Zitat von Tommi_nrw

    aber wer kann den FloppyKernal entsprechend anpassen?

    Kleinere Anpassungen kann ich schon machen.


    Das ist eigentlich meine Stärke, Hardware und CPLD sind bloss Hobby ...





    Das klingt kompliziert, ist aber ganz einfach.


    ProfDOS verwendet 8 KB um eine Spur zu cashen.


    Wir blenden einfach nur den "richtigen" 8KB Block ein bevor wir lesen.
    Und wir merken uns, ob der cashe gültig ist oder nicht.



    Zitat von Tommi_nrw

    Meiner Meinung nach brauchen wir:


    512kb Ramdisk (2 Disketten(seiten), unschaltbar)
    +8kb Spurcache bei Diskettenbetrieb
    +2kb Ersatz für FloppyRAM (wegen eigener 2MHz Takterzeugung auf dem Speeder)


    Genau.
    Und der große Flash ist auch gut.


    So kann man alle ROMs ersetzen und mehrere Versionen der Firmware umschaltbar halten.


    Sogar riesige GCR Tabellen wären ganz easy zu machen.





    Zitat von Tommi_nrw

    Das gibt zuviel Schreibverkehr auf der Diskette. Besser ist da ein "sync-Befehl" der die Diskette schreibt.

    Ja genau.


    Jeder 8 KB Spur Buffer hat flags:

    • Daten gelesen und gültig
    • Daten verändert (müssen geschrieben werden)


    Alle Operationen gehen im RAM, sofern die Spur bereits im cashe ist.


    Die Lazy Loop macht den Rest:

    • lesen der Tracks die nicht im cashe sind
    • schreiben der Tracks die verändert wurden (mit einer kleinen Verzögerung, 2 Sekunden oder so)
    Zitat von Diddl

    Wir blenden einfach nur den "richtigen" 8KB Block ein bevor wir lesen.
    Und wir merken uns, ob der cashe gültig ist oder nicht.

    Theoretisch gut, aber 35 x 8k sind schon 280k und mit 40 Tracks sind wir dann schon bei 320k ...
    dann reichen 512kb nicht für zwei Disks.
    Und so kommt die Speicherverwaltung wieder ins Spiel ...


    6k reichen für eine Spur, zumindest bei Professional DOS. Das würde passen, (6x40=240) aber wenn man dann
    z.B. mit DD anschließend noch weiter machen wollte, wäre schon wieder Ende. Denn DD verschwendet die ganzen 8k...
    Und dann kommt dazu, dass 6k wieder umständlich zu adressieren sind ...


    ... und dann glaube ich, dass Professional DOS im 8k (6k) Bereich auch noch Statusinformationen ablegen wird und die
    müssten dann ja immer in jeden der 6k Blöcke geschrieben werden.


    Daher denke ich, der Ansatz muss eher sein, das die 8k Spurcache (wie bei TT übrigens auch) separat von den RAMDisks sind.
    Es kann ja auch sein, dass ich zwei disks im RAM habe und trotzdem noch von der Diskette lesen will....


    Ja, jeden Block wie bei TT immer über alle Bänke zu verteilen finde ich auch nicht schön.


    Ich hätte bei Professional DOS16k - von $8000 bis $BFFF - frei für 64 Blöcke pro Bank. Wenn ich richtig rechne, dann benötigen
    wir 719 Blöcke für 40 Spuren, sind 12 Bänke oder 192k. Genug Rest für Statusbits und -bytes.


    Oder noch viel besser: 63 Blöcke pro Bank plus 256 Byte Status. Da kommen wir auch noch mit 12 Bänken aus, haben aber den Statur immer in der jeweiligen Bank.
    Das dann mal zwei - bleiben 128! KB über von 512kb.


    Wenn wir das RAM geschickt anbinden, könnte man davon die 2k und die 8k Spurcache auch noch direkt adressieren ... und hätte immer noch 118k über!

    Zitat von Diddl

    Warum möchtest du zwei Disketten buffern?

    Habe ich jetzt einfach mal vom TT übernommen ....



    Zitat von Diddl

    Denkst du an eine Anwendung in der 1571?


    Hatte ich noch nicht. Wenn es in der 1541 läuft, wären die Anpassungen am PD Kernal der
    1571 wahrscheinlich ähnlich. Nur leider habe ich da nicht so ein großes freies Adressfenster.
    Nur $1000 bis $17FF sind wirklich frei.
    $2000 bis $3FFF adressiert zwar auch eigentlich nichts, aber von irgendwoher kommt dann Müll
    auf die Datenleitungen. Habe ich aber nicht weiter erforscht, weil bisher egal.

    Ich kann da gerne mal eine HW-Lösung erarbeiten, aber das steht bei mir im Moment an x-ter Stelle.


    Ich bin froh, wenn ich endlich in den Weihnachsturlaub gehen und ein paar der Sachen endlich
    mal erledigen kann. Im Moment ist bei mir noch "Land unter".


    Immer vorraus gesetzt dass @Diddl dann den Kernal anpassen kann ....

    Sorry, bin gerade beim übersiedeln.
    Der PC ist jetzt zwar aufgebaut, aber ich habe noch kein Internet.


    Am Tablet ist es etwas mühsam, aber es geht.


    Keine Ahnung ob wir ihn unterstützen könnten?


    Denn Kernel anpassen wird klappen, aber auch etwas Zeit beanspruchen.
    Zudem kann man erst wirklich anfangen, wenn die Spec fix und fertig ist.
    Und erste tests natürlich erst, sobald die Hardware funktioniert.

    Zitat von WalkThatWay

    @Diddl können wir denn schon mal bei den Spezifikationen weitermachen?

    Mein PC läuft, und Internet!! :)


    Ja können wir schon.
    Teilweise.



    Reden wir jetzt von einer allgemeinen Lösung, die als 6502 Ersatz funktioniert?
    Quasi DIL-40 Mikrocomputer mit Flash, SRAM, CPLD und 6502?
    Also ein FE3 artiges Ding für 6502 Systeme?



    Oder reden wir von einer 1541 Lösung, die gängige Speeder Hardware emuliert?

    @Diddl, @Tommi_nrw: Welche Organisationsart des Caches wollen wir umsetzen?
    -direkt abgebildet
    -vollassoziativ
    -satzassoziativ bzw. mengenassoziativ


    Quelle: Link


    Evtl. könnten wir ja auch erstmal zu Versuchszwecken aus einer ausgedienten Festplatte den Teil der Kontrollerplatine benutzen, der das Cachen der Magnetplatten macht?

    Zitat von WalkThatWay

    @Diddl, Tommi_nrw: Welche Organisationsart des Caches wollen wir umsetzen?


    -direkt abgebildet
    -vollassoziativ
    -satzassoziativ bzw. mengenassoziativ

    Bei einem mechanischem Speichermedium wie Floppy Disk sind die größten Kosten beim Spurwechsel, wegen der Trägheit des Kopfes.
    Vor allem beim Wechsel der ersten und letzten drei Spuren, weil der Kopf erst beschleunigen muss.


    Zudem sind die Kosten bei Zugriff auf einen Sektor exzessiv, weil man warten muss, bis der richtige Sektor am Kopf vorbei läuft …
    Zugriff ist verzögert um bis zu 200ms.


    Und letztlich ist die Zeit zum hochfahren des Drive selbst schon sehr teuer


    ==


    Die Organisation im RAM ist faktisch egal, denn selbst wenn man es schlecht macht, ist es noch um Faktor 1000 schneller.



    Wir buffern in erster Linie eine ganze Spur.
    Und zwar die aktuelle Spur.


    Und in zweiter Linie die restlichen Spuren, also die ganze Diskette


    ==


    Die Organisation des Buffer beschäftigt mich schon eine ganze Zeit lang.
    Man hat folgende Möglichkeiten:

    • wir buffern native Daten, also GCR kodiert, exakt so wie es von der Diskette kommt
    • wir buffern GCR dekodierte Sektor Daten (Header + datanblock)
    • wir buffern überhaupt nur Sektor Daten



    Im Fall 2 sind wir schneller als im Fall 1. Die Floppy kann direkt die gewünschten Daten zum C64 senden.


    Im Fall 1 sind wir kompatibler. Die Floppy kann auch Lesefehler exakt wieder geben, dadurch funktionieren auch simple Kopierschutz Techniken weiterhin.


    Im Fall 3 sind wir am schnellsten. Aber es funktioniert nur mit Disketten die nicht manipuliert worden sind.



    Da wir genügend Flash Speicher haben, neige ich dazu, beide Varianten zu implementieren.
    Man kann die Floppy umschalten in den gewünschten Modus.


    ====


    Natürlich gibt es auch andere Möglicheiten:

    • wir buffern beides, GCR Daten und auch dekodierte Daten
      Man könnte sich für jeden Sektor merken, ob er lesbar ist oder einen Lesefehler hat.
    • wir Buffern nur dekodierte Daten und merken uns, welche Sektoren lesbar sind.
      Bei Zugriff auf Sektoren mit Lesefehler verwenden wir die normalen Leseroutinen und lesen direkt von Diskette
      Dann läuft das Laufwerk halt immer an, wenn ein Kopierschutz gelesen wird.



    ====


    Wenn es uns gelingen würde, die GCR Dekodierung direkt im CPLD zu machen, dann gäbe es nur netto Daten für uns und wir sparen uns die Rechnerei am 6502.


    Auch der Code in der Floppy Firmware wäre dann am einfachsten.


    ====


    Gedanken könnte man sich auch machen, ob man evt. die System Disk Buffer direkt einblendbar macht …


    | $0300-$03FF/768-1023 Puffer 0
    | $0400-$04FF/1024-1279 Puffer 1
    | $0500-$05FF/1280-1535 Puffer 2 (User-Puffer)
    | $0600-$06FF/1536-1791 Puffer 3
    | $0700-$07FF/1792-2047 Puffer 4
    | $0800-$08FF/2048-2303 Puffer 5
    | $0900-$09FF/2304-2559 Puffer 6



    Wenn man die Sektor Daten direkt buffert, dann könnte man diese 7 Bereiche direkt einblenden, beim lesen.
    Beim Schreiben allerdings wäre dies gefährlich.



    Mir fällt dazu keine Lösung ein …
    … wir werden wohl weiterhin die Sektoren per CPU in die System Buffer kopieren.



    Wobei man die CPU natürlich unterstützen könnte, eine Art DMA:

    • ein Register im CPLD für die Lese Adresse (ein Pointer)
    • ein Register im CPLD für lesen eines Byte + Inkrement des Pointer

    Der 6502 bräuchte nur den gewünschten Sektor setzen und 256 mal ein Register lesen







    @Tommi_nrw , @Diddl : Habt ihr euch schon mal das pi1541 Projekt angeschaut? Klick mich


    Man könnte evtl. das irgendwie mit benutzen in der 1541.
    Das Floppy ROM läßt sich austauschen ...
    Da wäre evtl. Lan, W-Lan, SD-Karte, Touch Screen und USB vom Raspberry mit nutzbar. Zusammen mit der 5 1/4 Zoll Floppy. Floppy cachebar über Softwarelösung ...


    Schwebt mir irgendwie so vor.

    Zitat von WalkThatWay

    @Tommi_nrw , @Diddl : Habt ihr euch schon mal das pi1541 Projekt angeschaut? Klick mich


    Man könnte evtl. das irgendwie mit benutzen in der 1541.
    Das Floppy ROM läßt sich austauschen ...
    Da wäre evtl. Lan, W-Lan, SD-Karte, Touch Screen und USB vom Raspberry mit nutzbar. Zusammen mit der 5 1/4 Zoll Floppy. Floppy cachebar über Softwarelösung ...


    Schwebt mir irgendwie so vor.

    Klar kenne ich das Pi1541.
    Hab auch eines laufen hier bei mir.



    Es geht nicht darum, eine noch perfektere Lösung zu finden.
    Sonst muss man einfach nur VICE auf einem schnellen PC verwenden mit einem USB Competition Pro. ;)



    Es geht darum, Retro Legenden am Leben zu erhalten (so wie Prof-DOS) und logische Weiterentwicklungen zu treiben.

    Zitat von Diddl

    Es geht darum, Retro Legenden am Leben zu erhalten (so wie Prof-DOS) und logische Weiterentwicklungen zu treiben.

    So denke ich ja auch.


    Bei dem PI1541 dachte ich mehr daran, davon irgend was mit zu benutzen beim entwickeln.


    In etwa so etwas
    c64->ca."PI1541"->1541
    Über den PI1541 könnten z.b. die BUS Signale schön auf einem Bildschirm zu analyse zwecken dargestellt werden, quasi ein Bode-Plotter oder wie das Dingen hieß für die DIN Buchse.
    Nur mal so als Beispiel. Was genau, weiß ich ja auch noch nicht.


    Und RAM hat der PI auch. Vieleicht geht da ja schon irgend was mit unserer Cache Geschichte und man kann erst einmal softwaremäßig etwas austesten, bevor wir es hardwaremäßig bauen.