You are not logged in.

Dear visitor, welcome to Forum64. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

BYB

wat'n data?

  • "BYB" is male

Posts: 62

Date of registration: Jan 5th 2011

Location: Ruhrpott

  • Send private message

member since 18 member since

481

Friday, October 7th 2011, 9:20am

gibt's denn irgendwo noch die alte

1.00.2011.09.19 Build 583 ?

Habe sie versehentlich überspielt, hat aber mehr Spass gemacht, weil nicht
so langsam. ^^

Acorn

Trainee

  • "Acorn" is male

Posts: 79

Date of registration: Sep 28th 2011

Location: Viersen

  • Send private message

member since 18 member since

482

Friday, October 7th 2011, 1:27pm

Die neueren Versionen laufen genau so schnell man muß nur half-cycle auschalten.

483

Friday, October 7th 2011, 10:04pm

Die neueren Versionen laufen genau so schnell man muß nur half-cycle auschalten.


Geht bei mir nicht mehr. Wenn ich die Option ausschalte, und per Escape raus aus dem Menü will, hängt sich der Emulator auf.
Dieser Beitrag wurde bereits 64 mal editiert, zuletzt von »Bagitman« (Heute, 00:03)

Acorn

Trainee

  • "Acorn" is male

Posts: 79

Date of registration: Sep 28th 2011

Location: Viersen

  • Send private message

member since 18 member since

484

Friday, October 7th 2011, 10:25pm

Ja ist noch buggy beim auschalten. Versuch mal half-cycle ausschalten und mit Load und ein Programm zu laden.

angryking

Trainee

Posts: 66

Date of registration: Oct 20th 2009

  • Send private message

member since 36 month member since 36 month

485

Saturday, October 8th 2011, 12:14pm


BYB

wat'n data?

  • "BYB" is male

Posts: 62

Date of registration: Jan 5th 2011

Location: Ruhrpott

  • Send private message

member since 18 member since

486

Saturday, October 8th 2011, 3:25pm

Vielen Dank :thumbsup:

...habs grad nochmal getestet, ist auch nicht schneller (aber sowas passiert mir schonmal)
Grad wenns verloren ging und ich es nicht mehr wiederfinde ;( .

BYB

wat'n data?

  • "BYB" is male

Posts: 62

Date of registration: Jan 5th 2011

Location: Ruhrpott

  • Send private message

member since 18 member since

487

Saturday, October 8th 2011, 4:14pm

...sorry, nochmal getestet (hät ja auch direkt das richtige File anklicken sollen).

Ich weiss jetzt zwar nocht nicht warum, aber mit der alten 583 version lädt der
bei mir auf jeden Fall schneller.
Vielleicht fällts bei mir auch nur auf, da ich ein Netbook mit so'm Atom Prozessor besitze.

488

Saturday, October 8th 2011, 7:51pm

weil nicht
so langsam. ^^

Quoted

a High-End Computer is strongly recommended
Benutze doch den vice da gibt es bestimmt keine Performance-Probleme.

BYB

wat'n data?

  • "BYB" is male

Posts: 62

Date of registration: Jan 5th 2011

Location: Ruhrpott

  • Send private message

member since 18 member since

489

Saturday, October 8th 2011, 8:08pm

ja aber der vice macht kein .....klack.....
und sieht auch nicht so original wischiwaschi nach Bildschirm aus.

Habe schon gelesen, dass der emulierende Rechner ein bischen mehr Leistung haben sollte,
den hab ich aber z.Z. nicht.
Trotzdem gefallen mir diese Gimmicks sehr gut :thumbsup:
Und vielleicht läuft das fertige Final ja auch wieder ein bischen flotter ?!

BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

490

Sunday, October 16th 2011, 9:57pm

So neuer Micro64 Build 597 ist online. Changelog:

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.


Also Micro64 hat nun zwei CPU Cores, eine CPU Emulation (default) und eine (arg langsame) CPU Simulation, die die CPU auf Transistor Gatter Switch-Level Ebene "simuliert", diese verwende ich zum debuggen/abgleichen der CPU Emulation.

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.

Unseen

Hätte gerne 'n Virtex 7 ;)

  • "Unseen" is male
  • »Unseen« is a verified user

Posts: 4,559

Date of registration: Jun 16th 2007

Location: Debara Hamtar

  • Send private message

member since 72 month member since 72 month member since 72 month member since 72 month

491

Sunday, October 16th 2011, 10:32pm

I do mean how a real 6502/6510 CPU realizes/manages the B flag st transistor gate logic level

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.

Quoted

Take the Visual6502.org stuff to your heart, and look at it and use it to debug your CPU emulation.

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.

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.

Warum arbeitest du nicht einfach den Speichertests in der Softwaresimulation ab und überträgst am Ende den Zustand in die Schalterlevelsimulation?

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

sd2iec Homepage

sauhund

ist falsch abgebogen

  • "sauhund" is male

Posts: 20,323

Date of registration: Jul 16th 2005

Location: zuhause

  • Send private message

member since 90 month member since 90 month member since 90 month member since 90 month member since 90 month

492

Sunday, October 16th 2011, 10:37pm

Quoted

nd sieht auch nicht so original wischiwaschi nach Bildschirm aus.

pal emulation einschalten? =P
http://www.hitmen-console.org http://magicdisk.untergrund.net
Die Furcht vor der freimütigen Antwort kann auch robuste Charaktere befallen.

BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

493

Sunday, October 16th 2011, 10:50pm

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.


Das weiss ich und das meinte ich ja. Aber ich nenne es nach aussen hin weiterhin B Flag für aus Einfachkeit für CPU Emulation Erklärungen etc. Tatsache ist halt es dass "B Flag" (nun in Anführungszeichen) bei einem entdecktem IRQ/NMI ohne Delay beim nächsten FetchCycle gecleart wird und nicht erst beim per IRQ/NMI geinjectem BRK Opcode, dadurch ist z.B. die Emulation vom PHP Opcode bei den meisten anderen 6502/6510 CPU Emus wohl eventuell inkorrekt. Das "B Flag" ist halt ein doubled-inverted Wert von D1x1, also ein Output von einem Inverter, falls du es hier wirklich genau stehen sehen willst. :)

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.


Weiss ich ebenfalls. :) 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".

Unseen

Hätte gerne 'n Virtex 7 ;)

  • "Unseen" is male
  • »Unseen« is a verified user

Posts: 4,559

Date of registration: Jun 16th 2007

Location: Debara Hamtar

  • Send private message

member since 72 month member since 72 month member since 72 month member since 72 month

494

Sunday, October 16th 2011, 11:09pm

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

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

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

sd2iec Homepage

BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

495

Sunday, October 16th 2011, 11:26pm

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.


Hm, ein Versuch wäre es wert, ob es dann wirklich so funktionieren würde. Ich werde es einfach mal so demnächst ausprobieren.

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


Ja, diese Simulation->Emulation Richtung wäre hingegen gar kein Problem, da selbst bei der Simulation das IRQ/NMI-"Tracking" der Emulaton trotzdem läuft (u.A. für die Cartridgeemulation für den NMI Kram etc.), aber das IRQ/NMI-Handling der Emulation "entschärft" bzw. nicht scharf geschaltet ist, da die Emulation in dem Fall ja nicht läuft.

BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

496

Monday, October 17th 2011, 8:49pm

So neuer Micro64 Build 599 ist verfügbar, nun mit (erstmal nur readonly) EasyFlash Cartridge Support, für welche, die auch die Prince of Persia C64 Version mal unter Micro64 antesten wollen. :D

Also die restliche EasyFlash Logik ist zwar schon implementiert und läuft auch schon, aber jedoch noch ohne scharf-geschaltete CRT-Datei-WriteBack-Funktion, weil ich den Code erstmal nochmal in Ruhe verifizieren muss, ob ich es (heute innerhalb knapp 2-3 Stunden) halbwegs korrekt implementiert habe, bevor einer hier meckert, dass Micro64 eine seiner CRT-Dateien zerschossen hat. :)

Acorn

Trainee

  • "Acorn" is male

Posts: 79

Date of registration: Sep 28th 2011

Location: Viersen

  • Send private message

member since 18 member since

497

Monday, October 17th 2011, 10:54pm

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.

BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

498

Monday, October 17th 2011, 11:12pm

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.


Also die CPU Emulation emuliert die CPU auf Softwarelogikbasis, die CPU Simulation simuliert hingegen also quasi einen echten 6502/6510 CPU Chip von den Chip DIE Transistorgattern her aber jedoch ohne die physikalischen Effekte, also nur als "digitalperfekte" Transistorgatter SwitchLevel Simulation, weshalb man auch nicht das Verhalten der instabilen illegalen Opcodes dieser Simulation als Referenz nehmen sollte, aber das sollte man eh auch nicht bei einer echten 6502/6510 CPU, denn selbst da gibt es Unterschiede von CPU zu CPU. Also die CPU Simulation wird nie die CPU Emulation ersetzen, sondern dient nur als Abgleichreferenz für die CPU Emulation für mich.

Aber fürs Debugging für mich wäre evtl. deine zwei Beispiele (als CRT/T64/TAP/etc.) interessant.

Acorn

Trainee

  • "Acorn" is male

Posts: 79

Date of registration: Sep 28th 2011

Location: Viersen

  • Send private message

member since 18 member since

499

Monday, October 17th 2011, 11:33pm


BeRo

Micro64 Autor

Posts: 199

Date of registration: Apr 18th 2011

Location: Mönchengladbach

  • Send private message

member since 18 member since

500

Tuesday, October 18th 2011, 3:08am



So, zumindest ghostbusters.prg wird beim neuen Micro64 Build 602 nun geladen. Micro64 muss einfach etwas länger (ca. 3 virtuelle Sekunden im TimeWarpModus) abwarten, bevor es "RUN" in den Keybuffer schreibt, dann läuft ghostbusters.prg auch wie bei der CPU Simulation mit gepatchtem Kernal mit geskipptem MemTest, wo es evtl. zufällig das Timing cyclegenau hinhaut. Und bei "jungle hunt.prg" habe ich noch nicht die Lösung gefunden.