Hallo Besucher, der Thread wurde 44k mal aufgerufen und enthält 247 Antworten

letzter Beitrag von LogicDeLuxe am

Speedtestprojekt für JEDES C64 Laufwerk *bitte mitmachen !*

  • Bei Speeder Software hat man immer den Kompromiss zwischen Speed und Kompatibilität.




    Ein Speeder der "nur" auf superschnelles LOAD abzielt, ist halt einfacher zu machen, als einer der alles andere auch beschleunigt.

    Natürlich gibt es viele Menschen, für die LOAD der mit Abstand häufigst benutzte Befehl ist ...


    Nichts gegen Jiffy, das ist ein kleines Wunderwerk.

    Aber die meisten seriellen Speeder sind halt hoch spezialisiert und beschleunigen oft nur das LOAD.

    Und richtig schnell sind die auch oft nur mit Einschränkungen:

    • speziell vorbereitete Disketten
    • kein Abbruch möglich
    • kein schneller Zugriff über OPEN
    • kein schneller Zugriff auf REL Dateien
    • wenig Fehlertolerant

    Da läuft spezieller Code in der Floppy und im C64, der nur eine Aufgabe erfüllt, eine Datei so schnell wie möglich zu übertragen.

    Da wird das DOS komplett übergangen.

    Es werden keine normalen Befehle mehr bedient.

    Es können währenddessen keine Dateien am Laufwerk offen sein.

    Der Vorgang ist hoch sensibel, kann nicht unterbrochen werden und lässt keine anderen Tätigkeiten zu.


    Das mag für Spieler interessant sein, hat aber wenig zu tun mit einem normalen Floppy Betrieb!




    Hardware Speeder haben etwas mehr Aufwand, dafür verhält sich das System weitgehend wie ein unbeschleunigtes Gespann aus C64 und 1541.

    Alles ist hoch kompatibel und es ist ALLES beschleunigt (SEQ, REL, OPEN, GET# ...).

    Es ist unauffällig und Fehlertolerant, speziell Dolphin II.


    Was das LOAD angeht, könnte man bei parallel Speeder ja auch zusätzlich auf spezielle Routinen zurückgreifen, mit allen Vor- und Nachteilen.

    Was aber fraglich ist, weil wenn man 202 Blöcke in 4 Sekunden laden kann, ist jede Steigerung effektiv kein großer Gewinn mehr.




    Mal davon abgesehen sind praktisch alle Test Ergebnisse höchst fraglich.

    Weil die Ausgangssituation unklar oder unscharf definiert ist.


    Praktisch alle Hardware Speeder sind nochmals viel schneller, wenn die "Bedingungen" gut sind:

    • sehr gutes Disketten Material
    • Motor Umdrehung perfekt.
    • Wichtig: Die Testdiskette wurde vom eigenen System formatiert und beschrieben!!!

    Wenn Dolphin eine Diskette liest, die mit Dolphin formatiert wurde und beschrieben (SAVE nicht ein Diskcopy), dann ist es meist nochmal schneller.

    Wobei natürlich auch ein Vorteil ist, dass Fremd Disketten die nicht präpariert sind, auch super schnell geladen werden.


    Drehen wir das mal um. Man kann Testergebnisse auch bewusst schlecht aussehen lassen.

    Speichere ein File so, dass jeder Folge Block auf einer anderen Spur ist.

    Damit kann ich alle Vorteile von Speeder mit Trackloader aushebeln, die sind dann möglicherweise sogar langsamer.

  • RAM dekodiert ja nicht.

    Eben das war mein Punkt ...

    RAM dekodiert ja nicht. Ich meinte schon so eine ROM-basierte Speziallogik, in die 5 oder 10 Bits reingeschoben werden und 4 oder 8 Bits rauskommen. :)

    Eben sowas, was Professional DOS benutzt.

    Und eben das macht Professional DOS (so) nicht. Das wäre dann ein echter HW-Decoder und ich kenne keine Hardware für die 1541 die genau das können würde.

    (Bis auf meine Lösung für MeGALoDOS die ich nie veröffentlicht habe - Aber das ist bisher nur Hardware - die Software dazu fehlt ...)


    Am Ende wurschteln alle nur mit Lookup-Tabellen rum ...


    Jedenfalls, für den enormen Hardware-Aufwand finde ich die Speeder auch irgendwie zu langsam, wie 1570 auch. :)


    Ja - eine Optimierung der Software für die Hardware hat nie einer wirklich gemacht ...

    Aber die Obergrenze ist am Ende eh die Laufwerksmechanik...

  • RAM dekodiert ja nicht. Ich meinte schon so eine ROM-basierte Speziallogik, in die 5 oder 10 Bits reingeschoben werden und 4 oder 8 Bits rauskommen. :)

    Eben sowas, was Professional DOS benutzt.

    Und eben das macht Professional DOS (so) nicht. Das wäre dann ein echter HW-Decoder und ich kenne keine Hardware für die 1541 die genau das können würde.

    Ganz sicher? Von http://www.d81.de/ProfessionalDOS/Hardware:

    "This chip could be identified as a 82S123, which is a 256 Bit PROM (32x8 Bits) also known as 74S188. It seems that it is used as some sort of programmable logic (5 inputs, A0...A4 and 8 outputs, O1...O8), like a PAL or GAL."

    Der eingerahmte Teil "GCR-Nybble-Dispatch" in http://www.d81.de/Professional…ional-DOS-V1-Sch-1.01.pdf sieht mir auch stark nach Custom-Dekodier-Logik aus.

    Und der relevante ROM-Code hier http://www.d81.de/ProfessionalDOS/Hardware/roms.shtml irgendwie auch. :)

    Am Ende wurschteln alle nur mit Lookup-Tabellen rum ...

    Sicher, aber das Ganze wird erheblich vereinfacht, wenn die Hardware direkt N*5 Bits verarbeitet.

    Aber die Obergrenze ist am Ende eh die Laufwerksmechanik...

    Ja... 200 ms zum Lesen einer Spur, während die Daten nebenbei und dann beim Spurwechsel verschickt werden.

    Für die Hälfte der Diskette (Spuren 1-17) sind das dann schon irgendwo knapp an die 25 KB/s, also so Faktor 60-64. :)

  • Bei Speeder Software hat man immer den Kompromiss zwischen Speed und Kompatibilität.

    Wow Diddl, Du hast doch eigentlich Ahnung, wieso dann so eine Aussage/Posting?

    Nichts gegen Jiffy, das ist ein kleines Wunderwerk.

    Die Prioritäten lagen da einfach anders als bei anderen Speedern. Man hat sich bei Jiffy entschieden, dass es ein KERNAL-Ersatz sein sollte mit dem entsprechenden (kleinen) Umbau-Aufwand, und natürlich ist man dann auch die "Extra Mile" gegangen, den KERNAL kompatibel zu halten, weil das ansonsten ein Rohrkrepierer gewesen wäre. Niemand will einen KERNAL-Ersatz, der inkompatibel ist.

    Aber die meisten seriellen Speeder sind halt hoch spezialisiert und beschleunigen oft nur das LOAD.

    Das sind sie, weil eine andere Vorgehensweise bei z.B. Epyx Fastload auch gar keinen Sinn gemacht hätte. Wieso einen Software-Speeder (denn das ist das wesentliche Kriterium, nicht dass er seriell ist!), der irgendwo im RAM liegt, $EE13/IECIN prinzipiell so gar nicht beschleunigen kann und definitiv mit diverser (nachgeladener) Software im RAM sowieso kollidieren würde, auf andere Dinge als schnelles LOAD optimieren? Das wäre völlig sinnlos.

    Praktisch alle Hardware Speeder sind nochmals viel schneller, wenn die "Bedingungen" gut sind

    Sorry, diese Aussage ist nur ein bisschen mit den Händen in der Luft wedeln, zumal...

    Wenn Dolphin eine Diskette liest, die mit Dolphin formatiert wurde und beschrieben (SAVE nicht ein Diskcopy), dann ist es meist nochmal schneller.

    Der 64'er Test formatiert im Testdurchgang die Diskette, schreibt dann eine Datei und liest sie danach wieder. Also genau das Optimal-Szenario für Dolphin (und auch Jiffy, denn ansonsten käme Jiffy nicht auf die im Test gemessenen 10fach bei LOAD).

  • Ganz sicher?

    Ja, ganz sicher!


    Die "Decodierhardware" sind der 157er, der 173er und der 367er. Am Ende verbiegen die aber nur die Adressen

    bei Zugriff auf $7000 bis $7FFF um auf den richtigen Tabelleneintrag zu zeigen.

    Das ist für mich kein richtiger Hardwaredecoder sondern nur eine Hilfe bei der Adressierung der Lookup Tabelle.


  • Die "Decodierhardware" sind der 157er, der 173er und der 367er. Am Ende verbiegen die aber nur die Adressen

    bei Zugriff auf $7000 bis $7FFF um auf den richtigen Tabelleneintrag zu zeigen.

    Das ist für mich kein richtiger Hardwaredecoder sondern nur eine Hilfe bei der Adressierung der Lookup Tabelle.

    Na ja, komplett weggekapselte Dekodierung wie auf den PET-Laufwerken hat ja auch keiner behauptet, und sowas wäre eher kontraproduktiv in Sachen Kopierschutz und Spezialformate.

    Mehr als ein wenig Hilfe für die CPU (wie eben durch diese Dekodierlogik, ohne Scare-Quotes, die das Bit-Rumgeshifte komplett erspart) ist weder notwendig noch wünschenswert.

    Es sind vielleicht nur ein paar einfache Bauteile, aber der Trick liegt in der Verdrahtung (Adressierung), die diese grässliche 5-Bit-GCR-Problematik löst.

    Das wäre alles so viel leichter, wenn Commodore einfach das Schieberegister-Gucklock auf 5 statt 8 Bits begrenzt hätte. :)

  • Gibt's denn irgendwo Infos dazu, wie DolphinDOS 2 genauer funktioniert? Z.B. https://www.c64-wiki.de/wiki/Dolphin_DOS#Technik ist ganz schön dünn und irreführend (Dolphin schafft ja eben NICHT das Auslesen und Übertragung einer Spur in einer Umdrehung), und ansonsten habe ich nur ein ziemlich liebloses ROM-Disassembly gefunden.


    Was macht DolphinDOS 2 denn beim Laden genau?

    • Einlesen der Spurdaten (GCR) ins Floppy-RAM (schon inkl. GCR-Dekodierung?)
    • Zusammensuchen der relevanten Sektoren (wann passiert das? Vor der Übertragung zum C64? Oder werden die Sektoren Out of Order mit Offset geschickt, so wie es die meisten Trackloader machen?)
    • Parallelübertragung (wie genau? Handshake pro Byte oder wenigstens teilweise Timing-basiert? Welche Datenrate würde der C64-Teil des Codes maximal schaffen?)

    Werden diese Sachen teilweise parallel ausgeführt, oder passiert das nacheinander? Letzteres würde ja das "schräge" 25fach erklären (zwar wird eine Spur in einer Umdrehung einlesen, danach wird aber decodiert/übertragen, während der Lesekopf untätig bleibt?).

  • Ich habe gerade mal mein SD2IEC mit der Version getestet, die aus dem Wiki hierher verlinkt. Die Originale steigt ja direkt mit "Divide by Zero" aus.

    Jiffy-Dolphin-Mod + sd2iec v1.0.0atentdead0-55-g91de152

    Code
    1. Format, prgsave, prgload, seqsave, seqload, rel anlegen, validate, scratch, transfer
    2. raw 10.8 7.45 23.09 10.24 12.46 78.67 0 690 8.28
    3. d64 16.56 3.68 20.82 2.49 50.67 1180 0 0 7.13
    4. d71 9.2 4.49 20.82 1.8 11.88 1180 0 27.6 8.28
    5. d81 4.05 1.63 23.09 1.79 12.46 1180 0 31.36 8.28

    Einige Werte kamen mir da suspekt vor. PRG SAVE scheint ziemliche Schwankungen zu haben. Ich wollte wissen, ob das auch so reproduzierbar ist und habe alle 4 Tests wiederholt:

    Code
    1. Format, prgsave, prgload, seqsave, seqload, rel anlegen, validate, scratch, transfer
    2. raw 11.83 7.45 23.09 10.12 12.67 78.67 0 690 8.28
    3. d64 16.2 1.82 20.82 1.8 11.88 1180 0 25.56 8.28
    4. d71 8.98 4.49 20.82 1.84 50.67 84.29 0 0 8.28
    5. d81 4.03 1.64 23.09 1.8 12.46 1180 0 31.36 8.28

    PRG LOAD ist ziemlich konsistent und angenehm schnell. Bei SEQ LOAD springt jeweils die 50.67 ins Auge. Die scheint nicht realistisch. Da scheint auch richtig was schief zu laufen, denn an der Stelle fing das SD2IEC an zu blinken und hat auch während REL Anlegen noch weiter geblinkt. Leider zeigt das Programm den Fehlerkanal nicht an. Wäre sicher aufschlussreich gewesen. Der Faktor von rund 12 in den übrigen SEQ LOAD-Tests scheint mir hier hingegen realistisch.


    Ich hätte erwartet, daß es da keine wesentliche Unterschiede zwischen den Imageformaten gibt. Interessant finde ich insbesondere, daß d81 so schnell läd wie im Raw-Modus während die beiden anderen Imageformate etwas gebremst werden.