Extend CD32 NVRAM?

[Amiga1992]

I was wondering if anybody EVER looked into doing this? NVRAM is such garbage at 1KB, it's pretty useless.

Is there the chance within the hardware to expand it? What about changing it for some Flash RAM? Have at least 1MB of it!

[strim]

That NVRAM is connected via I2C to Akiko. Changing the chip itself is trivial. But the software won't magically know that it suddenly got bigger.

[Amigajay]

Does it need to know? when you save something it just pushes data to the chip, like with Cannon Fodder it just wipes over anything anyway lol

[strim]

It does. I2C EEPROMs aren't addressed like normal memory.

[alexh]

I imagine that NVRAM read/write is a Kickstart ROM function and very few CD32 titles "bang the metal"?

It could probably be fixed but only with a Kickstart ROM change too.

[Daedalus]

According to the developer docs, the size isn't fixed and so software should be able to store more information there if the space is available. The ROM functions are indeed how it's accessed, and it starts off with a GetNVInfo() call, which lets the software know what size it is.

Of course, as is the Amiga tradition, there's always a chance that some games bypass those ROM calls and access the NVRAM directly, though why you would do that or if anyone did I don't know. But if games followed the rules, it should be possible not only to extend it, but also to use an external floppy drive (if the CD32 is suitably equipped) for saves transparently. Extending the existing ROMs may require patching the ROM-based nonvolatile.library, but without knowing the internal details of it and how it determines the space available it's impossible to know more.

Interesting information: http://amigadev.elowar.com/read/ADCD.../node04DB.html

[hooverphonique]

the GetNVInfo call will most probably get the size of the NV filesystem, though, and this will probably not necessarily automatically reflect the size of the eeprom (in case the NV filesystem is stored there, of course).

I would say that there must be an exec device in the kickstart which controls access to the eeprom, since this NV filesystem seems to be a regular amiga volume according to that link, so it will be up to that device, if it is able to determine the size of the eeprom, or it just has a hardcoded size inside..

[Amigajay]

Originally Posted by Daedalus

Of course, as is the Amiga tradition, there's always a chance that some games bypass those ROM calls and access the NVRAM directly, though why you would do that or if anyone did I don't know. But if games followed the rules, it should be possible not only to extend it, but also to use an external floppy drive (if the CD32 is suitably equipped) for saves transparently. Extending the existing ROMs may require patching the ROM-based nonvolatile.library, but without knowing the internal details of it and how it determines the space available it's impossible to know more.

Castles II on the CD32 already has the ability to save to an external floppy drive.

[Toni Wilen]

EEPROM size is hardcoded in ROM and everywhere else too.

[Daedalus]

Originally Posted by Toni Wilen

EEPROM size is hardcoded in ROM and everywhere else too.

Ah, that's a shame, because the documentation actually makes it sound like a well thought out and future-proof API. Still, patching the ROM *should* be easy enough, but if games are hard coded with the size too it's not gonna work.

[Toni Wilen]

Originally Posted by Daedalus

Ah, that's a shame, because the documentation actually makes it sound like a well thought out and future-proof API. Still, patching the ROM *should* be easy enough, but if games are hard coded with the size too it's not gonna work.

nonvolatile.library is designed to also work with disk based storage ("NVDISK"). "NVRAM" mode has hardcoded size.

Some games use direct hardware access, Cannon Fodder is one. (I assume all games that use RNC CD32 loader)

[Amigajay]

Originally Posted by Toni Wilen

Some games use direct hardware access, Cannon Fodder is one. (I assume all games that use RNC CD32 loader)

Is that why Cannon Fodder just writes over any saves in NVRAM regardless? Where as most other games are told there isn't enough space, please delete some saves?

[mombasajoe]

IIRC a friend of mine from the german-amiga-community.de (crazyIcecap) tried to build a kind of "switch-solution" (selecting one of 4 nvrams). But I don´t know if that worked. I´ll ask him.

[Daedalus]

Aww, that sucks! I can understand plenty of hardware banging for increased performance, but I think it's crazy to do it for NVRAM when there's a good API available, especially when the API will make larger storage / disk storage transparent to the game. I guess then the switcher idea might be the best bet - almost like a Gotek-style emulation with a number of slots... If they're all the same style of 1k "cells", it should be fairly easy to implement as a hardware mod.

[FOL]

That is a shame, I would love to up it. Even using a pin for pin chip, I could only find 16kb (still better than 1kb). Would it be possible to make a patched nonvolatile library (to increase hardcoded size) and load it resident?

[Daedalus]

That was what I was thinking too, but if software accesses the NVRAM directly it's not gonna work. The only options would be to patch the game or put some sort of hardware bank switcher in place instead.

[Amiga1992]

I'm glad I asked this question.
Good discussion and maybe you geniuses can figure out a way to actually make this work!

[xArtx]

Physically switching between several of the same chips is trivial.
They have 3 hardware address pins (1,2 & 3) that will be tied high or low at the PCA,
and the CD32 software will no doubt only address one chip with a specific hardware address.

They are designed so several chips can exist on the same bus, so to talk to several of them,
one would wire those address pins in different combinations so each chip only listens
for commands send to that chip. 3 bits is a maximum of eight devices on the hardware I2C bus.
To connect several that can be switched in or out only means wiring all hardware addresses
“nearly correct”, and switching in a remaining address pin to make it correct, the same way a ROM switch can work.

Internally, for a write, they are addressed with 3 device device select bits (the hardware address I just mentioned),
an address byte (address in EEPROM memory), followed by data.
chips in the same family higher capacity than 24LC02B also have a block select bit,
and higher than 24LC16B also have a 2 byte address.
So there are quite a few differences in the same family that must be accounted for in the software controlling them.

The maximum I’m aware of is 24LC512B. This is all Kilobits (not kilobytes),
so you actually need eight of those chips to make a 512 kilobyte array.
The CD32 has 1 kilobit NVRAM, which is actually only 128 bytes

[FOL]

Originally Posted by xArtx

The maximum I’m aware of is 24LC512B. This is all Kilobits (not kilobytes),
so you actually need eight of those chips to make a 512 kilobyte array.
The CD32 has 1 kilobit NVRAM, which is actually only 128 bytes

Hey, thats still 64kb. More than enough to fit my game saves into nvram.

[xArtx]

The hardest hitting data is probably the game title to display in the game save screen!
At the time I started using them is was a usual thing to use 24C16 (years after CD32 came out).
Commodore couldn’t have known the methods to control the larger chips at the time.

A shift register could be used to cycle through 8x24C01B with a button,
but I can’t see it being a marketable product considering the installation of a board to an 8 pin SOIC footprint