10 Commits
Author SHA1 Message Date
KallDrexx e76cec3d6d Loopback jumps should occur on the same cpu address of the jump
When a function is decompiled in the middle of a function, and that function
has a jump point prior to the function's entry point, we need to add a
fake virtual instruction that jumps back to the start of the function.

The virtual instruction needs to be the last instruction in the
ordered instruction set.

We previously accomplished that by adding an instruction at the
location of the function entrypiont minus one. However, this was
failing in cases where a system would cause an interrupt right on
the virtual address. Emulators would then save the virtual
instruction's address to the stack, and jump back into that address
once RTI occurs.

This fails because the virtual address can't be decompiled, because
legit code doesn't exist at that address.

To fix this, I updated the `SubAddressOrder` property to allow for negative
values. This allows the loopback instruction to be on the correct CPUAddress
while still being ordered as expected.

Also ensured that virtual addresses do not get labels, as they are not
actually valid jump targets.
2026-01-17 11:44:40 -05:00
KallDrexx c0380bd198 Allow for sub address instructions.
When a wrap around scenario is detected during single function tracing,
if the address prior to the "entry point" is a single byte, then we do
not have any space to add the required jump call.

This fixes that by adding the concept of sub address instructions. This
allows adding instructions at runtime that get sorted correctly against
the real instructions from the ROM.

This not only solves the wrapping issue, but also allows for adding hooks
at runtime.
2025-10-11 23:11:37 -04:00
Matthew Shapiro bbcd2a6aad Merge pull request #8 from KallDrexx/single_function_decompile
Add code path to decompile/disassemble a single function
2025-10-11 16:03:41 -04:00
KallDrexx 6d3ec6c2c8 Initial single function decompiler implementation 2025-10-10 23:06:03 -04:00
KallDrexx 9068403d56 Fix 16KB roms not decompiling
Roms with only 16KB of program code had the incorrect base address during the disassembly process. This caused the instructions not to be found.

Fixed by making sure the base address is adjusted based on the prgRomData size.
2025-09-28 21:16:37 -04:00
KallDrexx 40743c6889 Loop EnsureReferencedAddressesAreDisassembled
`EnsureReferencedAddressesAreDisassembled is needed to be run because
a jump/branch may occur that targets interwoven instructions that would
not have been picked up on the first pass.

However, an interwoven instruction may actually end up with a branch
into another interwoven instruction. These instructions wouldn't be
picked seen by the end of the 2nd pass.

So the logic in this function is now set to loop (with a maximum) until
all target addresses that are directly referenced have been
disassembled.
2025-09-28 11:20:12 -04:00
KallDrexx b627bc2a48 Decompiler direct jumps to instructions that are in between other instructions 2025-09-25 21:59:20 -04:00
KallDrexx e592c31a0c Add decompililng of other entrypoints, and add specific support for NMI and IRQ vectors 2025-09-24 20:33:38 -04:00
KallDrexx b968b151d0 Fix nullability warnings 2025-09-10 21:30:08 -04:00
ApfelTeeSaft 810f1458cb Initial commit 2025-05-15 14:33:41 +02:00