NGPC USB Flash Cart project

[Calpis]

I guess so. If saves are in the ROM itself, overwriting the ROM will overwrite the save when programming.

So as for the hardware, well it couldn't be more straight forward:

D0-7
A0-20
Low ROM /CE
High ROM /CE
/RD
/WR
------------------
8 I/O, 25 outputs = big microcontroller or small microcontroller with discrete latches/registers for multiplexed outputs.

[_SD_]

I guess so. If saves are in the ROM itself, overwriting the ROM will overwrite the save when programming.

Would there be a way for the device to dump the save ROM so that you wouldn't loose them when reprogramming the cart? Or would that make the programmer much more complicated to build?

[Calpis]

Well if the save is in the ROM, dumping the ROM would also dump the save, they're apparently a package deal.

[MoBoRoS]

Yeah but the shitty part will be that the save will be intergrated in the game... right?
How can we avoid that?

[Calpis]

You can only avoid it by dumping new games and then writing those. Depending on the content written it would probably be legal to distribute the initial data in the save area which would allow people to restore their used games too.

[NTM]

Would it help if I took a photo of the Bung cart PCB?

[MoBoRoS]

Please do so. It may help in a way.

[NTM]

[DiamondDave]

Does anyone have one of the dual-game kiosk PCBs?

[karsten]

any news on this interesting topic?

[NTM]

any news on this interesting topic?

Maybe its time to start a bounty :nod:

[_SD_]

Ok, so what do we need to build a programmer to test this then? Obviously we're gonna have to pull apart a (preferably dead) NGP/C to get a cart socket. I assume we need some sort of USB controller chip and another chip to handle the logic of sending the data to the cart?

[Calpis]

Either a USB microcontroller with 33 or 34 general purpose I/O or just 3x 8-bit latches for a parallel port interface.

[cdoty]

You could probably attach a NGPC cart slot to a DIP socket, and use a Willem programmer to dump/reflash the cart.

[xmog123x]

Using an atmega with a sd card would be a great idea. I was thinking doing this for the snes a while ago, but meh, got no time. It would be fairly simple.

[splith]

ATMega connected to all address lines of flash chips, and the other side to a PC programmer, and then use the spare I/O lines to control the power and write enable to each chip I'm guessing?

[Calpis]

Using an atmega with a sd card would be a great idea. I was thinking doing this for the snes a while ago, but meh, got no time. It would be fairly simple.

With a SD card you'd need a display, buttons and crap to know what you're programming... not great/cheap for such a basic programmer! A USB MCU is far better suited.

If you mean EMULATE the flash via ATmega (or any MCU) a la DS flash card, that's not happening lol; just the setup times of a SD card exceed a CPU fetch much less seeking ahead for random access. DS flash work because they use FPGA with hardware reading/buffering, not MCU, and the game cards don't run nearly at the CPU speed.

ATMega connected to all address lines of flash chips, and the other side to a PC programmer, and then use the spare I/O lines to control the power and write enable to each chip I'm guessing?

PC programmer? Isn't the idea for such a device to BE the programmer?

Address and control signals (and data) are a given when using any memory :P One thing you don't do though is power a chip with an I/O (?? wtf), just use the power supply.

[splith]

If you've got 4*32Mbit flash chips, to save on I/O lines, you have all address lines from all chips connected together, and I'd assume 4 enable pins connected to AND gates that go into each chips power line.

And sort-of.

[Calpis]

Nope, that is why chips on a multiplexed bus ALWAYS have enable inputs, they serve as secondary write and output enables and also typically put memory chips into a low-power mode by gating the row decoder.

Yes all common address lines are typically connected together, but the bus' more significant address lines are decoded to separate chip enables, NOT supply rails. It's done not to save on I/O lines but because the processor/chip only has so many memory spaces (often 1). If it can't access multiple buses simultaneously, it makes no sense to have multiple buses in parallel unless speed/noise is an issue (which it's not for old systems) and even that would only apply to the data lines which could conflict. Right now in computers with the high speed serial trend, each end-point has a separate bus (very necessary), but in reality there is a whole host on each bus, it's not time-multiplexed.

Chip decoding is typically done with significant address lines, so in your example you would use a 2:4 decoder since there are 4 states (4 chips) in 2 binary bits (higher address lines). On the NGP the two ROMs are predecoded within the ASIC to make the carts as cheap as possible. You just need to connect each ROM to a /CE. The reason there isn't one /CE and a higher address line (how it'd be on most other systems) is because the two ROMs aren't contiguous in memory.

You never disable a chip via power because it does not isolate the chip from the bus (and it really doesn't make any sense to since it'd be more costly too). Chips will still do wacky stuff from leakage current.

[Xian Xi]

In case you guys need it, gamesx has the cart pinout:

http://www.gamesx.com/grafx/neocart1.gif