The developer behind MAME CD-i Emulation talks about why emulating CD-i in MAME is so difficult (and why this won't improve in the foreseeable future)

The long answer is that the Philips CD-i platform is fiendishly difficult to emulate on two entirely different fronts.

For one thing, CD-i was never just a single hardware configuration. While consoles like the NES, SNES, and Megadrive did have various hardware revisions, those revisions tended to affect a relatively narrow amount of the consoles' functionality. The CD-i was, to a large extent, the predecessor to much later generations of consoles in that it was defined by a baseline hardware specification, which licensors could implement however they wanted. In order for games to be licensed for publishing, the games were required to interface only to a defined set of library functions. Any direct access to the underlying hardware was forbidden.

What this means is that in practice, the main CPU and graphics hardware tended to have relatively little variation (apart from the latter in very early generations), the input handling, audio hardware, and CD access hardware varies wildly from system to system. In some cases, the low-level drive management is handled by a Motorola 68HC05 microcontroller, as well as inputs having their own 68HC05, and audio is handled by a Motorola DSP56001. In other cases, CD management and audio are combined into a custom ASIC called CDIC. In still others, all three tasks are handled by yet another custom ASIC called IKAT. The BIOS for a given system implementation arbitrates between the game running on the platform and the underlying hardware for that specific system implementation.

MAME currently lacks a DSP56001 core, so CD-i players of that generation are off the table. I've never found dumps for the later IKAT-based generations, so those are equally unviable.

The only model that's emulated well enough to even boot games is the one using the CDIC ASIC, but as you can see, the emulation of the CDIC is not entirely great, and in the process of trying to rework it, I ended up making it worse. While some games run better than they ever did before, other games suffered.

This brings me to the other issue, which is the whole fact that the hardware access patterns are identical across all games, by virtue of the fact that they all have to access the hardware through the same BIOS routines. For 16-bit and many 32/64-bit consoles, different developers accessed the hardware in subtly (and at times, not-so-subtly) different ways. It was almost like a developer fingerprint, in a sense. By throwing a wide variety of games at an emulator, one can see a wide variety of access patterns, which allows an emulator developer to more clearly infer certain subtleties of the hardware functionality. All of that goes out the window when the hardware access patterns look identical across the entire library of games.

The problem here, too, is that at 512 kilobytes, the system BIOS is enormous. While, granted, not all of that is code, quite a lot of it is. It amounts to a more or less complete OS9/68k operating environment. As such, there's an equally enormous amount of code to sift through. Even worse, on the model of CD-i player that MAME does emulate enough to boot games, the CD library in the BIOS will tend to throw a fit if it sees the CDIC registers in a state that it's not expecting - but it's not always immediately obvious what it is expecting, nor is it always the result of the most recent command that causes it to blow up.

Ultimately, I have a long-term project to try to reverse as much of the CD library routines into human-readable C code as possible, but it's slow and grind-y work. It requires sitting and poring over MAME's disassembly window for hours, with very little immediate payoff. I'll eventually get it done - eventually - but I can't give any sort of practical timeline. So, for now, I would suggest going with CD-i Emu."

CD-i member Simzy: "CD-i emulation is facing quite some difficulties. One of the things is the need to implement all player variants. Are you sourcing them/trying to get them decapped or can the DU/me chip in cash or something to speed things up?" 

In theory, the majority of players have been dumped. I'd assume so since CD-i Emu has support for them. However, the CD-i scene has as much a problem with hoarding as the Japanese arcade scene does. I'm not actively buying un-MAMEd players to dump, but you can if you want. The CD-i platform is rather interesting, and has unique hurdles to emulating it. Dumping the systems involved and ensuring good community coverage is only part of it, but it's a good start. 
One of the most interesting things to me is that the CD-i platform was more akin to platforms from around 2005 onward than its late-80's contemporaries. It was the first console that demanded developers interface with just the system libraries, and avoid direct hardware access. It's worth mentioning that this presents multiple issues for emulating the CD-i: It's not a matter of emulating a single platform, it's a matter of emulating a specific implementation of the player spec. 

And that, really, is the problem with emulating the Philips CD-i: You can't derive any knowledge about the underlying hardware by throwing different games at it. You either make the BIOS happy, or you don't.

[Thanks, A Moogle (TheMogMiner)]