Hallo Besucher, der Thread wurde 5,3k mal aufgerufen und enthält 33 Antworten

letzter Beitrag von markusC64 am

Chameleon64v2 vs CMD SuperCPU unter GEOS

    Zitat von Pusti64

    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?

    Zitat von darkvision

    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 würde dem dann verwaisten bzw. verwundeten C64/CMD-Zeugs dann trotzdem noch ein neues zu Hause anbieten ;-)


    Pusti64

    Zitat von darkvision

    Wieso umstecken? Das TC64 funktioniert ja auch im StandAlone-Mode

    Stimmt, dies vergesse ich immer. :(
    Und wieso soll ich einen "C64" in einen C64 stecken? :whistling:



    Zitat von darkvision

    Der C64 mit SCPU wird demnächst wieder eingemottet... Save the Hardware!

    :cry:



    Zitat von darkvision

    Beim einschalten meines C64 mit der SuperCPU muss ich die Kiste schon 2-3x aus/einschalten damit die SuperCPU hochfährt.

    Ist bei mir auch so. ;(


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


    Löse ich das Reset an der RamLink aus, meldet MP3-64 beim ersten Start: "Speichererweiterung defekt (die RamCard der SCPU).
    Löse ich das Reset an der SCPU (langes drücken) aus, klappt alles beim ersten mal und während dem Betrieb gibt es keine weiteren Probleme.


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


    Gruss C=Mac.

    Zitat von C=Mac

    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.


    Zitat von C=Mac

    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.


    Zitat von C=Mac

    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.

    Zitat von darkvision

    Ich überleg mir mal ein kleines Testprogramm was Text-, Grafik- und I/O-Routinen verwendet um einen anderen Vergleich zu machen.

    Wäre auch interessant!



    Beim Vergleich SuperCPU mit RamLink und TC64 mit internen Laufwerken ist SuperCPU wesentlich schneller!! (normale Desktop arbeiten bzw. Programme starten) Das TC64 kommt mir dabei vor, wie ein C64 ohne SuperCPU und ohne JD... ;-)
    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??

    Zitat von OliverW.

    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

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


    Zitat von DarkVision


    Chameleon-1MHz/16MbREU, RAM81+CREU-Native
    Teil#1: 522s
    Teil#2: -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).

    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.

    Zitat von darkvision

    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.

    Kleiner Beitrag von mir:


    Wo man beim C64 zwingend InitForIO und DoneWithIO setzen muss, reicht beim C128 unter Umständen sei, php ...... plp aus.
    Mir ist das zumindest bei Deinem C= und Shift-L Tipp für 128Desktop aufgefallen.


    Pusti64

    Zitat von Pusti64

    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 Bank#1 (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).

    Zitat von darkvision

    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 Bank#1 (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).

    Danke für die Klarstellung ;-)


    Pusti64

    Zitat von darkvision

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

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

    Zitat von darkvision

    Ich hab nie erwartet das die internen Laufwerke schneller sind wie ein SD2IEC oder die RAMLink.

    Stimmt. Gilt für die U2+ bzw. dem U64 jedoch nur eingeschränkt: Wenn man nicht über die Laufwerksemulation geht, sondern über UCI / Ultimate DOS, so geht es rasend schnell. Bei optimaler Programmierung kann man eine ganze 16 MB REU in weniger als 10 Sekunden auf dem USB Stick speichern - gerade mit der neusten Betafirmware ausprobiert. Bei einer älteren Firmware waren es mal 20 Sekunden - die allerdings verifiziert, das der Inhalt auch stimmt.


    Diese rasende Geschewindigkeit bekommt man allerdings so extrem nur hin, wenn man per Ultimate DOS die U2+ bittet, den REU Inhalt zu speichern. Das selbst machen zu wollen (was auch über UCI / Ultimate DOS ginge), würde länger dauern.


    Ach ja: UCI / Ultimate DOS kann auch Teile der REU speichern. Man könnte so also ultraschnell Ramdisks befüllen und wieder abspeichern - wenn man passende Softwareunterstützung hat.


    Edit: REU ist in diesem Posting synonym zu GeoRAM zu lesen. Denn beide teilen sich in der U2, U2+ bzw. dem U64 den selben Speicherbereich. So dass die UCI-Funktionen für beides passen.

    Zitat von OliverW.

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

    Kleines Beispiel: StarWars-Demo.


    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 Laufwerk#8 am IEC-Bus, mein SD2IEC hat ohne Strom angefangen zu blinken weil es noch am IEC-Kabel hing.

    Ich habe gerade die ultraschnell abgespeicherte Dumpdatei meiner REU kontrolliert. Vor dem Speichern hat jene ein GCR-Image von Geos 2.0 beinhaltet (per Burstnibbler gelsen). Nach dem Ausschalten des C128, etwas warten und wieder einschalten konnte Burstnibbler, nachdem ich das 16 MB Image in etwa der selben Zeit wieder eingelesen habe. offenbar fehelrfrei schreiben. Der Anscheinsbeweis ist also erbracht, dass die ultraschnell geschriebenen Daten passen.