Devin: Let's get straight to the point, why did you program a CD-i emulator?

CD-i Fan: The CD-i Emulator has always been and still is a hobby project for me. Why do you start a hobby project? Primarily because it seems like fun, of course!

When I first started programming the original 68070 processor emulator in december 2000 I didn't foresee the amount of work and consequently time the project would take. I worked on it for a few days, figured that it was gonna take quite a bit of work and dropped it for almost a year.

This pattern recurred a number of times; when the work became tedious or boring I just dropped it for a few weeks or months. So in the end it really wasn't as much fun as I had thought at first. I always came back to the project, I guess mostly because of being stubborn: I've started this thing and I will (expletive) finish it! Most of the real fun is from very recent, since I only got my first CD-i title to play somewhere around Christmas 2004. After that I have pretty much worked on it steadily.

A secondary reason was my great love for the CD-i platform, and the consequent desire to see it live on beyond the lifetime of the CD-i discs and players. So far, most CD-i hardware has held up admirably, but at some point it's gonna fail, and what would happen to all those CD-i discs then? An emulator is a beautiful solution to the problem and also really the only worthy one. Hardware dies; software lives forever (through emulation)!

Of course, there was also the purely selfish reason of wanting to preserve for myself a few CD-i titles I loved, especially the ones whose production I have been involved with.

And lastly, a very important reason: It would be sooo cool :)

Devin: So this emulators been in the making for almost 5 years! Why do you think emulators are such a rarity for this system with the only other serious attempt made by the developer for the CD-i version of Rise of the Robots in Compact Disc interactive computer emulator (CD-ice).

CD-i Fan: I think there are several factors that combine to make CD-i emulators rare.

First, the low-level technical details of the system are not well-known. The software interface to which all CD-i titles are programmed is described in the so-called Green Book, which can only be obtained under non-disclosure. Many hardware details aren't available outside the player factories, although there is some publicly available information in this area.

The information scarcity means that only people already intimately familiar with the CD-i system can have a serious go at an emulator, which enormously shrinks the available talent pool. It's significant that the two people achieving serious progress are both former CD-i developers.

Second, a CD-i player is reasonably complex. It contains sophisticated (for its time anyway) audio and video decoding hardware and has its own custom operating system. Many parts interact to form a working CD-i player. This means that there is an enormous amount of development to be done before you actually get something working; it is easy to get discouraged in the process.

Finally, I think people have been going at it the wrong way. It seems that all past attempts have focused on building a completely "virtual" CD-i player, basically by emulating at the Green Book interface level. My approach is different and, I believe, easier to get right.

Devin: Evidently this project has a deeper value to you than just another program. Can you tell us which CD-i titles you'd specifically like to preserve and which ones did you work on.

CD-i Fan: There are quite a few games unique to the CD-i platform, and also a score of interesting non-game titles. The nice part of an emulator is that you don't have to choose, if done properly all CD-i titles will be preserved. So it's really just a matter of personal preference here that I won't go into any further.

I worked on many CD-i titles; its hard to make a full list. These include several game titles, where I didn't do the actual game programming but provided technical and platform support for things like sound mixing, memory usage and system interface. But most of my experience is with non-game titles, often professional titles that were never available on the consumer market.

I always found the CD-i platform interesting and challenging to develop for; you have to remember that this was mostly before the advent of the multimedia PC and CD-ROM. In the later years our company did a few combined CD-i / CD-ROM titles, at first just "porting" the CD-i version to the PC and later developing the versions simultaneously. Both platforms had their advantages and disadvantages, but in general I feel that CD-i came out better. That is, luckily, no longer the case.

Devin: The emulator requires the use of the CD-i players internal software often referred to as BIOS which needs to be uploaded into your program, doesn't this make it awkward for anyone wishing to trial CD-i software through emulation and oppose the purpose of emulation in the first place? Wouldn't it be far easier to follow the route of CD-ice and release a version that doesn't require a BIOS ROM to work.

CD-i Fan: It would be easier for users, of course, and in a sense more "elegant". It would certainly not be easier for me or any other emulator developer!

There's between 300KB and 500KB of software in most CD-i players making up the CD-RTOS operating system and its drivers. Most of it is written in assembly language and thus very compact. It would need to be essentially rewritten for a ROM-less emulator and thus introduce a quite significant amount of extra work, in addition to all the work of emulating the CD-i player hardware that would still mostly need to be done.

There are also compatibility and reliability issues. The software interface available to a CD-i title is large; most titles use only a small part of it, each in its own way. Debugging a CD-RTOS rewrite would thus be very costly and frustrating, each new title would probably expose new bugs.

The hardware interface of each player is considerably simpler, and it is not directly exposed to the CD-i title but used only via the ROM software drivers. The amount of machine language actually accessing the hardware is less then 50KB in each player and most drivers are very small programs implementing a documented interface. They are all written in assembly language which makes them easier to dissect and analyze for debugging purposes than most CD-i titles who are typically written in a high level language.

The number of ROM versions is also much smaller then the number of CD-i titles and they are often derived from each other. So its really just a trade here. By analysing and testing the ROMs once, the total amount of work and frustration in development is much less then would otherwise be required.

And finally, using the ROMs guarantees the "real" CD-i experience. The software running inside your emulator is *completely* identical to what runs inside your player. As a fan of the platform, I find this very appealing.

Having said all that, there has of course already been talk of a ROM-less emulator. It's certainly possible, and having a working hardware-based emulator will actually allow this to go forward more easily. When done carefully, the software-based emulator can be developed and tested incrementally, because the hardware-based emulation is still available as a fallback and test reference. But don't hold your breath!

Devin: What do you envision for the future of your emulator?

CD-i Fan: As of yet, I'm still very much working in the present. There are still a number of compatibility problems with several player model ROMs, and Digital Video capability still needs to be added. There's also quite a bit of non-essential but nice-to-have functionality on my to-do list, such as playing directly from the CD drive and the ability to use full emulator state snapshots. And there are a number of features that would be useful for CD-i title development.

In the longer term, I want to at least have a go at the ROM-less emulator concept. With all of the hard work and reverse engineering already done, this should be a relatively easy but probably long-running project.

Devin: Surely CD-i players would be made to much the same standard otherwise the software wouldn't operate between models. What sort of compatibility issues have you discovered with the various player ROMS any interesting details about these ROMS for the technical boffins?

CD-i Fan: The CD-i standard as contained in the Green Book is mostly a software interface specification. The data formats specified for programs, audio and video (base-case video as well as MPEG video) need hardware support but the exact functionality of CD-i hardware is not specified in any great detail.

It has actually surprised me how similar the various players are at the hardware level. There are several chipsets for each function, but they differ mostly in the details of registers and commands. And most ROMs appear to be from a single line of development. Not that reverse-engineering new hardware isn't challenging...

I did find quite a few test and diagnostic "hooks" in the players; all of the interesting ones can now be triggered by emulator options. The discovery of low-level hardware tests was particularly helpful.

I would also like to compliment the programmers of the original system software. From the software point-of-view, running inside an incomplete emulator is very much like running on very creatively defective hardware. I have seldomly seen the system drivers crash, particularly on the older players. If the hardware doesn't respond as expected, this will usually result in timeout errors, although I have also seen a few "hangs". I have seen very few outright crashes.

Devin: As mentioned earlier it's quite an involving process of uploading CD-i player ROMS for the emulator to become functional. You've provided a seperate program to support the ease of retrival for player ROMS through CD-i Link and the Stub CD. Can you elaborate on the development of these programs and will they be updated alongside the emulator for support of more players?

CD-i Fan: The CD-i Link and CD-i Stub program were developed completely from scratch in the first months of 2005, when it became obvious that something like them would be needed. The programs use an extended version of the download protocol that exists in the ROMs of almost all Philips CD-i players and is documented in the technical information for the CD-i 605 development player. As implemented in the ROMs, the protocol can only be used to download information into the player, not the other way around. So a small program that implements the extended version has to be downloaded before any uploading from the player can be done. I chose to call it a "stub" because it resembles the "remote debugging stubs" often used for cross-machine debugging.

There are several versions of the stub program, using different ways to access the serial port. The most generic one is actually a completely standard CD-i application, which could therefore easily be put on a CD-i disc. This allows CD-i Link to be used even with players that don't have the download protocol in ROM, because the stub program can be started from the disc instead of being downloaded.

I chose to release the stub program sources because they are useful examples of (very small) CD-i applications. This has actually helped some people.

Some of the more exotic CD-i players appear to have problems with the current stub program. I plan to extend the CD-i Stub program with a small GUI so that basic information can be read from the screen and the serial port can be chosen by hand, in case the player doesn't properly report it to CD-i applications as specified by the Green Book.

To keep the stub program small, most of the "advanced" functions are implemented inside CD-i Link, using the "remote system call" function implemented by the stub. The possibilities are endless; the currently implemented functions already go way beyond what was actually needed for the uploading the ROMs but it was hard to stop :)

There are some plans to extend CD-i Link to a full remote debugger, but that is a while away and there is no great need. The present version already works with any stub program speaking the proper protocol.

There will be an extension to CD-i Link for driving the front-panel display of the CD-i player; this is actually needed to find out its exact workings so that it can be properly emulated.

If we ever come across a player not supporting some form of serial port, we may have to resort to playing the ROM contents over the sound output of the CD-i player, much like a modem. It's certainly possible but there does not appear to be a need at present.

Regarding player model dependencies, there are none in either the CD-i Link or CD-i Stub programs per se. Recognition of player models is done with a "rules" file that can be updated separately. The CD-i Link program does contain a version of the rules file and the stub program inside the executable, but command-line options can be used to use external files for both.

CD-i Fan was interviewed by Devin

For more information and to purchase this superb program visit the official CD-i Emulator Website.