Coolboy cart programmer

[Memblers]

Nope, the original iNES header only shows if the WRAM is battery-backed or not, emulators just had to assume WRAM is there. The later NES 2.0 standard does specify if WRAM is present. http://wiki.nesdev.com/w/index.php/NES_2.0

Best way to be sure what's on the cart is to look at it, thankfully there is an excellent resource for that: http://bootgod.dyndns.org:7777/

[lidnariq]

Sorta.

If the "battery backed" flag is set, then the cart definitely has PRG RAM. If it's not ... well ... what Memblers said.

[BennVenn]

Thanks heaps guys!

Same with Bugs, WRAM. Works fine on the WRAM Cart

[darryl.revok]

Would it be possible to use this mapper to create a program which utilizes a massively oversized CHR-ROM?

Is it possible to instantly switch which section of ROM is available as you would switching a bank?

[lidnariq]

No, COOLBOY is still restricted to 128/256 KiB CHR RAM (depending on the specific hardware)

You could fake it by disabling rendering, copying all the data over (which is going to be SLOW, btw), and re-enabling the game, but ... if you're writing new software, you should just use the RAM as RAM rather than lousy ROM.

PRG ROM can be banked dynamically, but the location of the banking registers means that you can't really use PRG RAM in a game that needs access to the COOLBOY outer bank registers.

[darryl.revok]

Okay, so all CHR is RAM, but you can bank the RAM, right? Like a VRC7, except that VRC7 is not readily available in any form.

So, could you, in theory, decompress all of the graphics for a level onto the 256KB of CHR-RAM and then bankswap them during gameplay for faster frame transitions?

Furthermore, would it be possible to store the graphics on a different section of the PRG outer bank, switch over during a break in gameplay, copy, then swap back to the program?

I'm finding that the animations that I'm designing are not going to fit in a 256KB CHR-ROM. Looking for an option to expand that.

[lidnariq]

Yes, it has the ordinary MMC3 CHR banking registers ... just applied to CHR RAM.

And yes, pre-loading the CHR RAM is how the original pirate multicarts work.

[darryl.revok]

Would using a multi cart like this and preloading graphics on a per-level basis be a reasonable solution for creating a game that exceeds normal CHR limits?

It looks like activating the lockout is a one-way trip. After the lockout is set, $6003 will be treated as WRAM, right? Meaning that I couldn't use WRAM and flip between outer banks, but the PRG-ROM size is 2 MiB anyway though, so that's plenty.

Sorry for so many questions!

[lidnariq]

There's the notable loophole that WRAM addresses which are A%4=2 correspond exclusively to GNROM mode CHR bank #, and so you could use those 2 KiB of PRG RAM safely if awkwardly.

[BennVenn]

Soldering 30 solid core wire wrap wires was frustrating! Definitely using hookup wire next time. Below is the ARM STM32 board fitted to the 72pin 256k coolboy cart.

All I/O is High-Z input until USB enumeration is complete where it takes over the bus. You should NEVER have USB connected while the cart is in the console. The STM32 is a 3.3v part with 5v tolerant IO. The NES can source/sink far more current than the STM could and will instantly destroy its IO drivers. I've put the USB port on the side of the cart for that reason but some consoles will still allow an accident to occur.

My Version 2.0 PCB will fit between the 60 and 72 pin boards and remove the need for the 30 point to point wires. I was even thinking of making an integrated 72pin adapter board with the STM on there, though this would require gold plating which will drive the price up a bit.

If there is enough demand I'll make a small run, otherwise I have the 60pin socketed PCB's ready or just the bare STM board as in my 72pin cart below.

$12 for the STM board, programmed and shipped (No tracking, insurance etc....) Firmware updates via USB, PC side software coded in Python 3.4 and also compiled into an executable binary for windows. The python can be ported to any OS if you know what you are doing. TKinter is buggy on OSX.

Add $4 if you want the 60Pin Coolboy Programmer PCB (Bare, no 60pin socket etc...)

OR if time is money, I can sell you a pre-made flash cart. PM me.

I'll add WRAM reading/writing in the next firmware version.

[darryl.revok]

I'm going to get one of these, and I've been brainstorming on what might be possible with them.

First, I've heard that the Wiki may be wrong and that the ROM size may be limited to 512KiB with MMC3 mode. Has anyone successfully used a 2 MiB ROM in MMC3 mode?

Okay, so you can't use WRAM while adjusting the outerbank, but is that the only limitation? With 32 MiB of PRG storage, it wouldn't be hard to write a program that doesn't need WRAM. If you wanted to save progress, you could even wait to lockout when somebody selects "save and quit", then lockout, save, and reset to title menu, right?

Can you LDA from WRAM while registers are not locked out? That would make it easier to read save data without doing a reset trick.

I'm guessing it's not, but I just want to go ahead and ask if the CHR-RAM is dual ported, meaning that you could start a copy to it without turning off rendering? Like I said, I'm guessing this isn't the case, because people said dual ported RAM is pretty expensive.

[lidnariq]

First, I've heard that the Wiki may be wrong and that the ROM size may be limited to 512KiB with MMC3 mode. Has anyone successfully used a 2 MiB ROM in MMC3 mode?

The wiki notes are just my interpretation of FCEUX's source, where ClusteR wrote in a comment "Regular MMC3 mode, internal ROM size can be up to 2048kb!"

There's something that looks like a bug in FCEUX's source, where all the MMC3 derivatives call GenMMC3_Init with parameters in terms of maximum supported kibibytes, but GenMMC3_Init then generates a mask from that number that expects it to be give a parameter as a pure number of bytes ... but that should in practice have net no effect. (because (512 >> 13)-1 == -1 == uint32_max)

If you wanted to save progress, you could even wait to lockout when somebody selects "save and quit", then lockout, save, and reset to title menu, right?

It has to be a hard reset (person hits reset button ... or maybe even power button, depending), not simply the program starting over from scratch.

Can you LDA from WRAM while registers are not locked out?

ClusteR's implementation only attaches to FCEUX's write handlers in the $6000-$7FFF region, so according to that, you should be able to. But I have no idea whether that's accurate.

I'm guessing it's not, but I just want to go ahead and ask if the CHR-RAM is dual ported, meaning that you could start a copy to it without turning off rendering?

No.

Not only is dual-ported RAM expensive, but there's no interface defined for such a dual-ported interface here; the PPU's RAM interface is definitely busy during rendering.

[BennVenn]

In regards to the mmc3 limitations, I've brute forced all 4 registers to see what mapping options there are. I've flashed a 2megabyte ROM to the cart with identification strings in what should be the interrupt vectors for a 32k, 64k, 128k, 256k, 512k, 1024k and 2048k ROM. I've only managed to get the cart to map 128k, 256k and 512k ROM's in MMC3 mode (Reset vector in the correct place)

I have not tried to swap banks beyond the 512k ROM, that is switch to bank 255 on a 512k ROM. This could map up to 2048kbytes in the bank mapping regions if the mapper supported it. I'll try later tonight and report back. I know GNROM mode will allow it so it is very likely it can be done.

For the Mapper reset - My STM32 is held in a loop waiting for the 'Set Configuration' command from the USB host. There is no reason why I could't monitor the CPU bus and catch a reset command sequence (i.e. write &AA,$55,$AA to $6000) then act on that. It'll need some simple logic, an NPN + resistor to clamp the PHI signal to force a cart reset but it could be easily done. (Or just a resistor come to think of it)

The MCU runs at 72mhz and has very powerful interrupt hardware so will be fine catching writes from the comparatively slow CPU Bus. It could even do some more advanced trickery, I'm not sure exactly what as NES hardware is relatively new to me, I'm sure others could offer a few suggestions. Maybe a game genie or something? Serial Port?

I'll check out that mmc3 stuff and report back.

[BennVenn]

Initial testing shows mapping up to bank 63 works, past that there seems to be some odd masking going on. Bank 253 is mapped to bank 61 (indicating masking of %00111111). Bank 255 is mapped somewhere I haven't yet identified, well past the 2mbyte mark. I'll need to hook the logic analyser up to the ROM IC to see exactly what is going on.

This confirms my suspicions that accessing past 512kbytes could be tricky in mmc3 mode once the registers are locked out. There is still the hybrid GNROM/MMC3 mode to investigate.

[BennVenn]

For carts without WRAM, I had a look in my junkbox and found a couple of N64 Save Packs. Inside is a 32kbyte SRAM IC. I probed around the Coolboy cart's WRAM footprint and all the traces seemed like they were in the correct place. The upper Address bit was tied to VCC but the rest were controlled via the Bus/Mapper. This could mean 16kbytes is mappable.

Anyway, moving the SRAM IC from the N64 save pack to the cheapest coolboy cart seems to have worked. I can now boot ROM's that require WRAM including SMB2 and Bugs.