Bit 0 of RAMBO-1 CHR bank registers

In the MMC3, bit 0 of bank registers 0 and 1 isn't wired to anything because these registers use a 1 KiB bank number B to switch in the lower and upper half of the 2 KiB bank containing that 1 KiB bank: B & $FE and B | $01.

• Mode $00: 0 lower, 0 upper, 1, 1, 2, 3, 4, 5
• Mode $80: 2, 3, 4, 5, 0 lower, 0 upper, 1, 1

The MIMIC-1, a stripped down MMC3 in some Namco and Tengen games, doesn't have mode $80.

The RAMBO-1, used in some later Tengen games, is an enhanced MMC3 clone. It introduces a CHR bank mode with eight 1 KiB banks.

• Mode $00: 0, 0, 1, 1, 2, 3, 4, 5
• Mode $20: 0, 8, 1, 9, 2, 3, 4, 5
• Mode $80: 2, 3, 4, 5, 0, 0, 1, 1
• Mode $A0: 2, 3, 4, 5, 0, 8, 1, 9

How exactly does bit 0 of registers 0 and 1 of RAMBO-1 behave with bit 0 in both 2 KiB and 1 KiB modes? Should I write a test of basic PRG and CHR bankswitching behavior of MIMIC-1 (#206), MMC3 (#4), and RAMBO-1 (#64), and have someone with a modded cart run it?

I started on my RAMBO-1 verilog implementation last week, but haven't finished coding it up and testing out in hardware yet. So all I know for sure is that you have a good question. I'm sure someone knows the answer though, shouldn't emulators be able to tell you if the answer in the documentation is ambiguous? Otherwise they'd have CHR bankswitching all goofed up when playing every game pretty much.

I assume that the Reg0 and Reg1 of the RAMBO-1 aren't shifted back and forth when changing CHR modes. Meaning that it would be similar to MMC3, which I realized ignores bit 0. Except the RAMBO-1 doesn't ignore bit 0 when all CHR registers are in use (obviously uses all 8 bits). Doing anything else would require adding gates just to make things more complicated...

I Don't have a logical approach to MIMIC since they don't have $80 mode like you've pointed out. But I assume it follows suit with the MMC3. Hardware wise it's more sensible to line everything up where D7 always is directed to A17 etc.

I've got RAMBO and MIMIC boards, but no doubles that I'd be willing to hack up for a simple question like this. If you had the program running on RAM to do a cart swap I could test it in a jiffy though. EDIT: but I've got some easier ways to find out using hardware tools before we mess around with that.

I'll rely on emulators and a PowerPak when developing the tests, but relying on emulators got us games that work only in Nesticle.


I imagine that there are plenty of corner cases that the existing commercial games don't exercise, such as writing an odd value to register 0, or perhaps writing registers 8 and 9 before 0 and 1.


How do I make a program running in RAM catch NMI in order to reliably wait for vertical blank in order to switch between testing and displaying, or catch IRQ in order to do basic mapper IRQ capability tests? Or should one just skip any IRQ tests, use spinning on $2002 D7 (which has a known race condition) to wait for vertical blank, and just accept the missed frames? And how do I make a program running in RAM know what values are to be read back from CHR ROM, or what values correspond to the letters of the alphabet that would be used for displaying the results?

point taken.



Yeah the SRAM thing doesn't really work so hot... It's easier for me to test things by applying stimulus to the cart and probe things with my logic analyzer than anything really. That and I don't have to loose any games. I'll should be getting around to it in the next week or so, and post up here the results.

Game genie patching the ISR table? You might even be able to get away with just patching the MSB and a NOP slide.

For the other questions, it sounds like you might have to write the test specifically to the donor cartridge; "fortunately" there were only 5 RAMBO-1 carts, but (I just checked) all 5 of them put their alphanumerics in a different page.

As I understand it, INL is looking to do the same sort of pak-swapping used with TapeDump. The test program would have to load the actual test into internal RAM ($200-$7FF), enter a loop in the internal RAM, and wait for the cartridge in question to be inserted. The Game Genie boot menu would erase the program from internal RAM. Or were you talking about direct writes to the Game Genie's registers? Is there an emulator that supports this sort of swapping?

I guess the actual running of the test will have to wait until someone shows up who's willing to make a devcart from Klax, Road Runner, Rolling Thunder, Shinobi, or Skull & Crossbones. Any idea what the rarities on those are?

Although that's what I suggested, it wasn't a very well formed idea. I don't know enough to speak ineligibly on the matter. Really I'd rather test without using the NES at all. That's what usually do if I need to reverse engineer a chip. That way I can apply whatever sequence of signals I'd like, and not have the limitation of what the NES can physically do.



They are pretty common. I got mine when I was a kid by buying off video games stores that stopped renting em. Less than $10 on ebay, Rolling Thunder is pretty cheap but it's also one of my most beloved games... Really I don't need to do any destructive testing to figure out the bank switching. It's really pretty trivial. Now once it comes to figuring out how RAMBO-1 fires IRQ's a few cycles later than MMC3 it might be a little more tricky. I'd be willing to hack up a game for the greater good to determine a larger unknown like that.

BUT, to a point it really doesn't matter IMO. If it can be emulated and recreated in a dev/flash cart well enough to play the original games it's not of much worth knowing how it does what it does. If we like a feature we can just redesign it exactly how we'd like and have it well defined and understood. The only drawback there is if something is implemented slightly differently it might not work on the original RAMBO-1 (or any mapper) exactly right. In fact I see that as a benefit. That way people who didn't make the game won't be able to hack up old carts for homebrew productions (especially when not authorized by author). You'd have to use our own variant that would only be available on new PCBs. Basically our way of hindering hacking up old carts and supporting our community from within. I know there is the issue of emulator and powerpak support etc, but there are lots of smart people around here that could easily handle a new mapper update especially if it's well defined.

Then let me phrase the assertions in a different way that can be tested more easily with your logic analyzer rig:

1. In mode $00, does RAMBO-1 ignore bit 0 of register 0? If I write $0D to register 0, does it swap in banks $0C and $0D (like MMC3), or $0D and $0D (OR logic), or $0D and $0C (XOR logic), or $0D and $0E (adder logic)?
2. Repeat test 1 with register 1.
3. In mode $20, does RAMBO-1 ignore bit 0 of register 0? If I write $0D to register 0, does it swap in $0D (expected) or $0C (meaning it always ignores bit 0 no matter what)?
4. Repeat test 3 with register 1.

Does that look feasible?


One of the incentives to use existing mappers is that existing mappers have mapper numbers in the 0-255 range. Or does the PowerPak firmware support NES 2.0 extended mapper numbers (codenamed "Ice Age") yet?

Yeah I'll post the results here when I get around to it in the next 1-2 weeks hopefully. I've taken a break from my mapper work to try and get my 3D printer running