Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establish a fixed point in C64 ROM for c65toc64wrapper #104

Open
dansanderson opened this issue Dec 24, 2023 · 2 comments
Open

Establish a fixed point in C64 ROM for c65toc64wrapper #104

dansanderson opened this issue Dec 24, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@dansanderson
Copy link
Collaborator

Context: MEGA65/mega65-tools#184

The c65toc64wrapper helper is a blob of binary code that can be prepended to any C64 PRG so that it can start from MEGA65 mode, using various registers and KERNAL init routines to transition to GO64 mode without erasing the program from memory. This helper calls an interior address of a C65 init routine in the C64 ROM code. I recently noticed that this address is not an instruction in ROM 920390, and is one byte ahead of the routine labeled c65_ioinit_cold and two bytes behind the comment that reads "Fixed at $f7a9." Per the tracking issue, I tried making a new ROM build that pushed the routine one byte forward, but so far have not produced a working result with a test program and the wrapper.

This issue is to track any follow-up needed in the ROM to resolve problems with c65toc64wrapper. c65_ioinit_cold should start at either $f7a9 or $f7a6, using * = $f7a9 just before the label to make it so. There's a nop buffer just before it that appears to be intended to hold this in place, but assigning the PC will be more reliable and should break the build if the code before it grows for some reason. (We try not to make any byte changes to the C64 ROM, but this region contains some MEGA65 interfacing code that might shift.)

We should more generally consider adding a few spot checks to the ROM build, such as grep -q "f7a9 c65_ioinit_cold:" kernel64.lst, so that the build fails if certain fixed points are violated. I would not be opposed to using a similar technique on all published MEGA65 ROM API entry points, once we have some.

@dansanderson dansanderson added new New report, not classified yet enhancement New feature or request and removed new New report, not classified yet labels Dec 24, 2023
@dansanderson
Copy link
Collaborator Author

dansanderson commented Jul 17, 2024

Maybe we don't need both this issue and the mega65-tools issue: MEGA65/mega65-tools#184

The resolution probably involves a small change to kernel64.src, probably an .assert * = $f7a9 near here and the removal of a couple of those nops. The target is to get mega65-tools/src/tests/floppytest.prg to start properly from MEGA65 mode. I tried removing two nops to align $f7a9 with similar data in a known-working ROM 920254, but this didn't appear to change the broken behavior.

@dansanderson
Copy link
Collaborator Author

ROM 920387 breaks floppytest.prg. This is the keyboard scanner change.

Both 920386 and 920387 have 20 2C F7... at 2F7A9. We still might need a fix for a later version of the ROM in this regard, as it does look like it has slid two bytes later on.

There were no changes to the code for the C64 part of the ROM in 920387. Also no shared DOS changes. Maybe something shifted in the MEGA65 ROM that something else depends on.

(I'm a little confused about c65_ioinit_cold doing a jmp ($8000). This is using the DOS map, but the DOS map doesn't do anything special with $8000. Such a jump would cold-start a cartridge, but other uses are careful to test for a cart with a0int first. This doesn't seem to be broken, I just don't know how it works yet.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant