Philips CDI470 32 KB NVRAM Upgrade

Philips CDI470 32 KB NVRAM Upgrade

Some time ago, I noticed that the service manuals of most Mono II – IV boards have notes about 8 and 32 KB NVRAM types, to be set by jumpers and resistors. I never attempted to do that upgrade because most of my CD-i players feature 32 KB NVRAM or have older mainboards that cannot be upgraded. When I mentioned the possibility in this article, CD-i Fan warned me about the consequences: If device driver and descriptor in the ROM don’t support the extra RAM, then the player might not recognize it and lose the real-time clock – or it won’t work at all.

Why would you want to upgrade the NVRAM anyways?
For example, the save files of The 7th Guest, Lost Eden and Burn:Cycle already take up a lot of space. Add some more games and settings, and you will soon reach the critical limit of 97-98% where the player refuses to start.

CD-i memory full (8 KB)
CD-i memory full (8 KB)

This is a different error to the one featured in the previous article. Assuming that you have a healthy NVRAM chip, all you’ll have to do is to delete one or more items and you are good to continue.

If you don’t want to lose any of your precious data, then you have the option to back up the files one by one using a null-modem cable and either CD-i Link (cdilink) or CD-interlink and a terminal.

On a 32 KB NVRAM system, the screen will look like this. There is plenty of space available:

Total memory used: 23% (of 32 KB)
Total memory used: 23% (of 32 KB)

The theory

CD-i Fan provided me with some background knowledge: The jumpers underneath the NVRAM chip only take care of the different pinouts. After all, the ROM needs to be able to recognize the RAM. This is done with the modules nvr (device descriptor) and nvdrv (device driver).

I’ve captured a couple of ROM and information files from my Mono III/IV CD-i players with cdilink. This is an excerpt of these information files (modules with identical checksum are already marked):

CD-i Link information file (edited)
CD-i Link information file (edited)

With the offset and size data, I was able to locate the nvr modules in the actual ROM files (the NVRAM size is already marked):

Three ROMs with three nvr modules
Three ROMs with three nvr modules

The device descriptor option field PD_RSIZ at offset 74 ($4A) of module nvr specifies the size of the NVRAM. (See chapter / page VII-257 of the CD-i Full Functional Specification (Green Book) May 1994.)

PD_RSIZ field in the nvr device descriptor
PD_RSIZ field in the nvr device descriptor

Even though there are many different nvr modules, all of them use one of these values:
1. $1FF8 = 8 KB (8192-8, reserving 8 Bytes for the RTC registers).
2. $8000 = 32 KB (32768 Bytes).
3. $0000 = 0 KB (auto-probing).

With the information in Device Descriptor Modules on page 1-8 of the OS-9 2.4 Technical I/O Manual, we can dissect the module even further. For example, at offset $3A is M$PDEV, the offset of the device driver name: $0050. Following to offset $50, there is the name of the driver: nvdrv.
The last three bytes contain the CRC-24 checksum, E9B44E in this case.

The nvdrv modules are either 774 or 878 Bytes in size. The modules with the same checksum are marked in the table above. Interesting: both 8 KB and 32 KB device descriptors use the same device driver.
There are at least two more 774 Byte nvdrv modules and some more nvr modules with different content, but none of these are relevant for the experiment at the moment.

Preparing the CD-i player

Having a good theoretical basis, I chose a player (CDI470/20 – Mono IV) that had nothing left to loose and repaired it. Then, I attached a DPDT (double pole, double throw) toggle switch to the points shown below to keep the setup as flexible as possible.

Next, I needed a couple of NVRAM chips. For the 8 KB NVRAM, I chose DS1643 over the original M48T08 TimeKeeper. For the 32 KB, I used a combination of M5M5256DP and DS1216C, as described here.

Last, I needed a couple of CD-i player ROMs, but I really didn’t want to open up all my CD-i players and swap the chips during the tests. Luckily, the service manual gave me a hint for which EPROM to use: 27C400.

Patching the ROMs

Additionally, I prepared some patched ROM files:
Let’s see if we can patch the nvr device descriptor. After all, if the CDI220/60 with the same nvdrv device driver has both 32 KB NVRAM and a working RTC, why wouldn’t the CDI470/20, right?

However, there seems to be a catch: “OS-9 does not recognize a module with an incorrect CRC value. Therefore, you must update the CRC
value of any “patched” or modified module, or OS-9 cannot load the module from disk or find it in ROM.”
(see The CRC Value on page 1-8 of the OS-9 2.4 Technical Manual.)

Now the freeware hex editor HxD comes in handy. It allows you to define custom CRC settings. The required values were taken from here (CRC-24/OS-9).

HxD - custom CRC settings
HxD – custom CRC settings

We can now modify the 8 KB value ($1FF8) to 32 KB ($8000) and then calculate the new checksum of the module. It turns out to be the same checksum as the nvr module of the CDI220/60, B2F4A8. So they are identical after all. Don’t forget to change the checksum (in the red rectangle).

HxD - calculate CRC-24/OS-9
HxD – calculate CRC-24/OS-9

In one of the EPROMs (I’ve made several copies, just in case), I forgot to update the changed CRC-24 and the player did not complain about it at all. This was unexpected. But still, better do it right add correct checksums as required by OS-9.

There is one checksum, however, that the low-level test will complain about when it is incorrect: The 16-bit checksum of the whole ROM (ERROR:05).

ROM parity check ERROR:05
ROM parity check ERROR:05

The checksum is the algebraic sum of all bytes in the file, except the two last bytes. The result needs to be written into the last two bytes.

HxD - calculate ROM checksum
HxD – calculate ROM checksum

The low-level test is now able to calculate the real checksum and won’t complain anymore (EE26 + EE + 26 = EF3A in this case).

Programming the EPROMs

Before programming a ROM file to an AM27C400 EPROM, pay attention to the endianness (byte order). The Motorola 68000 processor expects the data in big-endian format, which it will be if you dumped a ROM with an EPROM programmer. If you dumped it via cdilink on a Windows PC (little-endian), then you will have to swap the bytes first. The program that came with your EPROM programmer will most likely have a function to take care of that.

Close to the beginning of the ROM file, you will run into these lines: “from the disk of Robert Doggett       and         Warren Brown” (early OS-9 programmers, by the way). This is little-endian.
Use the byte swap function and it will say “rfmot ehd si kfoR bore toDggte t      na d        aWrrneB ornw” in big-endian.

Little-endian vs. big-endian
Little-endian vs. big-endian
(EP)ROM and NVRAM chips ready for testing
(EP)ROM and NVRAM chips ready for testing


With every ROM and both 8 and 32 KB NVRAM chips I ran a test protocol that included:
1. Low-level test via terminal
2. Playing Earth Command (sensitive to missing RTC)
3. Setting date/time in the shell (if necessary)
4. Downloading a lot of files via batch script into NVRAM (32 KB = 95% / 8 KB = overloading)
5. Playing Burn:Cycle (loading and saving files)
6. Service Shell
7. Uploading the contents of the NVRAM to the PC
8. Binary check of the downloaded and uploaded files
9. Checking RTC in shell/in game/after communicating with cdilink and after the player was switched off.

I collected save files from all my players and could only fill about 36% of the 32 KB NVRAM first. Luckily, Burn:Cycle allows an almost unlimited amount of save files by changing the suffix of the save file (BURNCYCLE_x). The batch files utilized the cdilink downcopy (dc) and upcopy (uc) options transfer the save files. fc /b did the binary comparison of the transferred files.

The results

Let’s have a look at the test results. Remember, we want 32 KB of NVRAM and a working clock at the same time.

RAMROMCRC-32ChecksumROM IDReleaseVersionnvdrvsizenvrsizePD_RSIZ
8 / 32CDI490/009A10DA73C852771.7177517-200470-317d6e902878191c2498$0000
32CDI490 MAMEE2F200F60761771.6177516-200470-317d6e902878191c2498$0000
8 / 32CDI660/00FC327BF2C18F801.0180520-200490-317d6e902878191c2498$0000
8 / 32CDI470 + $80005E5E2DCAEF3A701.1170511-200470-317e18b45774b2f4a894$8000
8 / 32CDI470 + $0000947EEE1FED82701.1170511-200470-317e18b4577416558894$0000

Green = good, recommended.
Yellow = works, but has some errors.
Red = not recommended, too many errors.

CDI470 with 8 KB NVRAM
This is the original configuration. It runs fine, but there is only 8 KB NVRAM.

CDI470 with 32 KB NVRAM
Not recommended. It still has only 8 KB NVRAM available and the clock only advances if you are in the player shell. Otherwise, it will stop.

CDI220/60 with 8 KB NVRAM
Not recommended. The device descriptor is really for 32 KB only and that causes a lot of weird errors. Saving files will change the date/time settings. Saving beyond 8 KB will delete everything. Also, weird characters on the player’s display.

CDI220/60 with 32 KB NVRAM
This one runs surprisingly well, even on the wrong mainboard (Mono III vs. Mono IV). But, weird characters on the player’s display.

CDI490 with 8 and 32 KB NVRAM
This is the best choice. The CDI490 is almost identical hardware-wise and also detects the size of the NVRAM automatically. There are no issues at all with the clock.

CDI660 with 8 KB NVRAM
This also runs surprisingly well. However, the player shell doesn’t detect a full memory. You’ll have to delete files via cdilink. Also, the test plug for the service shell will put the player into a reset loop. Probably because the CDI660 has two controller ports on the front. A regular gamepad works fine though. Update (2021-03-14): The cause of the reset loop is explained in this article.

CDI660 with 32 KB NVRAM
This also runs surprisingly well. The only error is the reset loop with the test plug as described above.

Patched CDI470 + $8000
The results are somewhat devastating. Don’t even try to run it with 8 KB NVRAM, it is similar to what happened with the CDI220/60 ROM above. With 32 KB NVRAM, however, it becomes plain dangerous (for the saved files). Whenever something is written to the NVRAM, the date/time settings change and also parts of files saved in the 8 KB region are changed.

Patched CDI470 + $0000
Here I ran into the same problems. Additionally, all save files were displayed with the size of 0,0 %. The player shell didn’t seem to mind, but Burn:Cycle refused to save, even after deleting some of the files.

Burn:Cycle - no room (memory full)
Burn:Cycle – no room (memory full)


The Philips CDI470 NVRAM upgrade is possible, but it is not as simple as I thought initially. The results made it very clear:
At the moment, it is only possible if you already have a device descriptor in ROM that auto-detects the NVRAM size. Patching is not possible until it has been figured out what else needs to be changed.
Alternatively, you’ll have to replace the whole ROM with a similar player’s ROM. For the CDI470, this is pretty simple: Either use one of the CDI490 ROMs or one of the later CDI470 revisions that are out there for sure. There is also a CDI490 ROM file in the current MAME set (CRC-32 E2F200F6). It is an earlier revision than my CDI490, but it works fine as well (see CDI490 test results).
For the CDI210, it is probably best to try a matching CDI220 ROM. These players are very similar and shouldn’t make any problems.

If you figure anything out, please share your progress with me.

13 thoughts on “Philips CDI470 32 KB NVRAM Upgrade”

  1. A very nice set of experimental data! Quite a bit of work you did there.

    I suspect most of the timer problems are caused by the real-time clock driver (which is separate from the nvdrv module) that accesses those top 8 memory locations. OS-9 only reads the clock chip on bootup, so this explains some of the behaviour. What happens when you change the date/time? This should write to the clock chip…

    Also, some 60x ROM’s (don’t know about consumer players) manually scan the NVRAM for a player_shell_settings.prf file during boot, so this could give problems as well as they probably have the memory location and size of the NVRAM hardcoded (this is before OS-9 boot).

    I do not understand the strange display characters. Perhaps the “character mapping” tables in the SLAVE or IKAT processor are linked to this same 8KB/32KB setting? It could be interesting to compare the “bad” characters against the *.lds mapping tables in the CD-i Emulator sys directory…

    1. Thanks for the feedback!

      Actually, I’ve only noticed changes to the clock when I modified the NVRAM, not the other way around.
      What’s the name of the RTC driver module? I’ll try to keep an eye on it if I do this again.

      I didn’t include player_shell_settings.prf in my download script, they were always automatically created on each run. For me, they didn’t contain any useful data (eiter $21 or $22 at offset 00 and the rest filled with $00, $01 and $02).

      You can simulate this by renaming to, then start with a 220 F4 ROM and play a disc. I don’t know if it shows the same weird characters though.
      I’ll will attempt to do the same operation with a 210/40P player and a 220/60 ROM at some time and expect that the 210/220 switch takes care of the display.

Leave a Reply

Your email address will not be published. Required fields are marked *