Announcing CD-i Emulator version 0.5.3-beta6 for Windows

A new beta release of CD-i Emulator is now available from the Downloads section of the CD-i Emulator website at https://www.cdiemu.org/downloads/.

Release notes can be found in the RELNOTES file; a summary is available from the Release Notes section at https://www.cdiemu.org/relnotes/.

This is the sixth beta release for version 0.5.3. It is hugely out of date with the current development version 0.6.0; the only reason for its release is to get a working version available again.

The only major change is that emulation speed throttling has been fixed for modern machines so games running at unplayable speeds should be a thing of the past.

Note to would-be crackers of this version (you know who you are):

I really would prefer it if you didn't. There is really no need!

As with all previous beta versions, using a Mono-I CD-i system ROM (also called BIOS) will give you unlimited emulation functionality; this is the same ROM file needed for the MESS/MAME CD-i driver.

This beta version also has the NVRAM save functionality enabled, and before the built-in beta date limit expires a new beta release for version 0.6.0 should be available.

To obtain unlimited emulation functionality with a different CD-i system ROM file, please buy the unlimited edition of version 0.5.2 which is still available at https://www.cdiemu.org/payments/.

Activating the unlimited edition on your machine will also unlock the unlimited emulation functionality of this beta version.

If you like my work and/or would like to support future development, you can also send me a donation. You can send PayPal payments to payment@cdiemu.org or use one of the following websites:

https://www.buymeacoffee.com/cdifan

https://ko-fi.com/cdifan

Have fun emulating your favorite CD-i titles!

CD-i ROMs

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

 

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 2^nd 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:

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.

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:

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

                   crc="FC623645"

                   md5="D669D26A9E7228DF18E84E380F6CA6AF"
                   sha1="7DC5D62CE1686E45F2B68AA3943FE50BC47C71A7"/>
       </game>

and

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

                   crc="3685382E"
                   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:

Archive:  cdi220a11.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
  524288  Defl:X   230291  56% 2021/03/14 00:04 fc623645  cdi220a11-26-E620.rom
 
Archive:  vmpega41.zip
 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 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.

Why is CD-i emulation hard, or isn't it?

Recently, it has been argued on Reddit, Twitter and elsewhere that CD-i emulation in MAME is difficult and why this is unlikely to improve in the foreseeable future.

The main reasons given (paraphrased) are that

a)       there are different hardware implementations of the CD-i platform, and

b)      applications do not directly interact with that hardware but are mediated by the BIOS, therefore

c)       hardware access patterns look identical across the entire library of applications.

The conclusion from this is that

d)      an emulator developer cannot “more clearly infer certain subtleties of the hardware functionality”.

Note: This article uses the term “BIOS” for what I have called “CD-i system ROM” in the past. The latter is more descriptive, but the former appears to be what many other emulators use.

Some parts of the CD-i hardware are custom chips for which not much or only very skimpy documentation is available, some reverse engineering is therefore required. But is it really hard?

One of the ways to reverse engineer hardware is to look at the software that uses it. There are various ways of doing that, the classic MAME way is to look at the access patterns and the code immediately surrounding that. If you have a sufficient variety of accessing code, you will ultimately develop a good (emulated) approximation of the original hardware, by a sometimes lengthy process of trial and error. If this is your goal, the fact that all accesses go through the BIOS can indeed be a problem.

But is having such a good approximation actually necessary to have a working emulator? If every application can directly access the hardware, as typical for most consoles, certainly. But this is not the case for CD-i!

The fact that all CD-i specific hardware access is through the BIOS is actually an opportunity when viewed in the right light. It is not necessary to develop a generic “good” approximation of the hardware, the only thing that is needed is an approximation “good enough” for the BIOS!

Now, this goes against the stated goals of the MAME project which is actually *not* to produce a working emulator but to document the hardware legacy. From mamedev.org, right at the top:

MAME’s purpose is to preserve decades of software history […] by documenting the hardware and how it functions. The source code to MAME serves as this documentation. The fact that the software is usable serves primarily to validate the accuracy of the documentation.

Seen in this light, so-called “high-level emulation” (emulating the visible effects of hardware instead of the actual inner workings) is akin to blasphemy: it goes against the entire philosophy of MAME.

My own goal in developing CD-i Emulator was never to “document the hardware”, though. It was to have a good enough emulation to actually play CD-i discs. For this, it is technically not even necessary to emulate *any* existing CD-i specific hardware, as CD-i is basically a software API standard. If you have a correct implementation of that standard you are done (there are of course some complications).

It is interesting to note that CD-Ice, the first ever (public) CD-i emulator, did exactly this. The author used his knowledge of the CD-i specification (Green Book) to implement the API from scratch using his source code for “Rise of the Robots” as a working sample. Although often treated as a single-game emulator, this is not in fact correct as his emulator ran many other games as well.

The Green Book states that CD-i players run the CD-RTOS operating system using an “68000-family processor”. This is therefore the minimum amount of *actual* hardware that needs emulation, and it’s exactly what CD-Ice did. All other parts were implemented based on the specification and not on actually existing hardware.

Going the full HLE route like CD-Ice did has its own problems of course, mostly because CD‑RTOS incorporates significant parts of the OS‑9/68000 operating system and a full emulator would therefore need to implement that as well. Some features such as multitasking and interrupts can be particularly hard to tackle with a full HLE strategy. Using full HLE also reintroduces the “many access patterns” issue but on a different level. Since you are emulating the (software) interface against which developers work directly, you can only get it “good enough” by throwing lots of applications against it.

For all these reasons, I chose a different approach for CD-i Emulator. Knowing that fully implementing CD-RTOS would be hard, I wanted to use the existing BIOS software. This meant that I would have to emulate some hardware, but only to the extent that the BIOS uses it. And I would not just stare at access patterns and the immediately surrounding (disassembled) BIOS code but take a more holistic approach as described below. Of course, it also meant that I would need to emulate all the hardware versions, which in retrospect has been more work than expected but not intrinsically hard.

All the CD-i specific hardware accesses done by the BIOS are located in OS-9 driver modules which together are less than 20% of a typical BIOS (counted by module size in bytes). And significantly more then half of that is the video driver, mostly taken up with drawing code that is totally uninteresting from the emulation point of view. All in all, only about 5% of the BIOS is concerned with accessing CD‑i hardware, which is about 25KB of 68000 machine language, i.e. less than 10 000 lines of machine code.

The interesting thing about these drivers is that their service interface is specified in the Green Book. Starting from this documented interface you can infer at a high level what the hardware is supposed to be doing as a consequence of all the device register accesses done by the BIOS. Actually figuring out the functions of the individual device bits does require disassembling the drivers and tracing their logic and dataflow but with a symbolic disassembler that is doable.

Most drivers are (much) less than 2KB of machine language, meaning that the path between the documented software interface and the to-be-emulated hardware is typically less than a few hundred or so lines of machine code. This is not hard to trace through.

The only driver size exceptions are the Video driver and the CD+Audio driver. The video driver totals about 65KB of machine code but as said above most of that drawing code not relevant for hardware emulation. Moreover, the video hardware is actually fully documented starting from the Mono-I hardware revision which uses the Motorola MCD212 VDSC chip. Earlier hardware revisions utilize two Philips SCC66470 VSC chips that are also documented and a back-end processor that is technically undocumented but whose functional aspects follow completely from the VSC documentation and the Green Book specifications. So the Video driver is not a major hurdle.

That leaves the CD+Audio driver, arguably the most complex driver of the entire CD-i system. The size of this driver module varies somewhat with the actual chipset used (about 18KB for CDIC, 26KB for DSP and 20KB for CIAP, in all cases excluding downloaded microcode). There is some uninteresting stuff such as EDC/ECC error correcting code in there but most of this driver is actually relevant to emulating the hardware. This driver is therefore the single biggest stumbling block to good CD-i emulation, and it shows in the kinds of bugs and issues that CD-i emulators have.

The fact that the CD+Audio hardware actually has three different versions (in Philips hardware alone, non-Philips players use yet another few versions) makes proper emulation of all player models more work but not much harder, it helps that the actual drivers are descended from each other. Once you have a good understanding of cdapdriv (CDIC), it is not that hard to understand dspdriv (DSP) or ciapdriv (CIAP): the major structure is the same, only the details of driving the hardware differ.

All of the above is predicated on understanding drivers, i.e. *software*, not *hardware*. It therefore goes somewhat against the grain for MAME which has traditionally followed a hardware-centric view. Also, a relatively deep understanding of the Green Book and parts of OS-9 is required.

Given those prerequisites I would not say that CD-i emulation is hard. It is a lot of work, sure; getting a good emulation requires deep study of a few thousand lines of 68000 assembly language. But very doable.

The approach used by CD-i Emulator as outlined above also explains why I am not interested in non‑HLE emulation of the various microcontrollers and DSP chips. It serves no purpose in playing CD-i discs: getting good HLE emulations of these chips so the BIOS can do its thing is enough. As a not insignificant side bonus to this, no chip decapping or other exotic hardware exercises are required for this approach.

CD-i update

Over the last few days I did some CD-i website updates.

On the CD-i Emulator website http://www.cdiemu.org I added lots of hardware pictures taken in August of last year. These include an extensive series about my (then) new 180/181/182 authoring player set and some overview pictures of the FW380i player and my E1/E2 emulator hardware. I have many more pictures of the internals of those emulators but these still need adding. I also added some more serial number information, especially from the DV cartridges. Some of the pictures of those appear to be mixed up a bit and will need sorting out.

I also started creating a Books section to list all my hardcopy documentation, as part of an effort to scan some of it to create digital versions where needed, but that is not yet online.

The end goal here is to get everything that could possibly be needed by a CD-i title developer online in a single place.  This effort started in July 2017 when I took over editorial maintenance of the ICDIA website at http://www.icdia.co.uk from Devin. We had decided that the CD-i Emulator site was not the right place to put general CD-i documentation and the ICDIA site seemed a much better fit.  And Devin was looking for a new ICDIA editor anyway, so...

As my first action on the ICDIA website I added the CD-i Full Functional Specification (Green Book). It had already been online for years but was not very easy to find.  Next followed some more Microware OS-9 documentation (in particular the Allen-Bradley set) that was also already online, and today many service manuals (repair instructions including board and circuit diagrams) were added.

A start has also been made with adding authoring documentation, but much more of that still needs to be added. My hard disk contains a number of raw scans from last year that still need to be processed and put online. In particular, this includes the CD-I System Libraries Technical Reference Manual that contains C bindings for all the CD-i specific CD-RTOS functions described in the Green book; this information is an absolute must to have for any serious developer.

Devin has been sitting on a complete set of CD-i Technical Notes for developers for a long time; this needs to be scanned and put online also (so far he has only done a very limited subset of it). These notes document many intricacies of the CD-i system and can be very insightful for title developers

It has now been a very long time since I put anything on this blog, but this does not mean that CD-i related software development has stopped. However, it has slowed down considerably. Below is a very short (and unordered) list of my CD-i development related activities in the 7 years since I last posted here; most of these I will probably expand on in the future.
 
- handling of CD-i Emulator beta time limit expiry
- emulation and deconstruction of The 7th Guest for the 20th anniversary edition
- leveraging CD-i Emulator code for a homebrew project
- investigation of possible Android and SDL ports of CD-i Emulator
- restructure of CD-i Emulator video decoding for flexibility and performance
- investigation of current status of Microware CD-i build tools
- investigation of existing OS-9 ports of the GNU C/C++ compiler
- investigation of restructuring CD-i Emulator MPEG decoding to fix buffering issues
- substantive efforts at ROMless emulation for CD-i Emulator (promising but not finished)
- reaching out in an attempt to collect more CD-i player ROMs

Regarding the last item, from the Philips consumer player line I’m still missing ROMs from the CDI 210/00, CDI 210/60, CDI 220/80, CDI 380/00 and CDI 740/20 players. If anybody has one of these players, please contact me.

I’m also interested in more exotic players like the Philips CDI 602, CDI 604, CDI 610, CDI 611 and of course a number of non-Philips players, in particular the Bang & Olufsen BeoCenter AV5. For some of these there are possible acquisition routes, but it requires bugging people about them and that can only be done some much.

Last year I also acquired a Kyocera Pro 1000S player that so far hasn’t given up its ROM contents (the player is incredibly densely packed internally, but there appears to be a serial extension port that could be usable), and I’m also still looking for the SONY IVO player ROMs. If nothing else works, it should be possible to play out the ROM contents of these players as audio.

There are also many future projects that I’m still interested in; a new one as of today is getting the built-in service tests of the Mini-MMC and Mono-I players working as documented in the service manuals. These tests need a special Service PCB connected to the serial port that has only three buttons (TEST, YES, NO) and an 8-position 7-segment LED display. Part of these tests is probably run by the SLAVE processor, but ROM contents for this processor have recently become available from the MESS dumping efforts so there appears to be a possible route. It would require implementing 6805 processor emulation but that shouldn’t be that hard, this is a relatively simple and well-documented 8-bit microprocessor.

Having made a promising start with ROMless emulation (in particular, mostly working C++ versions of the video and pointer device drivers and a good setup to start developing C++ versions of the kernel and remaining drivers and file managers), it appears worthwhile to pursue this path as well. It would  make the (apparently) holy grail of CD-i emulation a possibility (no need for copyrighted player ROM contents, just the disc images) and would open up a path to re-releasing CD-i titles on other platforms without ROM rights issues (several title rights-owners have contacted me about this in the last few years). If done right (which I’m trying), it would even allow a rebuild of the CD-RTOS software from the C++ versions by compiling them with an OS-9 C++ compiler (GNU C++ comes to mind). Of course, this would not be the “authentic” CD-i experience but it would allow playing of supported titles (eventually, this should be most of them).

It would also be interesting to make more progress towards an SDL port of CD-i Emulator. The main structural barrier to this has already been removed; the CD-i video emulation used to be hardcoded for producing 24-bit Windows-compatible RGB format. This has now been replaced by more generic pixel-format-parameterized pixel generation code that can efficiently produce any RGB format fitting in 32 bits, as required by SDL; in the process also achieving some decoding performance improvement (in particular, more optimized region processing). A faceless SDL emulation (no GUI) should now not be very hard anymore; at some point an SDL-based GUI or perhaps a native Android / iOS / MacOS GUI could then be added.

So there’s still lots of work to do…

JNMS and Maxi-MMC updates

This weekend I fixed some disc emulation issues for the JNMS and Maxi-MMC boards. I had previously erroneously identified these two boards but they are different.

The JNMS board is the one in the CDI 180 player (also called the JNMS player). It is not used in any other player and contains a CDIC (CD Interface Controller) chip but no SLAVE processor.

The Maxi-MMC board is the one in the CDI 601 and 602 players. From the emulation point of view it is virtually identical to the Mini-MMC board used by the CDI 605 player, but it has a different CDIC chip version. Both boards contain a SLAVE processor.

The link between the JNMS and Maxi-MMC boards is the CDIC chip: both turn out to have the same older CDIC chip version that differs in a few details from the version used on the Mini-MMC and Mono-I boards players (I described these differences in the earlier “CD-i 180 disc playing” post).

I noticed the JNMS / Maxi-MMC link from the CD-i player type table in the July 1996 issue of The Interactive Engineer (it’s on the ICDIA site); turns out I had misinterpreted the Board column on page 4 (there’s also an error there: the 601/602 certainly do not have the 180 board!).

After noticing this I did some testing and it turns out that the CDIC modifications needed for the 180 also work for the 601, including the TOC reading problem.

I have yet to find a way to get chip version information from the CDIC chip itself, so for the time being I’ve keyed the differences on the SLAVE software version. The 180 has no such chip, the 601 has version 1.x where the 605 has version 3.x. For now I’ve assumed that version 2.x also uses the older CDIC chip, but that may be wrong (the 602 or 604 might be interesting test cases).

Having done that, I did some more digging into the TOC read issue. It turns out that the 601 ROM performs CRC validation on the subcode Q data from the lead-in area (which is where the TOC is stored), and CD-i Emulator didn’t provide a valid CRC (no other ROMs I’ve seen so far validate this in software). The ROM even has compensation for shifts of between 1 and 7 bits in the incoming subcode Q data, probably because of some hardware timing issue.

I also noticed a bug in the ROM: it always uses the first sector buffer because it takes the current buffer bit from the wrong memory location. Not that this really matters because the TOC data is repeated multiple times; half of the repetitions will always land in the first buffer anyway. The bug is fixed in the 605 ROM.

Generating a valid CRC turned out to be straightforward (it’s just a simple CRC-CCITT calculation), but the ROM wouldn’t recognize it! After some head scratching I focused on the ROXL instruction (Rotate Left with Extend) used in the validation code. It is quite an esoteric instruction; could it be that there was an emulation bug here? It turns out that there was indeed; during rotation the contents of the X flag where put in the wrong bit. After fixing this the ROM properly recognized the data and the TOC reads became just as quick as other player models.

In search of version information for the CDIC chip I looked at the emulations and found one potential point of interest: the release number displayed by the service shell. This is a special GUI shell that performs some service functions; you can get to it by inserting a specially wired test plug into input port 1.

After some digging I found that the service shell obtains this number from the SLAVE processor, so it probably does not directly correspond to a CDIC version. The number does appear to differ from other version numbers, though, at least on my two 605 players.

The service shell obtains this number using two special I$SetStt calls into the CDIC driver; extending CD-i Link to remotely perform these same calls was easy. The new -cds[tatus] option can now be used to make the special calls. Here's some representative output of the -cds A3 option:

CD status A3000000 -> A3320000

Extending CD-i Link with remote OS9 calls is actually a fairly easy way to perform some information and tracing actions; I will probably use it for sorting out other dangling issues in the near future. When possible, this technique avoids the problems of writing a fullblown memory-resident trace module.

A new public beta release of CD-i Emulator that has full JNMS and Maxi-MMC support (among other things) is scheduled before the end of this year; there are still a few other issues that need sorting out first. This release should also have better support for the PCDI board used by several portable players, including the CD-i 370.

The major player holes still remaining are the Sony IVO-10/11 players, the Kyocera player, the Bang&Olufsen TV/player combi and of course the I2M board. There is some perspective for all of these but they are not high priority; except for the latter I expect all of them to be minor hardware variations of existing boards.

The I2M board has the interesting feature that it has multiple "ROMs" downloaded from the PC software (which is available for download from ICDIA); it also has a very different way of reading from CD as this is handled by the PC. As a consequence of this, audio is probably also handled differently. I have this board booting to a blue screen where it hangs on host communication.

SCSI support and a big surprise

Last week I added SCSI disk support for the CD-i 60x extension board to CD-i Emulator. It took somewhat longer then I expected, though. This was mostly because the DP5380 SCSI controller chip exposes most low-level details of the SCSI protocol to the driver which means that all of these details have to be emulated.

The emulation ended up to be a more-or-less complete software implementation of the parallel SCSI-2 protocol, including most of the low-level signaling on the BSY, SEL, ATN, MSG, C/D-, I/O-, REQ and ACK lines. This is all implemented by the new CScsiBus class representing the SCSI bus that connects up to 16 instances of the CScsiPort class that each represent a single SCSI-2 bus interface. I was able to mostly avoid per-byte signaling of REQ and ACK if the target device implementation supports block transfers, a big performance win.

The new CCdiScsiDevice class emulates the DP5380 controller chip, working in conjunction with the CCdiScsiRamDevice and CCdiScsiDmaDevice classes that emulate the 32 KB of local extension SRAM and the discrete DMA logic around it that are included on the CD-i 60x extension board.

The CD-i 182 extension uses a compatible SCSI controller chip but a different DMA controller and has no local extension SRAM. I have not yet emulated these because I have almost no software to test it. 

The new CScsiDevice class implements a generic SCSI device emulating minimal versions of the four SCSI commands that are mandatory for all SCSI device types: TEST UNIT READY, REQUEST SENSE, INQUIRY and SEND DIAGNOSTIC. It implements most of the boiler-plate of low-level SCSI signaling for target devices and the full command and status phases of SCSI command processing, allowing subclasses to focus on implementing the content aspects of the data transfer phase.

The CScsiFile class emulates a SCSI device backed by a file on the host PC; it includes facilities for managing the SCSI block size and the transfer of block-sized data to and from the backing file.

The CScsiDisk and CScsiTape classes emulate a SCSI disk and tape device, respectively, currently supporting a block size of 512 bytes only. Instances of these classes are connected to the SCSI bus by using the new
-s[csi]d[isk][0-7] FILE and -s[csi]t[ape][0-7] FILE options of CD-i Emulator.

The CD-i 60x extension board normally uses SCSI id 5; the built-in ROM device descriptors for SCSI disks use SCSI ids starting at zero (/h0 /h1 /h2) while the built-in device descriptor for a SCSI tape uses SCSI id 4 (/mt0). This means that the useful options with the 60x are -scsidisk0, -scsidisk1, -scsidisk2 and -scsitape 4.

I've added the new dsk subdirectory to contain disk images; tape images have no standard location as they are mostly intended for bulk-transfer purposes (see below).

Inside the CD-i player this leads to the following response to the built-in inquire command:

$ inquire -i=0
vendor identification:"CDIFAN  CDIEMU SCSIDISK "
 
$ inquire -i=4
vendor identification:"CDIFAN  CDIEMU SCSITAPE "

where the "CDIFAN " part is the vendor name and the "CDIEMU SCSIXXXX " part is the product name.

In the previous post I described a 450 MB OS-9 hard disk image that I found on the Internet. After mounting it with
-scsidisk0 mw.dsk I got the following output:

$ free /h0
"MediaWorkshop" created on: Feb 17, 1994
Capacity: 1015812 sectors (512-byte sectors, 32-sector clusters)
674144 free sectors, largest block 655552 sectors
345161728 of 520095744 bytes (329.17 of 496.00 Mb) free on media (66%)
335642624 bytes (320.09 Mb) in largest free block
 
$ dir -d /h0

Directory of /h0 23:49:36
ASU/            AUDIO/          CDI_BASECASE/   CINERGY/        CMDS/
COPY/           CURSORS/        DEFS/           DEMOS/          ENET/
ETC/            FDRAW/          FONTS/          FontExample/    ISP/
LIB/            MAUI/           MAUIDEMO/       MENU/           MWOS/
NFS/            README_CIN      README_MWS      SCRIPT/         SHARE/
SHIP/           SYS/            T2D_RUNTIME/    TEMP/           TEMPMARK/
TEST/           USR/            VIDEO/          abstract.txt    bibliographic.txt
bkgd.c8         bkgd.d          cdb             cdb1            cdb2
cdi_opt_install chris_test      cin             copyright.mws   copyright.txt
csd_605         custominits_cin delme           dos/            file
font8x8         get             globs.mod       go              go.mkfont
inetdb          ipstat          kick1a_f.c8     kick2a_f.c8     mtitle
mws             net             new_shell       new_shell.stb   scratch
screen          startup_cin     thelist         

You can see why thought it was a MediaWorkshop disc, but on closer inspection this turned out to something quite different. Some basic scrutiny lead to the hypothesis that this is probably a disk backup of someone from Microware working on early development of the DAVID (Digital Audio Video Interactive Decoder) platform. There are various surprises on the disk which I will describe below.

Anyway, I wanted to transfer the contents to the PC as a tar archive, similar to the procedure I used for my CD-i floppy collection. After starting CD-i Emulator with a -scsitape4 mw.tar option this was simply a matter of typing the following into the terminal window:

tar cb 1 /h0

This command runs the "tape archiver" program to create a tape with the contents of the /h0 directory, using a tape blocking size of 1 (necessary because my SCSI tape emulation doesn't yet support larger block sizes). The resulting mw.tar file on the PC is only 130 MB, not 450 MB which indicates that the disk is mostly empty. At some point I might use an OS-9 "undelete" program to find out if there are additional surprises.

Extracting the mw.tar file was now a simple matter of running the PC command

tar xvf mw.tar

This produced an exact copy of the OS-9 directory structure and files on the PC.

Many of the directories on the hard disk are clearly copies of various distribution media (e.g. CDI_BASECASE, CINERGY, CURSORS, ENET, FONTS, ISP, MWOS, NFS). The contents of the ENET, ISP and NFS directories at first appear to match some of my floppies, including version numbers, but on closer inspection the binaries are different. Running some of them produces "Illegal instruction" errors so I suspect that these are 68020 binaries.

The SHIP directory contains some prerelease RTNFM software; the readme talks about PES which is a type of MPEG-2 stream (Packetized Elementary Stream). Various asset directories contain versions of a "DAVID" logo.

The CMDS directory contains working versions of the Microware C compiler, identical to the ones I already had and also many other programs. It also contains some "cdb" files (configuration database?) that mention the 68340 processor.

The contents of the CMDS/BOOTOBJS directory produced a first surprise: it contains a subdirectory JNMS containing among others files named "rb1793" and "scsijnms". Could this be floppy and SCSI drivers for the CD-i 182 extension, as it contains with a 1793 floppy drive controller (the CD-i 60x uses a different one) and the player has a "JNMS" serial number?

Well, yes and no. Disassembly of the scsijnms file proved it to be compiled C code using an interface different from OS-9 2.4 drivers, so I suspect this is an OS-9 3.x driver. In any case, I cannot use it with the stock CD-i 180 player ROMs. Bummer...

And now for the big surprise: deeply hidden in a directory structure inside the innocently named COPY directory is the complete assembly source for the VMPEG video driver module "fmvdrv". At first glance it looked very familiar from my disassembly exercises on the identically-named Gate Array 2 MPEG driver module "fmvdrv", which is as expected because I had already noticed the large similarity between these two hardware generations.

The source calls the VMPEG hardware the "IC3" implementation, which matches CD-i digital video history as I know it. The Gate Array MPEG hardware would be "IC2" and the original prototype hardware would be "IC1". Furthermore, the sources contain three source files named fmvbugs1.a to fmvbugs3.a whose source file titles are "FMV first silicon bugs routines" to "FMV third silicon bugs routines". The supplied makefile currently uses only fmvbugs3.a as is to be expected for a VMPEG driver.

The fmvbugs1.a source contains some of the picture buffer manipulation logic that I've so far carefully avoided triggering because I couldn't understand it from my disassemblies, and this is now perfectly understandable: they are workarounds for hardware bugs!

As of two hours ago, I have verified that with a little tweaking and reconstruction of a single missing constants library file these sources produce the exact "fmvdrv" driver module contained in the vmpega.rom file directly obtained from my VMPEG cartridge.

In general these sources are very heavily commented, including numerous change management comments. They also include a full set of hardware register and bit names, although no comments directly describing the hardware. This should be of great help in finally getting the digital video emulation completely working.

All of the comments are English, although a few stray words and developer initials lead me to believe that the programmers were either Dutch or Belgian.

Disassembly comparisons lead me to the conclusion that careful undoing of numerous changes should result in exact sources for the GMPEGA2 driver module "fmvdrv" as well. I might even do it at some point, although this is not high priority for me.

The disk image containing all of these surprises is publicly available on the Internet since at least 2009, which is probably someone's mistake but one for which I'm very grateful at this point!

CD-i floppy inventory

Last weekend I future-proofed my CD-i floppy collection. A bit to my surprise, all floppies except one turned out to be perfectly readable (nearly twenty years after they were last written!). Luckily, the one exception was a backup copy so I didn’t lose any contents.

I had originally intended to use the borrowed CDI 182 unit for this (it has two floppy drives). The primary motivation for this was that my unstowed CDI 605 could not read beyond track zero of any floppy, but after giving the matter some thought I decided to try my other CDI 605 first, the primary motivation for this being speed (see below). It turned out that this 605 could read the floppies perfectly, including the three 38U0 format ones that gave problems on the 182 unit. Microware has defined a number of OS-9 disk formats for floppies, the 38U0 one supposedly being the “universal” 3.5" format (there is also a 58U0 “universal” 5¼" format).

The problem with the “universal” formats is that track zero can be (and on my floppies, is) in a different density which makes it a bad fit for most tools, both on CD-i and PC. It also means that only 79 tracks are used for data storage, giving a raw capacity of 79 × 2 × 16 × 256 = 632 KB. The 3803 format used by all my other CD-i floppies uses all 80 tracks and consequently has 8 KB more of raw storage for a total of 640 KB (these are both double-density, double-side formats (DS, DD) with 16 sectors of 256 bytes per track like nearly all OS-9 disk formats).

Before unstowing my other CDI 605 (it was nearly at the bottom of a 150 cm stowed equipment stack) I tried reading the floppies with my trusty old Windows 98 machine which still has floppy drives. I could not quickly find a DOS tool that handled the 256 byte sectors (not even raread and friends), although I suspect that Sydex’s TELEDISK product would have handled it just fine. I also tried Reischke’s OS9MAX which should handle all OS-9 formats under the sun according to its documentation. The demo version ran under MS-DOS and gave me working directory listings, even for the 38U0 floppies, but it does not support actually reading the files and I am somewhat doubtful about the current availability of the paid-for full version (even apart from cost concerns).

Why did I decide to use the 605? It was not a question of reading the disks (the 182 did this mostly fine) but of handling the data thus read. The 182 unit has a SCSI connector but I have no drivers for it (yet) and dumping my full floppy collection over the serial port did not really appeal to me for speed and reliability reasons (it could have been done, of course).

The 605 player has a SCSI connector and includes drivers for it so I could have just connected it to the SCSI disk in my E1 emulator and copied the floppies to hard disk (I would still have needed to transfer them to my laptop which would have been a two-step process via the Windows 98 PC as I have no SCSI connection on my laptop).

Instead I used the BNC network connector of the 605 to directly transfer floppy images to my laptop (it needs a network switch supporting both a BNC connector and the modern RJ45 connectors, but luckily I have two of those, even if they are only 10 Mbit/s). Starting up the network environment of the 605 took only two OS-9 commands at the command shell prompt:

ispmode /le0 addr=10.0.0.120
mbinstall

After this I could just ftp in to my laptop where I ran ftpdmin, a very minimal ftp server program, and transfer floppy disk images directly:

ftp 10.0.0.110
bin
put /d0@ floppy.dsk

(where /d0@ is the raw floppy device, for 38U0 I used /d0uv@, both are built-in for the 605).

The transfers ran at the maximum speed of the floppy drive (way below the 10 Mbit/s network speed), and the resulting .dsk files are perfectly readable using the –v option (virtual disk) of Carey Bloodworth’s os9.exe program even though that program was originally written for Tandy Color Computer OS9/6809 floppies (the floppy disk format was not changed for OS-9/68000 which is at the core of CD-i’s CD-RTOS operating system).

For easy access I also created a “tar” format archive of each floppy on a RAM disk:

chd /d0
tar cvf /r768/floppy.tar .

and ftp’d those to my laptop as well (the /r768 device is a 768 KB variation of the /r512 built-in 512 KB RAM disk device of the 605 player).

I ended up with the following collection of unique floppy disk images:

• 605h3 - 605 H3 Driver Update (1 floppy)
  
• 605upd - 605 Driver Update (1 floppy)
  
• bcase - Basecase Tests (1 floppy)
  
• eboot41 - Emulation Boot Diskette (1 floppy)
  
• eburn41 - Emulation and CDD 521 Boot Diskette (1 floppy)
  
• inet - CD-I Internet Installation Disk - V1.3 (1 floppy)
  
• nfs - OS-9/68000 Network File System V.1.0 (1 floppy)
  
• os9sys - OS-9 System Diskette (1 floppy)
  
• pubsoft - OptImage Public Domain Software (2 floppies)
  
• pvpak - OptImage Preview Pak Installation Disk (1 floppy)
  
• ubridge - OS-9 UniBridge Resident Utilities (3 floppies)
  

The 605* and eb* floppies are mostly interesting for CD-i 605 or E1 emulator owners, but the bcase floppy contains a set of CD-i standard conformance test programs that.

The inet and nfs floppies contain a full set of Internet software including Telnet and FTP servers and clients and an NFS client (all except the latter are also in the 605 ROMs).

The os9sys floppy contains a full set of Professional OS-9 programs and is my original source for most of the OS-9 CD-i disc that I described earlier (most of these are not in ROM on any CD-i player that I’ve seen so far).

The pubsoft floppies contain miscellanous utilities such as bfed, du, kermit, umacs and vi, most of which can be obtained elsewhere, some CD-i specific utilities such as da (CD-i disk analyzer) and iffinfo (CD-i IFF file dumper) as well as library source files for the CD-i IFF file library.

The pvpak floppy contains preview software for CD-i images that will preview CD-i IFF files from an NFS-mounted host file system directory.

The ubridge floppies are the goldmine (and also the 38U0 format ones) as they contain a full set of native Microware C compiler/assembler/linker/debugger software for OS-9 complete with CD-i header files and libraries and C runtime startup sources. Both the srcdbg and sysdbg debuggers are included as well as the rdump utility for dumping ROFF (Relocatable Object File Format) files.

Unfortunately, most of the above software except for the pubsoft contents is copyrighted property of Microware (now Radisys) or OptImage (a former Philips/Microware joint venture) which means that I cannot distribute it, even though they could be very useful to CD-i homebrew developers. For that the hopefully soon-to-be available GCC cross-port will have to be enough...

While investigating all of the above I also stumbled upon a 450 MB OS-9 hard disk image for MediaWorkshop. The os9.exe program recognizes it just enough to say that it does not support it so I have no real idea about its contents except the obvious.

To remedy that problem I’m in the process of adding SCSI disk support to CD-i emulator so that I can use the SCSI support in the CD-i 605 ROMs to mount the disk image and look at it. This should also allow the CD-i 180 to boot from a SCSI disk if I ever find drivers for it (a possible path to that has just appeared, we’ll see...).