Beiträge von darkvision im Thema „Chameleon64v2 vs CMD SuperCPU unter GEOS“

    Danke für die ausführliche Erläuterung. Jetzt ist das klarer!

    Kleines Beispiel: Bitte melde dich an, um diesen Link zu sehen..

    Auf dem SD2IEC => 79, IMAGE FILE INVALID,00,00 - Ist aber ein D64. Am TC64 läuft das, an der UII+ bestimmt auch.
    Das Demo hat 40Tracks, passt also auch nicht auf eine RAMLink-1541-Partition.
    Unter VICE geht das auch problemlos.

    P.S. Wenn "FLIP-DISK" kommt drücke ich an meiner PS/2-Tatatur nur "F11" und es geht automatisch weiter :)
    Am besten aber nur ein LaufwerkBitte melde dich an, um diesen Link zu sehen. am IEC-Bus, mein SD2IEC hat ohne Strom angefangen zu blinken weil es noch am IEC-Kabel hing.

    Wo man beim C64 zwingend InitForIO und DoneWithIO setzen muss, reicht beim C128 unter Umständen sei, php ...... plp aus.

    Nur zur Klarstellung: Das funktioniert für ROM-Zugriffe und $Dxxx-Zugriffe. Aber InitForIO dient auch dem Zugriff auf die Laufwerke am ser.Bus und da taktet der C128 zusätzlich auf 1MHz runter.
    Dafür muss am C128 ständig zwischen BankBitte melde dich an, um diesen Link zu sehen. (GEOS) und Bank#0 (Kernal) gewechselt werden (im Kernal). Nur deswegen funktionieren (fast) alle ROM-Aufrufe. Es gibt aber ROM-Aufrufe die nicht übersetzt werden und dann stürzt Dir GEOS ab (z.B.
    SETBANKFILE = $ff68).

    P.S. Kleiner Nachtrag:
    Der Grund dafür warum SuperCPU+REU im 1MHz-Modus langsamer ist als ein C64 oder das TC64+REU liegt in den zusätzlichen Routinen für die SuperCPU die bei jedem I/O-Zugriff über InitForIO prüfen ob die SuperCPU heruntergetaktet werden muß. Das sind nur wenige Befehle aber bei 1000x ausgeführt kostet das schon einiges an Zeit. Bei 10MHz fällt das nicht auf. Das TC64 macht das automatisch.
    Auch die RAMLink benötigt zusätzliche Kernal-Aufrufe um die Transfers im Speicher auszuführen. Zusammen mit der SuperCPU bremst das noch mehr aus.

    Nur falls jemand die Werte oben in Frage stellt... das ist für mich schon nachvollziehbar.

    Sobald ich das Boot-D64 von intern (SD) auf das sd2iec kopiere, und von sd2iec boote wird das Geschwindigkeitsmäßig besser. Reicht aber ebenfalls noch nicht an SuperCPU mit RamLink ran. Da hätte ich mir aber mehr vorgestellt. Warum ist das so? Warum ist da SuperCPU mit RamLink schneller??

    Die 1541-Emulation im TC64 oder in der Ultimate sind fast eine 1:1 Kopie einer 1541, d.h. die verhalten sich fast so wie ein echtes Laufwerk. Inklusive internem RAM/ROM. D.h. da laufen auch spezielle Fastloader die das SD2IEC oder die RAMLink nicht kennen. Es gibt ja z.B. die Demos die nur mit einer 1541 funktionieren oder die GEOS-Bootdisketten die im Original ja auch nur von einer 1541 starten. Daher gibt es ja auch noch das .G64-Diskformat. Versuch das mal auf die RAMLink zu kopieren und GEOS von dort aus zu installieren... wird nicht klappen.

    Wenn ich das richtig verstehe ist ein Pi1541 auch noch so ein Kandidat der versucht die 1541 zyklengenau nachzubilden. Dadurch dauert das formatieren einer Disk genauso lange wie auf einer echten 1541.

    Wenn Du VICE nicht im WARP-Modus betreibst dauert das laden von der simulierten 1541 auch eine "Ewigkeit" (bei 100%)...

    Das SD2IEC oder die RAMLink machen das so nicht. Da sind die Zugriffe halt so schnell wie es geht. Dafür gibt es aber Programme oder Demos die davon nicht gestartet werden können. Deswegen braucht es beim SD2IEC die M-R-Emulation für 1541/71/81 damit MegaPatch die Laufwerke erkennt. Bei TC64/Ultimate/Pi1541 nicht erforderlich. Das sind wie echte 1541 nur ohne Motor...

    Unter GEOS ist da der limitierende Faktor wirklich die 1:1-Kopie des Laufwerks: Das SD2IEC liest auf Anfrage die Daten von der SD und gibt diese an das Programm weiter. So schnell wie es eben geht. Das TC64/Ultimate/Pi1541 liefern die Daten so schnell wie es eine echte 1541 machen würde.

    Die RAMLink ist aber langsamer als eine echte REU

    Zitat von DarkVision


    SuperCPU-1MHz/REU, RAM81+RL-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 757s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet-

    SuperCPU-1MHz/REU, RAM81+RAM-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 682s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet- (nicht genügend REU-Speicher)

    und im 1MHz-Modus auch langsamer als das Cham+REU:

    Zitat von DarkVision


    Chameleon-1MHz/16MbREU, RAM81+CREU-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 522s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestst-

    Wobei das hier wieder die Diskzugriffe sein können die das Ergebnis etwas verfälschen. Aber wenn man es mit der RAMLink vergleichen will ist das ja auch das wichtigere Kriterium als Bildschirmausgaben.

    Die RAMLink hat aber den Nachteil das man die 16Mb an RAM nur aufwändig auf einer HD sichern kann, die 16Mb der TC64-REU lassen sich in wenigen Sekunden auf SD speichern oder wieder laden. Das TC64 ist hier schneller Einsatzbereit als meine RAMLink. Da kommt ja erst RL-Init zum Einsatz, danach muss ich die Partitionen von der SD wieder unter GEOS mit GeoDOS zurücksichern. MCOPY funzt ja leider nicht mit dem SD2IEC.

    Ich hab nie erwartet das die internen Laufwerke schneller sind wie ein SD2IEC oder die RAMLink. Da hab ich schon so viel von der Technik verstanden um zu wissen warum das so ist. Daher ja auch mein Tipp ein SD2IEC dazuzunehmen. Dann deckt man beide Anwendungsfälle ab (wenn es um spezielle 1541-Disketten geht).

    Und wieso soll ich einen "C64" in einen C64 stecken?

    VGA-Bildausgabe... das Bild auf meinem HP-Monitor ist *GEIL*. Hab in letzter Zeit am C64 auch einige Konverter getestet. Aber alles Composite mit den verschiedensten Ergebnissen. Ohne S-Video an den Konvertern bleibt nur Composite und dann lieber SCART als Konverter auf VGA/HDMI. Der C64 hat also weiterhin den Dyon-TV wegen der vielen Anschlussmöglichkeiten. Bis auf das Dimming ist das Teil für die 80+€ super für meinen Zweck des "ab&zu mal testen"-Einsatz.

    Ist bei mir auch so.

    Nach dem Einschalteten nur ein schwarzer Bildschirm.
    Muss zuerst ein Reset auslösen, dann startet die SCPU korrekt.

    Ich merke das schon wenn die TurboLED beim einschalten nicht leuchtet. Wenn die AUS bleibt schalte ich gleich wieder aus und ein... dann gehts meistens.

    Hoffe sie lebt noch lange, Ersatz gibt es ja leider nicht.

    Genau... das TC64 ist kein Ersatz... aber nettes neues Spielzeug das keine alte Hardware erfordert und sich zum Teil trotzdem so verhält... die langen Wartezeiten wenn man von der 1541 ohne Jiffy Programme lädt...

    So, nu aber genug Off-Topic. Es ging ja um einen Vergleich SuperCPU vs. TC64. Ich überleg mir mal ein kleines Testprogramm was Text-, Grafik- und I/O-Routinen verwendet um einen anderen Vergleich zu machen. Unter GEOS geht es ja meistens um die Grafikroutinen um etwas auf den Bildschirm zu bringen. Der bisherige Test ist ja eher ein Test der I/O-Routinen.

    Und was hat das ganze Zeugs jetzt noch mit dem C64 zu tun? GEOS etwa?

    Wo steht denn das man nur mit Originaler Hardware Spaß haben darf? ;)
    Beim einschalten meines C64 mit der SuperCPU muss ich die Kiste schon 2-3x aus/einschalten damit die SuperCPU hochfährt. Das Teil macht irgendwann die Grätsche... und dann? Den DIMM aus der RAMCard musste ich schon tauschen... eine 1541 ist schon halb-tot, die FD2000 konnte ich gerade nochmal so reparieren. Meine SmartMouse läuft auch nur noch auf einem Bein... Muss man denn alles bis zum Totalausfall nutzen? Selbst wenn man es reparieren könnte...
    Ich hab die letzten Monate den C64 auch nur zum testen eingeschaltet, ansonsten lief die Entwicklung von MP3 ausschließlich unter VICE. Wenn ich so Alternativen nicht hätte nutzen dürfen weil das ja nichts mehr mit dem C64 zu tun hat wäre MP3 noch auf dem Stand von 2003.
    Das Cham64 ist für mich eine Entwicklungs- und Testumgebung, mehr nicht. Und es nimmt weniger Platz weg...
    Die UltimateII+ liegt seit einer Woche in Frankfurt bei der Post?!? Soll ich die wieder zurückschicken nur weil das keine echte 1541 ist?

    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...

    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 :thumbsup: 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) :D 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.

    Hier noch ein Nachtrag aus der Konversation mit Bitte melde dich an, um diesen Link zu sehen.

    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.

    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...

    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.

    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.

    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.

    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
    TeilBitte melde dich an, um diesen Link zu sehen.: 104s
    TeilBitte melde dich an, um diesen Link zu sehen.: 2.559s

    Chameleon-Turbo/16MbREU ohne MoveData, RAM81+CREU-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 76s
    TeilBitte melde dich an, um diesen Link zu sehen.: 1.821s

    Bei TeilBitte melde dich an, um diesen Link zu sehen. ergibt sich damit ein Faktor von 6,7x. Beim TeilBitte melde dich an, um diesen Link zu sehen. mit dem hochgerechneten Laufzeit am C64 ebenfalls 6,7x.

    :thnks: an Bitte melde dich an, um diesen Link zu sehen. für den Hinweis!

    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. TeilBitte melde dich an, um diesen Link zu sehen. ist der Kernal, TeilBitte melde dich an, um diesen Link zu sehen. sind Programme und Treiber. TeilBitte melde dich an, um diesen Link zu sehen. endet mit 67.403 erzeugten Assembler-Befehlen und 270.919Bytes.

    TeilBitte melde dich an, um diesen Link zu sehen. 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 TeilBitte melde dich an, um diesen Link zu sehen. nimmt:
    PlatzBitte melde dich an, um diesen Link zu sehen.: VICE (allerdings läuft hier die Uhr schneller) - Faktor 24x
    PlatzBitte melde dich an, um diesen Link zu sehen.: SuperCPU+RAMCard - Faktor 12x
    PlatzBitte melde dich an, um diesen Link zu sehen.: Chameleon64+REU - Faktor 5x
    PlatzBitte melde dich an, um diesen Link zu sehen.: C64/REU - Faktor 1x

    Bei TeilBitte melde dich an, um diesen Link zu sehen. 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 TeilBitte melde dich an, um diesen Link zu sehen. 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 :D . 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. :Peace


    C64/REU, RAM81+RAM81
    TeilBitte melde dich an, um diesen Link zu sehen.: 516s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet- (gem. VICE ca. 12.240s)


    VICE/Warp (bis zu 2600%)/REU, RAM81+CREU-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 21s
    TeilBitte melde dich an, um diesen Link zu sehen.: 503s (VICE zeigt 3h24m an wenn der C64 mit 1MHz laufen würde)


    Chameleon-Turbo/16MbREU, RAM81+CREU-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 104s
    TeilBitte melde dich an, um diesen Link zu sehen.: 2.559s


    Chameleon-1MHz/16MbREU, RAM81+CREU-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 522s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestst- (Hochgerechnet etwa 12.850sek = 3h34m)


    SuperCPU-10MHz/REU, RAM81+RL-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 47s
    TeilBitte melde dich an, um diesen Link zu sehen.: 1.326s


    SuperCPU-1MHz/REU, RAM81+RL-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 757s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet-


    SuperCPU-1MHz/REU, RAM81+RAM-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 682s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet- (nicht genügend REU-Speicher)


    SuperCPU-10MHz/RAMCard, RAM81+SRAM-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 43s
    TeilBitte melde dich an, um diesen Link zu sehen.: 1.092s


    SuperCPU-1MHz/RAMCard, RAM81+SRAM-Native
    TeilBitte melde dich an, um diesen Link zu sehen.: 682s
    TeilBitte melde dich an, um diesen Link zu sehen.: -nicht getestet-