A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

@TheMogMiner recently made a very informative post about why CD-i emulation is so difficult and why it's unlikely to improve anytime soon. @Interact_Dreams summed it up nicely here, I recommend anyone who asks about the subject to give it a read. https://cdii.blogspot.com/2021/03/the-developer-behind-mame-cd-i.html …

I think I don't fully understand this post. I thought everything going through a system library with a well defined spec but flexible implementation made things much EASIER to emulate, just by substituting your own library implementation?

That's not how emulation works.

Emulation doesn't work by "substituting [a] library implementation". Quite the opposite, it's 100% agnostic to the software itself. A well-made emulator reproduces the functionality of the underlying *hardware* as accurately as possible, with no consideration of the software.

As I explained in the earlier Twitter thread, when software bangs on the hardware directly, it makes it somewhat easier to tease out the nuances of the hardware's functions, as each developer tended to be subtly different in terms of their code.

Hmm. My impression was that Nintendo's N64 emulator does exactly that, hooking into and replacing system library calls with native code for the emulating platform. For a system like CDi where the hardware is *intentionally* unspecified, it seems potentially fruitful?

You're thinking of high-level emulation (HLE), which was pioneered in the late 90's with the N64 emulator, UltraHLE. Nintendo went that route for Virtual Console primarily for speed reasons, not due to a lack of hardware documentation on their part.