Hello, Guest the thread was called8.4k times and contains 95 replays

last post from Unseen at the

C64er mit 2MHz

    ja, schon passiert aber um das mal zu zietieren ....

    Quote from cbmhardware

    So etwas wird heute nur noch ein "proof of concept" bleiben.

    wenn irgendeine Turbo-Karte eine größere Verbreitung und auch Anwendungen hatte, dann wird es wohl die SuperCPU gewesen sein. Alles andere mehr oder weniger Bastelprojekte.


    Und genau unter diesem Aspekt ist auch mein Ansinnen (ja ich hab LOKI geschaut :)) zu verstehen.

    Also gibt es noch eine weitere Bastelanleitung ausser den beiden bisher genannten (c't und 64er)?

    Der kompatibelste Ansatz ist entweder FPGA oder eben der oben verlinkte 6510 Emulator, denn mit Beiden kann man auch die illegal op-codes des 6510 abbilden und somit müsste eigentlich alles laufen.


    Natürlich wird es Programme geben, die dann nicht mehr ihren Zweck erfüllen, z.b. stehende bunte Streifen auf den Bildschirmrahmen zu zaubern und dabei noch ein Liedchen abzuspielen oder Ähnliches, da dort das timing teils befehlsgenau in Assembler ausgefuxt wurde und wenn die CPU plötzlich zigmal so schnell ist, ausser bei Zugriffen auf die Hardware, dann stimmt das Timing natürlich nicht mehr...


    Die Frage ist allerdings tatsächlich, ob und was das heute noch bringen soll, wo doch 99,99% der Software für den C64 bereits geschrieben ist und eben nix von einer schnelleren CPU weiß oder diese nutzen könnte.


    Und wer heute noch mit dem C64 irgendwelche mathematischen Formeln berechnet oder andere rechenintensive Dinge macht, der hat aber tief und fest geschlafen die letzten 35 Jahre...


    Und ob das "Wow" eines 4x so schnell gezeichneten Apfelmännchens mehrere Hundert EUR oder gar über 1000 EUR für eine SCPU wert ist, das sei mal wirklich dahingestellt (vor Allem, wenn man möglicherweise den Algo selbst noch tunen könnte, was meist mehr bringt...)


    Der Reiz liegt doch gerade in den begrenzten und wohldefinierten, überschaubaren Ressourcen, quasi zu zeigen, was damit möglich ist. Und sei es durch verteiltes Rechnen im IEC-Bus-"netz", z.b. 2 Floppies dekodieren gemeinsam einen MP3-Stream direkt runter von der jeweils eingelegten Disk und der C64 setzt den dann zusammen und gibt ihn über die beiden PWMs der CIAs aus, um einfach mal ein konkretes Beispiel zu nennen ;-)


    Sowas klingt erstmal verrückt und von den Ressourcen her fast unmöglich, aber genau das sind so Herausforderungen, denen sich manch einer gerne stellt (im Vorruhestand, Rente oder Bore-Out...)


    Ich hatte das ct-Projekt damals auf dem Schirm, aber weder Zeit noch Geld, es je zu realisieren und war insofern interessiert daran, hatte auch vor einiger Zeit C128Egretz Seite im WWW darüber schon gefunden, aber dachte, das wäre auch schon im Zustand "gestorben", bis eben gestern er dann die Auktion hier im Forum ankündigte...


    Asklia und knusis arbeiten ja schon seit einigen Jahren an dem zweiten ct-Projekt für den C64, einer damals von Asklia erdachten und beschriebenen Möglichkeit, die CP/M Karte auf 8 MHz zu tunen und mehr des 64K RAM fürs CP/M nutzbar zu machen. Daher wusste ich auch, dass Seitens ct KEINE Unterstützung mehr möglich ist, da man dort keine Hardware mehr hat und wohl auch keine Images der letztlich lauffähigen Roms resp. Programme dazu...


    Aber die ct wird sich sicherlich nicht einer Veröffentlichung der von C128Egretz aufgetriebenen fehlerbereinigten ROMs und GAL-Maps verwehren, da bin ich mir zu 100% sicher und kann gerne den Kontakt dorthin übernehmen.


    Und die HW ist ja dank der abgedruckten Schaltpläne soweit nachvollziehbar, dass die Schaltpläne damals in fast allen Zeitschriften immer kleine Fehler enthielten, die -es gab ja kein Internet, nur Telefon und Post- teils erst einige Ausgaben später korrigiert wurden, das war mehr oder minder normal, das kam überall vor, auch im wissenschaftlichen Bereich!


    Aber die von C128Egretz genannten Dinge sind ja relativ leicht zu finden und zu beheben...


    Da ich aber ungern das Rad zweimal erfinde, bin ich immer noch auf der Suche nach einer Herausforderung, die hier nicht schon zig Andere in der Pipeline haben und die mir persönlich aber auch zusagen müsste, also mehr in Richtung Musikelektronik z.b. geht als in Richtung Grafik und mehr in Richtung Embedded Systems als in reine SW.

    Quote from Cpt.Hardy

    . Alles andere mehr oder weniger Bastelprojekte.

    Damit tust Du der Roßmöller-Entwicklung aber sehr unrecht!


    Die war meines Erachtens nach mindestens auf einer Stufe mit CMD, aber Roßmöller & Co. machten damals zu viele Fehler im Marketing und Vertrieb und denen ging letztlich das Geld aus, auch weil hierzulande viele dem C64 schon recht früh den Rücken zukehrten und zum Amiga500 oder ST wechselten oder gleich zum PC, was sich ja langfristig als die nachhaltigste Option auch rausstellte (ob gut oder nicht sei dahingestellt...)


    Die SCPU wurde nur durch das eine, erste Spiel so "berühmt", weil ansonsten eben schlicht die Anwendungen fehlten, s.o.

    Quote from Ruudi

    Damit tust Du der Roßmöller-Entwicklung aber sehr unrecht!


    Die war meines Erachtens nach mindestens auf einer Stufe mit CMD, aber Roßmöller & Co. machten damals zu viele Fehler im Marketing und Vertrieb und denen ging letztlich das Geld aus, auch weil hierzulande viele dem C64 schon recht früh den Rücken zukehrten und zum Amiga500 oder ST wechselten oder gleich zum PC

    Roßmöller = Friemelkram, weil die Turbokarten m.W. nicht out of the box funktionieren. CMD = anstecken und loslegen.

    Quote from -trb-

    Roßmöller = Friemelkram, weil die Turbokarten m.W. nicht out of the box funktionieren. CMD = anstecken und loslegen.

    Oh, das war m.W. mit der SCPU 1.0 sogar noch schlimmer, die musste zurückgesandt werden zur Modifikation!


    Und wenn ich mir so überlege, welches technische Produkt jenseits von Toaster und Eieruhr eigentlich in den letzten 30 Jahren dann KEIN "Friemelkram" wäre, Software schon mal ganz aussen vor, dann bleiben da nicht viele übrig, insbesondere keine Fahrzeuge aus dt. Fertigung...

    Der Gedanke aus C64er mit 2MHz ist mir schon mal gekommen, leider fehlt mir ein wenig der Background um so etwas zu realisieren.


    Abgesehen vom Turbo, den halte ich auf für völlig überbewertet, könnte man damit wirklich schöne Dinge machen, als erstes natürlich der

    SD-Slot als zyklengenaue 1541 emulieren, auch eine riesengrosse REU könnte man damit realisieren.


    Dann vielleicht noch Kernalumschaltung, diverse Module ablegen (Action Replay, FC3 oder ähnliches), und da gibt es bestimmt noch 1000

    Möglichkeiten die mir so schnell nicht einfallen.


    Mfg Jood

    Quote from Ruudi

    Die SCPU wurde nur durch das eine, erste Spiel so "berühmt", weil ansonsten eben schlicht die Anwendungen fehlten, s.o.

    Ja gut, das Du in dem Punkt nicht auf dem laufen bist, kann nicht die Schuld der exzellenten, ausgereiften Hardware von CMD sein.

    Hier hat jemand versucht, einen BBC Micro Emulator per JIT möglichst schnell zu machen:

    https://scarybeastsecurity.blo…ocking-6502-to-15ghz.html


    In BASIC Benchmarks werden dann Werte gemessen, die den emulierten 6502 irgendwo bei 12-15 GHz vermuten

    (auf einem Core i9-9980XE mit 4,5 GHz Singlecore-Turboboost)



    Mit I/O ist das natürlich deutlich langsamer, trotzdem sind die meisten Spiele dann unspielbar schnell.

    Aber vielleicht macht 3D Rendering (sowas wie GigaCAD beim C64) damit ja mehr Spass...

    Na ja, wenn der emulierte Prozessor angeblich schneller taktet, als der Host physikalisch und das als SingleCore, dann stimmt da was absolut nicht!

    Vermutlich läuft da in der Emulation eine Art PreCompiler, der schlicht die Sinnlosigkeit einer "Benchmark" Schleife wie


    20 FOR N=1 TO 10000:NEXT N


    erkannt hat und N gleich auf 10001 setzt und weitermacht...


    Könnte man rausfinden, indem man N innerhalb eines binären Zahlenraums ( int, long int etc) verändert und

    dann schaut, ob sich die Ausführungszeiten überhaupt unterscheiden und wenn ja, ob sie linear skalieren...


    Innerhalb eines Zahlenraums deshalb, weil davon die Übersetzung und Optimierung abhängen könnte...

    Quote from Ruudi

    Na ja, wenn der emulierte Prozessor angeblich schneller taktet, als der Host physikalisch und das als SingleCore, dann stimmt da was absolut nicht!

    Warum? Der 6502 braucht für jeden Befehl mehrere Takte. Ein moderner OOO-Superscalar-Prozessor kann oft mehrere Befehle pro Takt ausführen (CPI<1 bzw. IPC>1).

    Wenn man also jeden 6502 Befehl auf einen x64 Befehl ummappen kann, dann kann der "virtuelle" 6502 schon einen höheren Takt erreichen, als der Hostprozessor.

    (z.B. statt CPI 2,5 ein CPI von 0.75 und schon hat man einen Faktor 3,333)


    Ob der JIT dead code elimination hat, könnte man auf github mal nachsehen. Sowas macht aber einen JIT deutlich komplizierter und die Übersetzung deutlich langsamer - was man bei JIT ja gerade nicht gebrauchen kann.

    Nöh, die Flash8 war gut gemeint, aber schlecht gemacht. Das hatte nichts mit Fehlern im Marketing/Vertrieb zu tun, sondern primär mit Fehlern des Produkts:

    Allein schon die Tatsache, dass nach einem Reset der Speicher vollgemüllt wurde und man nicht weiterprogrammieren konnte, weil das Programm weg war, war zuviel. Das noch kombiniert mit den häufigen, willkürlichen Abstürzen aufgrund timing-Problemen (trotz mehrfachen Versuchs, dass mittels dem Potentiometer zu korrigieren), war für mich der Grund, diese Karte - mit Hinweis auf die o.g. Problematiken - weiter zuverkaufen.


    Als ich mir kurz darauf stattdessen die SCPU zulegte, war das quasi wie eine Offenbarung...

    Quote from RexRetro

    Wenn man also jeden 6502 Befehl auf einen x64 Befehl ummappen kann, dann kann der "virtuelle" 6502 schon einen höheren Takt erreichen, als der Hostprozessor.

    Genau das würde ich bezweifeln, denn dazu sind die Architekturen viel zu unterschiedlich und auf dem Host läuft ja auch ein Betriebssystem, d.h. auf Register-Ebene optimieren ist da eher nicht drin und die größere Wortbreite bringt auch manchen Overhead wieder mit sich.


    Zudem wäre so ein 1:1 Crosscompiler ein wahres Wunderwerk der Programmierung und angeblich ist es ja eher ne Art Interpreter, was nochmals overhead einbringt. Und die Schleifenlänge ist beim 6502 Code so klein, da bekommt der moderne Prozessor seine Pipelines vermutlich auch nicht so effizient gefüllt...


    Vielleicht findet sich hier ja Jemand, der die interne Realisierung kennt und das klären kann?

    Quote from rayden

    dass nach einem Reset der Speicher vollgemüllt wurde und man nicht weiterprogrammieren konnte, weil das Programm weg war, war zuviel

    Das ist bei jedem PC und vielen anderen Systemen auch so, die dynamischen Speicher erst nach einiger Zeit refreshen, wenn der Chipsatz initialisiert ist und alles stabil, kenne einige Architekturen, die den Speicher sogar absichtlich mit einem Initialwert beschreiben, um die Sicherheit und Stabilität des Systems zu erhöhen.


    Der C64 macht ja auch ein "new" nach dem Einschalten/Reset, um Probleme mit korrumpierten Speicher zu umgehen, dass man dieses "new" wiederum rückgängig machen kann, um zu retten, was noch da ist, ist ne andere Sache, aber als "Normalfall" sehe ich das nicht und als KO-Kriterium schon gleich gar nicht...


    Also das sehe ich nicht als Argument an, man speichert doch vor jedem Start sein Programm, spätestens, wenn man das erste Mal was verloren hat...



    Das mit dem Poti war natürlich nicht sehr professionell, aber dafür wurden ja dann auch zig Abhilfen entwickelt, eine erste und einfache wäre schon mal gewesen, ein 10-Gang Präzisions-Poti zu verbauen, das temperaturkompensiert ist.


    und HOLY MOSES/ROLE : Wie sollte ich bei was am Laufenden sein, das ich nicht habe und für >1500 EUR, die aktuell dafür aufgerufen werden mir auch sicher NICHT zulegen werde, weil eben eine Beschleunigung für Spiele per se selten sinnvoll ist (ok, die Berechnung der "Grafik" am Ende jeder Runde bei Kaiser, da drehe ich im Emulator schon gern mal auf max speed) und andere Anwendungen heute ja nun überhaupt keinen Sinn mehr machen und neue Spiele auf VICII/SID ja auch nicht wirklich...


    Ich für mich habe meine Schuhe, wenn ich draus gewachsen war immer abgelegt und neue angezogen, nicht aufgepumpt und angestückelt, aber die ganz alten Lauflernschuhe, die schaue ich mir immer noch gern mal an! Und in der Rolle sehe ich den C64 und noch mehr den VC20 bei mir.

    Quote from Ruudi

    Genau das würde ich bezweifeln, denn dazu sind die Architekturen viel zu unterschiedlich und auf dem Host läuft ja auch ein Betriebssystem, d.h. auf Register-Ebene optimieren ist da eher nicht drin und die größere Wortbreite bringt auch manchen Overhead wieder mit sich.

    1. Der 6502 hat nicht viele Befehle. x64 hat inzwischen über 1000. Da sollte es oft was "Passendes" geben. Und wenn es ab und zu mal 2-3 sind, wird das trotzdem wett gemacht.
    2. Die besagte Host-CPU hat echt viele Cores (18 physische, bzw. 36 mit HT) und nicht auf allen wird dauernd das OS dazwischenfunken. c't hatte mal einen Artikel, wie man unter Windows einen Core komplett von System-Interrupts frei bekommt, um Instruktions-Latenzmessungen und sonstiges Profiling zu machen.
    3. Die größere Wortbreite stört nicht, da x86/x64 weiterhin mit den Registern auch Byte (und Word und Long) Operationen ausführen kann. Ist ja kein reine 32 oder 64 Bit (RISC) ISA, wo man bei jeder Integer Op gleich mal 24 oder 56 Bit wegmaskieren müsste.
    Quote from Ruudi

    Zudem wäre so ein 1:1 Crosscompiler ein wahres Wunderwerk der Programmierung und angeblich ist es ja eher ne Art Interpreter, was nochmals overhead einbringt.

    Es ist eben kein Interpreter, sondern ein JIT. Natürlich muss der konservativ und kleinschrittig arbeiten, wegen selbstmodifizierendem Code und ähnlicher Scherze.

    Quote from Ruudi

    Und die Schleifenlänge ist beim 6502 Code so klein, da bekommt der moderne Prozessor seine Pipelines vermutlich auch nicht so effizient gefüllt...

    Gerade für kleine, enge Schleifen wird doch bei jedem modernen OOO Prozessor enormer Aufwand getrieben, damit die Pipeline eben nicht dauernd stalled. Mehrstufige Branchprediction, Branch-Target-Caches, Pipeline-Bypasses, Registerrenaming/Schattenregister Instruction Decoder Caches für Schleifen. Micro-Op Fusion macht evtl. sogar den realen Befehlsstrom noch kürzer, indem decrement-compare-branch Befehlsfolgen zusammengefasst werden, zu sowas ähnlichem wie DJNZ bei Z80.


    Quote from Ruudi

    Vielleicht findet sich hier ja Jemand, der die interne Realisierung kennt und das klären kann?

    Hier passieren wohl die spannensten Sachen:

    https://github.com/scarybeasts…lob/master/jit_compiler.c

    https://github.com/scarybeasts…ob/master/jit_optimizer.c


    Da ich weder fit bzgl. 6502- noch x64-Maschinencode bin, will ich mir sowas nicht antun. Aber vielleicht mag ja jemand genauer reinschauen.