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.
 |
| Philips CD-i 210 F3 ROM 1.1 |
 |
| Philips CD-i 210 F3 ROM 1.5 |
 |
| 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.
 |
| 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 CD‑i Emulator is that a user
dumps the ROMs from his own CD‑i player using CD‑i Link and then proceeds to
use these ROM files with the emulator. For this reason, it is important that
CD‑i Emulator supports as many ROM versions are practical.
In practice, CD‑i ROM files can also be found on the
Internet and many CD‑i 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 www.cdiemu.org.
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 retrostuff.org 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):
Note: The information about the last 1024 bytes
is incorrect for Mono players!
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
1AA5BB-2CC4DD-3EE
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
1AA2BB-3CC4DD-5EE
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.
Underdumping
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: http://www.icdia.co.uk/iengineer/.
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:
{511K} #$26 ::cdi220a.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
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.
Overdumping
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.
 |
| Kyocera Pro-1000S ROM |
Datfiles
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:
<description>CD-i 220 F1 system ROM 1.1</description>
<manufacturer>Philips</manufacturer>
<rom name="cdi220a11-26-E620.rom" size="524288"
sha1="7DC5D62CE1686E45F2B68AA3943FE50BC47C71A7"/>
</game>
and
<description>VMPEG digital video cartridge ROM 4.1</description>
<manufacturer>Philips</manufacturer>
<rom name="vmpega41-10-11-FFD9-4BA9.rom" size="131072"
md5="9694C466F9B65C1990A81B7A6280546B"
sha1="1D9C040B4FE974F5EB600C6F80797F40B45EFCF1"/>
</game>
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.
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 http://www.cdiemu.org 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.
