nesdev.com

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?

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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
...

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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...

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

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?