c65toc64wrapper not working with the latest ROM betas

[dansanderson]

c65toc64wrapper appears to be not working with a recent environment (development core, ROM beta 982390). This might be better as a ROM bug but I want to accrue notes near the wrapper code.

Test Environment (required)

• MEGA65 Platform: MEGA65, xemu
• ROM Release: 982390
• Core Commit: fcf8cc4

Describe the bug
I'm trying to get c65toc64wrapper working with a recent example to confirm that the C64 ROM binary hasn't pushed an entry point it relies on. I noticed that this instruction in the wrapper hard-codes a C64 ROM address with no build-time guarantees that the ROM will keep it there: jsr $f7a9 ; C65 DOS reinit According to the BSA symbols file (kernel64.lst) for ROM 920390, this address is not an instruction, but one byte into kernel65.src:c65_ioinit_cold. I tried to make a simple example PRG using the wrapper, confirmed that it failed with ROM 920390 in Xemu, then tried to make a new ROM with c65_ioinit_cold starting at $f7a9. This did not fix the example PRG or change its behavior.

wrappertest.zip contains:

• hi.prg, a simple BASIC program created in GO64 mode: 10 PRINT "HI"
• hi_65.prg, the same PRG data prepended with a fresh build of c65toc64wrapper.prg, built with make src/utilities/c65toc64wrapper.prg in mega65-tools, development branch
• t.d81, a disk image with these files
• wrappertest.rom, a build of ROM 920390 with c65_ioinit_cold pushed to $f7a9

In Xemu, I loaded the custom ROM, mounted the D81, then loaded and ran hi_65.prg, and I see this:

I will proceed to reproduce on real hardware, and try to determine if older ROMs can run hi_65.prg unmodified. If there are known-working binaries of programs that rely on the wrapper out there, let me know, and I'll test with those also. If the entry point slip is an issue, these programs should fail on newer ROMs.

[dansanderson]

Looking at this again. The test program I posted isn't viable. It fails in the same way on a very old ROM 920254. A custom ROM that pulls the kernel64.src line documented as "Fixed at $f7a9" back to that address by dropping two nop statements does not change the behavior of hi_65.prg.

src/tests/floppytest.prg uses the wrapper, and a fresh build of this works in old ROM 920254 but not the most recent ROMs. Disappointingly, the two-byte shift fix does not resolve the issue. Curiously, if I compare 920254 and the two-byte shift fix, they both place 20 2C F7 ... at address 2F7A9. It seems like that's the right idea—the ROM address difference I noticed would explain breakage—but I don't know why the fix doesn't resolve the issue for floppytest.prg. I can try hunting down the first ROM where it fails.

I added .assert to BSA a while back so once we figure out the correct ROM change, we should be able to enforce it. In general, I'd rather c65toc64wrapper not call an internal ROM address, but in this case we're trying to avoid large changes to the C64 ROM, and there's not a lot of room for a jump table entry. So this is an acceptable compromise, if we can get it working again.

[dansanderson]

Sorry, the 2F7A9 jump location looks like a red herring. ROM 920387 is the first broken ROM for floppytest.prg. That's the keyboard scanner change. It doesn't modify the C64 ROM at all: 2F7A9 is identical in 920386 and 920387.

I will add more notes to the ROM issue: MEGA65/mega65-rom-public#104 I want to leave open the possibility that an incompatibility might require a change in c65toc64wrapper given how it doesn't use public APIs. A better overall solution would be to determine what c65toc64—and programs like it—needs, and make it a formal feature of the ROM, e.g. a KERNAL jump table entry that switches to GO64 mode and jumps to an address.