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’nterlink and a terminal or the CD-i Link program (cdilink), as described here.
On a 32 KB NVRAM system, the screen will look like this. There is plenty of space available:
CD-i Fan provided me with some background knowledge: The jumpers underneath the NRAM 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 188.8.131.52 / 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.)
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.
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.
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.
Let’s have a look at the test results. Remember, we want 32 KB of NVRAM and a working clock at the same time.
|8 / 32||CDI490/00||9A10DA73||C852||77||1.7||177517-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 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 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.
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.
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.