Home Page Forums MAME MAME CD-i WIP

Oh, that's a shame.

Has anybody ripped one of these open?

Slave I'm guessing is some kind of CPU? or MCU? Is it known what it is? Does it upload any code for it at any point?

That commercial emulator is shocking, charging a premium rate for something with less than 10% compatibility and no proper inputs? There are probably GAME_NOT_WORKING drivers in MAME/MESS that work better than that....

From previous conversations with Kale it sounds like the system is just That weird 68k variant, a framebuffer, a blitter / DMA device, an mpeg decoder, and a CD unit...

From the pictures we've seen the SLAVE is a Motorola part with probably internal ROM (68CH11 perhaps?). Unfortunately none of them are clear enough to read the numbers, just the part where it's stamped "SLAVE".

Yeah, but at the same time it's a lot better than what I've managed to do so far. I'd say the real shocking CD-i "emulator" is the one that only runs one game and does it entirely using HLE. I forget its name, though.


There are multiple CD-i revisions, all of which are pretty dissimilar, and will require a whole lot of work on a per-machine basis to emulate in MESS. I'm currently emulating the Mono Imodel (Philips 220 F2), which is arguably the simplest out of all of them. There is no MPEG decoder in the original base machines, just an external cartridge that is used by some (but not all) games, hence skirting around the MPEG patent issue for now.

The Mono I model that I'm emulating consists of an SCC68070-based processor, SLAVE (probably an MCU) + CDIC (both working together for CD tasks), some model of off-the-shelf RTC (I forget which, but it's documented in the driver), and an MCD212 video chip.

Later CD-i revisions include (shamelessly ripped off of the cdi-emu site):
- Mono-II: replaces CDIC with DSP (probably DSP56k) for audio
- Mono-III: replaces DSP with CIAP for audio and SLAVE with IKAT (known to be an M68HC05 with internal ROM)
- Portable: replaces CIAP and IKAT with CDAP and RCHIP

So, yeah, a whole crapton of work is going to be necessary to get all of this stuff working. No wonder it took CD-i Emu's author 2 years to get where he is.

ETA: Anyone want to buy me this? http://cgi.ebay.com/Philips-CDI-CD-...=item2c50fc7251&_trksid=p3286.c0.m14

As the author of that "commercial" emulator I can safely say that everybody except Just Desserts seems to very badly underestimate the complexity of the CD-i hardware.

You might want to consider that so far MESS only partially emulates two documented chips from the system; for full function of a single ROM at least two complex undocumented ones remain (CDIC and SLAVE). I'd estimate the MESS CD-i emulation is at most a few percent complete relative to CD-i Emulator.

However, I sure welcome the effort, as opposed to all the whining for several years but nobody ever getting any code written.

I have already been contacted and asked for assistance and I'm willing to give some; the details will need to be worked out.

Kudos to Just Desserts for the hard work so far!

I was the guy who contacted you, well, one of the two - the one who wasn't Mark Kloffy (I'm not sure who that is).

I greatly appreciate the fact that you're willing to help out, I'm quickly realizing what an undocumented system - systems! - the CD-i series are.

I definitely agree at the relative level of incompleteness of the MESS driver, so far the Mono I board is the only one I've even attempted to emulate, who knows how hard things like CIAP and IKAT are.

Good work on CD-i Emu, and I look forward to working with you!

Might be one of those chips which is worth ripping off an adding to that never ending list of chips for more scientific investigation then?

From what's been said it sounds like proper emulation of that chip as opposed to simulation would probably go someway to providing a much improved level of compatibility.

At least it sounds like progress is being made, my only real experience with it is in helping Kale with that Magic Card thing on the MAME side, but I doubt that touches a fraction of the features of the real unit. (it's a crappy gambling game afterall)

That, unfortunately, isn't true and also a whole lot more work then necessary. It would push the emulation boundary out to another new set of undocumented hardware :-(

The SLAVE/IKAT interfaces are pretty simple and mostly deal with basic control of the CD drive (seek, start, stop, etc) and full control of pointing devices (except backside port), front display and buttons, and a small bit of machine control (reset). The difficult part is that these interface are referenced from many different drivers (one for each device type accessible via the SLAVE/IKAT), but it's not inherently hard to emulate, just a lot of work.

The main source of incompatibilities is, in my view, in the register and timing details of the CD+AUDIO controller chips. These chips are undocumented and reverse engineering of drivers only goes so far. I have in a few cases made instrumented drivers to run on the the real hardware and provide me with actual chip register access traces, but this is hard to do, the trace buffers are finite and you quickly drown in the data except for very simple test cases (which running a game with compat probs certainly is NOT).

You can use it to figure out parts of the address map... Another way to do part of this is the OS9 "devs" command which lists IRQs and memory locations (or something like that, it's been a long time).

That was CD-ice.

Most of the work is per-chipset but I'm sure you know this; the various boards are often reused in several player models.

All the revisions are actually pretty much identical from a CD-i software point of view (save for bugs of course), but since we're emulating hardware...

That depends entirely on where you start counting; as much as 5 years is defendable. But you have to keep in mind that this is hobby work done in spare evenings. If I had a full-time go at it, I could probably have done it in a few months. Then again, I've got a lot of experience with the system as I've done a lot of programming on it, and a full set of developer documentation and software (Green Book, TechNotes, C compiler, etc).

Seems like a nice machine, but I think this is not a mono player. The 220 players exist in five different versions (mini-mmc and mono-I to IV), but all mono versions have 32KB of NVRAM (see the player comparison chart on the ICDIA site) and this one is listed as using an M48T08 chip which is the 8KB NVRAM version. The size difference is hard-coded in the ROMs so this means that it has to be a mini-mmc.