ROM "corruption" in emulator? (3E+ with PlusROM)

[brpocock]

When I open my ROM image, which is a 32kiB 3E+ file, in Stella, I see the following "garbage" data at the end of the ROM.

However, the actual ROM file ends like so:

ROM bank 0 ($0000 - $03ff file-relative offsets)

000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0003f0 54 4a 33 45 2b 8d f1 1f 2b 2b 20 20 00 ff 1b ff

ROM bank $1f ($7800-$7fff file-relative offsets)

007c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
007ef0 00 00 00 00 00 00 00 00 00 00 00 20 00 00 1f 03
007f00 a2 c0 86 3f 4c 00 fc a2 df 86 3f 4c 0f fc a2 c0
007f10 86 3f 85 ab a9 fc 85 ac 6c ab 00 48 a9 c0 85 3f
007f20 68 4c 09 fc 01 02 04 08 10 20 40 80 fe fd fb f7
007f30 ef df bf 7f 00 00 00 00 00 00 00 00 00 00 00 00
007f40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
007ff0 54 4a 33 45 2b 8d f1 1f 2b 2b 20 20 00 ff 1b ff
008000

The relevant CPU vectors are in the ROM file at both offsets, to be paranoid, but Stella does report that $fc00 = bank 0, so the ones at $03f0 (file) should be at $1ff0 = $fff0 (mapped)

I am a bit mystified by the way the 3E+ bank switchers display in the Cartridge 3E+ widget — in particular, the allegation that $fe00 is mapped to $0400 (file-relative, I presume?) which doesn't make much sense to me — nor does it appear to be true.

If I command bank 0 to map into another segment in ROM (e.g. here it's at $f400) I see the correct bytes at what I can only assume are $f7f0 or so:

The last few bytes beginning at $03f0 & $7ff0 (binary-relative) mapping into $1ff0 = $fff0 seem to have been replaced by … something. I've searched the binary itself and there's no occurrence of the sequence anywhere in the file, so it's not just copying or remapping from elsewhere in the ROM image. In fact — not only does that byte sequence not exist in the ROM, but there are actually no occurrences of the bytes $be nor $27 in the entire file.

• I have confirmed that another 3E+ ROM runs correctly without this remapping, although it's not 32kiB long.
• Tried in v6.7 (Fedora RPM), GitHub HEAD ( 4ba7bfd ) with the same outcomes
• Tried in Gopher 0.35.2 and no (related) issues
• The NMIVEC $2020 is for PlusROM functions, $ff00 RES and $ff1b IRQ are correct
• The corruption seems to not be affected by the "randomize RAM" developer settings and occurs even in "player" mode
• The "garbage" values seen are consistent between starts, they're not random

I'd be grateful for any assistance.

[thrust26]

There are numbers problems in the debugger when it comes to bank switching. Most likely you have found another one.

Which ROM were you using?

[brpocock]

This is a new (and very broken in its own right) ROM I'm working-on, I will try to reduce it to a minimum viable test case today and upload it here, if you'd like. Thank you!

[thrust26]

That would be very helpful.

[brpocock]

3Eplus-ROM-with-RESVEC-wrong.a26.gz

I had to GZip to appease GitHub …

This ROM should, in its current form, start up, send a 4-byte "HELO" ping to the PlusROM server at http://delving.interworldly.com/plus and then show "all the colors" flashing with two black bars (PF2)

The correct reset vector is $ff00, and if I enter with stella -debug and pc ff00 then run, I get the expected output, but starting it normally does not work, since it starts up with some arbitrary PC.

I've intentionally used the expanded RAM for the background color counter, so this test should be doing very many of the things that a real game would do.

[thrust26]

@brpocock Today I did some analysis on the problem Stella has with Delving.

After a lot of debugging I noticed that the last pageAccess, which is used for access to $1fc0..$1fff is not set. And the reason is, that the PlusROM hotspots are in the same area. Hotspots must be accessed directly.

This causes an unforeseen situation, where the code assumes extended RAM (e.g. SuperChip) and peeks to RAM for $1fc0..$1fff. This address range contains the startup vector, which now becomes random. The game will not work and the debugger will show the random garbage you noticed.

After finding the bug, the fix was dead simple. 😄