Another Universal Flash Cart

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Another Universal Flash Cart
by on (#45353)
I'm new to the forum but I've been working on this project for about a year and a half now. This is my take on a universal flash cart (called UNES) which is similar to the Funky Flash Cart in that it utilizes a CPLD for a mapper, and contains both SRAM and FLASH ROM.

There's a lot of major differences though. The main idea was to have something like 'on the fly' programming where nothing would need to be removed from the NES. In fact, the intent of this project is to modify a NES to use only this flash cart - where through an LCD / button interface the cart will have full control over the NES power and reset, as well as game selection and whatever else.

So far I have only been able to develop 3 mappers for the prototype - just as a proof of concept. The goal is to stick all the mappers possible onto the CPLD at the same time. The mappers working so far are NROM, CNROM, and UNROM. As you can see below is an image of the machine playing Contra. Next on the list is MMC1, then MMC3, etc. It can only be programmed presently via a PC's seral port and my own software, though an SD slot will be fully implemented in the final.

Image
The prototype.
Image
The prototype playing Contra.
Image
LCD interface.
Image
Final PCB (just placed the order).

Comments, anyone?

by on (#45355)
Do you use KiCAD?

by on (#45356)
That last picture was a screenshot from Ultiboard, which is what's available at my school. It has a spiffy 'view 3D' option that I used to get the picture.

by on (#45379)
Whoa Sweet

It uses flash memory right? And the little MCU can remember the settings.

Good job with the prototype! I usually just order the boards and they work ;)

by on (#45400)
Yeah, specifically I am using SST39SF040 flash ROMs. The MCU stores the iNes header into it's own EEPROM on every program and sends info to the PLD to tell it how to operate.

And thanks. I don't think I can even roughly guess how much work this has been for me so far.

by on (#45423)
Nice, very nice!

I'm glad you went with the 'on-the-fly' programming, that's the way to go. I guess the upload speed is limited to the flash, I wonder what speeds you're getting.

by on (#45426)
The prototype itself is actually limited by the serial port speeds. Running at 57k6 baud I'm getting roughly 200uS per byte. The ROM chips themselves are rated for a max of 20uS per byte, so hopefully by using an SD card I can improve my upload speeds by a factor of 10.

I've also got some 4Mb SRAM chips that I wanted to try on one of the boards when I get them. You'd have to reprogram each time you turned the system on but it would allow the fastest possible program times.

A large game can program in roughly 1.5 to 2 minutes, a small one (NROM) is obviously much faster. It was a big goal of mine to achieve the fastest program speeds possible so I'm excited to get working on the SD interface. :)

by on (#45429)
You should be able to replace your current serial interface with an FTDI USB serial chip really easy. That would gain a large speed advantage with few or no software changes. Changing to one of their parallel USB chips would be another speed bump, again with little or no changes on the PC side.

by on (#45450)
Always good to hear from Bunnyboy. We do love the Powerpak here at home.

Neoflash seems to have dropped off the map, is anyone in the world working on a flash cart for the SNES? I like Tototek's a whole lot, but that Parallel port programmer just fails on my new PC. Suckage.

by on (#45456)
cd_vision, I developed a SNES flash cart and USB programmer. Its going to be on sale real soon now! I will make an announcement in the SNES forum when it is.

I love FTDI chips! I always use the parallel version, you can connect it to a data bus and have the MCU control it. With this you should be able to get your 10x speedup.

by on (#45484)
cybertron wrote:
cd_vision, I developed a SNES flash cart and USB programmer. Its going to be on sale real soon now! I will make an announcement in the SNES forum when it is.


I love you, make babies with me. I don't care if we're both men.

by on (#45489)
I'll have to look into those FTDI chips, the reason I initially went with serial is because this is a thesis for school with deadlines, etc. so I wanted to keep it simple (well, at least the parts that could be). As well, I'm relatively new to the field (in the 2nd year of my course) and I haven't been familiarized with USB options.

A parallel version that can work on a data bus would actually work really well. I could use the LCD data bus and share that again with the FTDI. Thanks :)

by on (#45502)
The fact that you're making schematics readily available, makes you worthy of great respect.

Well played!

Mike

by on (#45579)
Well the software is where all the real work is, especially that for the CPLD. If they are of interest, I could post a schematic.

by on (#45620)
The main reasons why Flash Carts aren't popular as of yet is that... oh, you already know. Greed and all that :D

Schematics would be awesome. Even a how-to instructable would greatly widen the variety of people who can achieve something like this, as such multiplying the amount of people who can work with NES Dev.

Math plus good human nature... it's a Canadian thing

by on (#45627)
Well the other thing is cost. Just the components together (say from Digikey or similar) add up to over $100 CAD, I doubt many people would jump at that. On top of that, a farmed PCB is the only way to go due to the amount of fine pitch surface-mount stuff there is (with no DIP replacements). There's also the need for a JTAG programmer for the CPLD (which is from Cypress, BTW).

In total, to make a single UNES would cost say... $500+ give or take.
I'm making 10 to get the cost down - but then what? They'll be worth in excess of $250 a piece (NES not included).

by on (#45628)
Holy cow 500 bucks. Everything on Digikey is about 5x what it really costs, and it adds up.

What are the most expensive parts? Perhaps some clever designing can cost reduce it.

cd_vision, thanks.. I guess! lol

by on (#45630)
Clever Designing always wins the day.

Kathaku, you're a Canuck as well?

good show old chap

by on (#45646)
So back on topic, what makes it so expensive beyond the large PCB?

Your bus switches look non-standard/expensive just from the package, thought of using '244/'245 or the CPLD itself for isolation? It appears to have enough I/O...

Are the ROMs programmed in parallel or using EXTEST like FunkyFlash?

Are you using the power supply for SRAM retention instead of battery backup?

Personally I really dislike FTDI chips since for me the most useful application is the asynchronous bit-bang mode. If I wanted to interface my hardware using an MCU, I'd probably get a USB MCU and drop the expensive FTDI...

by on (#45650)
Alrighty here we go!
The $500 dollars is including costs like the JTAG programmer for the CPLD (the devkit was $100), plus the touch fee for the PCB ($400), etc. The power supply is actually to power the NES and the UNES (it was part of the requirements for school, as well, I didn't feel too comfortable adding so much load to the NES's 7805).

----Biggest Expenses----
CPLD: Cypress CY37192 -> $30 (Any cheaper 5v CPLD's with that much I/O out there?)
MCU: PIC18F8520 -> $8.50
Bus Switches: 4xSN74CBT16211A & SN74CBT16245 -> $9
16x4 Display -> $15
RAM: 2 x CY7C199D -> $5
ROM: 2 x SST39SF040 -> $5
PCB -> $110 (After touch fee and an order of 10)
Passives, RS232 circuitry, power supply circuitry, SD card circuitry, buttons, knobs, etc. -> $23
The total here on my BOM is $205.76

The bus switches serve 2 purposes:
1) To isolate the ROM from the NES during programming (and I tried using the CPLD for isolation, but there isn't enough I/O) (These aren't actually implemented in the prototype)
2) To allow the MCU to access both the ROM in parallel with less I/O (The ones you saw)

At my school there is a CNC Milling Machine which allows us to route double sided PCBs for free - so any surface mount part you see on the prototype is soldered onto one of those 'adapter boards' that I've made.

by on (#45654)
Bus bufers are great (different from a bus switch). I used 3.3v logic for everything, the chip 74LVC4245A can convert 5<->3.3v for the data bus and 74LVC541 does 5->3.3 for the address bus.

I also used a 3.3v CPLD by Altera that can accept 5v signals, so its impossible to break it. I didn't know Cypress made CPLDs.

I used OurPcb for the boards too, they were way more reasonable. That sounds like your biggest expense!

by on (#45656)
Looks like I'm gonna be going for a version 2 after this is all said and done. I realized that a 3.3v PLD would have been exceptionally cheaper, but hadn't found a solution to make the voltage conversions practical for so many lines.

by on (#45684)
Alright here it is. It's cryptic. It's rough. It's sole purpose was to generate a netlist for my PCB. I hope someone out there might find this useful. :)

http://img91.imageshack.us/img91/5831/unescircuit.pdf

by on (#45694)
I don't see why you need so many CPLD I/O when it appears to be strictly for mapper emulation. I counted necessary signals and think you should be able to get away with a PLCC84/TQFP100 easily:

15 cpu a
8 cpu d
1 romsel
1 phi2
1 rw
1 irq

14 ppu a
1 ppu na13
(+8 ppu d for MMC5 though it's not fitting into any CPLD)
1 vram ce
1 vram a10
(+2 ppu rd & wr for MMC5)

6 cpu rom/ram a output (+1 for NSF bankswitching)
9 ppu rom/ram a output (+3 for MMC5)
4 rom/ram ce

--------------------

63 I/O

Also it's true you don't really *need* 5V outputs as the CPU/memories are TTL compatible (Vih is 2V) and you're not driving any 4000 series CMOS inputs.

If you plan on implementing some larger NES mappers like FME7, RAMBO1 etc, I don't think even if they reused registers they could all fit into a *300* macrocell design simultaneously. So, if you want to support them, you're probably going to have to keep reprogramming the CPLD. Any given NES (and FC!) mapper (except MMC5, MMC5-like pirates, sound chips etc) by itself will fit into around 120 macrocells though so if you wanted to, you could definitely find a cheaper CPLD! I'd recommend a $6 Xilinx XC95144XL, that way your design can have a little overhead.

by on (#45733)
It actually looks like a good design, I see why you chose those bus switches

If you want to use the FTDI chip for USB, you can defiantly place it on Bus1

As kyuusaku mentioned, the CPLD can probably be reduced. You can actually use a 3.3v CPLD with 5v compatible inputs. It wont get fried by the 5v and you won't have to change the rest of the circuit

I don't think CPLDs should be reprogrammed in the field, some of them only last a few 100 times

by on (#45736)
Thanks. Granted, when I began this project a year and a half ago, I knew absolutely nothing about nintendo hardware. The first half a year was purely research, more or less.

When I chose the PLD, I was really aiming for something I knew would be too big - especially because I didn't know how big I was actually going to need it. Now in hindsight it's definitely the first thing to change.

I found a part that would be useful here: GTL2000 (seems like an odd part number to me) but it's a 22-bit voltage translator. 2 of these could replace the bus switches at the NES end, and I could switch the entire rest of the circuit to 3.3v - which would reduce cost in nearly every way. I could also use an MCU with built-in USB (or FTDI, more expensive though).

cybertron, how would you handle the CPLD programming?

by on (#45757)
I'd still consider moving over to sustainable 3-state buffers. Adding a single 7400 would let you decode the two 74245s needed to preform bidirectional I/O with the NES. Even 12x 74244, 4x 74245 and a 7400 should cost less than $5.

For the 245s:

cpu_245_dir = cpu_rw
cpu_245_en = !(!(mcu_cpu_en & phi2))
ppu_245_dir = ppu_!wr
ppu_245_en = !(!(ppu_!wr & ppu_!rd) & mcu_ppu_en)

by on (#45833)
To program a CPLD in-system you need to connect the JTAG port to the microcontroller

Altera and Xilinx can export JTAG commands in a binary form that can be played back by a microcontroller to configure the part. This would also eliminate the need for a separate programmer. You could do this to switch board types easily, but make sure the CPLD can endure that many re-writes

http://www.altera.com/literature/an/an111.pdf

kyuusaku, 74HCT series would be good for that