When I was playing around with the SPI RAM on the Uzebox, I noticed that touching the chip (or the ATMega's related pins) would corrupt the SPI transmissions. I thought it was just a consequence of the high baud rate (~14MHz), but now I am not that sure.
At work I am testing an FRAM (this one, interesting chips, we want to use them for logging) with an XMega running at 32MHz, reading and writing it at the maximal possible rate (16MHz on the SPI).
The test itself consists writing and reading back random data cycling through a 32 bit LFSR, writing and reading back the entire chip about once in a second. I tested the test with fault injection and momentarily shorting SPI pins, so I am sure it works proper, it detects faults (and counts / reports them by UART along with real time and temperature read back from an SPI RTC, the stuff is intended to be analyzed on wide temperature range later) all right.
Now when I touch this configuration anywhere, nothing happens at all, it just keeps running all right. By this I have some doubts whether the SPI RAM as integrated into the Uzebox is stable (I don't know whether the SD card itself exhibits such behaviour, maybe it would worth some examination too: if it does, possibly the SPI RAM is also fine for the purpose of games).
SPI RAM stability
Re: SPI RAM stability
I don't recall where but I thought I remember someone else mentioning this before, though it may have been uberlinuxguy(guy who initially brought up the idea of using this chip) on a breadboard setup and not the PCB. And maybe it was actually related to the SD card, since apparently some people have some problems requiring resetting the console for the SD card to work...or did simpleSD fix that with the weak pull up..I don't know at all really except everything has always more or less worked for me. Is this with the Uzenet module 1.0 or 2.0 PCB?
I have not tested anything on hardware with this except for multiple times of the high resolution monochrome demos that shows Akuma. For me it always displayed perfectly even running minutes at a time though I never tried touching the circuitry. I would guess touching it could add a bunch of capacitance and screw up the otherwise fine square transitions. What is the difference between your work project and the Uzebox; just that the Uzebox has the addition of the SD card on the SPI bus?
I have not tested anything on hardware with this except for multiple times of the high resolution monochrome demos that shows Akuma. For me it always displayed perfectly even running minutes at a time though I never tried touching the circuitry. I would guess touching it could add a bunch of capacitance and screw up the otherwise fine square transitions. What is the difference between your work project and the Uzebox; just that the Uzebox has the addition of the SD card on the SPI bus?
Re: SPI RAM stability
The PCB is V1.3.1, it has the ESP 8266 and the SPI RAM.
I did a few tests with the Akuma demo trying pull-up and pull-down on the MISO pin. It doesn't help, only changes the behavior slightly. I also noticed it isn't necessary to touch any pin of the SPI RAM, just hovering a finger right above the chip causes distortions, and touching the SPI lines on the AVR's side has no effect (touching reset has which is next to the SPI pins). So it seems like the overclocking has no ill effect at least on the AVR's side (the SPI RAM should happily run at 14MHz, maybe it doesn't like the higher voltage). Removing the SD card has no effect (my copy of the Akuma demo is altered to call sdCardInitNoBuffer() to coexist with the SD card, and I usually program it using the bootloader).
Stability is important if you want to do anything with the SPI RAM beyond graphics. You wouldn't much notice a byte occasionally missed or being off if you only used the SPI RAM for graphics, but things could get very nasty if you stored game state or logic in it.
Maybe it is a peculiarity the SPI RAM itself. If it is, obviously my board with the FRAM chip wouldn't exhibit the behavior (that board has nothing very notable, actually it was a sloppy board on which initially nothing worked apart from the crystal and a few LEDs, lots of patchwork and dangling components its designer missed - so it is rather a miracle that it works in the end).
I did a few tests with the Akuma demo trying pull-up and pull-down on the MISO pin. It doesn't help, only changes the behavior slightly. I also noticed it isn't necessary to touch any pin of the SPI RAM, just hovering a finger right above the chip causes distortions, and touching the SPI lines on the AVR's side has no effect (touching reset has which is next to the SPI pins). So it seems like the overclocking has no ill effect at least on the AVR's side (the SPI RAM should happily run at 14MHz, maybe it doesn't like the higher voltage). Removing the SD card has no effect (my copy of the Akuma demo is altered to call sdCardInitNoBuffer() to coexist with the SD card, and I usually program it using the bootloader).
Stability is important if you want to do anything with the SPI RAM beyond graphics. You wouldn't much notice a byte occasionally missed or being off if you only used the SPI RAM for graphics, but things could get very nasty if you stored game state or logic in it.
Maybe it is a peculiarity the SPI RAM itself. If it is, obviously my board with the FRAM chip wouldn't exhibit the behavior (that board has nothing very notable, actually it was a sloppy board on which initially nothing worked apart from the crystal and a few LEDs, lots of patchwork and dangling components its designer missed - so it is rather a miracle that it works in the end).
Re: SPI RAM stability
Interesting even being close to it is enough interaction! I will have to try this on my side as well, and see if the Uzenet modules are any different in that respect. I think just the SPI bus is over-volted, as it is powered by the extra 3.3V regulator with the ESP8266. Haven't looked at the schematics or datasheet in a long time, but that would seem, if anything, the only item out of spec on a presumably commercial grade tested product.
I guess for me it seems no real "risk" to make games using it for logic since in the grand scheme, it's just a game. I wouldn't want any important scientific research to be calculated in the SPI ram at this point I suppose, but so far my "computational achievements for humanity" have been rather frivolous
I should probably throw a scope on it and see what it looks like during the interference, but I am pretty bad at all that as of yet.
I guess for me it seems no real "risk" to make games using it for logic since in the grand scheme, it's just a game. I wouldn't want any important scientific research to be calculated in the SPI ram at this point I suppose, but so far my "computational achievements for humanity" have been rather frivolous
I should probably throw a scope on it and see what it looks like during the interference, but I am pretty bad at all that as of yet.
Re: SPI RAM stability
Hmmm, interesting this somehow rings a bell. I always had weird transient issues with the SPI RAM. Touching or hovering could be one, I can't remember. As you guys mentions, indeed it's just a game, but yet I would really like to know the real reason for that. On my V1.3 board it's not sensible to hovering, but indeed it is very sensitive to barely touching on pins 5 to 8.
Edit: Damn, I know why it glitches, at least when touching. I left Pin 7 floating (/HOLD)!
The spec clearly state "HOLD must be held high any time this function is not being used". Sure enough if I run a wire from VCC to pin 7 all is fine. @Jubatian: can you test this out on your side for the hovering issue? Fortunately it's a easy fix since the next pin (8) is VCC...just add a solder bridge between pins 7 & 8. 
Edit2:That FM25V10 F-RAM chip is pretty nice...non-volatile ram (151 years retention!) in such a tiny factor. Too bad it's not available in DIP.
Edit: Damn, I know why it glitches, at least when touching. I left Pin 7 floating (/HOLD)!
The spec clearly state "HOLD must be held high any time this function is not being used". Sure enough if I run a wire from VCC to pin 7 all is fine. @Jubatian: can you test this out on your side for the hovering issue? Fortunately it's a easy fix since the next pin (8) is VCC...just add a solder bridge between pins 7 & 8. Edit2:That FM25V10 F-RAM chip is pretty nice...non-volatile ram (151 years retention!) in such a tiny factor. Too bad it's not available in DIP.
Re: SPI RAM stability
Yes, that fixed it!
Well, I have no soldering iron at home. Anyway, a DIP chip, a DIP socket, let's think... 
It is stable. At work, the SPI chips we tested all work rock solid (the aforementioned FRAM chip, an MRAM chip, and a Cypress 64MBit flash) at 16MHz, after several days of testing already. So for gaming these are definitely all OK. By the way Fujitsu sells FRAMs in DIP socket, such as this one, but it is 3.3V. Cypress has 5V FRAMs, but those are SOIC. However Adafruit has one on an easy to use breakout board (I think that's a Fujitsu chip).
These are great news, I almost finished an SPI RAM Mode 74, but put it aside due to the stability issues. Now that the problem is discovered, experimenting can continue
By the way isn't it possible that the RESET pin also has this problem? At least on this it seems like so. Something like this (found on a SparkFun tutorial) seems to be missing from there.
- SPI RAM patched
- P3296346.JPG (96.33 KiB) Viewed 6707 times
- Akuma
- P3296347.JPG (124.33 KiB) Viewed 6706 times
It is stable. At work, the SPI chips we tested all work rock solid (the aforementioned FRAM chip, an MRAM chip, and a Cypress 64MBit flash) at 16MHz, after several days of testing already. So for gaming these are definitely all OK. By the way Fujitsu sells FRAMs in DIP socket, such as this one, but it is 3.3V. Cypress has 5V FRAMs, but those are SOIC. However Adafruit has one on an easy to use breakout board (I think that's a Fujitsu chip).
These are great news, I almost finished an SPI RAM Mode 74, but put it aside due to the stability issues. Now that the problem is discovered, experimenting can continue
By the way isn't it possible that the RESET pin also has this problem? At least on this it seems like so. Something like this (found on a SparkFun tutorial) seems to be missing from there.
Re: SPI RAM stability
Well, I never got any issues with the reset but, technically, yes it should have a pull-up. Interesting if I touch pin 9 with my fingers, no problems. But if i touch with a long piece of wire it resets the console.By the way isn't it possible that the RESET pin also has this problem? At least on this it seems like so. Something like this (found on a SparkFun tutorial) seems to be missing from there.
Unless someone discovers a real problem with that I wont chaneg the design since that would required another part (a 10K resistor), redoing part of the pcb, assembly guide, etc.Re: SPI RAM stability
I checked the ATMega644 datasheet, it states that the RESET pin has a weak pull-up of 30-60KOhms (DC Characteristics on page 316, circuit diagram on page 46). So at least it isn't floating. But it is definitely weaker than my finger (I can reset the Uzebox by touching that pin), anyway, in normal circumstances it should work (it is good to know that this is a reason for that behavior, not the overclocking).