-
Notifications
You must be signed in to change notification settings - Fork 88
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
MAP upper bytes not working as expected #838
Comments
Hi! This time I made very sure, that several aspects were always the same:
Outcome: Working
Not working
Working
I hope this helps when somebody is addressing the issue. I'll keep the test code in commented state in my program, so that I can help with testing when the time comes. |
@Pimau Can you attach your test code to this ticket? |
Sure. I am using the infrastructure of my current project to place an expected byte-stream with DMA in Attic before the test. These routines have too much dependencies to paste them here in a clear format. But finally, after sorting memory contents, I call this routine and sbreak directly after it (see comment). Basically nothing you can't write in minutes.
|
Test Environment (required)
You can use MEGA65INFO to retrieve this.
Describe the bug
Setting MAP upper bytes, such as to map 16-bit addresses to Attic RAM, does not appear to be working correctly.
I believe I tested the Memory chapter thoroughly including an example of mapping A000-BFFF to 800.0000 with an offset of 7FF.6000 (MAPH = 7F.F60(00) region 2), so if we can confirm that our tests are correct, then we should look for a recent regression.
I attempted to reproduce using short assembly language programs entered into the MONITOR but could not get any example to work. It's possible I'm doing it incorrectly and my test needs troubleshooting. As follows:
In Matrix Mode, this correctly shows the code in an infinite loop at $161B, with the lower bytes of MAPH set to $2100 and MAPL to $0000. The Matrix mode debugger does not display the upper bytes of the MAP register; this is expected to set MAPH upper to $80, for a total offset of 801.0000 added to A000-BFFF.
Expected:
m801a000
should show BB BB BB, as shouldm777a000
.Actual: Both show 00 00 00.
@Pimau tried to affect a similar change via m65dbg and says this example mapping of A000 to 801.A000 is working, but A000 mapped to 800.0000 (offset 7FF.6000) is not working. The latter is the example from the Memory chapter. MEGA65/mega65-rom-public#172
The text was updated successfully, but these errors were encountered: