"The Question" ported to 32X

[haroldoop]

That's really weird; AFAIK, there's no routine on the engine that would reach beyond the size of the compiled code.
Anyway, I suppose the compiler should have padded the ROM, anyway; I should implement the improvement on a future version.

Anyway, I'm happy to know it's working on real hardware!

[notaz]

EDIT2: The current NeoMyth menu mirrors rom data to make certain games work that expect mirroring.

Could you share an example of such a game?
I'm not aware of any games that are relying on mirroring.

[Chilly Willy]

EDIT2: The current NeoMyth menu mirrors rom data to make certain games work that expect mirroring.

Could you share an example of such a game?
I'm not aware of any games that are relying on mirroring.

God, it's been YEARS since I worked on that, but there were two types of mirroring needed, hence the three settings in the options. HW uses the mapping hardware in the cart to mirror the rom like "normal" - if the rom is 1MB, three mirrors occur in the next three MB to fill the 4MB rom space. This is the default and works for damn near anything. FORCE was added for something, no idea what anymore. It loads the rom, then copies the rom contents via software through the rest of the rom space IMMEDIATELY after the rom. There was something that was an odd size, but still expected a mirror immediately after the rom. OFF simply has 0xFF filling all the space after the rom contents out to 4MB. That is the setting for this game, and I seems to remember some other games needing it, not how many or what, but at least a few.

I worked from reports of games not working, looking to see why. Sometimes the games need a patch, and I'd make a patch for the game patching system to distribute with the latest menu. Sometimes it was a mirroring issue, and I'd implement a new mirror mode to handle the game. You'll maybe find a post on it at SEGA-16 or the NeoFlash forums for the MD cart... one or the other.

[Sik]

That's really weird; AFAIK, there's no routine on the engine that would reach beyond the size of the compiled code.

Taking a guess: when the setting is set to HW, it'll get confused if the ROM has a weird size and end up trimming part of the end of the ROM (and mirror everything before that). Then the game crashes because part of the data is missing.

[Chilly Willy]

That's really weird; AFAIK, there's no routine on the engine that would reach beyond the size of the compiled code.

Taking a guess: when the setting is set to HW, it'll get confused if the ROM has a weird size and end up trimming part of the end of the ROM (and mirror everything before that). Then the game crashes because part of the data is missing.

No, that can't be the case. There's no difference in the read code between any of the rom bank aliasing modes. The only difference between HW and OFF is OFF fills the space after the rom data with 0xFF and doesn't set the rom mapping for mirroring. The rom size used is 4Mb, or 512KB, so it's not accidentally making the space too small. Note that if the rom data is smaller than the rom space, HW doesn't fill that space with anything - it's left at whatever it was before the data was read. If I ever do an update, I'll fill the space up to the rom size with 0xFF. That would also fix this issue as I made a padded version of the file, and it works in HW mode. So it's just something about the space immediately after the file data up to (at most) the next Mb size.

By the way, the cart description is still "Example startup code for 32X". You might want to change that to something like "Powered by VN32X". Just make sure to pad the length with spaces - those rom header fields are very picky about the lengths. You really ought to pad your rom files to at least the next Mb size as well. You can pad with 0s or 0xFFs.