It is currently Sun Dec 10, 2017 9:04 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 4 posts ] 
Author Message
PostPosted: Sat Nov 18, 2017 6:27 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1114
Location: Gothenburg, Sweden
So, i might aswell try to compile a comparative list of the newer RAM/ROM types that i think are getting more and more practical for NES(and other machines) homebrew related hardware. Maybe this is public knowledge, but i thought it might be a good time to collect this info.

We all know flashROM. It's abundantly available, cheap, versatile. GTROM is using it, and it can sort of be considered a well-rounded universal memory, if a little slow. It's great for what it does. It has three caveats as far as i'm concerned.

-Slow rewrites, + the fact that you can't read and write at the same time is a combo makes it somewhat inappropriate as expansion work RAM.
-Data cells overwritten will slowly lose their data retention capacity over use, with a capacity that's comparatively low-end to alternatives listed below.
-Also because of the slow rewrites, it is somewhat slow when you want to compile/assemble and test in quick cycles (for GTROM, now there's a workaround provided by NovaSquirrels' PowerPak support)

Then we have MRAM (magnetoresistive RAM).
This can also sort of be considered a universal memory.

Pros:
+endless write/read/rewrite endurance
+(sometimes) block-based write protection
+Hi-speed writes, they seem to range 35-45ns
+Interface: are parallel interfaced versions (aswell as less useful serials).
Cons:
-Data retention typically lasts only 20 years after last power-off. This makes its use for PRG-ROM/CHR-ROM purposes debatable.
-Maybe a bit pricey; see below.

Other notes:
*warning: power supply nominally 3.3V, with a typical tolerance up to 3.6. Needs a voltage converter, might add to cost depending on if it was needed anyway or not.

Price and availability:
I haven't found too many actual commercial producers, and the one i found most info on only had few suitable types in stock at mouser. The most interesting was this:
256kB parallel, at the price of 4,75EUR at a batch of 100. This seemed to be the most reasonable one. TSOP package. SOIC currently not in stock.

There might be more manufacturers of similar memory chips, i wasn't very thorough

There are 1, 4 and 16MB versions. 1MB would clock in at around 9-10EUR in a reasonable batch, and the 4 and 16MB versions are probably both more than any homebrewer would need + a lot too much in price.

Quick Evaluation:
Great for Work RAM, Save RAM, external graphics RAM (seemingly a lot better than FlashROM), but debatable use in the role of PRG-ROM or CHR-ROM because a copy unused in ~20 years will start to decay. Speculatively, maybe future generations of MRAM will improve on this, who knows.
As for external graphics RAM, it is potentially OK, but look at lidnariq:s comment just below for potential problems.

References:
https://eu.mouser.com/new/Everspin-Tech ... rspinmram/


And then there's FeRAM / FRAM (reformatted from this post).
Pros:
+Speed: Close to conventional RAM speeds; overwrites in a single cycle. Suitable for quick access.
+Durability/data retention: While there's an upper limit (typically 10^12 times per byte ), it goes way many times beyond FlashROM and EEPROM.
+Interface: Comes as parallel, though serial seems to be cheaper in general. The parallel ones typically have a SRAM like interface built in.
+Price range: 1-5 dollars for reasonable sizes in the 64kB-512kB range
+Unpowered data retention: typically estimated to last over 200 years below +35C, 95 years at +55C, or 10 years at a temperature of +85C, which is way better than MROM in this regard

Cons:
-Because reads wear the memory down just like writes (it's basically the same operation), this memory type is only suitable for storing ROM if any and all tight loops, like spinlocks, are copied from ROM and run from the systems' internal RAM instead. If used on a cartridge, emulators supporting it should be made to warn devs of code that is potentially harmful to this memory type.

Other notes:
*price and availability: seemingly better than MRAM in both regards. A few major companies like fujitsu and texas instruments manufacture FeRAM/FRAM; aswell as some relatively smaller companies.
*warning: just like MRAM, power supply is nominally 3.3V, with a typical tolerance up to 3.6. Needs a voltage converter; might add to cost depending on if it was needed anyway or not.

Quick evaluation:
Great for WorkRAM, Save RAM, external CHR-RAM/ROM.
Potentially OK for PRG-ROM, provided the program copies and runs any and all high-rate code like tight loops and such in the NES' internal 2kB RAM.

(Has better data rentention than MRAM in a powered off state. Has better data retention than FlashROM when rewriting, but worse than MRAM in this regard, and worse than both when reading).

References:
https://www.semiconductorstore.com/cart ... duct=48940



====

While i started looking into this as a part of the "procedural level generation on the NES" query, it seems to me the largest benefit with both MRAM and FeRAM from a design perspective is that they potentially provide means to make the outlook of simulation, map manipulation, large save files and persistent level generation more available to homebrews. Compared to battery backed standard RAM, i think they should prove somewhat competitive in price, although they'll need a 5v to 3.3v converter.

Edit:
Some last notes:
-PCB size: FlashROM, EEPROM, FRAM and MRAM all have in common that they need less PCB real estate than battery backed RAM

-FRAM used as PRG-ROM - durability calculations:
Code run 60 times per second is rated by Fujitsu to last ~5 years and 3 months of continous use, so it's safe to say this is sound.
Code spinning at 7 cycles, as calculated by Tepples, would last ~83 days and 8 hours of continous use, which i wouldn't recommend even if i think it's rare of any single cartridge to see so much use. For example, a demo/arcade cartridge is going to be burnt out rather quickly. It's worse still with code spinning faster than that.

_________________
http://www.frankengraphics.com - personal NES blog


Last edited by FrankenGraphics on Sat Nov 18, 2017 8:33 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Nov 18, 2017 7:57 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6503
Location: Seattle
FrankenGraphics wrote:
-Data cells overwritten will slowly lose their data retention capacity over use, with a capacity that's comparatively low-end to alternatives listed below.
Er.

Flash has a lower total number of writes than other options, but its program/erase speed already makes it inappropriate for repeated read/write cycles.

But as far as raw retention without rewrites? It trivially blows everything else out of the water. Microchip's SST39SF040 Flash is rated for 100 years retention after a block has been erased 10k times.

Quote:
-Also because of the slow rewrites, it is somewhat slow when you want to compile/assemble and test in quick cycles (for GTROM, now there's a workaround provided by NovaSquirrels' PowerPak support)
Flashing the SST39SF040 is quite quick; 8 seconds to erase and refill it is probably faster than the amount of time it takes remove the CF card from the PowerPak and put a new image on. One of the serial bootloaders (both Memblers's modified Game Genie and the Power Pak have serial port adapters) makes this more comparable, but otherwise the difference is going to be hard to notice.

Older and/or bigger flash is slower, but not relevant here.

Quote:
[FeRAM] Great for WorkRAM, Save RAM, external CHR-RAM/ROM.
Last bit is not entirely clear. Worst case: on every scanline, any scanline with fewer than 8 sprites sees a fetch from tile $FF. I don't know which row ... it's probably always the same one? That means that you're talking about at least ~7k reads of wear per second on that byte. That hits 10¹² reads in about 4.5 years of continuous operation; half that time if using 8x8 sprites, and prorate by the number of sprites fewer than 64. (Of course, it might be ok to just write off tile $FF from the sprite sheet if FeRAM errors remain confined to the overworn byte)


Last edited by lidnariq on Sat Nov 18, 2017 8:01 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Nov 18, 2017 8:00 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19322
Location: NE Indiana, USA (NTSC)
MRAM is "Maybe a bit pricey", but how does this compare to, say, the combination of flash and 32 KiB of non-battery-backed work RAM (such as a 62256 SRAM)? A game would load a campaign by copying it from flash to work RAM and save it by copying it back.


Top
 Profile  
 
PostPosted: Sat Nov 18, 2017 8:26 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1114
Location: Gothenburg, Sweden
lidnariq wrote:
Flash has a lower total number of writes than other options, but its program/erase speed already makes it inappropriate for repeated read/write cycles.
Huh, I thought i wrote that, albeit in different places and probably way more unclear than you put it. But yeah, my (perhaps poor) judgment is based on what the different types of memory are capable of doing up to their rated number of writes (or in the case of FeRAM, any access), not how good they retain data past that point.

Quote:
Flashing the SST39SF040 is quite quick
So the bottleneck isn't really FlashROM in itself, but any serial interface added into the mix.

Quote:
Last bit is not entirely clear. Worst case: on every scanline, any scanline with fewer than 8 sprites sees a fetch from tile $FF.
Oh. So i wouldn't exactly label it "great" with this knowledge in hand. I'll revise the OP, thanks!

tepples wrote:
MRAM is "Maybe a bit pricey", but how does this compare to, say, the combination of flash and 32 KiB of non-battery-backed work RAM (such as a 62256 SRAM)?
In terms of price, that should be a bit cheaper? But it's not as straightforward as a procedure. More code for the programmer to write, and you still need to copy and run your storage code from RAM. While storing, you might want to turn rendering off, because you're likely to save all of the campaign in one chunk. Other methods, especially with the help of MRAM, could provide continuous saving depending on cpu budget, or simply treat the campaign as the save.

I think the price of MRAM is bound to drop a euro or two for sizes 256kB-1M, *if* wider commercial applications are found and/or more manufacturers start making them, though the market seems to be in bigger sizes of the STT-MRAM variety.

<digression>FeRAM already has some solid applications in the form of one-time init factory settings where the write speed plays a role in effectivizing the assembly line, so you can get a better profit margin or retailer price on your product, and in passcard systems, which are somewhat more secure and above all just a little quicker to process a pass, which plays a role in public transportation.</digression>

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot], Yahoo [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group