Ich habe "Marble Boy" gespielt und eine Cartridge getestet, die jemand fuer mich angefertigt hat...
Der MEGA65-Laber-Stammtisch
- Snoopy
- Thread is Unresolved
-
-
Sam‘s Journey läuft auch, und der IEC Anschluss für z.b. eine 1541 sollte doch funktionieren?
-
Targas Im GO64-Modus sollte der Anschluss funktionieren, aber scheinbar beim C64-Core (noch) nicht (lasse mich da aber gerne korrigieren...). Finde es auch, wie auch ZeHa meint, irgendwie cooler ohne zusätzlichen Core zwischen den Modi hin und her zu wechseln. Daher bin ich wirklich an einer möglichst hohen Kompatibiliät des "hauseigenen" C64-Modus interessiert und hoffe, dass er diesbezüglich noch weiterentwickelt wird. Wenn der Mega 65 dann mal irgendwann bei mir eintrifft...
-
Daher bin ich wirklich an einer möglichst hohen Kompatibiliät des "hauseigenen" C64-Modus interessiert und hoffe, dass er diesbezüglich noch weiterentwickelt wird.
Das wäre auch in der Hinsicht wünschenswert, weil man mit dem C64-Modus des MEGA65 auch auf die erweiterten Features des MEGA65 (z.B. 40 MHz CPU-Geschwindkeit) zugreifen kann, was mit dem C64-Core natürlich nicht geht, weil der "nur" den C64 kennt.
-
Die aktuelle Kompatibilität des im Mega65 integrierten C64 (GO64) ist meines Wissens nach kaum noch zu steigern.
Es gibt zwei wesentliche Unterschiede zur originalen C65.
1. Die ganzen illegalen Opcodes des 6502 kann der 4510 nicht, bzw. die Opcodes sind jetzt mit funktionierenden neuen Befehlen belegt.
Die 4510 CPU ist also nicht 100% kompatibel zur originalen 6502 CPU.
2. Die ganzen zusätzlichen Funktionen/Register im Mega65 (speziell VIC III und VIC IV) sind im C64 Modus sichtbar, und wohl auch nutzbar. Auch das kann zu Problemen führen.
Wenn z.B. C64 Programme Registerbereiche beschreiben, die im VIC II nicht belegt waren, aber im VIC III/IV neue Funktionen beherbergen, dann kann das merkwürdige Effekte zur Folge haben.
Diese beiden mir bekannten Unterschiede lassen sich nicht einfach weg optimieren.
Da macht der portierte MiSTer Core durchaus Sinn, denn die beiden oben gelisteten Unterschiede gibt es schlicht nicht.
Weiss jemand hier, ob es noch etwas im Mega65-C64 gibt das sich weiter optimieren lässt, so das der C64 Modus kompatibler wird?
Du vielleicht Snoopy?
Das würde mich mal interessieren.
-
Daher bin ich wirklich an einer möglichst hohen Kompatibiliät des "hauseigenen" C64-Modus interessiert und hoffe, dass er diesbezüglich noch weiterentwickelt wird.
Das wäre auch in der Hinsicht wünschenswert, weil man mit dem C64-Modus des MEGA65 auch auf die erweiterten Features des MEGA65 (z.B. 40 MHz CPU-Geschwindkeit) zugreifen kann, was mit dem C64-Core natürlich nicht geht, weil der "nur" den C64 kennt.
Nur das genau diese Unterschiede zum C64 genau die sind, die die Inkompatibilität darstellen.
Die neue 4510 CPU und die erweiterten Möglichkeiten des VIC III/IV stellen ziemlich exakt die gesamten Inkompatibilitäten zum originalen C64 dar.
Mehr zusätzliche Features -> mehr Inkompatibilität.
-
Wir brauchen einen Mega Dual Core mit 4510 und 6510 CPU Cores.
-
Die VIC III und IV Features sind doch standardmaessig ausgeblendet, da sollte es also aus meiner Sicht keine Probleme geben.
Vielleicht gibt es aber auch in Zukunft ein paar gefixte Versionen von Spielen, so wie "fuer Easyflash-angepasste Versionen", koennte es ja auch "MEGA65-GO64-angepasste Versionen" geben. Vielleicht ist es ja bei einigen Spielen nur eine Kleinigkeit...
-
Weiss jemand hier, ob es noch etwas im Mega65-C64 gibt das sich weiter optimieren lässt, so das der C64 Modus kompatibler wird?
Das größte Problem beim C64-Modus des C65/MEGA65 sind gar nicht einmal so die fehlenden "illegalen" Opcodes. Die wurden - meines Wissens - gar nicht allzu oft in kommerziellen C64-Spielen verwendet, sondern eine ganz andere Baustelle, der sog. "Read-Modify-Write Instruction Bug", der wohl so einige C64-Programme betrifft, die im C64-Modus nicht (korrekt) laufen.
Ich zititiere hierzu mal aus dem "großen" MEGA65-Handbuch (ab Seite G-4):
QuoteRead-Modify-Write Instruction Bug Compatibility
The 65CE02 processor optimised a group of instructions called the Read-Modify-Write (RMW) instructions. For such instructions, such as INC, that increments the contents of a memory location, the 6502 would read the original value and then write it back unchanged, before writing it back with the new increased value. For most purposes, this did not cause any problems. However, it turned out to be a fast way to acknowledge VIC-II interrupts, because writing the original value back (which the instruction doesn’t need to do) acknowledges the interrupt. This method is faster and uses fewer bytes than any alternative, and so became widely used in C64 software.
The problem came with the C65 with its 65CE02 derived CSG4510 that didn’t do this extra write during the RMW instructions. This made the RMW instructions one cycle faster, which made software run slightly faster. Unfortunately, it also meant that a lot of existing C64 software simply won’t run on a C65, unless the interrupt acknowledgement code in each program is patched to work around this problem. This is the single most common reason why many C64 games and other software titles won’t run on a C65.
Because this problem is so common, the MEGA65’s 45GS02 includes bug compatibility with this commonly used feature of the original 6502. It does this by checking if the target of an RMW instruction is $D019, i.e., the interrupt status register of the VIC-II. If it is, then the 45GS02 performs the dummy write, allowing many C64 software titles to run unmodified on the MEGA65, that do not run on a C65 prototype. By only performing the dummy write if the address is $D019, the MEGA65 maintains C64 compatibility, without sacrificing the speed improvement for all other uses of these instructions.
Hier der Einfachheit halber die deutsche Übersetzung und DeepL:
QuoteKompatibilität von Read-Modify-Write-Befehlen
Der 65CE02-Prozessor optimierte eine Gruppe von Befehlen, die Read-Modify-Write (RMW)-Befehle. Bei solchen Befehlen, wie z. B. INC, die den Inhalt einer Speicherstelle erhöhen, las der 6502 den ursprünglichen Wert und schrieb ihn dann unverändert zurück, bevor er ihn mit dem neuen, erhöhten Wert zurückschrieb. Für die meisten Zwecke bereitete dies keine Probleme. Es stellte sich jedoch heraus, dass dies ein schneller Weg ist, um VIC-II-Interrupts zu quittieren, da das Zurückschreiben des ursprünglichen Wertes (was der Befehl nicht tun muss) den Interrupt quittiert. Diese Methode ist schneller und benötigt weniger Bytes als jede andere und wurde daher in der C64-Software weit verbreitet.
Das Problem kam mit dem C65 und seinem vom 65CE02 abgeleiteten CSG4510, der diesen zusätzlichen Schreibvorgang während der RMW-Befehle nicht durchführte. Dadurch wurden die RMW-Befehle um einen Zyklus schneller, was die Software etwas schneller laufen ließ. Leider bedeutete dies auch, dass eine Menge bestehender C64-Software einfach nicht auf einem C65 läuft, es sei denn, der Interrupt-Acknowledgement-Code in jedem Programm wird gepatcht, um dieses Problem zu umgehen. Dies ist der häufigste Grund, warum viele C64-Spiele und andere Software-Titel nicht auf einem C65 laufen.
Weil dieses Problem so häufig auftritt, enthält der 45GS02 des MEGA65 eine Fehlerkompatibilität mit dieser häufig verwendeten Funktion des ursprünglichen 6502. Dazu prüft er, ob das Ziel eines RMW-Befehls $D019 ist, d.h. das Interrupt-Statusregister des VIC-II. Wenn dies der Fall ist, führt der 45GS02 den Dummy-Write aus, so dass viele C64-Softwaretitel, die auf einem C65-Prototyp nicht laufen, unverändert auf dem MEGA65 laufen können. Indem der MEGA65 den Dummy-Write nur dann durchführt, wenn die Adresse $D019 ist, bleibt die C64-Kompatibilität erhalten, ohne daß die Geschwindigkeitsverbesserung für alle anderen Anwendungen dieser Befehle geopfert werden muß.
Der "Bug" wurde im MEGA65 schon gut gelöst, so dass der MEGA65 schon deutlich mehr C64-Programme als der C65 laufen lassen kann.
Was mal geplant war, aber dann fallengelassen worden ist, ist ein automatisches Umschalten der "CPU" (in FPGA) auf "6502", wenn man in den C64-Modus schaltet. Das würde auch die "illegalen" Opcodes mit einbeziehen.
Quote from MEGA65 Manual (Seite G-4)6502 Unintended Instructions
The 65C02, 65CE02 and CSG4510 processors extended the original 6502 processor by using previously unallocated opcodes of the 6502 to provide additional instructions. All software that followed the official documentation of the 6502 processor will therefore work on these newer processors, possibly with different instruction timing. However, the common practice on the C64 and other home computers of using undefined or unintended opcodes (often called “illegal opcodes”, although there is no law against using them), means that many existing programs will not work on these newer processors.
To alleviate this problem the 45GS02 has the ability to switch processor personalities between the 4510 and 6502. The effect is that in 6502 mode, none of the new opcodes of the 65C02, 65CE02, 4510 or 45GS02 are available, and are replaced with the original, often strange, behaviour of the undefined opcodes of the 6502.
WARNING: This feature is incomplete and untested. Most unintended 6502 instructions do not operate correctly when the 6502 personality is enabled.
Quote from Übersetzung von DeepL6502 Unbeabsichtigte Befehle
Die Prozessoren 65C02, 65CE02 und CSG4510 erweitern den ursprünglichen 6502-Prozessor, indem sie zuvor nicht zugewiesene Opcodes des 6502 verwenden, um zusätzliche Befehle bereitzustellen. Alle Software, die der offiziellen Dokumentation des 6502-Prozessors folgt, funktioniert daher auch auf diesen neueren Prozessoren, möglicherweise mit einem anderen Befehls-Timing. Die auf dem C64 und anderen Heimcomputern übliche Praxis, undefinierte oder nicht vorgesehene Opcodes zu verwenden (oft als "illegale Opcodes" bezeichnet, obwohl es kein Gesetz gibt, das ihre Verwendung verbietet), bedeutet jedoch, dass viele bestehende Programme auf diesen neueren Prozessoren nicht funktionieren.
Um dieses Problem zu entschärfen, kann der 45GS02 zwischen den Prozessorpersönlichkeiten des 4510 und des 6502 umschalten. Dies hat zur Folge, dass im 6502-Modus keine der neuen Opcodes des 65C02, 65CE02, 4510 oder 45GS02 verfügbar sind und durch das ursprüngliche, oft seltsame Verhalten der undefinierten Opcodes des 6502 ersetzt werden.
WARNUNG: Diese Funktion ist unvollständig und ungetestet. Die meisten undefinierten 6502-Befehle funktionieren nicht korrekt, wenn die 6502-Persönlichkeit aktiviert ist.
Wenn, dann könnte man vermutlich hier noch bisschen was "drehen und schrauben", aber man hat dann z.B. das Problem, wie man damit umgeht, wenn man vom C64-Modus Features des MEGA65 nutzen will. Immer zwischen den "CPU"s hin- und herschalten? Auch deswegen hat Paul dieses Thema erstmal "irgendwo ganz nach hinten" geschoben.
-
Millie und Mollie ist bei ir im C64 Modus vom MEGA65 nicht gelaufen..
-
Musste das gleich mal googeln, kannte ich noch nicht. Ist genau die Art von Spielen, die mich heute noch süchtig machen...
Bin auch gespannt, welche Anwendungssoftware noch läuft. Habe im Keller immer noch einen alten Star-Drucker. Keine Ahnung, ob der noch tut. Farbbänder scheint es aber noch zu geben. Wäre schon scharf, den wieder zu aktivieren und etwas mit PrintShop oder ähnlichem zu erstellen und direkt auszudrucken... oder meine alten Facharbeiten in Originalformatierungen mit Vizawrite etc.
Und klar, ich weiss, für sowas wurde der Mega nicht primär entwickelt und gäbe es wohl andere Lösungen. Aber irgendwie kribbelt es mich...
-
Und klar, ich weiss, für sowas wurde der Mega nicht primär entwickelt und gäbe es wohl andere Lösungen. Aber irgendwie kribbelt es mich...
Aber warum denn nicht? Ich meine er wurde für alles entwickelt was du damit machen willst. Einen "vorgesehenen" oder gar produktiven Zweck würde ich so einem Liebhaberprojekt hingegen nicht unterstellen.
Also los!
-
Also los!
Ja, werde ich auf jeden Fall tun! Aber eben, erst muss er mal eintreffen bei mir...
Das mit dem zweiten Batch wird wohl noch ein Weilchen dauern.
-
Einen "vorgesehenen" oder gar produktiven Zweck würde ich so einem Liebhaberprojekt hingegen nicht unterstellen.
Die NASA hat sich 3000 MEGA65 für die geplante Marslandung vorbestellt.
-
Die NASA hat sich 3000 MEGA65 für die geplante Marslandung vorbestellt.
Wollen die jetzt auf dem Mars ne Kaktusplantage anlegen ?
-
Wollen die jetzt auf dem Mars ne Kaktusplantage anlegen ?
Natürlich! Die Astronauten müssen ja auf dem Mars auch was zum Essen haben.
-
Das ist ja praktisch, dann können die sich ja mal nen Eintopf kochen. Oder am Wochenende auf der Terasse grillen.
-
Weiss jemand hier, ob es noch etwas im Mega65-C64 gibt das sich weiter optimieren lässt, so das der C64 Modus kompatibler wird?
Das größte Problem beim C64-Modus des C65/MEGA65 sind gar nicht einmal so die fehlenden "illegalen" Opcodes. Die wurden - meines Wissens - gar nicht allzu oft in kommerziellen C64-Spielen verwendet, sondern eine ganz andere Baustelle, der sog. "Read-Modify-Write Instruction Bug", der wohl so einige C64-Programme betrifft, die im C64-Modus nicht (korrekt) laufen.
Ich zititiere hierzu mal aus dem "großen" MEGA65-Handbuch (ab Seite G-4):
QuoteRead-Modify-Write Instruction Bug Compatibility
The 65CE02 processor optimised a group of instructions called the Read-Modify-Write (RMW) instructions. For such instructions, such as INC, that increments the contents of a memory location, the 6502 would read the original value and then write it back unchanged, before writing it back with the new increased value. For most purposes, this did not cause any problems. However, it turned out to be a fast way to acknowledge VIC-II interrupts, because writing the original value back (which the instruction doesn’t need to do) acknowledges the interrupt. This method is faster and uses fewer bytes than any alternative, and so became widely used in C64 software.
The problem came with the C65 with its 65CE02 derived CSG4510 that didn’t do this extra write during the RMW instructions. This made the RMW instructions one cycle faster, which made software run slightly faster. Unfortunately, it also meant that a lot of existing C64 software simply won’t run on a C65, unless the interrupt acknowledgement code in each program is patched to work around this problem. This is the single most common reason why many C64 games and other software titles won’t run on a C65.
Because this problem is so common, the MEGA65’s 45GS02 includes bug compatibility with this commonly used feature of the original 6502. It does this by checking if the target of an RMW instruction is $D019, i.e., the interrupt status register of the VIC-II. If it is, then the 45GS02 performs the dummy write, allowing many C64 software titles to run unmodified on the MEGA65, that do not run on a C65 prototype. By only performing the dummy write if the address is $D019, the MEGA65 maintains C64 compatibility, without sacrificing the speed improvement for all other uses of these instructions.
Hier der Einfachheit halber die deutsche Übersetzung und DeepL:
QuoteKompatibilität von Read-Modify-Write-Befehlen
Der 65CE02-Prozessor optimierte eine Gruppe von Befehlen, die Read-Modify-Write (RMW)-Befehle. Bei solchen Befehlen, wie z. B. INC, die den Inhalt einer Speicherstelle erhöhen, las der 6502 den ursprünglichen Wert und schrieb ihn dann unverändert zurück, bevor er ihn mit dem neuen, erhöhten Wert zurückschrieb. Für die meisten Zwecke bereitete dies keine Probleme. Es stellte sich jedoch heraus, dass dies ein schneller Weg ist, um VIC-II-Interrupts zu quittieren, da das Zurückschreiben des ursprünglichen Wertes (was der Befehl nicht tun muss) den Interrupt quittiert. Diese Methode ist schneller und benötigt weniger Bytes als jede andere und wurde daher in der C64-Software weit verbreitet.
Das Problem kam mit dem C65 und seinem vom 65CE02 abgeleiteten CSG4510, der diesen zusätzlichen Schreibvorgang während der RMW-Befehle nicht durchführte. Dadurch wurden die RMW-Befehle um einen Zyklus schneller, was die Software etwas schneller laufen ließ. Leider bedeutete dies auch, dass eine Menge bestehender C64-Software einfach nicht auf einem C65 läuft, es sei denn, der Interrupt-Acknowledgement-Code in jedem Programm wird gepatcht, um dieses Problem zu umgehen. Dies ist der häufigste Grund, warum viele C64-Spiele und andere Software-Titel nicht auf einem C65 laufen.
Weil dieses Problem so häufig auftritt, enthält der 45GS02 des MEGA65 eine Fehlerkompatibilität mit dieser häufig verwendeten Funktion des ursprünglichen 6502. Dazu prüft er, ob das Ziel eines RMW-Befehls $D019 ist, d.h. das Interrupt-Statusregister des VIC-II. Wenn dies der Fall ist, führt der 45GS02 den Dummy-Write aus, so dass viele C64-Softwaretitel, die auf einem C65-Prototyp nicht laufen, unverändert auf dem MEGA65 laufen können. Indem der MEGA65 den Dummy-Write nur dann durchführt, wenn die Adresse $D019 ist, bleibt die C64-Kompatibilität erhalten, ohne daß die Geschwindigkeitsverbesserung für alle anderen Anwendungen dieser Befehle geopfert werden muß.
Der "Bug" wurde im MEGA65 schon gut gelöst, so dass der MEGA65 schon deutlich mehr C64-Programme als der C65 laufen lassen kann.
Was mal geplant war, aber dann fallengelassen worden ist, ist ein automatisches Umschalten der "CPU" (in FPGA) auf "6502", wenn man in den C64-Modus schaltet. Das würde auch die "illegalen" Opcodes mit einbeziehen.
Quote from MEGA65 Manual (Seite G-4)6502 Unintended Instructions
The 65C02, 65CE02 and CSG4510 processors extended the original 6502 processor by using previously unallocated opcodes of the 6502 to provide additional instructions. All software that followed the official documentation of the 6502 processor will therefore work on these newer processors, possibly with different instruction timing. However, the common practice on the C64 and other home computers of using undefined or unintended opcodes (often called “illegal opcodes”, although there is no law against using them), means that many existing programs will not work on these newer processors.
To alleviate this problem the 45GS02 has the ability to switch processor personalities between the 4510 and 6502. The effect is that in 6502 mode, none of the new opcodes of the 65C02, 65CE02, 4510 or 45GS02 are available, and are replaced with the original, often strange, behaviour of the undefined opcodes of the 6502.
WARNING: This feature is incomplete and untested. Most unintended 6502 instructions do not operate correctly when the 6502 personality is enabled.
Quote from Übersetzung von DeepL6502 Unbeabsichtigte Befehle
Die Prozessoren 65C02, 65CE02 und CSG4510 erweitern den ursprünglichen 6502-Prozessor, indem sie zuvor nicht zugewiesene Opcodes des 6502 verwenden, um zusätzliche Befehle bereitzustellen. Alle Software, die der offiziellen Dokumentation des 6502-Prozessors folgt, funktioniert daher auch auf diesen neueren Prozessoren, möglicherweise mit einem anderen Befehls-Timing. Die auf dem C64 und anderen Heimcomputern übliche Praxis, undefinierte oder nicht vorgesehene Opcodes zu verwenden (oft als "illegale Opcodes" bezeichnet, obwohl es kein Gesetz gibt, das ihre Verwendung verbietet), bedeutet jedoch, dass viele bestehende Programme auf diesen neueren Prozessoren nicht funktionieren.
Um dieses Problem zu entschärfen, kann der 45GS02 zwischen den Prozessorpersönlichkeiten des 4510 und des 6502 umschalten. Dies hat zur Folge, dass im 6502-Modus keine der neuen Opcodes des 65C02, 65CE02, 4510 oder 45GS02 verfügbar sind und durch das ursprüngliche, oft seltsame Verhalten der undefinierten Opcodes des 6502 ersetzt werden.
WARNUNG: Diese Funktion ist unvollständig und ungetestet. Die meisten undefinierten 6502-Befehle funktionieren nicht korrekt, wenn die 6502-Persönlichkeit aktiviert ist.
Wenn, dann könnte man vermutlich hier noch bisschen was "drehen und schrauben", aber man hat dann z.B. das Problem, wie man damit umgeht, wenn man vom C64-Modus Features des MEGA65 nutzen will. Immer zwischen den "CPU"s hin- und herschalten? Auch deswegen hat Paul dieses Thema erstmal "irgendwo ganz nach hinten" geschoben.
Die Fähigkeiten des Mega65 im C64 Modus zur Verfügung zu haben ist meiner Meinung nach schwachsinnig. Das würde ja nur den Mega65 betreffen - und da wäre es sowieso besser, im Mega65-Modus zu programmieren anstatt im C64-Modus ein C64-Programm mit Mega65-Fähigkeiten zu schreiben, das sowieso nur auf einem Mega65 funktionieren. Wer kommt auf so kranke Ideen? Somit den Bug lieber fixen und einen wesentlich kompatibleren C64-Modus zu erhalten…
-
Wer kommt auf so kranke Ideen?
Commodore beim C65.
Like the C128, all of the extended features of the C65 system are accessible from "C64 mode" via custom software
Es gibt schon einen Vorteil: Man kann vorhandenen Quellcode für den C64 relativ "schnell" mit paar Feature (z.B. Stereosound) erweitern und das so auf dem MEGA65 laufen lassen. Das komplette Programm auf den MEGA65-Modus anzupassen kann je nach Programm deutlich länger dauern.
-
Die VIC III und IV Features sind doch standardmaessig ausgeblendet, da sollte es also aus meiner Sicht keine Probleme geben.
Vielleicht gibt es aber auch in Zukunft ein paar gefixte Versionen von Spielen, so wie "fuer Easyflash-angepasste Versionen", koennte es ja auch "MEGA65-GO64-angepasste Versionen" geben. Vielleicht ist es ja bei einigen Spielen nur eine Kleinigkeit...
Nee, die ganzen Neuerungen, also VIC III/IV, sind auch im C64 Modus zugänglich.
Warum man das gemacht hat, und ob man das braucht, weiss ich nicht.
Aber das war im C65 schon so vorgesehen.
Die CPU des C65 wich auch schon vom 6502 ab.
SIDs in Stereo gehen auch im C64 Modus.
Der portierte C64 MiSTer Core ist doch eine super Lösung.
Der GO64 Modus des Mega65 ist für mich auch ok so wie er ist.
So kann jeder wählen was ihm lieber ist.