Illegal opcodes emulation in simple emulator written in C

[LTVA]

Hello. I have forked this nice tool: https://github.com/LTVA1/siddump. In cpu.c I tried to add some illegal opcodes support (search by word "Lunatico"), but when I try to use the program on Lunatico sid files I don't get any SID registers writes but they should happen. This means that the 4 opcodes I tried to implement are done wrong. So I need help since I know almost nothing about 6502 internals and how illegal opcodes work.

[BigEd]

Welcome!

A quick look suggests that you'd need
WRITE(ABSOLUTE());
in some appropriate place(s).

[LTVA]

BigEd wrote:

Welcome!

A quick look suggests that you'd need
WRITE(ABSOLUTE());
in some appropriate place(s).

Hmm, I was worried that this might be the case since WRITE(foo) just does nothing (it has something commented out). I will try to add the actual WRITE() functionality first and see if it doesn't break.

[LTVA]

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

[LTVA]

Ok so I corrected program counter increments and now Lunatico sids actually write some data to SID registers, but it seems like the program is being stuck in short loop since after some time it starts to output repeating portions of nonsensical data (e.g. C-0 notes over and over again which isn't what the sid should play, obviously).

I updated code on github, and it's late now, so for today I won't do any further work on this.

P.S. Funny thing with this emulator is that

Code: Select all

MEM(ABSOLUTE()) = x;

is what actually writes to some memory location, while

Code: Select all

WRITE(ABSOLUTE());

just does nothing.

The whole issue is basically because LFT made his custom sid player to fit in like ~15 rasterlines which is apparently implying some self-modifying code (?) and clever illegal opcodes hacks.

[MicroCoreLabs]

LTVA wrote:

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino

[dp11]

I would probably check to see how good the emulation is of the instructions with https://github.com/Klaus2m5/6502_65C02_functional_tests and my cycle timing checker which includes undocumented instructions : https://github.com/dp111/6502Timing

[LTVA]

MicroCoreLabs wrote:

LTVA wrote:

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino

Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.

[LTVA]

dp11 wrote:

I would probably check to see how good the emulation is of the instructions with https://github.com/Klaus2m5/6502_65C02_functional_tests and my cycle timing checker which includes undocumented instructions : https://github.com/dp111/6502Timing

Actually no need now, I have the source code so I see what opcodes are implemented and what aren't.

[MicroCoreLabs]

LTVA wrote:

MicroCoreLabs wrote:

LTVA wrote:

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino

Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.

Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...

[LTVA]

MicroCoreLabs wrote:

LTVA wrote:

MicroCoreLabs wrote:

LTVA wrote:

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino

Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.

Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...

Okay I think I will try to use it since the in-place opcode implementation didn't work.

[LTVA]

okay so... I could not adapt it, it just hangs on some instruction forever!
https://github.com/LTVA1/siddump/tree/broken

[LTVA]

MicroCoreLabs wrote:

LTVA wrote:

MicroCoreLabs wrote:

LTVA wrote:

Well, it does break. Maybe it won't be an easy fix, although I haven't found any C emulator with all illegal opcodes.

You could take a look at my MCL64 which is a 6510 emulator written in C and supports the undocumented/unstable opcodes fairly well when used as a drop-in replacement into a Commodore 64.

https://github.com/MicroCoreLabs/Projec ... /MCL64.ino

Quite nice emulator, although it can't be easily made as a replacement in my case since in my fork there is an array which acts like C64 memory and a function that reads virtual SID registers values regularly. I like your code for illegal opcodes though, may adapt it to my program.

Sounds like you are all set, however note that the MCL64 has a separate Bus Interface Unit (BIU) which takes as inputs the memory read and write commands and inplements them on a physical bus signals. If you wanted to instead use an array for your memory or implement peripherals then this is the place to do this. This is how I debugged the code using command-line gcc - instead of physical interface I just used an array in the BIU...

So I tried to remove internal RAM requests and all the stuff related to MCU and external signals. From what I debugged it seems like it successfully passes SID model check but then it just hangs executing 0x00, 0x40 or 0x60 forever (I made it stop on these as in original emulator but it just stops and does not advance any further; I made sure PC increments when I jump out of the loop)