Electronics Question on Flash(ing) Memory

Hello,

I am planning on designing on a flash programmer. My only experience with this level of digital electronics was when I built the official GB Flasher, which actually uses an FTDI chip to do serial communications UART over USB to the micro controller.

I heard about those native USB microcontrollers out, the AT90USBxxx devices. What I was wondering is, would I want to investigate more into this device or some different way of flashing a memory chip? Are there any different ways besides serially? Or should I just stick to the FTDI method. Either way, I have to learn entirely about the method.

Moving on, one of my gripes with the flashing of the memory is how long it takes to do so. Is the FTDI and baud rate responsible for such slow operation? I'm talking, not out of my ass, but a little outside my knowledge. Either way, I am keen on finding a faster method of flashing the memory, I just hope it is not outside the scope of my time and learning.

Thanks for the help dudes,
anything works, appreciate it!

This should probably go in the hardware forum. There's a lot of folks here that can help you more than I, but here's a few points:

1. Flash takes a long time to overwrite due to the speed of the memory, communication port shouldn't be your bottleneck.
2. AVR micro controllers with USB support are teh bomba. You should check them out.
3. If you want to workbench something without a lot of soldering, check into the Arduino (SparkFun has a wide selection). It's an AVR micro controller hooked up to, powered by and programmable through a USB port, and has tons of I/O pins attached to pin headers. Many folks (myself included) have made chip programmers with nothing more than an Arduino, a few shift registers and a breadboard. In fact, there's not much you can't do with those parts

Ok, well I want to cover 2 things :

1) I was originally designing a plan for designing an Eprom Emulator for a SNES cart. It would use SRAM. Now I have the following question on that:

If I had an SRAM chip the same specifications as a flash chip. Would it still program faster? The reason I ask is because I was planning on designing an Eprom Emulator for when I do real design of a snes game. Using the emulator would allow me to never have to unplug the game from the SNES. I'm getting a little more into design, but I was wondering if people were saying about Eprom Emulators that they save time only because of not having to unplug the flash rom to program it. is it actually also faster in itself to send the same bits to SRAM? I am asking in the case of the chip being the same speed in ns as the flash chip. However, I am of course also aware that SRAM chips appear to be available at much higher speeds than what I see for flash (in what, the 1 time I searched. I believe I have plans with a 20ns chip(s)) Either way, it's most definitely going to be faster since I plan to design it to be able to stay in a powered SNES even when re-programming, using the Soft-Reset capabilities of SNES (something I vaguely studied here on nesdev forums, about grounding the reset pin on SNES cart).

2) The answer to #1 will help me answer #2.. If I cannot hope to find satisfactory / near instantaneous times with the SRAM chip, I wonder what other mediums are available to me?

I must also take note that the size of the ROM to upload has a positive effect on this. With a game like SMW being 4Mbit, I imagine how could I make my own game bigger than that. And in that case, what would that load time be?? The answer to that question, if unsatisfactory, would mean I definitely want a faster approach. But if load times for 4Mb are satisfactory, perhaps I could put up with it.

My issue with Arduino were the lack of I/O. I don't know anything about shift registers, except for the fact you use it to expand your i/o?

My other reason is that I would have to purchase lots of break-out-boards or sockets, ne?
They are expensive, and until I have a job, that is kind of screwing with me.

It takes a certain amount of time to "burn" the bits into the 'PROM. Here's some examples:

• Atmel's AT28C64 : 8.2s (1ms/byte × 8192 bytes)
• Catalyst's CAT28C64 : 1.3s (5ms/page × 256 pages of 32 bytes).
• Atmel's AT28C040 : 20.5s (10ms/page × 2048 pages of 256 bytes)
• Microchip/SST's SST39SF040 : 8s (per the datasheet) to 10.5s (100ms/erase + 20µs/byte × 528244 bytes)

Yes, but in practice you will be spending much more of your time iterating than waiting for the 'PROM to absorb the data.
20ns is overkill. For the SNES, you won't need to buy anything faster than 140ns.
FLASH and EEPROM, as you surmised. New old stock DRAMs, if you can find fast enough and 5V-tolerant ones and are willing to add some simple circuitry to add hidden refresh. and UVEPROMs.
EEPROMs (and SRAMs) bigger than 512KB (4Mb) are no longer available at 5V (i.e. SNES voltage) For anything larger, you'll either need to gang multiple PROMs together, or to use voltage shifters. Either way, you should get your feet wet before you reach for something larger.

In theory, SRAM and PSRAM* program as fast as the CPU can access it. In practice, you're limited by the speed of the serial link between the EPROM emulator and the host computer. That can be fast if you use Hi-Speed USB, but not if you're trying to get in through controller port 2.

* PSRAM, or pseudo-static RAM, is DRAM with its own refresh circuit to make it appear as SRAM to the rest of the system.


The speed depends on how you plan to connect the EPROM emulator to the computer and to the memory: whether it's a device that sits on the A bus, a device that sits on the B bus, or a device that takes the memory off the bus entirely. The PowerPak Lite for NES, for example, is an SRAM cartridge that uses the CopyNES, an A bus peripheral soldered into the NES, to transfer information over a cable.

I have a lot to learn. Since the most important thing to me now is the transmission from computer to memory device, tepples, you mentioned that if I used a high-speed usb transmission. What could I use to achieve such high speeds? The current 2 possibilities I have chosen to flirt with are FTDI FT232R, and AT90USB series micro controllers.

I do not yet know enough to derive the best solution.

Well, I thought it would necessary for fast pc->sram r/w, but please do correct me if I am wrong. I will have to see.

Doing the math: 140ns × 524288 bytes = 73ms. Also, the SNES can't read from anything in its cartridge slot in less than 140ns. (one read cycle at fastest is 3.6MHz; half of that is 140ns)

Pretending for the moment that you wanted to build a 12MB/95Mbit SNES RAM cartridge, that would still only be 2 seconds. Anything faster is entirely wasted.

edit: fix math; lost track of decimal place, specified too fast by factor of ten.

I don't understand your point, after I stressed the fact that I am focusing on minimal upload time from the PC. You answered with focus on the SNES again

How "minimal" do you want it? In theory, a 32 Mbit upload can complete in under a second using less than 10% of the 480 Mbps bandwidth of Hi-Speed USB.

Hi Tepples,

I would prefer 1-2 seconds,

Please reread my post. I have put in boldface everything that does NOT pertain to the SNES.

If you're going to tell me that you're working with a format that is larger than 12MB, you're working with a format that requires a substantially more complicated controller than just flat memory. (GBA, DS, PSP, N64, &c) You will need programmable logic for any of them to work. Furthermore, for amounts of RAM noticeably larger than 512KiB you will either be spending a gazillion dollars for it, or will need a huge beefy power supply, or you'll need voltage shifting logic, or some combination.

If you're going to tell me that you think that you will care about the difference between uploading a full image in 200ms and anything less, you're wrong. It will take longer to group the data for upload.

I answered things giving you answers pertaining to the SNES because you'd asked about the SNES.

edit: fix same math as above in quite (lost track of decimal place, specified too fast by factor of ten)

slow down. I never wanted to transfer anything near 12MB! Actually, I just want to start testing with 4Mbits now.

I'm just looking for the fastest and easiest way to get a ROM over USB to a flash chip and/or SRAM chip(s). Unless there are better ways unknown to me. Please shine the light on me.

The reason why I have a problem accepting your answer is because I do not see the full picture here of how this is associated with the yet to be found optimal USB transfer and how the speeds of that transfer are affected any way (such as micro controller speed?) This is all new to me so please be slow.

Also, in the GB Flasher, it used a crystal of 6Mhz with the FTDI chip, I wonder how that works and could it be sped up. I have yet to learn how it all works.

My gripe here is that I want to be sure I am venturing in the right direction. It takes a lot of learning . It would be nice to take the correct approach first.

Great. 4Mbit is 512KiB. You don't need to be faster than 200ms. (That's as fast as a nominal web page load). Doing the math: You don't need a write speed faster than 2.5MB/sec, or 20mbit/sec, or a byte every 400ns.

This is 1/20th of USB2.0 "high speed". It's about 2x USB1.1"full speed".

The 6MHz crystal is specifically used as the reference timebase for USB communication; it must be a factor of either 12MHz or 480MHz (depending on the specific variant of USB spoken)
The ratio is probably fixed in hardware.

Let's try this: What Are You Really Trying To Do?
I'm guessing the answer is "build a really fast programmer", so if I'm right, let me follow that with:
What are you going to use that really fast programmer to do?

From the moment I saw "EPROM emulator", I realized that the OP is trying to run a freshly built ROM image on hardware without having to pull the CF out of the PowerPak all the time. When the user clicks "Build and Run" in an IDE, the IDE rebuilds the ROM image from source code and then, instead of opening an emulator, sends it to the cart. Then the cart should write this image to SRAM or PSRAM, connect the RAM to the Super NES cart bus as if it were ROM, and reset the Super NES Control Deck.

Or are you asking what one is trying to do by developing software for the Super NES in the first place?

Ok, so then the next questions are:
How long do you think it will take to build said ROM image?
What percentage overhead is permissible to program a device relative to the time it takes to build said image?
Which of the many aspects of the obnoxiousness of removing the CF/SD card from the powerpak/everdrive are the ones you want to fix?
What if you had to pick only one of them?

You are hitting the nail on the head, except no PowerPak.


Beats me. It's supposed to go hand-in-hand with a game I am writing in C++ and SDL. So I imagine a multi-platform release with a SNES version to go along.


Very interesting question. I am just enjoying learning. I am not too worried about the relationship between the overhead, because it is teaching me to be patient.[/quote]



I have never tried these devices, so I am not sure. I have a variety of goals that if I organized in serial fashion would be this.

1) Get money
2) Purchase assorted supplies for:
3) Building a Gameboy Cartridge flasher
a) learn about electronics
b) learn about micro-controllers
c) learn about USB (2.0)
d) figure out best approach or design that is the best
e) clean, simple, fast,
f) be happy

4) make modifications and boards for snes flasher
a) modify firmware / software to reflect SNES aspects
b) possibly segment the software into a combination software for one unit that can do both

5) I am still interested. Make Eprom Emulator for the perfect explanation Tepples gave as reason for its existence.

6) Work on my incompleted SNES VRAM organizer software for importing graphics and exporting VRAM binary for direct DMA. here is a writeup on it, and github: http://www.bazz1.com/snes-gfx-edit/

That has to be determined whether to continue in QT, or I can program in an easier and more intuitive environment. This will involve learning more about graphics file formats such as PNG.

7) Work on SNES game

There's more to it. Ok I'll keep going

8) Minimalize SDL version of the game, ensure raw graphics are directly usable for harmless intuition of use with both SNES and ports. Harmonized to use SVG graphics format with a multi platform SVG->PNG conversion that is in the works, allows exporting SVG at any scale with no less in quality. http://www.youtube.com/watch?v=70YGaHByQSQ
This may or may not help with different screen resolutions. Inconclusive, yet seems to be safest approach. However, I do not know how friendly SVG format is with pixel artist types.

9) Get in touch more with graphics artists. Tighten up art specifications for enemies and objects.
10) Get money

11) Continue programming game in SNES and SDL. Stay happy. Have fun.
12) We'll get there.

Sounds like a great plan!

One of the best rules of thumb of inexpensive¹ engineering is: build the simplest thing that could possibly work. Figure out what you like, or don't like about it.

Once you've got something to compare to, and with the experience of having built something, you'll now have the experience to know what to change, how to change, and where you need to do further research.

¹ Inexpensive means "in terms of human life" or "lawsuits", so e.g. the space shuttle, medical research, and bridges don't count. Software, most electrical engineering, some bioengineering and mechanical engineering does.

I suggest cutting all the superfluous complicated electronics and just stick with the basics:


On a serious note, one thing to consider for target times is the erase time of the memory you're considering. Large flash chips take ~1min or more to erase. So in that situation having a 2 second programmer is kind of pointless. Not that large flash is bad, or 2 seconds isn't valuable time savings. But I'd consider things like that when considering the speed of the overall design. If you've settled on slow erasing flash chips, then there isn't much point to jump through a bunch of hoops for sub-10second USB speeds.

In regards to flash writing speeds using a chip with buffered writes can drastically reduce programing speeds. I went from ~12min to ~3min with this switch on one of my projects just due to buffered writes alone. It's also much more stable and reliable than programing individual bytes.

I think that's why the OP is going with RAM instead: erase happens in the same 140 ns it takes to program each byte.

In any case, if you're not using all the RAM in the console, there's always the option to make a cart that just receives 184 KiB of data, stashes it in $7E2000-$7FFFFF and VRAM $0000-$7FFF, and redirects the interrupt vectors. That might be the simplest thing that could possibly allow testing 1-level builds of your game.

Yes RAM is a nice option when considering writability/erasability. But it has it's drawbacks of being volatile, cost, and easy corruption. When I realized my programming options were not going to cheaply/easily reach USB 2.0 programming speeds, RAM started loosing it's edge.

If it takes only one to three seconds to reprogram the RAM while the cart is connected to a PC that's providing power, you don't really need to worry about volatility so much.

Can you fellas remind me of the most important speed factors in accomplishing a speedy upload/download of Flash Memory? Assuming this setup is through USB (hiSpeed, or Full), and uses a microcontroller. I can't be much more clearer than that (literally)

I'm not sure what you're looking for exactly... Speed factors? What kind of details are you asking for? I've tried to provide general input on the matter. So if you can explain how that input isn't what you're looking for, or what kind of 'factors' your asking about perhaps I can re-direct my answer.

Things to consider that might answer your question:

*Using a micro-controller to receive data serially in any fashion will be slower than if the mcu can get data in byte chunks from what ever is handling the USB comms. The less time the mcu has to handle recieving data, the more time it can devote to pumping data into the flash.

*Writing to flash is gernally slow, especially old ones. Current day chips (ones which are still in production) often have means to improve the programming time. As I pointed out previously buffered writes is one of these tactics. Another is accelerated voltage for faster programming, this is generally 12v you can apply to a specific pin for faster writes.

*Optimizations can make a big difference depending on the application. If you're developing a game, each build won't likely need the entire chip erased and reprogrammed. If you do the extra work to sense what bytes/sectors were affected, then you could just transfer the data needed to make those modifications and reflash the needed sectors only.

Some other optimizations could be taking advantage of the time the mcu is waiting on the flash chip to finish it's write. Instead of sitting there and polling the flash for several micro-seconds, the mcu could be making use of that 'down time' to fetch the next chunk of serial data.

Get the data in byte chunks. What is this called? I am investigating High-Speed USB support with microcontrollers, and I started learning about USB specification, for instance Bulk transfer and - isochronous - is faster but not guaranteed, bulk is always guaranteed. I figured to go with Bulk for my first time around. Now I feel as to try isochronous. However, I don't very much understand the difference between serial transfer and receiving in byte chunks as you suggest. I don't even know where to start.[/quote]

Interesting,

My plans exactly. Let's not forget I am programming a flasher first, and not the Eprom Emulator. Therefore, this method will only be useful for the RAM method. However, it could still be used to possibly narrow down segments of flash as well.[/quote]
no comment

That's about as much as I can give you, parallel vice serial. Find a USB device, that will communicate to your mcu in parallel 'byte wide' interface, vice serially. Or use a beefy (overly expensive) mcu which has built in USB interface, that will allow data to come in, without tying up the mcu. (EDIT: I will point out though, that by taking this approach there is little regard to the cost of the device. You're saying I'd rather pay 2-4 times as much so I can wait a few seconds vice a min.)

I don't know about this bulk/isochronous stuff, but you want reliable data regardless of what you're doing.

As for the 'EPROM Emulator', not sure what your plans are. But if you're trying to get a mcu to act as a ROM for the SNES, I'd stop right there. Too much data, to fast, and too random for the SNES. Just use memory to 'emulate' memory...

That depends on how many times one plans to push Build and Run, especially while tracking down an accidental reliance on emulator inaccuracy, and how much one makes per hour.


That's what an "EPROM emulator" does. Kev made one, for instance.

This question comes from Phineas in Colorado: Does the Super NES CPU let the cart bus float while in reset, or is it still driven?


And who got the Phineas reference?

Well kev's using RAM to act as ROM. Not an mcu to act as ROM. There is a significant difference between the two. That was I why suggesting when I said memory to 'emulate' memory. Bazz's flash/ram device would be similar, just not termed 'EPROM emulator' IMO as it's more of a flash/ram cart, so that's where I got confused I guess.

Bazz, if you want my uncandid advice, I'd point out that you need to walk before you can run. Start off with the simplest, easiest, and cheap entry option you can find. Something that doesn't require you to really 'know' much about USB. Perhaps something like arduino with provided USB libraries and everything. Sure it may be slow as molasses to start, but there is quite a bit you can do to make it acceptable in speed. If you're able to get something like that *working* you'll have a much better idea of what you need to get yourself into to program something in a few seconds. If you try to start off with the most complicated, highest speed option you can find to kick off your project I'd imagine your doomed for failure based on what I'm gathering from this conversation.

Guys/Gals check this out:

http://www.cypress.com/?id=193

I've been looking into it, and it sounds very useful and interesting.

Looks legit. With a specialized part like that though, I make sure you can figure out nearly everything you need to know/learn from the datasheet. You probably won't find a lot of forum/internet help on a specialized part like that, so it's just you and the datasheet, and the cypress website.

I'm currently accessing Cypress forums. Asking how/if the Cypress can effectively read/write a parallel flash.

I kind of have it figured out subconsciously. It's good to ask and learn more.

That Cypress part is the same one used in the Saleae Logic and its knockoffs. It contains a comparatively slow 8051 core (relative to USB data rates) and a bit of glue logic that allows for bulk 8- or 16- bit DMA in either direction over USB2.0 at up to 24MB/s without any involvement from the microcontroller.

What it won't do is attain "USB2.0 high speed" speeds at any kind of nontrivial process, such as polling FLASH to see if it's done. (What it can do is provide or measure data either isochronously or in response to an external trigger) A megabyte or two per second should be doable, though.

(BUT: the flash can't be programmed that fast anyway. Getting the host side that fast won't help until you program RAM)