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.

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:

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):

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):

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

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).

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).

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).

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.

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.

Example:
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.

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.

RAM	ROM	CRC-32	Checksum	ROM ID	Release	Version	nvdrv	size	nvr	size	PD_RSIZ
8	CDI470/20	C51E6545	EFA2	70	1.1	170511-200470-317	e18b45	774	e9b44e	94	$1FF8
32	CDI470/20	C51E6545	EFA2	70	1.1	170511-200470-317	e18b45	774	e9b44e	94	$1FF8
8	CDI220/60	6397089B	8E16	60	1.5	160515-200470-317	e18b45	774	b2f4a8	94	$8000
32	CDI220/60	6397089B	8E16	60	1.5	160515-200470-317	e18b45	774	b2f4a8	94	$8000
8 / 32	CDI490/00	9A10DA73	C852	77	1.7	177517-200470-317	d6e902	878	191c24	98	$0000
32	CDI490 MAME	E2F200F6	0761	77	1.6	177516-200470-317	d6e902	878	191c24	98	$0000
8 / 32	CDI660/00	FC327BF2	C18F	80	1.0	180520-200490-317	d6e902	878	191c24	98	$0000
8 / 32	CDI470 + $8000	5E5E2DCA	EF3A	70	1.1	170511-200470-317	e18b45	774	b2f4a8	94	$8000
8 / 32	CDI470 + $0000	947EEE1F	ED82	70	1.1	170511-200470-317	e18b45	774	165588	94	$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.

Conclusion

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.