Chameleon64v2 vs CMD SuperCPU unter GEOS

Vergleich Chameleon64v2 mit CMD SuperCPU64/RAMCard unter GEOS MegaPatch64 V3.3r4.

Test mit MegaAssembler V4. Die Zeiten geben an wie lange der Assemblierungsvorgang von GEOS MegaPatch gedauert hat. Teil#1 ist der Kernal, Teil#2 sind Programme und Treiber. Teil#2 endet mit 67.403 erzeugten Assembler-Befehlen und 270.919Bytes.

Teil#2 wurde nicht immer getestet, hochgerechnet würde der am C64/REU 3h dauern... das muss nicht sein.

Zum assemblieren wurden zwei Laufwerke eingerichtet: Laufwerk C: ist immer ein RAM-Laufwerk im GEOS-DACC, Laufwerk D: Entweder RAMNative, CREU-Native, RAMCard-Native oder RAMLink-Native. C: Enthält den Assembler und den erzeugten Programmcode. D: enthält alle Quelltext-Dateien.

Wenn man aus dem Test die besten Werte für Teil#1 nimmt:
Platz#1: VICE (allerdings läuft hier die Uhr schneller) - Faktor 24x
Platz#2: SuperCPU+RAMCard - Faktor 12x
Platz#3: Chameleon64+REU - Faktor 5x
Platz#4: C64/REU - Faktor 1x

Bei Teil#2 bleibt die Rangfolge gleich. Nimmt man die Werte von VICE als Basis ändern sich bei den vielen kleineren Dateien die Faktoren minimal.

Die RAMLink bremst den Test etwas aus, aber ich hab keine REU mit der ich ein so großes Native-Laufwerk als D: einrichten könnte (nur CMD 1750XL 2MB). Daher wurde hier eine RAMLink-Partition verwendet. Bei Teil#1 zeigt sich das mit einer echten 16MB-REU die Ergebnisse fast identisch wären wie mit der RAMCard.

vergleicht man SuperCPU/1MHz und C64/REU muss ich feststellen das der DMA-Chip doch schneller ist als der 16Bit-Code der SuperCPU. Allerdings lässt sich das nicht kombinieren, da der SuperCPU-Patch den Speicher der DMA-Routine benötigt. Ohne den Patch ließe sich aber die SuperCPU nur im 1MHz-Modus betreiben.

Fazit: Das ist ein ganz spezieller Test und nicht allgemein auf andere Programme übertragbar. Aber hier sieht das Cham64 nur die Rücklichter der SuperCPU . Aber das Cham64 ist ein tolles Stück Hardware, da kann ich bald den realen C64 wieder einmotten und die teure Hardware schonen: Und für GEOS ist die Geschwindigkeit des Cham64 absolut ausreichend, kein Vergleich mit einem "puren" C64.

C64/REU, RAM81+RAM81
Teil#1: 516s
Teil#2: -nicht getestet- (gem. VICE ca. 12.240s)

VICE/Warp (bis zu 2600%)/REU, RAM81+CREU-Native
Teil#1: 21s
Teil#2: 503s (VICE zeigt 3h24m an wenn der C64 mit 1MHz laufen würde)

Chameleon-Turbo/16MbREU, RAM81+CREU-Native
Teil#1: 104s
Teil#2: 2.559s

Chameleon-1MHz/16MbREU, RAM81+CREU-Native
Teil#1: 522s
Teil#2: -nicht getestst- (Hochgerechnet etwa 12.850sek = 3h34m)

SuperCPU-10MHz/REU, RAM81+RL-Native
Teil#1: 47s
Teil#2: 1.326s

SuperCPU-1MHz/REU, RAM81+RL-Native
Teil#1: 757s
Teil#2: -nicht getestet-

SuperCPU-1MHz/REU, RAM81+RAM-Native
Teil#1: 682s
Teil#2: -nicht getestet- (nicht genügend REU-Speicher)

SuperCPU-10MHz/RAMCard, RAM81+SRAM-Native
Teil#1: 43s
Teil#2: 1.092s

SuperCPU-1MHz/RAMCard, RAM81+SRAM-Native
Teil#1: 682s
Teil#2: -nicht getestet-

Kleiner Nachtrag: Mit dem Cham64 sollte MoveData im Editor abgeschaltet werden. Damit ist das Cham64 etwas schneller beim Test:

Chameleon-Turbo/16MbREU mit MoveData, RAM81+CREU-Native
Teil#1: 104s
Teil#2: 2.559s

Chameleon-Turbo/16MbREU ohne MoveData, RAM81+CREU-Native
Teil#1: 76s
Teil#2: 1.821s

Bei Teil#1 ergibt sich damit ein Faktor von 6,7x. Beim Teil#2 mit dem hochgerechneten Laufzeit am C64 ebenfalls 6,7x.

an @schumi für den Hinweis!

Hab ich da was überlesen? Ich sehe da nicht wie er dazu kommt zu behaupten das TC64 wäre schneller als die SCPU. Ich hab aber auch MegaPatch getestet, im Thread ging es wohl um GEOS.

Bei meinem Test werden die Daten von einem RAM-Laufwerk gelesen und auf ein RAM-Laufwerk geschrieben. Wenn die REU als GEOS-DACC angesetzt wird ist am TC64 evtl. das ein Problem weil da wohl auf 1MHz umgeschaltet wird, der Transfer in die REU geht ja mit den REU-Registern ab $DE00. Bei MegaPatch128 wird der Takt auch auf 1MHz gedrosselt obwohl der im 80Z-Modus bei 2MHz liegt. Ein Kommentar dazu besagt das dies wohl notwendig ist. Wenn das TC64 hier kompatibel sein will würde das ein runtertakten auf 1MHz erklären und dann wären die Diskzugriffe das was das TC64 ausbremst. Das ließe sich aber nur umgehen wenn man direkt in die 16Mb der REU Daten schreiben/lesen kann ohne die REU-Register zu verwenden.

P.S. Wie gesagt ist mein Test ein sehr spezieller Anwendungsfall: Da werden massenhaft Daten von Disk gelesen und gespeichert. Es ist durchaus möglich das andere Programme die Hauptsächlich im Speicher arbeiten mit dem TC64 schneller sind. Da müsste ich mal ein Testprogramm schreiben wass z.B. nur Grafikroutinen verwendet.

Zitat von captain_zzap

wiki.icomp.de/wiki/C64_Benchmarks
Kommt halt drauf an, was man benchmarkt. Finde deine Ergebnisse interessant.

Danke

Die Seite kannte ich, dort sieht man ja auch das in einigen Bereich das TC64 schneller ist als die SCPU. Hier werden aber Einzelfälle getestet. Das ist mein Test zwar auch, aber eben einer den ich bis vor kurzem täglich im Einsatz hatte. Es zeigt sich also wieder mal das es einen absoluten Test nicht gibt. Würde man da meinen Test mit dran hängen würden das Rating anders aussehen.

Zitat von markusC64

Könnte sogar gehen - beim TC64 geht ziemlich viel. Allerdings Standard-REU kompatibel wäre so ein Zugriff sicher nicht mehr...

Muss ja nicht. Bei der SuperCPU gibt es auch einen Treiber der die Daten via 16Bit-mvn-Befehl verschiebt. Wenn ich wüsste wie man Daten ohne Register in das 16MB-REU-RAM speichern kann könnte man da was programmieren.

Das Handbuch hab ich schon... für die RTC. Aber auch noch nicht damit beschäftigt.

Für mich ist der Unterschied jetzt nicht so groß das ich da dringend Abhilfe schaffen müsste. Aber nachdem ich meinen TC64-Arbeitsplatz mit umgelabelter PS/2-Tastatur+Maus und Selbstbau-Netzteil für TC64+SD2IEC und HP-Monitor fertiggestellt hab wollte ich das einfach mal testen. Wirklich relevant ist das alles für mich sowieso nicht mehr. Und CMD-Partitionen kann ich auch mit einer FD am TC64 testen... Fazit: Das TC64 wird über kurz oder lang meinen C64+SCPU als Test-Platform ablösen...

Hier noch ein Nachtrag aus der Konversation mit @schumi

Zitat von schumi

nicht das chameleon schaltet beim zugriff auf reu register runter - sondern die reu kopiert immer 2 bytes pro 1mhz takt. das chameleon schaltet den takt nie runter - mit der einzigen ausnahme wenn "iec sync" aktiviert ist, dann triggern zugriffe auf cia2 ports das runterschalten.

Also ist die REU immer langsamer, da müsste man echt was patchen. Und mit einer GeoRAM-Emulation wird das TC64 noch langsamer als TC64+REU ohne MoveData.

Zitat von OliverW.

Ich mache gerade die ersten Versuche mit meinem TC64. Jetzt muss ich doch mal fragen: Wie bootest Du das MP3? Von einem Laufwerk, das am TC64 hängt? Oder von einem Image?

Ich hab schon D64 Images für MP3 erstellt... aber...

Zitat von markusC64

Ich möchte wetten, vom SD2IEC... Darkvision hat sich schließlich extra ein paar SD2IECs zugelegt.

Und ja, es ist eine der besten Möglichkeiten. CMD Hardware (HD) mag eine andere der guten Möglichkeiten sein.

...ich hab jetzt 3x SD2IEC Leider wurde das V5.2 mit Display erst nach meinem dritten SD2IEC angeboten... das riecht nach einem vierten (vor allem weil das den größeren Chip hat) Momentan hängt aber nur ein SD2IEC via MiniIEC-Kabel am TC64. Die internen Laufwerke nutze ich gar nicht...

Die Installation von MP3 auf D64 Images hab ich ja schon getestet und da hab ich auch schon ein HowTo angefangen... werde ich demnächst noch vervollständigen.

Nein, ich hab das D81 vom C64 verwendet... solange die Geräte-ID+Typ gleich ist kann man problemlos auch vom SD2IEC am TC64 booten.

Zitat von C=Mac

Jetzt müsste man beides haben und je nach Anforderung umstecken.

Wieso umstecken? Das TC64 funktioniert ja auch im StandAlone-Mode
Der C64 mit SCPU wird demnächst wieder eingemottet... Save the Hardware!