Quoted
- Added missing interrupt delay counter stop behaviour when RDY0 if low in the CPU emulation. Fixes the IRQDMA issue.
- Added switch-level transistor-based 6502/6210 CPU simulation (for debugging of the 6502/6510 CPU emulation). It uses the netlists from Visual6502.org in a converted format, but i've optimized these for myself for a bit more simulation performance, so that it runs on my Intel i7 2630QM CPU at about 7-8kHz. It's on-switchable for the main C64 CPU with the "+cpusim" command line parameter.
- Finetuned IRQ/NMI behaviour at tricky IRQ/NMI/BRK cases of the CPU emulation to match the the CPU simulation. But so far, the most other CPU 6502/6510 emulation implementations do handle these cases probably not correct. And I did not mean the BRKNMI, LostBRK, etc. stuff, but I do mean how a real 6502/6510 CPU realizes/manages the B flag st transistor gate logic level in connection to the D1x1 and IRQ/NMI lines and so on, and that IRQ/NMI are just a by-the-in-CPU-PLA injected BRK opcode. So my advice to the other emulator authors: Take the Visual6502.org stuff to your heart, and look at it and use it to debug your CPU emulation. It's better than all logic analyzer stuff in the most cases in my opinion, because you can look on transistor gate level inside the CPU, while it's working.
I do mean how a real 6502/6510 CPU realizes/manages the B flag st transistor gate logic level
Quoted
Take the Visual6502.org stuff to your heart, and look at it and use it to debug your CPU emulation.
Quoted
Wenn man die wirklich sehr langsame CPU Simulation benutzt, wird dann zudem ein gepatchter Kernal geladen, wo der MemoryTest als Zeiteinsparung übersprungen wird, aber allerdings nur da, also wenn man die CPU Emulation verwendet, werden weiterhin nur ungepatchte ROMs verwendet.
|
|
Quellcode |
1 2 3 |
10 x=rnd(-1963):fori=1to81:y=rnd(1):next 20 forj=1to5:printchr$(rnd(1)*16+70);:next 30 printint(rnd(1)*328)-217 |
Quoted
nd sieht auch nicht so original wischiwaschi nach Bildschirm aus.
Es gibt im 6502 nirgendwo ein B-Flag. Auf visual6502 ist an dieser Stelle lediglich ein Node dargestellt welcher dafür sorgt, dass beim Pushen des Statusregisters an dieser Stelle eine 0 oder 1 geschrieben wird, tatsächlich wackelt der aber auch in anderen Situationen manchmal.

Verwende das bloss nicht als Referenz für illegale Opcodes, für einige davon ist die Simulation zu ungenau. Die Lorenz-Testsuite meldet Abweichungen zum erwarteten Ergebnis in den Tests alrb, ancb, aneb, arrb, lasay und lxab.
Ich meinte es für den stabilen Anteil also sprich für die stabilen Opcodes und fürs Interrupthandling und so.Warum arbeitest du nicht einfach den Speichertests in der Softwaresimulation ab und überträgst am Ende den Zustand in die Schalterlevelsimulation?
Weil das nicht so einfach umsetzbar ist, wegen den zig Pipes, Latches, etc. auf Transistorbasis, von daher kann man da nicht so einfach einen CPU Stand aus der Emulation "injecten".
|
|
Quellcode |
1 2 3 |
10 x=rnd(-1963):fori=1to81:y=rnd(1):next 20 forj=1to5:printchr$(rnd(1)*16+70);:next 30 printint(rnd(1)*328)-217 |
Du musst ja nicht unbedingt den schwierigen Weg wählen, die Zustände der Knoten und Transistoren direkt zu ändern. Wenn man sich auf die einfachen Fälle (Instruktionsgrenze, kein anstehender Interrupt) beschränkt kann man die CPU mit ein paar Befehlen füttern um den Zustand nach Wunsch einzustellen.
Für den umgekehrten Weg (Switchlevel->Software) empfiehlt es sich auf der Schaltersimulation noch ein NOP auszuführen, da insbesondere bei ALU-Operationen die internen Registerwerte erst nach dem ersten Taktzyklus des Folgebefehls den endgültigen Wert angenommen haben (kann man alternativ auch so interpretieren, dass der Takt in dem der SYNC-Pin aktiv ist und der nächste Opcode gelesen wird der letzte Takt des ausgeführten Befehls ist und nicht der erste des gelesenen).
Hi BeRo in wie weit unterscheiden sich die CPU-Cores (BUILD599), ausser das die eine arg langsammmmm ist. Ich Frage weil mir aufgefallen ist, das mein Cartridge-Rip von Jungle Hunt komischerweise nur mit dem neuen CPU-Core läuft, beim alten bleibt der Bildschirm einfach schwarz. Das gleiche bei Ghostbusters (Tape-Rip) neuer Ja alter Nein.
Aber um die Sache noch besser zu machen, als Cartridge läuft Jungle Hunt auch mit den normalen CPU-Core.
Hier die Dateien fürs debuggen.
index.php?page=Attachment&attachmentID=38696
index.php?page=Attachment&attachmentID=38697
index.php?page=Attachment&attachmentID=38698
Forum Software: Burning Board® 3.1.7, developed by WoltLab® GmbH