Making repoduction NES/SNES carts?

Yes, thats been done by retro usb.

However, its also more expensive (especially in small numbers).

 

There is a guy that has made brand new plastic cartridge shells. And there is another guy that is going to be making programmable SNES Flash cartridge pcbs that he currently estimates to cost around $20. So in the future, totally brand new SNES carts that anyone can program will be around. The SNES CIC was cloned which was the biggest step away from using donors.

 

If you can get the pcb and other components I will chip in with that to split the costs. But I have no pcb design experience though. A quick question: are there One Time Program chips of 4mb that would work on the snes cartridge?

 

If you have a 3d printer, you could potentially make your own SNES cartridges using that.

 

http://forums.nesdev.com/viewtopic.php?f=12&t=10088

And a member here is the guy that's had new SNES cart shells made. http://www.assemblergames.com/forums/member.php?75357-pichichi010

No need to reinvent the wheel.

 

Tried that, not the most cost effective way to do it, but if you doing colored ones only it might work. I was looking into it for a while.

 

Since OTP chips use EEPROM technology they have become rather hard to get hold of and expensive in larger capacities. On top of this, most of the higher capacity devices are designed for 3.3V systems with 16 bit wide busses - nothing you can't engineer around, but it all adds complexity to the design.

There are similar problems with flash - the devices you really want to use to make things simple are ones with a x8 organization and 5V signals - but they are now mostly either EOL or at best NRND, so are hard to get a relatively expensive. Even with this, my personal bias would be to just use a flash chip and tie the WE/ line to VCC on the board - same overall effect as using an OTP, but the package is smaller, and the parts are easier to get and cheaper.

 

I still haven't been able to get my GQ-4X to read 29F032's with the proper adapter. It'll identify in all sorts of fun ways in different configurations but not properly to the point where I can use it.

Though this problem is ridiculously common and the few who have had the same problem and gotten it working don't seem to have any solutions that apply to my situation. Only thing I can think of is that the adapter I made is defective somehow or I improperly assembled it.

 

If it identifies but won't program then check to see if the high order address lines are connected correctly - most of the address lines are don't care for an identify operation so it will work even if they are floating. If you have a 32bit mask ROM you removed from a cartridge PCB then you can test the programmer adapter by reading it and verifying the contents against a known good dump (make sure you disable automatic ID mode before doing this - mask ROMs generally don't like 12V applied to their A9 pin) - if the dump is wrong you should be able to get an idea what the problem is by looking at it. For example, if the first and 2nd 1MB are the same and so are the 3rd and 4th then A20 is stuck or wrongly connected.

 

So what voltage is the cartridge run at? I was looking at some other flash chips that are 64 mb but are 3.3v and would need another adapter made so it would fit in the snes cart since it's a tsop44. I'm wondering what needs to be done to make it work with the voltage the chip runs on.

 

5v

 

The SNES is a 5V system, and the cartridge bus is 8 bit - which is why the standard part is that AM29F032 or something that's compatible with it, since it drops right in without problems.

If you can find a 3.3V flash part with 5V tolerant pins, then all you need is a regulator - although this approach will have a negative effect on the noise margin on the system because of the threshold shift (normally, a 5V CMOS input has a switching point at 1/2 VCC, so 2.5V - driving this with 5V logic gives you a 2.5V noise margin, but driving it with 3.3V logic gives you only a 0.8V margin).

The strictly correct approach is to use level translating buffers on all the pins - but this adds quite a bit of circuitry and also means that your flash needs to be faster since there are two additional sets of propagation delays to deal with (this is, admittedly, not a significant issue with the SNES because it runs so slow).

 

So sounds like it's better to stick with what is currently used but the chips are getting pricey, I wish there was an alternate chip that's cheaper.

 

This is why they are getting pricey. They werent this high before everyone was using them for repros

 

Fixed.

 

True I know supply and demand determine prices but I'm wondering what flash chip that person who's making the reprograble pcb mentioned above is using.

 

Something that is 3.3v, still in production, and thus available at an affordable price are safe bets. Nothing someone is going to shoe-horn into an original retail game cartridge.

 

I just did some experiments with 3.3V flash in SNES carts - this was done using a Japanese Super Famicom console (SHVC-001) and a US copy of NBA Live '96 (M/SNS-A6BE-USA) - this game was chosen because I had it, it uses an NTSC CIC, it was in bad condition and I wouldn't really feel that bad even if I ended up destroying it.

First of all, I desoldered the original mask ROM and copied the contents to a 3.3V flash chip, A MX29LV160TMC90 - this is only a 16mbit part, but since it's only a 16mbit game this is not a problem.

Hookup #1 (NOT RECOMMENDED!)

Just subregulate down the 5V line to 3.3V using a LDO regulator (I.E. AMS1117-3.3), and connect the other lines directly to the 5V signals. Since the logic high level on the SNES bus is about 4.2V and the datasheet absolute maximum pin voltage rating is VCC + 0.5V (I.E. 3.8V) this will clearly result in conditions that exceed the device limits. In practice, it seems that the protection diodes in the chip were becoming forward biased and the excess voltage was being coupled to the 3.3V line, where is was visible as several hundred millivolts of noise above the nominal 3.3V level. The signal levels on the bus were also somewhat attenuated by a few hundred mv. Having said that, it worked, and appeared stable - but it's obviously impossible to project the life of a part being consistently run outside it's design limits.

Hookup #2 - Zener clamps on the bus
Same basic arrangement as #1, but all the pins are wired with a 3.3V zener to ground with a low value (220R) resistor wired to the signal on the SNES bus. This also worked, and the induced noise on the 3.3V line went away - the tradeoff was that the slew-rate of the signal at the ROM input pins was degraded and that the VoH driven to the bus was about 3.2V - the lower amplitude of this signal was clearly visible when compared to the write and SRAM read cycles. It was also a hassle to wire on a prototype card, although it should be reasonably tractable on a PCB using resistor networks and quad zeners.

Hookup #3 - fully engineered overkill approach
Replace the zeners with FET bus clamps on the input lines and level translating buffers on the data lines - I used the TI SN74CBTD3861DW as a clamp (x3) and the TI SN74LVC4245ADW as the buffer for the DQ lines. Both of these are SO devices, but are also available in smaller packages that would be more suitable if you were designing a PCB. The FET clamps eliminate the slew rate issues seen with the zener clamps because they are low-impedance until the output pin voltage reaches the desired level. The propagation delay across them was minimal - a few hundred ps. The buffer was somewhat slower (about 6us), but this was not problematic even with a "fastROM" game like NBA - and it does generate a full amplitude signal to drive the SNES logic.

Conclusion:

Using the buffer ICs seems to be the way to go - it's not that expensive (a couple of dollars even at low volume distributor pricing), and doesn't seem to have any negative characteristics I can see. Since this was a hack, I just put the chips directly on the pins of the flash (with the SRAM still on the original 5V bus), but for a new PCB design it would make more sense to move both the SRAM and flash to the 3.3V power domain so that the buffer chips could be located right next to the edge connector and only a single level bus (3.3V) used on the board.

I'm also not avocating that specific Macronix flash - it was simply one that was sitting here, supported an 8-bit bus interface and I had the programming adapter for - it was also a .050" pitch SO package, which is a lot easier to deal with for prototyping than a TSOP. For a production item, something like one of the Spansion flashes would seem a good fit (I.E. S29GL064N90TFI010 - $1.74 at single unit pricing at Newark, and at 64mbit large enough even for a game like ToP).

 

Thats pretty much whats going on here: http://forums.nesdev.com/viewtopic.php?f=12&t=10088

 

Yeah, except that he's obviously actually done it rather than just did a bit of hacked up testing :smile-new:

I'm not sure I like the resistive voltage divider on A8-A11, though - assuming it's that pair of resnets R4 and R5 you can see on the photo they look like they are 10k and 20k - and even with a relatively low speed bus like the SNES and the minimal capacitance of a flash address pin I can still see that causing major slew rate issues. I'm also a bit dubious about the use of a "NES Style" SRAM protection system, since I have many bad memories of the NES trashing saves...