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 !*

  • Da klingelt doch was bei mir. Das gleiche Problem gab es sicherlich auch bei Turbo-Trans RAM. War das nicht so, dass man einfach einen anderen Einsprung verwendet? Also falls das Programm mit SYS2063 gestartet wird, einfach SYS2066? Irgendwie sowas :)


    Eben probiert: mit SYS2085 anstatt mit RUN gestartet (was SYS2082 macht), wird das Formatieren ausgelassen.

  • Bedingung:
    Bitte nur zuverlässige Leute melden denen wir nicht wg. jeder Kleinigkeit hinterher rennen müssen. War leider im ersten Anlauf so und hat nichts gebracht!

    Hm, sorry - hier muß ich mich wohl an meine Nase fassen.
    Wo sollen denn die Ergebnisse hin? Hir ins Forum oder per PM an dich?


    Das Programm aus der 64er finde ich übrigens sehr gut für den Vergleich. Besser jedenfalls als ein einfaches load von nem 202 Block File.


    Chris

  • Jetzt müssen wir das nur noch mit der Software regeln ...

    Angehängt eine gefixte Version des 64'er-Speed-Tests. Gibt bei zu kurzer Zeit "0" als Speed-Faktor aus. Ggf. könnte auch das noch auf "1" umbiegen, damit der Gesamtfaktor hinkommt, aber der ist ja eh' eher zum Spaß da.


    VICE/x64 mit "True Drive Emulation" liefert übrigens überall praktisch genau Faktor 1. Dessen Timing ist also offensichtlich ziemlich genau.

  • Angehängt eine gefixte Version des 64'er-Speed-Tests. Gibt bei zu kurzer Zeit "0" als Speed-Faktor aus. Ggf. könnte auch das noch auf "1" umbiegen, damit der Gesamtfaktor hinkommt, aber der ist ja eh' eher zum Spaß da.


    Wenn Du den Speedtest mit Sys2085 startest, wird das Formatieren gar nicht beachtet und der Faktor stimmt ...

  • Dankeschön. Kannst du hier nochmal kurz erklären was du jetzt gepatch hast ?

    Naja, bei der Division, die zum Errechnen des Speed-Faktors gemacht wird, wird halt ggf. eine Division durch Null abgefangen und einfach Null zurückgeliefert. Nichts Spannendes. x1541 hat schon recht, bringt eigentlich nichts, was man durch den anderen Start nicht auch machen könnte, aber vielleicht kann ja das eine oder andere Laufwerk kein LOAD, dann würde der (ungepatchte) Test da mit Division durch Null aussteigen ;). Nicht dass man mit so einem Laufwerk was Sinnvolles machen könnte ;).

  • Schonmal ein paar Werte aus VICE (64'er Speed Test):


    1541: Überall 1x
    Jiffy+1541: Format 3,7x, SAVE 2,54x, LOAD 9,84x, SEQ schreiben 2,2x, SEQ lesen 5,3x, REL anlegen 1,14x, Validate 1,26x, Scratch 1,25x, Datentransfer 4,2x.
    FC3+1541: Format 1x, SAVE 5,4x, LOAD 9,34x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1x, Validate 1x, Scratch 1x, Datentransfer 1x.
    FC3+Jiffy+1541: Format 3,7x, SAVE 2,6x, LOAD 10,4, SEQ schreiben 2,2x, SEQ lesen 5,31x, REL anlegen 1,14x, Validate 1,26x, Scratch 1,25x, Datentransfer 4,2x.
    AR7.5+1541: Format 1x, SAVE 7x, LOAD 15,3x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1x, Validate 1,3x, Scratch 1,3x, Datentransfer 1x.
    AR7.5+Jiffy+1541: Format 3,7x, SAVE 7,6x, LOAD (file not found), SEQ schreiben 2,4x, SEQ lesen 2,37x, REL anlegen 1,14x, Validate 1,36x, Scratch 1,3x, Datentransfer 4,2x.


    1581: Format 2,3x, SAVE 2,15x, LOAD 1,31x, SEQ schreiben 2,4x, SEQ lesen 1,34x, REL anlegen 14x, Validate 11,2x, Scratch 10x, Datentransfer 1,13x.
    Jiffy+1581: Format 2,3x, SAVE 6,37x, LOAD 19,54x, SEQ schreiben 8,11x, SEQ lesen 11,18x, REL anlegen 14,22x, Validate 11,2x, Scratch 10x, Datentransfer 6,55x.
    FC3+1581: (nicht unterstützt)
    AR7.5+1581: Format 2,3x, SAVE 11x, LOAD 16x, SEQ schreiben 2,4x, SEQ lesen 1,34x, REL anlegen 14x, Validate 11,2x, Scratch 10x, Datentransfer 1,13x.
    AR7.5+Jiffy+1581: Format 2,3x, SAVE 11,3x, LOAD 16,7x, SEQ schreiben 7,89x, SEQ lesen 11,34x, REL anlegen 14,22x, Validate 11,4x, Scratch 10x, Datentransfer 6,55x.


    Dummerweise läuft der Test nicht auf einem DTV (benutzt Time of Day-Timer des CIA, die auf dem DTV nicht implementiert sind), sonst hätte ich mal das MMC2IEC-Jiffy damit ausprobiert.


    Die Format-Werte sind Quatsch, weil vom 64'er-Test bei den Cartridges nicht die beschleunigten Routinen aufgerufen werden.


    Man sieht ganz gut, dass die Cartridges LOAD und SAVE beschleunigen, sequentiellen Zugriff (EE13/CHRIN) aber nicht. Das widerum kann Jiffy machen. Leider funktioniert anscheinend die AR7.5+Jiffy+1541-Kombi nicht, ansonsten wäre das wohl insgesamt recht fix.


    Wenn in in x64 allerdings - ohne Speed-Test - mit 1541+Jiffy LOAD abstoppe, komme ich eher auf 6x. Komisch.

  • Zitat


    Wenn in in x64 allerdings - ohne Speed-Test - mit 1541+Jiffy LOAD abstoppe, komme ich eher auf 6x. Komisch.


    um sicher zu sein ob die werte aussagekräftig sind müsste man sich wohl mal die kompletten routinen anschauen und guckn ob die nicht irgendwie an den timern rummachen =)


    achso mit load....wie gross ist denn das file das der 64er test lädt? je kleiner das file und je schneller der eigentliche loader desto stärker fällt das suchen in der directory ins gewicht. da sollte man also zumindest einmal die dir laden vorm test damit er schon auf track 18 steht.

  • Der 64'er Speed-Test scheint die TODs für das Timing zu benutzen, ist also okay. Was anderes wäre ja auch irgendwie schwierig. Der Test schreibt eine 202 Blocks-Datei und liest sie danach wieder ein. Die Unterschiede in meinen Tests kamen vermutlich, weil ich natürlich sonst mit dahergelaufenen D64s getestet hatte, die vermutlich kein Jiffy genehmes Interleave benutzen. Das Jiffy-SAVE dagegen wird das schon richtig machen. Strenggenommen wäre das also auch wieder eine Sache, die man testen müsste: wie schnell ist a) das LOAD mit Dateien, die mit normalem SAVE gespeichert wurden und b) das LOAD mit vom "eigenen" SAVE gespeicherten Dateien. Andererseits gehe ich mal davon aus, dass davon nur die Speeder betroffen sind, die nicht im LOAD ganze Tracks lesen (in dem Vergleich also nur Jiffy). Die Werte des FC3 und AR kann ich jedenfalls auch mit anderen D64 nachvollziehen, da scheint das Interleave egal zu sein.

  • Ich habe hier Werte von einem c128d blech.


    Formatieren: 0.98
    Programm Load: 1.12
    Programm Save: 0.99
    SEQ schreiben: 1.13
    SEQ lesen: 0.98
    REL anlegen: 1.21
    Validate: 0.49
    Scratch Files: 0.5
    Daten Transfer: 1
    64´er-Faktor: 0.9


    Ich hätte eigentlich überall eine 1 erwartet. Wieso ist der denn bei Validate und scratch doppelt so lahm wie ein c64? liegt es an der 1571?

  • Im C128D ist halt eine 1571 drin, keine 1541. Die 1571 hat ein anderes ROM, macht also auch bei den Aktionen ggf. minimal was Anderes. In VICE/x64 mit 1571 sieht das ziemlich exakt genauso aus (hast Du Programm LOAD und SAVE verwechselt? Hier hat SAVE Faktor 1,14 und LOAD Faktor 1). Was die 1571 beim Validate und Scratch anders macht, keine Ahnung.

  • Jiffy+1571: Format 3,4x, SAVE 2,77x, LOAD 14,43x, SEQ schreiben 2,35x, SEQ lesen 6,18x, REL anlegen 1,23x, Validate 1,49x, Scratch 1,49x, Datentransfer 4x.
    FC3+1571: Format 1x, SAVE 5,33x, LOAD 9,34x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1x, Validate 1x, Scratch 1x, Datentransfer 1x.
    FC3+Jiffy+1571: Format 3,4x, SAVE 2,8x, LOAD 10,24, SEQ schreiben 2,35x, SEQ lesen 6,23x, REL anlegen 1,23x, Validate 1,49x, Scratch 1,49x, Datentransfer 4x.
    AR7.5+1571: Format 1x, SAVE 7x, LOAD 15,5x, SEQ schreiben 1x, SEQ lesen 1x, REL anlegen 1,08x, Validate 1,3x, Scratch 1,3x, Datentransfer 1x.
    AR7.5+Jiffy+1571: Format 3,4x, SAVE 7,65x, LOAD 15,49x, SEQ schreiben 2,3x, SEQ lesen 6,91x, REL anlegen 1,34x, Validate 1,35x, Scratch 1,37x, Datentransfer 4x.


    Anscheinend profitiert nur Jiffy von der 1571. Erstaunlicherweise sind Jiffy und AR7.5 anscheinend kompatibel, was die 1571 angeht (anders als bei der 1541).

  • Hab bisher das hier:


    64er Speed Test


    128D (64er Mode) interne 1571 mit RR
    Test Zeit Faktor
    Formatieren 01:14.2 1
    Programm save 02.19.3 0.98
    Programm load 00:12.1 10,5
    SEQ schreiben 01:26.6 0.99
    SEQ lesen 01:19.5 0.96
    REL anlegen 01:52.6 1.05
    Validate 01:56.1 0.57
    Scratch files 01:58.8 0.58
    Datantransfer 01:13.1 0.98
    64er Faktor 2.7


    128D (64er Mode) interne 1571 mit IDE64 3.1 IDEDOS 20071202 (0.90 patch 37)
    Test Zeit Faktor
    Formatieren 01:14.2 1
    Programm save 02:19.5 0.98
    Programm load 00:50.2 2,53
    SEQ schreiben 01:29.2 0.96
    SEQ lesen 01:18.5 0.97
    REL anlegen 01:52.7 1.05
    Validate 01:56.1 0.57
    Scratch files 01:58.6 0.58
    Datantransfer 01:13.2 0.98
    64er Faktor 1.2


    128D (64er Mode) interne 1571 mit FC3
    Test Zeit Faktor
    Formatieren 01:11.0 1.05
    Programm save 00:52.8 2.59
    Programm load 00:13.7 9.27
    SEQ schreiben out of memory



    Das FC3 hat mit einem ?out of memory abgebrochen. Ich werde das nochmal wiederholen.


    Chris