Saturday, March 27, 2021


Most currently existing CD-i emulators use so-called low-level emulation for the system software. This means that to perform their emulation function they need copies of this software.

The CD-i system software is typically stored in read-only memory (ROM) chips inside the CD-i player; the only known exceptions to this are the PCI/ISA CD-i boards from I2m / Philips that have their system software loaded from the hard disk of the host system.

ROM picture
Philips CD-i 210 F3 ROM 1.1

ROM picture
Philips CD-i 210 F3 ROM 1.5

ROM picture
B&O Beovision AV5 ROM 1.9

ROM types and sizes

The typical CD-i player contains 512KB of system ROM which contains the CD-RTOS operating system based on Microware OS-9/68000 version 2.4. This system ROM contains the core system software including the OS-9 kernel, CD‑RTOS file managers, drivers for the specific CD-i player hardware, as well as system startup programs. The core system software typically takes less than half of the ROM, the rest is taken up by code and resources (e.g., images, fonts) for the player shell and usually some utility modules. On some of the later Philips players the system ROM is so full that niceties such as the CD+Graphics decoder cdgr or the Service Shell sv have been omitted.

Notable exceptions to this are the Sony IVO players which have 1MB of system ROM, although only a little over 835KB of that is used. The core system software takes less then 200KB of this, the remainder of the ROM is again filled with code and resources for the player shell.

Most CD-i Digital Video Cartridges (DVCs) contain 128KB of additional ROM with CD-RTOS file managers and drivers to support the MPEG playback functions. Little over half of this ROM is typically used, it varies somewhat with the hardware generation. Some cartridge versions also contain some utility modules as well.

Professional or authoring players typically have other additional ROMs, usually located on some kind of (removable) extension board. For example, the CD-i 182 unit contains an additional 64KB of ROM with drivers for the floppy drives and other hardware in this unit. Extension boards for this unit have sockets for additional ROM chips but I have never seen them filled.

In contrast to this, the CD-i 605 extension board contains 512KB of additional ROM to support the Ethernet and SCSI controllers and other hardware on the board, and it is mostly filled.

The CD-i 615 and CD-i 670 use another extension board which also contains 512KB of ROM with support modules for their additional hardware, which in this case includes IMPEG digital video.

Dumping ROMs

A low-level CD-i emulator needs access to the contents of these ROMs, which must be obtained from the hardware using a process called dumping.

All CD-i system ROMs are standard ROM chips that can be read out by a ROM dumping device. These devices can be custom made hardware, but an off-the-shelf EPROM programmer device can also be used. For this to happen the ROM chip typically needs to be removed from the CD-i player, which means opening the player and often requires desoldering the ROM chip.

However, the contents of these ROMs are also accessible from inside the CD-i player (that is after all their primary function), so they can also be dumped using software. This is typically done over the serial port as most consumer players have no other easily accessible output port (theoretically the ROM contents could also be dumped over the audio or video outputs but that has so far not been necessary).

Early 2005 I wrote a program called CD-i Link that uses the built-in download function of most CD-i players to download a small CD-i Stub program into the CD-i player so that memory can be scanned for ROMs and their contents can be dumped via the serial port. If the player has no such download function, a CD-i stub disc can be used to start the stub program.

The system ROMs of all CD-i players encountered so far can be dumped this way, with one exception: the Sony IVO-V10/V11 players. These players do not have a regular serial port accessible from the outside. Fortunately, they do have a service port that supports serial communication although it needs to be accessed directly from the system board which in this case does mean opening the player and doing a little soldering.

open player picture with soldered wires
Sony IVO-V11 player with service switch and serial cable

In addition to the CD-i system ROMs, which are accessible from the main 68000 CPU, CD-i players and digital video cartridges often contain microcontroller and/or signal processing chips that have their own ROM. Dumping this can be complex, in some cases the chips need to be “decapped” or a special test or manufacturing mode needs to be used in order to read out the ROM contents.

Fortunately, CD-i Emulator does not use low-level emulation for these chips and hence does not need dumps of their ROMs. Other emulators may need these dumps now or in the future, but it is not relevant to the rest of this article and I will ignore such ROMs below.

ROM versions

There are several brands of CD-i players, and typically multiple player models and versions within each brand. Even nominally identical players will sometimes contain different ROM versions.

The intended scenario for using CDi Emulator is that a user dumps the ROMs from his own CDi player using CDi Link and then proceeds to use these ROM files with the emulator. For this reason, it is important that CDi Emulator supports as many ROM versions are practical.

In practice, CDi ROM files can also be found on the Internet and many CDi Emulator users obtain them this way. These files are however still copyrighted, and their distribution is not legally allowed.

ROM detection

So how does any emulator deal with this bewildering variety of ROM versions? It will need to detect what hardware is expected by a particular ROM, assuming the emulator supports that hardware.

CD-i Emulator uses rule-based detection to determine the CD-i player type and the expected hardware based on the contents of the ROMs. The detection is driven by a rules file with conditions on the OS-9 modules contained in the ROMs. Doing it this way means that the detection is generally tolerant of ROM variations, which was important early on because it was unclear what kinds of ROMs were out there.

For an explanation and the current contents of the rules file used by CD-i Link and CD-i Emulator see the CD-i Types section of my website at

For a different approach, the MAME emulator uses detection based on hashes (checksums) of the ROM files, which means that it only works with specific ROMs (actually, MAME does not so much “detect” ROM versions as well as “verifies” them, its source code contains lists of ROM hashes that are accepted by specific emulation drivers).

Refining ROM detection

Some CD-i users have been collecting CD-i ROMs for many years now. It has become apparent that many more versions of CD-i system ROMs exist than initially expected. Therefore a better way of cataloguing ROMs instead of just by main player type is needed. Also, as more ROMs became available holes were uncovered in the detection rules used by CD-i Emulator. These holes usually resulted in mis-detecting the player version, although the emulation would often still work as the hardware variations were minor or non-existent.

In January of this year, I made an attempt to fix some mis-detection issues based on information supplied by rosewood of and I also tried refining the detection rules to differentiate between ROM versions. The latter quickly became unwieldy, but it turned out that there is a much better way.

ROM tags

The low-level tests of many players display ROM ID and ROM release information as well as ROM checksums, and newer player shells display some of this information in the copyright screen as well. Could this information be used for ROM detection?

Pointed in the right direction by rosewood, I found out that this “ROM tag” information is stored in a consistent, documented, way across all Philips and Philips-based CD-i ROMs which makes it easy to extract that information for detection purposes.

From the CD-i 220 phase 1 and CD-i 350/360 service manuals (these are both Mini-MMC players):

5.1.8 Release number, position and checksum storage 5.1.9 How is the checksum calculated?

Information for the Mono-I players can be found in the CD-i 210 phase 1 and CD-i 220 phase 2 service manuals:


      Note: The information about the last 1024 bytes
      is incorrect for Mono players!

This information was dropped from later service manuals, but it turns out to be valid (with suitable modifications) for all Philips and Philips-derived CD-i system ROMs, included the additional ROMs used in extension boards and digital video cartridges.

The ROM ID and ROM release bytes are stored in BCD (binary-coded-decimal) with an implied decimal point. Some low-level tests render these bytes directly (e.g., 12), others include the decimal point (e.g., 1.2).

So far, the only CD-i system ROMs found to not contain ROM tags are those from the Philips CD-i 180, Sony IVO and Kyocera Pro players.

Copyright screen

CD-i players with the 2nd Philips player shell display the ROM ID and release numbers in the copyright screen in the format


where AA is the system ROM ID and BB is the system ROM release. The other numbers are not important for ROM version detection but are interesting nonetheless, CC is the SERVO chip version (Mini-MMC, Mono-I, and Mono-II players) or the extension ROM release (CD-i 615 / 670 players) or 00 (other players), DD is the SLAVE/IKAT version, and EE is the player shell “ps” module edition.

Philips CD-i 210 F3 copyright screen for ROM 1.5

Some non-Philips CD-i player shells display some of this information in a different format, e.g., the Digital Video System DVE-100 player shell “vs” uses the format


where AA is again the system ROM ID and BB is the system ROM release. The CC and DD numbers are hardware related, and EE is the player shell “vs” module edition.

ROM tag complications

As described by the service manuals, the ROM tag information is always stored in the last four visible bytes of each CD-i ROM chip. But there are some complications not described in those manuals.

The Maxi-MMC CD-i players (CD-i 601) and the analog digital video boards (22ER9141) use two 8-bit wide ROM chips to provide the main CPU with 16-bit wide ROM data. In the case of such a ROM chip pair, each of these ROM chips contains its own ROM tag information. All such pairs encountered so far have the same ROM release byte with the ROM ID bytes differing by one (e.g., 10:11 or 20:21). In these cases, the CPU will see two interleaved ROM tags in the last eight visible bytes of the ROM space.


On the Mini-MMC and Maxi-MMC boards, the last 1024 bytes of the system ROM are not accessible by the CPU; the video registers of the VSC video chips are located there as described in the service manual. On these boards, the ROM tag is in the last four bytes just before the 511KB mark, and the rest of each ROM is considered empty (full of FF bytes) for checksum calculation purposes.

As only 511KB is available from within the CD-i player, the current CD-i Link program will “underdump” these ROMs (i.e., it will omit the last 1024 bytes).

ROM ID and release values

From the information gathered so far, it appears that Philips has assigned the ROM ID bytes in such a way that they almost exactly correspond to the player model / phase combinations. Within a single combination, there can be multiple ROM releases, but these are almost always of the form 1n (e.g. 1.n).

For digital video cartridges, the ROM ID bytes are always 10:11 (22ER9141) or 10 (22ER9956), and the ROM release bytes indicate the cartridge type as described in the Interactive Engineer 96/05 article Which DV cartridge is in a 605? that can be found here:

Detection using ROM tags

Over the last two months I have extended the rule-based CD-i detection logic used by both CD‑i Link and CD‑i Emulator to use the ROM tag information for player type and ROM version detection. There appears to be some logic to the ROM ID values but it is not exact, so the ID-based detection is still rule-based although the ROM version detection is totally automated.

To reflect the ID and release information, a new naming convention for CD-i ROMs has been defined, and together with rosewood I have been gathering information for a “ROM catalogue” (see the section Datfiles below).

As an example of the new detection rules, the following is now included in the rules file:

cdi220a??.rom: Philips CD-i 220 F1 system ROM ?.?
      {511K} #$26 ::cdi220a.rom

cdi220a.rom: Philips CD-i 220 F1 system ROM
      csd_220 minimmc.brd

The first rule says that any ROM with a ROM tag at 511KB that has a ROM ID byte with value hexadecimal 26 is a CD-i 220 F1 system ROM, with the specific version in the ROM release byte. The ::cdi220a.rom part means that the ROM must conform to the generic cdi220a.rom detection rule that is specified just below it, which uses the existing module-based detection syntax.

The conformation requirement ensures that both detection types remain in sync.

ROM file names

I have extended the previously somewhat ad-hoc ROM file names to include the ROM tag information.

Special logic included in the detection engine will replace the question marks in the ROM name cdi220a??.rom and its description above with the ROM release byte, so that a ROM with ROM ID 26 and ROM release 11 will be recognized as cdi220a11.rom with description “Philips CD-i 220 F1 system ROM 1.1”.

In addition to these “short names” a “full name” has also been defined that includes the ROM ID and ROM checksum in the filename. The above-mentioned CD-i 220 F1 ROM happens to have checksum E620, which means that its full name is cdi220a11-26-E620.rom.

For cases where two 8-bit ROM chips are used together, both interleaved ROM tags are added to the full name. E.g., the 22ER9141 F2 VMPEG digital video cartridge has ROM IDs 10 and 11; version 4.1 of this interleaved ROM has the full name vmpega41-10-11-FFD9-4BA9.rom.

Full ROM information also includes the CRC32, MD5 and SHA-1 hashes of the ROM contents (for a 511KB ROM file, the additional 1024 empty FF bytes are included in these hashes even though the actual ROM file does not have those bytes). These three values will now also be displayed by CD-i Link.

CD-i Type

A new CD-i Type command-line program has been created to manage collected ROM information. This program can be used to list ROM information just like CD-i Link does, but it can do so without the hassle of dumping the ROM.

Using CD-i Type, the example ROMs mentioned above would be listed as:

    File             Addr    Size    Type             Description

------------------ -------- ------ ------------------ ------------

cdi220a.rom        00000000   511K cdi220a11.rom      Philips CD-i 220 F1 system ROM 1.1

cdi220a.rom        00000000   511K cdi220a.mdl        Philips CD-i 220 F1 player

cdi220a.rom        00000000   511K minimmc.brd        Mini-MMC board

cdi220a.rom        00000000   511K cdi220a11.tag      {511K} ID: 26 Rel: 11 Sum: E620

cdi220a.rom        00000000   512K cdi220a11.crc      CRC: FC623645

cdi220a.rom        00000000   512K cdi220a11.md5      MD5: D669D26A9E7228DF18E84E380F6CA6AF

cdi220a.rom        00000000   512K cdi220a11.sha1     SHA1: 7DC5D62CE1686E45F2B68AA3943FE50BC47C71A7

------------------ -------- ------ ------------------ ------------

vmpega.rom         00000000   128K vmpega41.rom       Philips VMPEG digital video cartridge ROM 4.1

vmpega.rom         00000000   128K vmpeg.dvc          Philips VMPEG digital video cartridge

vmpega.rom         00000000   128K vmpega41.tag       {128K} ID: 10:11 Rel: 41 Sum: FFD9:4BA9

vmpega.rom         00000000   128K vmpega41.crc       CRC: 3685382E

vmpega.rom         00000000   128K vmpega41.md5       MD5: 9694C466F9B65C1990A81B7A6280546B

vmpega.rom         00000000   128K vmpega41.sha1      SHA1: 1D9C040B4FE974F5EB600C6F80797F40B45EFCF1

CD-i Type is also capable of taking this information from informational text files produced by the new CD-i Link as well as itself, so that it is not necessary to ship around ROM files to catalogue them.

The individual 8-bit ROM files from a ROM pair are not recognizable by OS-9 module rules because they contain only half of each module. Instead, CD-i Type uses the rules file to recognize them by their ROM tags and/or checksums.


Although CD-i digital video cartridges contain 128KB of ROM, the sockets containing the ROM chips appear to have an unused address line. This is probably the reason that the ROM contents appear duplicated in the CD-i player address space, causing “overdumping” by the current version of CD-i Link. The resulting ROM files are 256KB even though the actual ROM contents are only half that.

The new CD-i Link will avoid overdumping by detecting the duplication; as a bonus this will make the dump operation faster.

Fixing ROM dumps

There are some issues with existing CD-i Link ROM dumps (overdumping, underdumping) and there can also be issues when ROMs are dumped with a ROM dump device (pair splitting, byte swapping). The CD‑i Type program can “fix up” these issues when instructed to do so with the -fixuproms option (it will also rename ROM files in this case).

To correct overdumped digital video cartridge ROM files, the CD-i Type program discards the duplicate data.

To correct underdumped 511KB ROM files, the CD-i Type program adds the missing 1024 empty FF bytes.

To compensate for pair splitting, the CD-i Type program interleaves the separate ROM files into the proper interleaved file usable by CD-i emulators. For completeness, the reverse operation of splitting interleaved ROM files is also available with the -splitroms option.

Finally, to correct for byte swapping, the CD-i Type program swaps the bytes in ROM files if it detects them being swapped as indicated by a swapped ROM tag.

Untagged ROMs

Untagged ROM versions can still be identified by checksums although there are no ROM IDs or clearly discernible ROM release numbers. The actual ROM chips in fact often include that checksum on the ROM labels. For this reason, the full name for these ROMS includes the checksum, for example pro1000s-986D.rom for the Kyocera Pro-1000S CD-i player.

ROM picture
Kyocera Pro-1000S ROM


The final function of the CD-i Type program is cataloguing a set of ROM (information) files in the form of an XML “datfile” bundling all the information in a single file.

With the availability of such a “datfile” for CD-i ROMs it will become possible to use ROM managers such as ClrMamePro, RomCenter and RomVault to check CD-i ROM collections.

I worked with rosewood in figuring out the best way to format the CD-i ROM information into datfile entries for general use without losing information; the new “short name” and “long name” formats were tuned for this.

Typical resulting datfile entries for the above example ROMs would be:

       <game name="cdi220a11" board="Mini-MMC">
              <description>CD-i 220 F1 system ROM 1.1</description>
              <rom name="cdi220a11-26-E620.rom" size="524288"


       <game name="vmpega41" board="VMPEG">
              <description>VMPEG digital video cartridge ROM 4.1</description>
              <rom name="vmpega41-10-11-FFD9-4BA9.rom" size="131072"

With this input, the above ROM managers will put each ROM file inside a folder or archive using the short name while the ROM file inside will use the full name.

For example, the following ZIP files would be produced using maximum compression:

 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
  524288  Defl:X   230291  56% 2021/03/14 00:04 fc623645  cdi220a11-26-E620.rom
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
  131072  Defl:X    42344  68% 2021/03/14 00:04 3685382e  vmpega41-10-11-FFD9-4BA9.rom

Notice that the CRC-32 of each ROM file inside the ZIP archive matches the CRC-32 values listed above; this is by design as the exact same algorithm is used.

Given the above information, the ClrMamePro ROM manager is in some cases also capable of “fixing up” the issues with ROM dumps mentioned above. In an ideal world, it would not be necessary to use the command-line CD-i Type program for this but that is not currently the case.

To avoid confusion, both CD-i Type and CD-i Emulator will be extended to support this new folder/archive way of storing ROM files inside the rom folder.

Release timing

The new and updated CD-i programs will be released together with the new CD-i ROMs datfile cdiroms.dat; at that time, the CD-i Emulator Home website at will also be extended with a CD-i ROMs page that contains the collected information in browsable form.

The actual ROM files themselves are copyrighted and will not be available.

Dimo says hi

No comments:

Post a Comment