Old school N64 memory pack mod thread.

[William Gaatjes]

Back in the days when the N64 was out, the memory packs were pretty expensive.

In essence, the N64 memory pack is nothing more then a 32K*8bits RAM powered by a CR2032 lithium coin battery.

Long ago , i decided to mod it by piggybacking another RAM on top of the ram present. But before i did that, i soldered the original RAM and cut the trace that connected the #CE pin (low active chip enable) to keep the ce pin of the ram floating. I then soldered it back and piggybacked another ram on it.
The ram is a TC55257B from Toshiba.

I added some (27k) pullup resistors to the #CE pins of each RAM (to keep the not selected RAM inactive) and a single pole double throw switch to select between both rams. N and O contacts to each of the #CE pins. And the P contact to the trace that i cut.

The selection which RAM to use can only be done with the N64 turned off, but it worked great.
I had a memory pack with double the capacity for a fraction of the cost.
I had to open it up because my N64 no longer recognized the memory pack when i tried it a few days ago. As it turns out, the CR2032 coin battery is fully drained. I am going to replace it. Must have been more than 15 years ago that i did that mod. Looking at the soldering quality, i think i did not had access to flux at that time.

EDIT:
For those wondering, the wires are insulated copper wire, not blank copper.

 

[sonoma1993]

What did the extra memory allow you to do?

 

[William Gaatjes]

What did the extra memory allow you to do?

The mod doubled the storage capacity of the memory pack.
From a single 32k*8bit to 2x(32k*8bit).
Games store savepoints and checkpoints on the memory pack.
And this way, i can store twice the amount of save points and checkpoints.
Unlike most console games today that do not allow you to save individual checkpoints and progress data,
most of the N64 games allowed you to do this.
Just like older 1st person shooters on the PC like halflife2 and return to castle wolfenstein allow to load and store indivual save points and progress data.
But since storage space is limited, this often meant you could not save a lot of gamesavedata from multiple games on one memorypack.
With this mod, i could.

 

[sonoma1993]

Very nice, for some reason I was thinking you modded the ram expansion pack.

 

[William Gaatjes]

Very nice, for some reason I was thinking you modded the ram expansion pack.

Oh no,

That is a RDRAM module from RAMBUS and i think it runs on the for that time amazing speed of 500Mhz bus (9 bits) speed. That would not work. It would cause serious impedance matching problems. Also, the N64 would not support it.

 

[BrainEater]

EDIT:
For those wondering, the wires are insulated copper wire, not blank copper.

Looks like wire-wrap wire to me.



------

Very cool....+1 nerd badge.

 

[sm625]

I was hoping for a mod to convert to USB flash or even compactflash...

 

[William Gaatjes]

No, it is really old school.

Replaced the battery.

I just tried to play turok 2. But i am so used to the mouse and then trying to aim with that joystick from the N64, there is a learning curve there for sure.
I have no idea how i was once able to aim with that joystick.
At least the memory pack is recognized again and of course all my save games are gone but at least it could be initialized again.
If there would be anything that i would make, it would be a mouse and keyboard to N64 controller converter because this is awful. Or at least a playstation controller to N64 controller converter.
I just started shadowman. Was a great game, but it all sure looks dated. (20 to 16 year old games for an 8MB console) I really would like to see a remake of shadowman or a shadowman invoked (2) with high res textures.

Mariokart64 works, so when i have people over, there can be some old school racing

 

[Exophase]

I was hoping for a mod to convert to USB flash or even compactflash...

That wouldn't work, at least not without some logic (FPGA or microcontroller?) to move between the SRAM it'd still need to interface and a flash chip.

An FRAM/MRAM replacement might work.

 

[William Gaatjes]

That wouldn't work, at least not without some logic (FPGA or microcontroller?) to move between the SRAM it'd still need to interface and a flash chip.

An FRAM/MRAM replacement might work.

Actually, since the sram in the memorypack is continue powered, it is relatively easy to program a microcontroller to read out the sram in the memory pack and store it on an SD card. The sram in the memorypack can just be read and stored in a file on an sdcard. With fatfs for microcontrollers it is easy.
http://elm-chan.org/fsw/ff/00index_e.html

Reading out the sram is just setting address lines one by one and activating the R/W (read/write)pin and the OE (output enable pin).
And a connector is present inside any n64 controller to use when making a proto pcb.

Writing would be similar.

If you want to go further, you could program a microcontroller (Like the SAM series from Atmel) to store the data on a sdcard and use the atmel frame work to create an usb mass storage device that can read out the memorypack, store it on the sdcard and present that data when connected to the usb bus to a host os such as windows or linux.
Swapping or sharing memorypack data like gamesave data.

 

[Exophase]

Actually, since the sram in the memorypack is continue powered, it is relatively easy to program a microcontroller to read out the sram in the memory pack and store it on an SD card. The sram in the memorypack can just be read and stored in a file on an sdcard. With fatfs for microcontrollers it is easy.
http://elm-chan.org/fsw/ff/00index_e.html

Reading out the sram is just setting address lines one by one and activating the R/W (read/write)pin and the OE (output enable pin).
And a connector is present inside any n64 controller to use when making a proto pcb.

Writing would be similar.

If you want to go further, you could program a microcontroller (Like the SAM series from Atmel) to store the data on a sdcard and use the atmel frame work to create an usb mass storage device that can read out the memorypack, store it on the sdcard and present that data when connected to the usb bus to a host os such as windows or linux.
Swapping or sharing memorypack data like gamesave data.

This is what I said, isn't it? You need logic interfacing with SRAM to do it. You can't just replace the SRAM with a flash chip; you couldn't make a flash-only version of the memory card without modifying the games. Unless they already have support for flash memory packs and can detect them.

It's kind of baffling that Nintendo went with SRAM based carts in the first place. They had enough foresight to not make that mistake with PS1. Some GBA games also still used SRAM backup.

 

[William Gaatjes]

This is what I said, isn't it? You need logic interfacing with SRAM to do it. You can't just replace the SRAM with a flash chip; you couldn't make a flash-only version of the memory card without modifying the games. Unless they already have support for flash memory packs and can detect them.

I agreed and agree with you, but i extended the idea a bit, sorry.

It's kind of baffling that Nintendo went with SRAM based carts in the first place. They had enough foresight to not make that mistake with PS1. Some GBA games also still used SRAM backup.

I am not sure , i think in 1996, 256kbit eeproms were expensive and slow.
Sram was more cheaper since it was readily available.
Also, i looked at the standby current of the sram i used (Not sure anymore if the original present sram in the memorypack is the same model, could be) and it is incredibly low. When the chip enable is pulled high, the typical static current draw is 300nA at 2V. Perhaps around 500nA at 3V. That is low enough that a lithium battery can sustain the memory pack for many years.
It is also a good business model to sell memorypacks once every few years.

The cartridge reason is also simple, the rom in the cartridge, allowed developers to fetch textures at very high speed to process without needing to buffer in the 4(8) MB dram first.
This buffering would had to be done when using a disc.

 

[Exophase]

I agreed and agree with you, but i extended the idea a bit, sorry.

Got it, thanks

I am not sure , i think in 1996, 256kbit eeproms were expensive and slow.
Sram was more cheaper since it was readily available.
Also, i looked at the standby current of the sram i used (Not sure anymore if the original present sram in the memorypack is the same model, could be) and it is incredibly low. When the chip enable is pulled high, the typical static current draw is 300nA at 2V. Perhaps around 500nA at 3V. That is low enough that a lithium battery can sustain the memory pack for many years.

It's hard to find actual prices.. all I know is it was cost effective enough to use in PS1 1.5+ years earlier. And the market was flooded with third party multi-bank memory cards that had several times the storage. At the very least there was a decent assurance that the EEPROM cost would go down in time, but I doubt the cost of the CR2032 battery would.

I suspect a lot of this came down to SRAM w/battery just being the years old industry standard and Nintendo having less willingness to try something new than Sony. Sega used battery backed SRAM packs for Saturn as well.

Some N64 cartridges actually included EEPROM, and I wonder if it was even worth bothering having external storage packs at all.

It is also a good business model to sell memorypacks once every few years.

By the time they did actually die I imagine most people had moved on to other hardware and didn't bother to replace them. Or at least I hope they lasted that long.

The cartridge reason is also simple, the rom in the cartridge, allowed developers to fetch textures at very high speed to process without needing to buffer in the 4(8) MB dram first.
This buffering would had to be done when using a disc.

This is kind of a different subject, but IMO the ROM carts were not a great decision.. they were faster and that was good, but the bulk price difference plus initial investments, minimum order numbers, and time to market constraints along with much greater overhead for spinning revisions were huge detriments. The cartridge bus in N64 was actually not that fast anyway, looks like about 5MB/s: http://n64.icequake.net/mirror/www.crazynation.org/N64/

A lot faster than CD-ROM, especially if you're randomly seeking things, but you wouldn't want to directly address code or repeatedly used data from there. You would almost certainly be loading textures into the RDRAM unless the 4KB of GPU texture memory was enough for the entire scene.

 

[William Gaatjes]

Got it, thanks
It's hard to find actual prices.. all I know is it was cost effective enough to use in PS1 1.5+ years earlier. And the market was flooded with third party multi-bank memory cards that had several times the storage. At the very least there was a decent assurance that the EEPROM cost would go down in time, but I doubt the cost of the CR2032 battery would.

I suspect a lot of this came down to SRAM w/battery just being the years old industry standard and Nintendo having less willingness to try something new than Sony. Sega used battery backed SRAM packs for Saturn as well.

Some N64 cartridges actually included EEPROM, and I wonder if it was even worth bothering having external storage packs at all.

Yep, some cartridge had eeproms in them. I have the game perfect dark, and started it yesterday and all my save games are still there.

This is kind of a different subject, but IMO the ROM carts were not a great decision.. they were faster and that was good, but the bulk price difference plus initial investments, minimum order numbers, and time to market constraints along with much greater overhead for spinning revisions were huge detriments. The cartridge bus in N64 was actually not that fast anyway, looks like about 5MB/s: http://n64.icequake.net/mirror/www.crazynation.org/N64/

A lot faster than CD-ROM, especially if you're randomly seeking things, but you wouldn't want to directly address code or repeatedly used data from there. You would almost certainly be loading textures into the RDRAM unless the 4KB of GPU texture memory was enough for the entire scene.

That is an interesting webpage. I never knew that the cartridge had a shared 16 bit adress / 16bit data bus.
And 2 extra address lines to select the lower and higher 16 bits.
I also counted ~5MB/s.


I read in the wikipage that nintendo stated transfer speeds between 5 to 50MB/s max for reading cartridges.
https://en.wikipedia.org/wiki/Nintendo_64_Game_Pak#Performance

I do wonder if you only have to apply the address once and that the prom in the cartridge (game pack) has an automatically incrementing address counter that increments every time the read pin toggles from low to high and that the data is available when the read pin goes from high to low.

That would be great for continuous reading. But random reads are slowed down by the shared address/ databus when compared to a separate address and separate databus.

 

[Exophase]

That is an interesting webpage. I never knew that the cartridge had a shared 16 bit adress / 16bit data bus.
And 2 extra address lines to select the lower and higher 16 bits.
I also counted ~5MB/s.

Yeah that sort of design is pretty common among carts. GBA also had a 16-bit shared bus, but it extended out the address lines to 24-bits instead of splitting them into high-low. Also meaning that GBA was stuck with a 32MB size limit (unless bank switching was added)

I read in the wikipage that nintendo stated transfer speeds between 5 to 50MB/s max for reading cartridges.
https://en.wikipedia.org/wiki/Nintendo_64_Game_Pak#Performance

https://en.wikipedia.org/wiki/Nintendo_64_Game_Pak#Performance

Seems to match official documentation I just googled. Looks like the parallel interface bus can do up to 50MB/s.. they say "5 Meg/sec from typical slow ROMs." So the ROM was probably the limiting factor. Maybe you could get faster ROMs, but they were so expensive as it was it seems really undesirable to have to pay for more. Unless they just naturally got faster as time went by.

I do wonder if you only have to apply the address once and that the prom in the cartridge (game pack) has an automatically incrementing address counter that increments every time the read pin toggles from low to high and that the data is available when the read pin goes from high to low.

That would be great for continuous reading. But random reads are slowed down by the shared address/ databus when compared to a separate address and separate databus.

It would appear that way, that timing diagram says up to 256 word bursts after asserting the address line.

 

[William Gaatjes]

Aha.

If you ever want to try it out, Ramtron (Owned by Cypress) made a f-ram that is pin compatible with static sram.

The FM18W08: 256-Kbit (32 K × 8) Wide Voltage Bytewide F-RAM Memory.

http://www.cypress.com/documentatio...bit-32-k-8-wide-voltage-bytewide-f-ram-memory

Timings are a bit slower, but i do not think the asic inside the n64 controller pushes data in nanoseconds.
The battery can be removed and the sram replaced with the fram.
If it works, it would retain data for +100 years.

EDIT:
Alternative : FM28V020

http://www.cypress.com/documentation/datasheets/fm28v020-256-kbit-32-k-8-f-ram-memory

 

[Skunk-Works]

I used to use Game Shark or Action Replay to transfer my game saves from the Playstation memory card to a USB stick and then onto my computer. Was a great feature because I often ran out of space on the memory card.

Now I just use an emulator for Playstation or N64.