How to build a RAM-Cart / Plugin for the CopyNES

Hi!

I'd like to have a killer dev system.

But I dont have a powerpak lite, and got no intentions to buy one. [Just maybe, if this thread fails to collect all the required infos.] But back on topic.

I would like to understand how a ram-cart or rather the CopyNES itself works. I can understand why to bow certain pins on eproms, or how some mappers work. And I did some basic demos. But I can not put all that together myself, so I could create a dev-cart and a plugin for a given cart.

I dont want to buy a powerpak - I want to understand how it actually works.

Someone on here, that can explain the mystery of writing dev-carts with the copyNES?

Thanks in advance,
ninn

Oh, I forgot:
That old thread comes pretty close, but it lacks explanation why it is wired that way:
viewtopic.php?t=894

And it uses a mapper that is already supported by the copynes.

Replacing the ROMs with SRAM that is appropriate is the first step. The next depends on the mapper being used. I think generally mappers like MMC3 will be disabling PRGROM when you attempt to write to the ROM area as it expects you are writing registers. I'm not sure what you'd have to do to overcome that.

Maybe you could modify the cartridge so you could map any part of SRAM into the PRG-RAM area of the cartridge. Didn't the PowerPAK Lite support MMC1? So that sort of issue was tackled somewhere, though it isn't an original ASIC so perhaps the CPLD code was modified for it.

The reason I didn't explain the wiring is because I figured it wasn't necessary - you don't need to know why it works a particular way in order to make it. I also figured that anybody who'd be making a devcart would already know why it needed to be wired that way.


Back when I posted that message, I had just added support for that RAM cart to the Win32 CopyNES client.

Adding support for a new type of programmable cartridge to the CopyNES client requires writing C[++] code to implement it - even though each RAM cart uploader has its own CopyNES plugin (1KB 6502 code), the command interface for each one is totally different and requires custom logic in the client to handle it.

If I really wanted to, I could probably rewrite all of the existing plugins to use a common interface and then come up with some sort of simple scripting language to describe how the client should talk to the plugin (e.g. send CHR before PRG, special logic to either mirror data to upload to the cart or tell the plugin to do it for you) and any special restrictions (allowed mapper numbers, valid PRG/CHR size ranges, etc.), but I'd rather not bother with something so complicated when it would be easier to just hardcode support for additional devcarts as people request them.

The basic problem is differentiating writes to the mapper(banswitching) and writes to the PRG-ROM(for programming). when you're writing to SRAM's externally through the cart connector.

From what I understand the powerpak lite and copyNES uses the EXP0 signal as a 'mapper disable' signal. So if you want to write to the PRG-ROM you'd disable the mapper first, so it doesn't swap banks on you as you're programming the cart.

Not sure if that's the 'mystery' you're referring to, but that's the main issue that needs to be resolved to program a cart externally.

I have been thinking in this for a long time.

In order to interface with the computer, I have been thinking in using either a UART I removed from an old 8086 motherboard, or bit-banging through the controller ports. Bit-banging is something I wouldn't like to use, as I use several NES and famiclones with varying grades of accuracy.

The bootloader would be either stored on a cartridge or inside the NES along with the UART, so I could use it to dump cartridges.

Personally, the way to go is having a ROM with a bootloader (and maybe a supervisor) and an UART at $4028 (unused, so it does not conflict with exotic mappers like the CopyNES sometimes does) inside the console with an independent RAM cart.

I was under the impression that any famiclone that ran games with raster effects had a cycle-accurate CPU. Operation Wolf and Zap Ruder bit-bang the controller port with timed code to get a vertical position from the Zapper, so anything that runs those games smoothly should support controller port bit banging.

There was an example of bit-banging online for the NES and it didn't work on my Famiclone or my official NES either, even though I were using the same FTDI-based RS232 adapter they recommended. I think it had support for PAL console, maybe I were wrong.

Dendy style PAL clones need NTSC comms code. Their clock rate is far closer to that of NTSC.

It was blargg's bootloader: http://slack.net/~ant/old/nes-code/bootloader/

I tried it on Windows, so I'm going to try it again, now from Linux (Lubuntu)