A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

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.

It's not quite as simple as just dropping in a new library, and away you go. The N64 had a vector coprocessor (the RSP) which handled the calculation side of both the graphics and audio stack. HLE-ing the N64 still required reverse-engineering the routines uploaded to the RSP.

Overall, there were roughly 20-40 unique sets of microcode routines. Some were used by only one or two games, some were used by a fairly large chunk. So it's not entirely the same situation with the CD-i.