TASEmulators
BUG: Axelay NES Tech Demo running on Mapper 23 doesn't work
This tech demo runs fine on Mesen. There's some problem with FCEUX emulating Mapper 23 exactly to get this working like it does on real hardware and Mesen.
YouTube of Emulation: https://www.youtube.com/watch?v=AA9zGxJij5g
Tech Demo ROM link (creator's Google Drive): https://drive.google.com/file/d/1O8QpTlegVoxHFxteGTNu9C88_wV44G9H/view
Fceu expects prg to be power of two. This version of the ROM has a PRG of 48K which can cause mask issues when used. Considering it's mapper 23, it should be at least 64 or 32k. There is another version which has 32k prg and that works. If there's a reason to run with this ROM version in fceu instead then modify initial prg loading in mapper 23 to load prg C000 and E000 at banks 4 and 5 respectively
@negativeExponent Ahhh, gotcha. I couldn’t find the 32KB version anywhere of this tech demo but I can modify the original in the way you described to try it out.
But my question is, if 48KB runs on real hardware - why wouldn’t it be FCEUX’s goal to emulate the NES properly rather than “expecting” standardized chips / sizes and failing to run otherwise? Doesn’t that make it less accurate?
If Mesen emulates this properly and FCEUX doesn’t. I would say that FCEUX should consider being more lax as is with real hardware to allow for emulating this properly. Or am I missing something?
Also, would you mind linking that demo that works on 32KB? I looked for it since I can’t change the NES header on a phone to make this version work?
Use this.
this is practically the same rom with the last 16K of PRG (banks 4/5) mirrorored to make PRG a total of 64K.
and here is the 32K prg version of the rom Axelay_32K.nes.zip
dunno which demo is the latest
The 64KB one which I assume you modified manually is the latest demo and it works perfectly in FCEUX. Thank you very much for doing that for me. ☺️
it’s a cool tech demo fs. But the reason I brought this issue up is because the official final demo on the dev’s Google Drive is 48KB (they added music). 🎉
This demo plays fine in Mesen and not in FCEUX. The goal in making this ticket wasn’t to hack around to get the demo working (tho it’s hella cool) - but to discuss if FCEUX should properly emulate the 48KB version like Mesen does?
Is there any reason not to program logic to handle this rare use case just like Mesen or is Mesen incorrect for emulating this the way it does (making it work)?
Should I close this or is this considered something FCEUX should emulate as the official final demo of this game (what the dev tweeted) uses this mapper in this way?
It's not immediately clear how this WOULD work on a real NES. What happens if the mapper chip requests an invalid rom bank number? Is another bank accessed? Is FF returned? With the pow2 implementations it's implicitly clear: high bits of the mapper chip output are disconnected. invalid rom banks return the valid rom bank with the disconnected bits masked off.
A physical 48k PRG rom with 8k banks (or a combination of 32KB rom and 16KB rom with additional discrete logic) could be organized all these ways ABCDEFxx (x is disconnected, returns all FF or such) ABCDEFAB (wrap around, I guess? not very hardware-realistical, but I HAVE seen other emulators do this, beacuse at least it's a rule that can be applied with simple logic in a consistent way, i.e. modulo equivalent of masking. I don't think it's a good idea, though) ABCDEFCD (EF selected by higher bit, but final two banks not patched on by higher bit, falling through to CD) ABCDEFEF (this.. can naturally fall out of the discrete logic too, but it's hard to explain how) (this is negativeExponent's linked solution) ABCDEFEF (I wrote this again because this is what mesen does, but by an alternative explanation which requires a different example to see clearly: ABCDExxx -> ABCDECDE i.e. work backwards from the final bank to fill in at the end)
The VRC defaults to selecting rom bank $FF (which is surely invalid) for the final $Exxx-$Fxxx bank. So which bank is selected by that? x, B, D, or F?
An actual REAL hardware device would probably be a 64KB rom with SOMETHING chosen to put in the end (F, probably). It would actually be set up like this: ABCDEFxF
How big are the banks, anyways? Some mappers can interpret banks as various sizes. How should those be filled in? Who knows?
"alternative explanation" - this is most commonly implemented by unrealistic "wisdom" in the VRC mapper which defaults it to a value other than $FF ... for instance, in this case, $05 because it's the highest-numbered bank. But if you model the VRC chip and the PCB logic at separate layers, this is impossible, because the VRC is stuck defaulting to $FF which means at the PCB level you have to model the incomplete bank assignments somehow by choosing one of the arbitrary rules
So now I hope you see this isn't as simple as "do what the NES does". As far as I'm concerned, these NPOT mappers are illegal hacks until someone proves it otherwise by putting it on a physical cart. Then we can talk about how to emulate that hardware.
I want FCEUX to emulate homebrew games, but if the dev has made a 64k version and a broken hardware-incompatible 48k version, then let's PUNT for now and only support the 64k version. if the dev hasn't made a 64k version, then please ask them to make a 64k version. Homebrew roms that aren't ACTUALLY hardware compatible are quite common, you know, until you have someone analyze it and fix the final problems such as this strange selection of rom size.
I would also consider detecting broken homebrew roms and "fixing" them, by padding as expected in this case. That's better than mucking up the mappers with faux hardware details. I'll be thinking about if there's a way to add that. But if we can get a 64k game, forget it and get a 64k game.
@zeromus I really appreciate the insight, like, a lot. Thanks for the write-up, you're one of the rare few emu devs that is still p nice (and informative) even when a user is wrong. And given your info, I'm seeing this as more of a "It worked in MESEN and that's all that matters" homebrew dev situation (given most use MESEN for development). I incorrectly assumed if they were making a tech demo, they'd have tested it on real hardware - but it's v clear now the dev didn't do that.
They never released the final demo in the correct format (the final demo has music and is 48KB, sans music the rom is 32KB and works as expected) so I'll tweet them about it. negativeExponent was the one who padded it to get the final (music) version of the demo to work on FCEUX.
As for detecting and padding the ROM, that seems doable. Open ROM -> ROM doesn't work -> FCEUX does a little test to determine if the cause is incorrect PRG ROM size and pads / fixes the file. Obviously this isn't a priority by any means since there's unlikely to many more instances of this exact situation happening in the homebrew dev world. But, the fact that MESEN runs the "official" ROM "as the dev intended" means this specific dev's mistake, well, other's may make the same one in the future. So fixing the ROMs rather than emulate incorrectly (MESEN, tsk) will be better for the community IMO.