Holy Mapperel (formerly Holy Diver Batman)

Holy Mapperel
NES cartridge PCB manufacturing test

Source code is on GitHub: pinobatch/holy-mapperel
____________________

Paul Molloy (infiniteneslives) is selling INL-ROM circuit boards for making NES game cartridges. These boards are configured at manufacturing time to support the mapper circuits required by several games. Among them are Holy Diver by IREM (#78.3) and Batman: Return of the Joker by Sunsoft (#69). Putting those titles together results in something Burt Ward as Dick "Robin" Grayson might say: "Holy diver, Batman!"

To make testing easier before he ships the product, he has commissioned a test ROM that automatically detects the mapper, PRG ROM size, PRG RAM size and battery backup, and CHR ROM/RAM and size. It tests every byte of RAM on the cart and basic functionality of the mapper, though nowhere near as thoroughly as blargg's tests. If something is seriously wrong, it beeps out 2 or 3 letters of Morse code describing the error; your local ham can interpret these for you. Otherwise, it displays the results on the screen and beeps them through the speaker.

It's also useful for people learning to make NES reproductions. If you can successfully make a Holy Diver Batman cart on a given board, you can reproduce most games that use the same board.

Supported mappers: SxROM (1), UxROM (2), TxROM (4), AxROM (7), PNROM (9), FxROM (10), INL-ROM Action 53 (28), BNROM (34), NROM/CNROM/GNROM (66), JxROM (69), IF-12 (78.3), TxSROM (118), UxROM (180)

Try Holy Diver Batman 0.01 on your devcart.

To avoid trademark problems, the project is renamed to Holy Mapperel as of version 0.02.

One thought that occurred to me: for battery-backing detection, you should be able to detect if the user hit RESET instead of power cycling by using a fingerprint in NES-internal RAM. If it wasn't enough time to fade from internal RAM, it wouldn't have been enough time to fade from cartridge RAM either.

Also, the README doesn't seem to mention the "LB" or "SU" morse codes.

Thanks again Tepples.



That's an interesting thought. I think it'd work for detecting TSROM vs TKROM well, although a faulty TKROM (eg no battery) Would probably still pass as TKROM because of the diodes and caps protecting that supply from being drained by the NES. It takes a few mins for a TKROM with missing battery to discharge the cap and corrupt data.

the .7z download link gives text gibber...

Am I/my browser doing something wrong?

The .7z file should be opened in 7-Zip. If you're already using 7-Zip, then perhaps p7zip (the command-line version of 7-Zip used by the archive manager in my OS) has a bug. Or did you accidentally download it as .7z.txt? If so, I might need to figure out how to add 7-Zip's MIME type to my web hosting.

There's no means to download it in the traditional sense (the .zip downloads just fine in my browser)

But the .7z just opens a new page (address: http://pineight.com/nes/holydiverbatman-bin-0.01.7z) in my brower with all that gibber. I suppose I could copy paste it into a .7z file I create myself or boot up my linux machine and wget it quick. But I don't get the impression that's the desired means of download.

The file is being served with MIME type text/plain for some reason, and so your browser ignores the extension and tries to render it as text. You can right click on the link and select "Save As" and the file will save properly.

What browser are you using? Both Firefox for Linux and Chrome for Linux start a download.

EDIT: Grapeshot is right, as confirmed through

I'm looking up how to set MIME types through my web host.

EDIT 2: After I appended the following to the site's .htaccess, Wget confirmed the correct Content-type.

save as worked. I also refreshed and was able to download it by normal means, guessing you fixed it, or it was a fluke? Anyways, I'm using firefox and it's working fine now.

Got MinGW and MSYS installed and working through building things for myself on my windows7 64-bit machine.

First thing I noticed is all the src directory names for files including files which are also in the src directory.

Changing things like



fixed those up easily as I run into them while compiling.

But now I'm running into something kinda funky...

line 540 of main.s and surrounding:


I don't really understand the funky notation of the adc #'A'-'9'-2-64 and there's just a lonely little semi-colon on the next line??? Commenting that line out and continuing on for the moment...

Looks like I got through all that to the point of where I need to get python up and running.

Include paths changed from older ca65, where they were relative to the current directory, to newer ca65, where they are relative to the directory containing the source code file.


This also changed from older ca65 to newer ca65. Newer ca65 requires constants used as immediate values to be positive integers, not negative integers. Change it to the following:



'A' means the code unit for the character LATIN CAPITAL LETTER A in ASCII encoding, which is $41.
'9' means the code unit for the character DIGIT NINE in ASCII encoding, which is $39.
'A'-'9' means the difference between these code units, which is $41 - $39 = $08.
The minus 2 includes one for the fact that 'A' and '9' are one apart, and one for the fact that the carry is set on entry to this line.
The minus 64 compensates for the fact that the glyphs for characters with ASCII encodings $20-$3F and $40-$5F are stored at tiles $20-$3F and $00-$1F.

I should add these as comments to the next version.


Not a semicolon, a colon. It's an unnamed label.

Do I need to make another release targeting the new version of ca65?

Understand all, thanks for the info. Fixed up with your suggestion and compiling assembly files just fine now. No need for another release, I'd rather just stick with my current build anyways. Hopefully after I can get some of this flash identifying code written up in the near future. That might be a good time to release for new ca65.

I've successfully modified drivers.s in order to read flash manf/device ID's from PRG flash and CHR flash on NROM flash cart.

Some things should probably be moved around to a more appropriate location as my understanding is only mapper specific code belongs in the driver. I'm proposing a new file flash.s which would provide code in the prg-rom that doesn't get copied to RAM with the driver. With that setup the only code in the drivers would be prg flash sensing which is the only code that NEEDS to run from RAM.

I've pretty well settled on my hardware design for flashable discrete mapper boards. I discussed it over here which turned out to be pretty accurate. I've confirmed that there is indeed not enough address setup time before PRG R/W goes low. Driving /CE with ~M2 works great for my NROM board, I'll try BNROM next, but all signs point to success with this method.

PRG flash ROM
/OE -> PRG /CE
/CE -> ~M2
/WE -> PRG R/W

Here is code where I read the manf & device ID from a NROM, which has been tested and working on hardware. Reading CHR flash ID's works too, but isn't as interesting...


I'm sticking with my idea (or at least would like to support) to use NOR gates on a UNROM board which gives a free inverter. Only difference there is that PRG A14 gets inverted in that case. Which moves $5555->$1555, and $2AAA->6AAA. So $1555 conflicts with RAM mirrored down to $0555. That's pretty much smack dab in the middle of RAM. Shouldn't be too much of an issue so long as the driver isn't there, I'm guessing it is though... Chances are as long as I clean up after myself and temporarily store the value (code) in $0555 and then restore it I'll be safe. If those few (~8) instructions happen to land in the same exact spot you'd stomp over yourself though. What's the best way to avoid that with the driver code?

As an aside, any idea what happens when you write to $2002 PPUSTATUS? Guessing/hoping nothing, or at most resets the latch just like a read does. It'd be a bummer if it didn't decode the difference between R/W and caused a bus conflict when writting to $2002 and it's mirrors.

Nothing happens. The 2C02 has a lookup table that decodes the 5-bit input (A0,A1,A2,R/W,loopy_w), and only 12 of the 32 are decoded: w2000, w2001, r2002, w2003, w2004, r2004, w2005a, w2005b, w2006a, w2006b, w2007, r2007.

The CHR flash detection code could be put there as well, relying on the mapper driver's implementation of set_chr_8k to set the upper bits of the CHR ROM address.


Right now the driver is $0300-$04FF or thereabouts IIRC, but we planned to extend it to 3 pages. I could do that by changing the link script to move the mapper driver's run address down to $0200 and moving OAM up to $0700.


Ignored in an authentic NES, as lidnariq mentioned. You could verify it in Visual 2C02 if you want. But some famiclones that support enhanced graphics modes might be using w2002 for something.

Yeah that's what I was thinking. It might be easier to keep all the chr flash detecting in one location though. Assuming the flash detection was called after all other testing/sensing was complete, the chr flash detection could do everything from flash.s since it would know the mapper and board config. Either way would work though, doesn't make much difference either way.

That'd work for me!

Good to know it won't be an issue on the NES, if it is an issue on clones that choice could be for the developer to decide how to handle. Similar to whether one would choose to use 4 screen mirroring. There are options to keep the unlock registers from conflicting with RAM. For one, most homebrews appear to be 256KB these days which means there is no free inverter to be had on UOROM. For UOROM you could use standard OR gates and then a single inverter to generate ~M2 keeping commands at $2AAA/$5555.

So what kind of things will cause the "PROBLEM" message to appear?

I've got a bad SLROM board with a 128KB PRG chip and 128KB CHR ROM chip.

PRG side is fine, and the test reports SLROM correctly.

"128KB CHR ROM PROBLEM" is reported for CHR.

My first thought about the potential problem with the board was that only 8KB of CHR ROM was being made available on the 128KB CHR ROM game/test. So I was halfway expecting that it would report a good SLROM board was sensed but only 8KB of CHR-ROM was present. However it reported the full 128KB of CHR is present, but there is a "PROBLEM"

Since it reports 128KB does that mean the highest found bank tag is the 128KB'th bank? And since the text is displayed properly that means the first bank is seen just fine. So my guess would be there is a problem with a few of the upper address bits that prevent every bank from being seen? Or perhaps every bank is seen, but the pseudo random pattern isn't being read back properly and it's reporting "PROBLEM" because of that?

The detailed result is "0003" I couldn't find any info in the readme as to what this may indicate to me.

Ideas?

PROBLEM is displayed when chr_test_result is nonzero, and with CHR ROM, that happens when the bank numbers are read back wrong in 8K bank mode.


The detailed result depends on the driver. The fourth nibble comes from a CHR test, and in the case of MMC1, mmc1_test_one_chr_window in mmcdrivers.s tests 4K banking. So there may be a problem with how your MMC1 clone sends the bank number to the CHR ROM. Does it work in an emulator? Or in an authentic SLROM board? Might you have transposed two CHR bank lines? Do I need to display on the screen what is being read back from the ROM, byte-by-byte?

I figured it out for myself by replicating what I thought happened, and confirmed the indications match.

Basically I had a SLROM board that was programmed with a SNROM file on the CPLD.

So it was basically configured as a SLROM board with only 8KB of CHR-ROM. My expectation was that would give a passing result, but with 8KB of CHR-ROM instead of 128KB of CHR-ROM with a problem.

No changes necessary AFAIK, I just wasn't sure how everything worked well enough to diagnose issues.

It looks only at the last bank when calculating how much memory is present. If your SNROM fusemap is programmed to hold CHR A13-A16 high, it'll see the last bank but raise a PROBLEM when it can't see the first. If CHR A13-A16 were held low, it would have detected 8K CHR, which is SNROM.

The font is in all 8K banks.

Gotha, Makes sense now why I got exactly what I did. I wouldn't change anything with the test rom. My only suggestion would be to explain some of what you just did in the readme. CHR Size determined by largest tag found, "problem" if not all tags found, font in all CHR banks, etc.

Found this:


Holy Diver Batman, it's Dio! (memegenerator.net)

Is it time to revise this test to support new ca65 and incorporate new findings about the FME-7? Are there any other mappers that would be worthwhile to incorporate?

Yes, add the support of new findings of FME-7. Probably you should add other mappers too eventually

if you're interested in adding more mappers, here are a few I've got up and running since the release. Some might be of more interest and others happily avoided as you see fit.

Colordreams mapper #11: pretty basic, I'd recommend adding this one. It's a pretty great choice for homebrew considering it's the cheapest step up from NROM. Most prefer chr-ram, but this is one of the the most viable options for discrete chr-rom. My favorite trick is the simplicity of putting saves in chr flash without added circuitry/cost.

VRC's: I've got VRC1,2,& 4 up and running 100% all flavors of mixed up address lines and all.. VRC3 is entirely possible but I didn't give it much thought being so obscure. VRC6/7 would be cool to see as I'm sure there's interest in them, but I can't support them until I finish my next board rev due to sound resources. I could whip up a soundless versions fairly easily if it aided testing.

Irem H3001 mapper 65. Kind of obscure but I have it running. Prob not of much interest homebrew wise as the comparable fme7 is more popular.

DxROM / Mimic-1 mapper 206: I've done non 4 screen versions, could do a 4-screen version if there was interest or to support testing. Having a predefined stripped down mmc3 here might be of interest to some, that and the curiousness of 4-screen mirroring.

Food for thought, here are some others I'm considering adding support for on my end at some point in the hopefully not so distant future.
Tengen rambo-1 mapper #64
Namco mappers 19/210
MMC5
...

There seems to be a slight advantage for ease of thread safety (and to an even lesser extent, code clarity) with "directly mapped" registers (such as those in FCG, N163/175/340, VRC2/4/6/7, X1-005/017, &c) rather than the indirect register addressing like the MMC3 & FME7.

Is there any significant difference in fusemap size? I assume the quanta of "fits into 36/72/36+72/72+72 macrocell cpld" is coarse enough that there's no useful ability to trade off pin count for fusemap complexity.

Yeah any time you can cut out the indirect control register is nice for saving on macrocell resources, but then the limitation on I/O comes into question as you bring up. That savings can be doubled when you have to put the same control register bits in two separate cplds as I sometimes do. The two cpld solution does typically have plenty of I/O to work with. The main I/O limitation I have is based on how I choose to route my boards years ago, and adding support to other mappers without trying to change much from one pcb rev to the rev. That limitation of course wouldn't exist for someone designing their own board for a specific application, and not needing to find a way to get A0-A7 routed in depending on what flavor of vrc they wanted that day.

Something else I didn't learn as an issue until late that is a facet of my I/O limitations due to routing is due to the internal restrictions of the cpld's internal routing. Most cplds of this size are split into four function blocks, and those are tied to their dedicated I/O. Since I can't really move around I/O on my pcb I frequently have to experiment juggling logic around from one cpld to the other for the fewer cases where I have one output signal routed to both cplds. The vrc irq counter was proving an extra pain because of the extra logic needed for the prescaler. Hard to explain/understand but basically I found a point where I couldn't fit more bank switching logic in the one cpld because the irq counter was sucking up multiple function blocks, then restricting my use of the I/O in that function block. The trick I found to get around this and allow me to fit 256KB PRG/CHR was to put the prescaler in a separate cpld, and have that cpld signal to the counter logic in the other cpld that the prescaler reached zero.

So yeah I'm probably rambling on too long off the subject of the thread here, but I guess my point is, if you don't plan out your I/O assignment based on the internal routing of the cpld (something I still find challenging) you can find yourself limited not by number of I/O or logic cells, but by internal cpld switch matrix route ability.

Some more slightly related ramblings:

And then you have the dynamic of Xilinx bringing their XC9500XL series to end of life as announced this spring. They're discontinuing the PLCC package I've been using, and jacking the price ~25% on the QFP family member. It's not just the added cost of switching to QFP that is concerning but knowing that the next step is to axe the entire family in a matter of a couple years most likely. Out with the old 5v tolerant low logic solutions and in with the new level shifted non-5v tolerant high logic solutions when you want something larger than SNROM. So now I'm finding the lattice Mach xo/xo2 line more desirable for mappers needing more than ~32-36 macrocells. Which brings 256-640 macrocells to the plate while still in a financial budget that works for a single game dedicated board/cartridge. So if a guy were to be looking to design a game with a mapper more capable than mmc1, suddenly you have 256+ macrocells sitting in your lap. Lots of capability that negates much of the concerns for logic limitations discussed in the beginning of this post. While we're not necessarily I/O restricted on a 100pin TQFP, we are restricted based on how many signals need level shifted to 3v. So in this dynamic the indirect control register is a much preferred trade off between logic and 5v input I/O.

So yeah.. It's complicated...

How much more does, say, the Action 53 mapper cost compared to a plain old UOROM (161+32)?

How much does it cost to level-shift each pin?

Action53 multimapper with 512KB of PRG-ROM still fits in a smaller CPLD, so it's more cost effective to still use a smaller 5v-tolerant CPLD. It used 27 macrocells in the XC9536XL. My plan would be to migrate it to use A 32 macrocell lattice M4A3 or isp4000V series CPLD that are close to $1.26 which is comparable to the Xilinx XC9536XL used thus far. So the concerns of level shifting each pin aren't an issue.

The parts cost between a discrete mapper and the CPLD and 3v supply is around $1.50. There is added labors involved with CPLDs compared to discrete mappers though too, but I've tried to keep those minimal for Action53 doing most the work myself.

For a more complex mapper on par with the MMC3/FME7 (effectively something with an IRQ counter and/or fine CHR banking) and beyond that would now make more sense to put in a non-5v tolerant CPLD the cost per level shift would most likely be grouped by 16bits at a time.

FME7, fits perfectly in 16bits, where MMC3 comes goes one bit over with the addition CPU A0
(8) PRG-DATA
(3) PPU A10-12
(3) CPU A0, A13-14
(3) control (PRG R/W PRG /CE M2)
17 bits total.

I'm toying with the idea of using a voltage divider for something like CPU A0, but I'd have to do some thorough testing before that sat well with me. There are smaller options for 4-8bit level shifters, but I'd rather not hassle with them for stocking reasons. EDIT: I guess there are single bit levelshifters under 10cents in qty..

Once pushed to the point of needing two level shifters there are added benefits since you'd get the whole CPU bus down to 3v. Now you're no longer restricted to 5v memories for WRAM/PRG-ROM. So super cheap 4-8MByte 3v TSOP-44 flash becomes attractive if you can stomach the finer pitch that comes with them. That and the cost of 5v sram/flash has been on the rise some of mine have even been EOL recently as well.

The actual cost of level shifters is greatly dependent on quantity purchased, but $0.50/16bits is prob the best number to use I'd say. There are added assembly costs as well to consider.

Could I request that the morse code be spelled out in the readme?

Like instead of just saying "WB" say "WB .-- -..."

Good idea.

That means I need to do these before pushing to GitHub:

1. Build under recent ca65 and Python 3. Version 2.14 changed a lot: #<-, .include path, and -o first.
2. Rename to "Holy Mapperel" so as not to anger the Warner Bros., the other Warner Bros., or IREM.
3. Find and document all Morse crash codes.
4. Show dits and dahs in manual

And these after:

1. File an issue to track hardware verification on authentic donors of all supported mappers, so that error codes don't indicate defects in the test itself. The test for FME-7 PIT, for instance, is known to be defective because its acknowledgment behavior wasn't confirmed at the time.
2. 2K WRAM support

Sort of related request: does WB have to be a hard fail instead of just a diagnostic message? Is it not valid to run this on a discrete mapper board?

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?