Mario's Mystery Meat Romhack Graphical Glitches

[DarthPidgey]

Textboxes in the game turns a background layer white after the textbox disappears which later prevents progress. Textboxes are also missing arrows indicating there is more text ahead. Textboxes also are lacking cursors so you don't know what choice you are making which impacts the quiz and the earthbound spoof fight. None of these glitches occur on a real 1st rev Super Famicom with a SD2SNES on latest firmware

[littlegamer87]

I can reproduce this on stable. This is an SA1 hack so probably an SA1 issue somewhere. Hack is made in Lunar Magic 3.11 so should have SA1 pack implemented. Interesting, but be advised that this can still be an illegal SA1 operation, SD2SNES's SA1 is not perfect either.

/edit: As expected setting breakpoints on SA1 registers written by the CPU triggers a break. This hack is also writing to SA1 multiplier registers by the CPU. Mister does not support this because on original hardware the CPU has no access to it. SD2SNES does allow this which is technically inaccurate.

[littlegamer87]

I would like to use this issue to start a discussion, because I am starting to question whether it is necessary for the core to be so strict about this.

This only impacts SA1 homebrew/hacks, the only new content the SA1 will ever see. I understand very well that this would never work on a real SA1 cart, but this content does not exist on SA1 carts and nobody will make one. It does run in emulators and flash carts. That also makes it hard for romhackers to find out that this is an issue if this core is the only platform that won´t run it.

It should be possible to support this without breaking the published SA1 library, and doing so would open the core up to more rom hacks and also less reports like these. The fact that it runs on a flash cart is probably by choice too.

Inviting those with an opinion to share.

[birdybro]

Generally if it runs on a flash cart that means that the underlying hardware supports it, so usually it's a good idea to do things the underlying hardware can do.

There are only a few exceptions personally that come up, like supporting theoretical address spaces for sram to the full limit not being possible in the core, or supporting the theoretical address space limit for the MegaCD memory cards, etc... Those can be argued to not be representative of what was ever possible or even done contemporaneously on the hardware at the time it had active development for it.

It's more of a philosophical question than it is a technical one though. The person maintaining the repository gets the say in what counts or doesn't count to be included since that person is the one that has to deal with the long term implications of that. All of our opinions on it are not that important.

This specific hack didn't even used to load before when I last tested it (2+ years or so), so some recent changes must have made it slightly more compatible.

[littlegamer87]

I built a core that allows the cpu to access the sa-1's alu, that does fix the problem with this hack it seems. It does not fix the vanilla level design contest 8 which does the same thing - that might be an alu timing bug. I am looking into it.

SNES_SA1_w_CPU_ALU_xs.rbf.zip - This build excludes commit b8c3d4a because we know it can cause SA1 regressions.