INL HiLoROM SNES flash cart

[tepples]

Given the SNES memory layout, 4 MiB + 8 MiB could hold everything, even decompressed Star Ocean. It could use the 4 MiB chip for $xx0000-$xx7FFF, or for $008000-$3FFFFF and $808000-$BFFFFF.

[infiniteneslives]

Yeah I realize that. The difference between supporting a two 8MByte chips and 4+8MByte chips was routing a single trace on the board to connect A22 from the CPLD to both flash chips. So it was a no brainer to just have support up to 2x8MBtye chips which will inherently support 4+8MByte chips as well. At this point it's just a matter of what memories to solder on.

I'll probably offer a break down something like this:

lowest cost version: a single 4MByte (32Mbit) flash this will work for MOST production Hi/Lo ROM games. I could get/use smaller flash chips but I'm not sure it's really worth offering these options unless someone was looking for a large number of carts for a specific small homebrew game or something.

Double the memory: a single 8MByte (64Mbit) flash this will support nearly every Hi/Lo ROM game out there. With the one exception of decompressed star ocean.

Max addressable memory: one 4MByte + one 8MByte (96Mbits total). This would basically be targeted towards star ocean. Could also be used as some sort of hack/homebrew multicart that doesn't involve bankswitching.

Max the board: two 8Mbyte flash chips (128MBits total). You can't address all this at once. But with bankswitching and proper archiecture in the CPLD 'mapper' you could fill all 128Mbit with multiple games (both Hi and Lo ROM) and use the reset button to toggle through each game. This would also be able to support up to 16x (8KByte 64Kbit) battery backed save slots, which is plenty since the flash limitation would leave mean you'd have to be using 16x 1MByte (8Mbit) games which doesn't seem likely...

[qwertymodo]

How about an option for no memory? I have a bunch of Micron M29W640G and M29W320G on hand, which are supposed to be a drop-in replacement for the Spansion S29GL064N/S29GL032N you're using (there are software differences, but nothing that should effect its usability here). I'm interested in buying a couple, so if I could get them a bit cheaper without the ROM chips, that would be awesome.

[tepples]

This would also be able to support up to 16x (8KByte 64Kbit) battery backed save slots, which is plenty since the flash limitation would leave mean you'd have to be using 16x 1MByte (8Mbit) games which doesn't seem likely...

You'd be surprised. Some people have a large collection of Super Mario World hacks, and SMW is 4 Mbit before expansion.

[infiniteneslives]

That's a good point about SMW hacks Tepples, I didn't realize that SMW was so small. A nice combo considering it's probably one of the most heavily hacked SNES games.

How about an option for no memory?

Possibly by special request, but it's not something I'd list up for checkout by the general public... The biggest issue with that route and very fine pitched components is the challenge of soldering. Don't get me wrong it can be done, but there isn't much reason to go though that pain. Additionally it's pretty impossible to guarantee I'm delivering something fairly trouble free when it requires a high level of skill to assemble. Not only that, but it's hard for me to test that the board if fully operational when it's missing the flash. But I may entertain such requests if the buyer was willing to accept responsibility for those risks.

EDIT: oh and the spansion chips have a buffered write which isn't on all pin compatible flash chips. The buffered writes does cut down on programming speed, so you'd have a time increase there. Additionally all the high level software and firmware support for reflashing the chips is designed with that buffer in mind, so you might have compatibility issues there if your flash doesn't support buffered writes.

[qwertymodo]

How about an option for no memory?

Possibly by special request, but it's not something I'd list up for checkout by the general public... The biggest issue with that route and very fine pitched components is the challenge of soldering. Don't get me wrong it can be done, but there isn't much reason to go though that pain. Additionally it's pretty impossible to guarantee I'm delivering something fairly trouble free when it requires a high level of skill to assemble. Not only that, but it's hard for me to test that the board if fully operational when it's missing the flash. But I may entertain such requests if the buyer was willing to accept responsibility for those risks.

EDIT: oh and the spansion chips have a buffered write which isn't on all pin compatible flash chips. The buffered writes does cut down on programming speed, so you'd have a time increase there. Additionally all the high level software and firmware support for reflashing the chips is designed with that buffer in mind, so you might have compatibility issues there if your flash doesn't support buffered writes.

Well, when you have these ready for sale, I would be willing to buy a couple without memory installed. I understand you not wanting to do so in general, but I'd definitely be one to make that special request. I'm perfectly comfortable soldering 0.5mm pitch by hand, just did a few M29F160's yesterday. As for software support, that won't be an issue either, I'm currently in the process of building my own hardware for doing the flashing, and I'll be writing the software from the ground up as well. Anyway, the M29W640G is write-buffered as well, so no problems there...

In case you're interested: http://www.micron.com/~/media/Documents ... 64Mbit.pdf

[wyndcrosser]

I just wanted to make mention that your products look amazing, and I'm excited for your work.

[MottZilla]

I got one of these SNES boards yesterday. After a little bit of tinkering, it's awesome. Much better than shoehorning eproms or flash into old PCBs. The only thing that's a bit of a downer is it can take awhile to program very large games. Otherwise it's pretty sweet. Any downside is more than made up for by never having to lift a soldering iron yourself.

[infiniteneslives]

Thanks Mottzilla, Yeah the bigger chips still take awhile to flash. It was even worse about a month ago. Once I get the firmware to automatically double up to fake the mirroring that'll speed things up quite a bit so you don't have to send data over USB several times. So that will make programming time more dependent on rom size vice chip size. The next step to up the speed is multi-task the mcu on the kazoo. Currently the firmware accepts 256 bytes and then flashes them 32bytes at a time with the associated wait while flashing. I'm going to step the packet size down to 32Bytes so that the mcu can accept the next packet of data while the flash is off programming the last 32bytes on it's own. Not sure how much that'll save exactly, but should be significant.

It currently takes ~2 1/2 mins to program a 4MB game onto a 4MB board. So something like 1.6KB/sec right now. Not that long ago it was about 3x that before I was doing 32byte buffered programming.

[muckyfingers]

I got one of these SNES boards yesterday. After a little bit of tinkering, it's awesome. Much better than shoehorning eproms or flash into old PCBs. The only thing that's a bit of a downer is it can take awhile to program very large games. Otherwise it's pretty sweet. Any downside is more than made up for by never having to lift a soldering iron yourself.

Have you tested it with your SNES PAR MK3, to see it if works with it or not?

[MottZilla]

I have not yet but I plan to test it, and it's *very* likely to work just like a real cartridge. The INL SNES boards unlike Memory Card loading Flash cartridges (EverDrive or PowerPAK) should have no problems using Game Genie or PAR. They function pretty much the same as original cartridges as far as those cheat devices are concerned.

[bazz]

Thanks Mottzilla, Yeah the bigger chips still take awhile to flash. It was even worse about a month ago. Once I get the firmware to automatically double up to fake the mirroring that'll speed things up quite a bit so you don't have to send data over USB several times. So that will make programming time more dependent on rom size vice chip size. The next step to up the speed is multi-task the mcu on the kazoo. Currently the firmware accepts 256 bytes and then flashes them 32bytes at a time with the associated wait while flashing. I'm going to step the packet size down to 32Bytes so that the mcu can accept the next packet of data while the flash is off programming the last 32bytes on it's own. Not sure how much that'll save exactly, but should be significant.

It currently takes ~2 1/2 mins to program a 4MB game onto a 4MB board. So something like 1.6KB/sec right now. Not that long ago it was about 3x that before I was doing 32byte buffered programming.

I would love to hear more about your transfer protocol. the SNES Flasher I designed over this summer uses FTDI Usb UART transmit/receive. However, I do not yet have a packet protocol, I just send one byte at a time to the flasher. This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time? (1 hour for 32Mb) Note MCU is running at 16 Mhz, I flash using nested For Loops, I'm not even delaying or verifying the bytes have been programmed before moving on. Still so low? Makes no sense. Of course, I verify everything after programming is done, always a success.

[qwertymodo]

I would love to hear more about your transfer protocol. the SNES Flasher I designed over this summer uses FTDI Usb UART transmit/receive. However, I do not yet have a packet protocol, I just send one byte at a time to the flasher. This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time? (1 hour for 32Mb) Note MCU is running at 16 Mhz, I flash using nested For Loops, I'm not even delaying or verifying the bytes have been programmed before moving on. Still so low? Makes no sense. Of course, I verify everything after programming is done, always a success.

Your code could probably use some optimization. I have a single-byte-at-a-time microcontroller flasher that uses latches for the address lines due to lack of I/O pins and I do wait for verification after each byte and I'm running about 20 minutes for 32Mbit.

[infiniteneslives]

My programmer is an adaptation of two separate V-USB library projects that use an AVR micro-controller and a few discrete components for USB. The hardware is adapted from the kazzo, and the software/firmware started off as the EE-prog. If you want the nitty gritty details look into the code for the EE-prog, and ignore all the I2C programming protocol. Once I get things more polished and full line up operating as I'd like, I'll make my sources available. The only reason I'm not doing it now is that it's a little messy and not fully documented, I may also change the structure significantly and don't want to invalidate any work someone might choose to do for themselves. (If someones reading this a year from now, feel free to poke me and I'll share what I've got at that point.)

My software/firmware is setup to transfer 256Bytes over USB storing them in the mcu's ram until all 256Bytes of the 'packet' have been transferred over USB. At that point I call my programming function where those 256Bytes are written to the flash chip. Initially I programmed 1 byte at a time from my 256Byte 'packet'. At that point my programming speed was something like 10min for 32Mbits. As noted in the datasheet for the flash, 32byte buffered writes are drastically faster than individually programming 32Bytes. So you use one command to write a buffer of 32Bytes to the flash at once and then wait while the flash chip goes off on it's own to program those 32Bytes. That improvement cut me down to where I'm at currently with ~2.5min for 32Mbits.

This means in my write routine, I am fetching a single at every iteration. Could this explain my insane long flash programming time?

YES.

There is a lot of time and code between accepting the byte over USB, and then actually writing that byte to flash. Programming byte by byte means that code is executed for every single byte. Going to the 256Byte packet size means that code is only executed once for every 256Bytes. That could explain some of the time difference between qwertymodo and my implementation. Yours too bazz, but taking 1hr for 32Mbits you've got to have a few other inefficiencies going on. Not sure how fast your UART is, I'd find out and ensure that it's not bottle necking you.

The two things that consume the most amount of time though are serial transfer over USB, and the flash chips programming time. There isn't a whole lot you can do about either of these. Faster USB would require dedicated components that don't justify the expense IMO. However figuring out a way to fetch new data over USB while waiting for the flash to write the old data. This would be difficult and most likely diminishing returns to perform on a byte level, however powered with 32Byte buffered flash writes I think the ~240usec write recovery time is sufficient time to go fetch a good chunk of data via USB. Adjusting the 256Byte packet size down match the 32Byte buffered write size would allow for this to happen. I'll just have to double buffer the writes and verify the old buffer just before writing the new buffer. Might get me under 2min for 32Mbits I'm thinking.

[MottZilla]

That improvement cut me down to where I'm at currently with ~2.5min for 32Mbits.

So that will be in the next update then? =) When I tried I roughly measured around 10 minutes for 32Mbits. 2.5min for 32Mbits is very acceptable.