@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
