Hello, Guest the thread was called1.3k times and contains 36 replays

last post from 0xdeadbeef at the

Der MEGA65-Laber-Stammtisch

  • Ich muss mal blöd fragen, weil ich Freezer eigentlich nur so kenne, dass sie den aktuellen Zustand abspeichern und dann wiederherstellen. Ich habe mich damit nie näher beschäftigt. Ist das nicht das, an "was die CPU rankommt"? Was gibt es dann darüber hinaus noch zu speichern?

    Als Emulator kann man halt auch den Zustand der Hardware mit abspeichern. Gegen normale Freezer gibts ja Schutzmechanismen, aber wenn quasi die Hardware gefreezed wird, dann gibts keinen Schutz. z.B. würde dann u.U. auch die aktuell Rasterzeile, oder Floppydrehung mitgespeichert und solche Sachen, worauf die CPU halt keinen Einfluss hat, ein Emulator aber schon.

    Danke! Das eine ist also "nur der Computer an sich" und das andere ist "das komplette System", das gleichsam "schockgefroren" wird?

  • Mir kam grad so ein Gedanke... aber ich weiss nicht ob ich dazu 'nen eigenen Thread eroeffnen soll.


    Was, wenn Commodore den Amiga nie zugekauft haette - was haette Commodore dann selbst entwickelt? Eventuell auch den C65, als Nachfolger des C64 und C128 und vom Stellenwert her sowas wie ein Amiga 500 light? Oder haetten sie einen 16-bit-Rechner entwickelt, und den C65 trotzdem hinterhergeworfen als guenstige Alternative? Waere der 16-bit-Rechner vielleicht eine Art "C65 on steroids" geworden, also etwas was grob in Richtung A500 geht, aber trotzdem mit C64-Modus und mit PETSCII-Charset und sowas? Eine Art C130?

  • Was, wenn Commodore den Amiga nie zugekauft haette - was haette Commodore dann selbst entwickelt?

    Falscher Thread? Wie hätte Commodore Marktführer bleiben können?

    ah ok, werd ich mich mal reinlesen, danke. hatte jetzt nicht erwartet dass es dort u.a. auch um die eigenentwicklungen geht, sofern sie keinen amiga gehabt haetten

  • Mir kam grad so ein Gedanke... aber ich weiss nicht ob ich dazu 'nen eigenen Thread eroeffnen soll.


    Was, wenn Commodore den Amiga nie zugekauft haette - was haette Commodore dann selbst entwickelt?

    AFAIR war eine Z8000 basierte Unix Kiste (Coherent) in der Mache. Mit homebrew (S/W-)Blitter und MMU. Die Unix-Fetischisten unter den Entwicklern haben sich dann auf Amiga(OS) gestürzt und 68030+PMMU Turbokarte, A2500UX und 3000UX mit AMIX vorangetrieben.


    Ich glaube der Z8000 hatte nicht unbedingt die Fans unter den Entwicklern und war nur, weil das Management mit Motorola noch aus MOS Zeiten Zoff hatte (und daher den 68000er meiden wollte).


    Im Homecomputer-Segment hatte man sich ja 84-85 mit TEDs und C128(D) mit Z80 und CP/M und dem Portable etwas "verrannt". An einen "C65" war da noch nicht ansatzweise gedacht worden. Wie ich schon anderswo schrieb, waren die CPU und dann der VIC-III ja eher ein "pet project" eines Chip-Designers in der Semiconductor Group/MOS und lief ewig lange unter dem Radar des (oberen) Managements.


    Erst als die Ende der 80er merkten, dass Nintendo und Sega ihnen mit Spieleconsolen den C64 Markt kaputtmachen und der Amiga als low-cost Konsole ungeeignet ist, wurde der "C65" als richtiges Projekt angestossen. IMHO viel zu spät, viel zu halbherzig, viel zu plan- und ziellos um noch rechtzeitig mit interessantem Feature-Set und im anvisierten Preissegment Erfolg zu haben.


    Im Grunde hat es wie das defizitäre PC-Geschäft nur Ressourcen vom Amiga abgezogen, als man den massiv hätte vorwärts pushen müssen (ECS und AGA hätten 1.5-2 Jahre früher kommen müssen, der A3000 hätte gleich mit dem 68040 kommen können, SUN hätte den A3000UX vertreiben können, Epson hätte Amiga in Japan pushen wollen... alles vertane Chancen).

    Oder Sachen wie AA3000+ mit TI DSP (hat dann Apple 'geklaut' und zum AV-Mac gemacht), 16-Bit-PAULA, schnelles HD-Floppy, AGA+ und AAA und Hombre... Commodore hatte viel zu viele Baustellen, wo am Schluß nicht genug Ressourcen für die rechtzeitige Produktisierung da waren.

  • Es gibt register, die nicht lesbar sind oder der innere Zustand eines Chips (latches, flip Flops,....) usw. ein Freezer kann sowas nicht speichern, der Emulator via Snapshot aber schon. Das wäre quasi ein 1:1 Abbild des Computers.

    Das ist nun die Frage, ob der Freezer beim MEGA65 überhaupt die technischen Möglichkeiten hat, das wirklich gesamte System einzusehen und einzufrieren oder ob er nicht immer auch selbst Teil des Gesamtsystems ist?

  • Ich muss mal blöd fragen, weil ich Freezer eigentlich nur so kenne, dass sie den aktuellen Zustand abspeichern und dann wiederherstellen. Ich habe mich damit nie näher beschäftigt. Ist das nicht das, an "was die CPU rankommt"? Was gibt es dann darüber hinaus noch zu speichern?

    Freezer lösen einen NMI der CPU aus und sichern dann das RAM, CPU-Register usw. Aber weil das ja die gleiche CPU macht, die man gerade unterbrochen hat, wird dazu Stack gebraucht usw. Dazu kommt, das man nicht alle Peripherieregister (konsistent) auslesen kann usw. Es gibt da diverse kleinere Probleme, die das erfolgreiche Freezen von bestimmten Spielen und Demos schwierig bis unmöglich machen.

    Gideon hat dazu einen interessanten Artikel geschrieben, auf den ich alle paar Monate mal wieder verweise:

    https://codebase64.org/lib/exe…fely_freezing_the_c64.pdf


    Ansonsten gibt es halt auch noch das große Problem, daß der gesamte Zustand der 1541 nicht eingefroren wird. Was gerade an Code ins Floppy-RAM geladen wurde oder welchen Zustand der 6502 in der Floppy hat, bleibt dem Freezer völlig verborgen. Auf einem richtigen C64 ist das ein praktisch unlösbares Problem und macht das erfolgreiche Freezen von Spielen mit eigenen Laderoutinen unmöglich. Ein Emulator oder auch eine FPGA-Nachbildung hätte dagegen alle notwendigen Informationen für die Speicherung und Wiederherstellung einen perfekten Systemzustand. Leider hat aber bisher anscheinend noch niemand versucht, das in einer FPGA-Implementierung umzusetzen.


    Last but not least gibt es noch das Problem mit dem Einfrieren von Spielen, die selber von einem Modul laufen. Da Freezer ja selber immer als Expansionsportmodule implementiert sind, kümmern sie sich darum, daß RAM unter ihrem ROM zu sichern usw. Aber ein bereits aus einem anderen ROM laufendes Programm ist schätzungsweise kein Anwendungsfall, den ein echter Freezer berücksichtigen muß oder könnte. Bei einem echten C64 ist das zum einen kein sonderlich realistisch Szenario und vermutlich auch nicht beherrschbar, aber ein Emulator oder eine FPGA Nachbildung kann sich natürlich auch hier über die Begrenzungen eines echten Freezers hinwegsetzen. Bei Emulatoren ist ein Savestate eines EF-Spiels kein Problem. Für FGPA-Nachbildungen ist das IMHO ebenfalls nie umgesetzt worden.

  • Es gibt register, die nicht lesbar sind oder der innere Zustand eines Chips (latches, flip Flops,....) usw. ein Freezer kann sowas nicht speichern, der Emulator via Snapshot aber schon. Das wäre quasi ein 1:1 Abbild des Computers.

    Das ist nun die Frage, ob der Freezer beim MEGA65 überhaupt die technischen Möglichkeiten hat, das wirklich gesamte System einzusehen und einzufrieren oder ob er nicht immer auch selbst Teil des Gesamtsystems ist?

    Ich denke beim MEGA ist das anders.

    Der 'Freezer' läuft wohl in ein Hypervisor Mode, da wäre sowas wohl möglich.

    Genaueres könnte natürlich Paul sagen ;-)

    Ist wie mit Virtuelle Maschinen: der Hypervisor steuert die einzelne Maschinen. Kann sie jederzeit stoppen, sichern und gesicherte Maschinen wieder starten (als wenn nix gewesen wär).

    Die Maschine selbst kriegt das eigentlich nicht mit.

    Aber wie gesagt: Paul fragen ;)

  • Ich frag jetzt mal blöd - beim einschalten ist das (fertige) mega65 Basic aktiv? Mit Go64 wechselt man zum C64? Und als Netzteil nimmt man ein Handyladegerät?

    Ja, Ja und Nein, es ist ein Hohlstecker 12V/2A

  • Hallo Namensvetter !


    Der MEGA65 ist im Prinzip immer noch in erster Linie ein C65. Wenn du eines der Original ROMs des C65 verwendest, z.B. 911001 oder 911210, wird die wenige Software die es für den C65 gibt darauf laufen. (oder nicht, je nachdem für welche ROM version die Software geschrieben wurde ;-) ). Eines der Hauptprobleme war ja, dass der C65 in seinem Prototypstatus selbst untereinander nicht kompatibel war, da die C65 Prototypen in verschiedenen Revisionsstufen einfach "verramscht" wurden.


    Eines der ersten Dinge die damals von uns während der Designphase hinzugefügt wurden, war z.B. der VIC-IV, wird dieser aber nicht aktiviert, ist der MEGA65 wie ein C65 mit VIC-II und VIC-III.

    Es kann also nicht sein, dass es einen MEGA65 ohne den VIC-IV gab. auch auf der Amiga Convention in Neuss (30 Jahre Amiga), wo damals einer der ersten MEGA65 Prototypen vorgestellt wurde, damals noch mit Nexys4DDR (Nexys A7) FPGA board, gab es schon den VIC-IV.
    Der Blitter der z.B. für den C65 gedacht war, war mit den 3.5MHz so brechend langsam, dass er eigentlich sinnlos war daher wollten wir einen erweiterten VIC Chip für den MEGA65 haben, welchen Paul (Gardner-Stephen) auch implementiert hat.


    Also grob zusammengefasst: Im Herz ist der MEGA65 ein C65 mit verbesserter Kompatibilität zum C64, einem extra VIC Chip und einem überarbeiteten Kernal ROM

    Gerne stehe ich, oder auch andere Teammitglieder für ein Interview zur Verfügung, schicke mir am besten eine PN.

    Viele Grüße,


    Anton

  • Danke für die prompte Antwort und die Zusatz-Infos. Wegen dem Interview melde ich mich noch per pm. LG Anton

  • Hallo Leute,


    der Freezer des MEGA65s ist etwas anders als einen C64 Freezer und dadurch ist deutlich kraftvoller. Das freezen und unfreezen is im Hypervisor implementiert. Auch einige die Chips haben Unterstützung des Hypervisor Modus, dass bedeutet, dass die internalen Werte vom Hypervisor ausgelesen kann, die normalerweise unmöglich wäre. Zum Beispiel, die CIAs pausen ihren Timers im Hypervisor Modus und erlauben die internalen Timer Werte ausgelesen, zzg. vom Hypervisor geschrieben zu werden.


    Auch weil der Hypervisor sein eigenen Speicherplatz besitzt, erlaubt jeder letzten Byte gespeichert zu werden.


    Bei Modulen, wenn der Modul einfach als Speicherplatz Eimer benutzt wird, könnte der Freezer Spiele, die davon geladen wurden, freezen lassen. Aber weil der Freezer keinen Brücke zwischen die digitalen und echten Welten wie ein Transporter Muster Puffer vom Startrek einschließt, kann der Freezer keine Modulhardware selbst auf den SD Karte legen lassen.


    Gerne. Schick mir einfach eine Email an paul@m-e-g-a.org und wir könnten es arrangieren.

    LG,
    Paul

  • Das freezen und unfreezen is im Hypervisor implementiert. Auch einige die Chips haben Unterstützung des Hypervisor Modus, dass bedeutet, dass die internalen Werte vom Hypervisor ausgelesen kann, die normalerweise unmöglich wäre. Zum Beispiel, die CIAs pausen ihren Timers im Hypervisor Modus und erlauben die internalen Timer Werte ausgelesen, zzg. vom Hypervisor geschrieben zu werden.

    Das klingt schon mal sehr vielversprechend. Es wäre toll, wenn es mal einen Artikel gäbe, der die Unterschiedes des Mega65-Freezers zu einem herkömmlichen Freezer beleuchtet. Speziell auch, was die 1541-Emulation angeht, falls der Freezer des Mega65 da erweiterte Features hat.

    Bei Modulen, wenn der Modul einfach als Speicherplatz Eimer benutzt wird, könnte der Freezer Spiele, die davon geladen wurden, freezen lassen. Aber weil der Freezer keinen Brücke zwischen die digitalen und echten Welten wie ein Transporter Muster Puffer vom Startrek einschließt, kann der Freezer keine Modulhardware selbst auf den SD Karte legen lassen.

    Ich rede von emulierten Modulen, also von CRT-Dateien, deren Modultyp der Mega65 ausliest und nachbildet. Um solche Module in den Systemzustand einzuschließen, ist keine Magie notwendig, aber der Freezer müßte halt so implementiert sein, daß er den Zustand des emulierten Moduls ebenfalls abspeichert (aktive Bank usw.).