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:
All PRG-ROMs of any given size are the same. Otherwise they differ only by iNES header and the presence of CHR-ROM.
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.
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.
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.