A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

@TheMogMiner I read what you wrote about CD-i emulation and the difficulties faced; but my eye as drawn to you mentioning no dump for certain variants, etc. Are you sourcing them/trying to get them decapped or can the DU/me chip in cash or something?

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

Replying to my own post, and in the hopes that @Interact_Dreams sees - the CD-i platform 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.

Some players are straightforward enough: A Philips SCC68070 (68k-derivative SoC), a Motorola DSP56k for audio, a Motorola 68HC05 for I/O, and another for CD servo control. Some have the latter three components all rolled into one ASIC (IKAT).

Others have a middle ground, with I/O handled by a 68HC05, and CD control and audio rolled into another ASIC called CDIC. That's the model that MAME currently emulates, for better or for worse.

With platforms like the NES, SNES, Megadrive and even later platforms, each game accesses the hardware in a different way, leading to more insight as to how the hardware works. When everything has to route through a system BIOS, you don't get that breadth of info.