nesdev.com

WB means the font may not be present in CHR RAM yet. If I made it treat WB as nonfatal, it'd crash with FON.

Several discretes are supported, including that of Holy Diver (hence the previous name). There's supposed to be a stub every 16K to switch to the last bank. Please describe in more detail the exact mapper setup that produces WB for you, so that I may reproduce it in an emulator.

Hmm, I had always presumed that this project was basically the exact same ROM just with different headers and the banks duplicated different numbers of times, i.e. all banks would be more or less the same content but with just a bank number changed. Apparently this assumption was wrong.

Like I thought it was just "put this ROM on a cartridge and it will tell you what board it's on". I guess it's not that, but that's what I had assumed. Sorry.

My error was further misled by this description:


From what you're saying it sounds like the problem isn't "didn't start up in last bank", but rather "could not switch to last bank, thus not able to start up"?

What I was really looking for was a quick way to get a ROM that would test mapper 0 for PRG-RAM and CHR-RAM. My first attempt to just change the header of the M0 test failed at this (crash). My second attempt to just change the header of the M34 test also failed (WB error), and after consulting a morse code chart and decoding "WB" and reading the description, I removed all but the last 32k of PRG from it, which caused it to succeed (though it reports 128k PRG and U*ROM, but that's not really an issue here).

What exactly is in the other 3 banks anyway? Why wouldn't they all be usable as "startup" banks?

Another difference is that the last bank has an additional flag set.


It is that. It's just that I don't want tests to incorrectly pass or crash when an unsupported mapper is used. Examples of unsupported mappers whose behaviors I had to take into account include mapper 31, which is why the WB code is repeated at 4K intervals. (See "Place wrong bank code into all 4K banks".) What makes you think it isn't?


I agree that this description is misleading. It has been fixed in the description that I will upload to GitHub after having finished making the promised changes and having answered follow-up posts.


Yes, as I have clarified in the description that I will upload to GitHub after having finished making the promised changes and having answered follow-up posts.


I took M0_P32K_C8K_V.nes and changed its header as follows, and it worked.

The purpose of the 07 is described in section "Byte 11 (Video RAM Size)" of article "NES 2.0". What emulator are you using, and what header did you use?


Whatever make_roms.py puts there.

Less flippantly: I don't remember all the decisions that I made four years ago when I originally made this. To answer your question rigorously, I would have to look in make_roms.py. How urgently are you expecting the answer?


I don't duplicate the entire test into all 4K banks because I don't want to have to fit absolutely everything into 4K in case there's a desire to support mapper 31 in the future.

There's no urgency to any answer. I'm just giving feedback because you asked why I was confused by the error.

I was just wrongly expecting all the banks to be the same except for bank numbers, so I thought any bank would be fine for booting up. I didn't think all the custom ROMs for various boards were going to be putting different stuff in each bank.

I was not trying iNES 2 headers, only setting CHR-ROM size to 0 to specify CHR-RAM, i.e.


On second look the crash is actually FCEUX's fault, so don't worry about that. nintendulator rejects it as a bad header, and puNES accepts it as 0 = 8k CHR-RAM where it runs OK. Didn't run into the same crash with the modified M34 ROM because that header was already iNES 2 to begin with, apparently.

Any 16K bank is fine for booting, as it tries to write $FF. Search for gnromstub in src/wrongbanks.s and tools/make_roms.py.


All ROMs of any given size are the same. But the 32K ROM is not the same as the first 32K of the 256K ROM because the "is last bank" flag is in a different place.
The "wrong bank" code repeats every 4K, as that's the smallest window size for existing mappers.
The "jump to last bank" code repeats every 16K, as that's the smallest boot window size among mappers that don't guarantee the last bank is switched in at power on.
The test engine itself repeats only every 256K. It repeats that much mostly to work around some difficulties I had in getting SUROM going.


Flags 7 lower nibble = 8 means NES 2.0. To use traditional iNES headers, you'll have to zero that nibble.

Ah yes, missed that. I was actually using quietust's nes2edit program, though, not a hex editor, and apparently it does not update the radio box for "Standard iNES" vs "NES 2.0" when you load a ROM.

Also, I tried tracking down the crash in FCEUX but I think it's already been fixed in the current SVN build.

What I meant was that I expected any bank could boot from itself, because I presumed there was no reason for them to be different. i.e. I didn't expect a failure to switch to the expected "last" bank to fail everything.

Anyhow, again, not actually a problem and I don't expect you to restructure it to do things the way I would have done, just explaining what confused me (i.e. my own assumptions + that description of the WB error).

Thanks for the questions. I'll rephrase README to answer them better. For example:

However, you can't chop off the end of a larger ROM and use that on a smaller ROM, as it will be missing the special tag that identifies it as the last bank of the ROM. This is intentional in order to prevent builds with disconnected upper address lines from silently working.

Do you have any other ideas for better organization of the documentation?

Well, maybe I wouldn't suggest that particular text. I don't know if anyone else would do what I did, because my actual problem was just that I failed to edit the M0 ROM's header correctly. (My fault for not verifying the hex, or for not interpreting FCEUX's crash correctly, or maybe nes2edit's fault for not displaying the "NES 2.0" flag.) I only started trying to adapt the M34 ROM because that attempt had failed.

What I think would be more helpful is just to say a version of something you said to me earlier in this thread, something like:

I think saying that is a lot simpler and addresses the point of putting this ROM on various mappers to see what it will do, which is exactly why I wanted to use it in the first place.


So, as above, I don't think it's very useful to say this specifically, but also because this text just raises another question for me:

Why do you want to produce a morse-code-only error when you could produce one that displays diagnostic text as well? The choice isn't really between "silently working" and "morse code error only", is it?

It's a very onerous way to diagnose an error-- and that's why I was making the suggestion to put the actual morse code in the documentation (instead of making it even more onerous by requiring users to look up a morse code table as well). Shouldn't it only be used as a very last resort?

Or to put it a different way: this ROM does many useful tests at once, most of which are independent, but here you seem to state that this one test result has veto power on all the others. This is why I wanted to use it in the first place: I knew it could test for the presence of PRG-RAM and CHR-RAM, so I thought it would be a good/easy way to test various emulators' response to different headers.


Anyhow, that's just a suggestion, not a demand or anything. It already works fine, and it's certainly acceptable and useful the way it is.

I'd have to sit down for a while to figure out how to fix that, and whether it'd be practical to limit the size of the test's PRG ROM to 16K so that it can be duplicated into all 16K banks to ensure that a message is displayable even for a truncated ROM. That limits the ability to add more mapper drivers or features, just as fitting my controller test in lidnariq's 8K test cart limits what I can test.


That's done.


Something has to have veto power because ultimately I have to kick it out to FON when it can't display text. The more things I make nonfatal, the more likely the execution is to end up at FON, which the user is unlikely to find useful.

Well, I don't know if "truncated ROM" is really a problem you need to address, that's just something I happened to try in this case due to misunderstanding, but maybe something similar could arise from e.g. a board without a working bank switch or otherwise miswired ROM? ...or maybe not worth worrying about?


Hmm, well, eyeballing it with shiru's space checker it looks like there's only about 8k of stuff in the ROM at the moment. If 16k is your target size, you're probably doing okay?