JMPF after RET

[Exant64]

Sorry for the nondescriptive title, this issue may just be a misunderstanding from my part, but I disassembled Chao Adventure 2, and noticed a lot of instructions are interpreted as data. I used the official VMU emulator from the sdk since it has a proper debugger to see where the code jumps to a part that's interpreted as data.

Above you can see how this part of the code looks like in the disassembly code trace from the emulator

Here you can see it in this program
To me it seems like ret doesn't matter if a JMPF is after it? Not completely sure, but SH4 (the DC's processor) also had something like this so it may be possible. Regardless, it seems to be a problem

[wtetzner]

So it's possible to dynamically jump to an address on the VMU by pushing the address to the stack and then calling ret, which it looks like is happening here. Unfortunately, I'm not sure how to statically determine the target of that jump.

I think some better analysis would help catch more of those cases, but I'm not sure it's possible to statically determine all of them.

Can you tell from the debugger whether or not the jmpf at 7DCA is executed right after the ret?

[Exant64]

Yes, the jmpf seems to be executed, this is from a stacktrace showing where the program counter is right now and it was inside the function referenced in the jmpf

looking at some examples from the PDF from the SDK though, it does seem to be intentionally running the line after the ret though (values 7D and C7 getting added)

[Exant64]

For now I'll try hardcoding specific entrypoints or something similar as a temporary solution, not sure how this could be figured out in general for all executables

[gyrovorbis]

By the way, the reason the Dreamcast executes the instruction after a return or branch is because it's a superscalar processor that executes two instructions per cycle, and the extra instruction is called a "delayed branch slot." This isn't relevant to the VMU.

Also wtetzner and I are collaborating together to add this kind of debugger functionality into EVMU eventually. :)

[gyrovorbis]

That looks to be a jump table with instruction padding, so I doubt that the VMU Simulator is correct either.

$21, $96, $E1 jmpf $96E1
$21, $96, $F9 jmpf $96F9
$21, $99, $1A jmpf $991A
$A0, $00, $00 ret
$21, $E5, $1C jmpf $E51C
... etc

[Exant64]

yeah I think the simulator only showed the lines it was executing so it didnt show the jmpf $96E1 either, hardcoding that jumptable rn
nice to hear that there's gonna be a more accessible debugger out there, I had to write a tool for the simulator that converts the regular VMU executable into this intel 8bit hex listing thing because apparently it can't load regular bins

[gyrovorbis]

By the way, I don't have debugger support yet, but I was able to completely reverse-engineer Chao Adventure 2's text rendering in my Flash hex editor and create a "mod" with my own text and then export it from EVMU into its own ROM...

Also relevant, I'm working on adding emulation support for the serial ports to emulate DC/VMU connectivity, then release a library on the PC side that maybe you guys could hook into to emulate transferring Chaos to Chao Adventure...

Also niiiiice on the converter. Do you have that uploaded anywhere? I wanted to support loading all of the formats that simulator loads as well!

[Exant64]

it's this format https://en.wikipedia.org/wiki/Intel_HEX, more specifically the 8 bit version so it's like
: 2 digit hex number of bytes -- 4 digit hex address -- 2 digit "record type" (for the simulator just setting it to 0 is fine)
then comes the actual bytes, and at the very end one extra byte which is the checksum but that's ignored by the simulator too
i'll upload my code in a moment to convert bin to h00 but warning its very hacky, I only made it to get Chao Adventure 2 running though it should work with other minigames too

EDIT: it's up on my github, btw sorry for derailing the thread