A Moogle  🏳️‍🌈 💻 🎮 🎶 🇸🇪

wish I were brain normal enough to work on something for a sustained period of time and be cool and finish it me: I want to work on MAME Driver X you know how much I like reverse engineering hardware also me: hmm, I don’t own an X to compare it to and X costs $5,000 on eBay

Wait doesn’t MAME’s Atari ST emulation still not work, like at all @TheMogMiner I have many STs and much 68000 knowledge don’t I

The main sticking point with ST emulation, as far as I know, is a lack of a cycle-interruptible 68k core, which is something @o_galibert has been working on, albeit glacially.

That said, to my knowledge, cracked games generally work fine-ish.

That also said, that mid-instruction-interruptible 68k core is going to be necessary for emulating the DTACK line. More broadly, that includes some 68k-based Macs and all of the CD-i players that used an MCU dubbed 'SLAVE' (Philips's term, not mine) for I/O.

I'm confused. Holding DTACK/ unasserted (high) doesn't interrupt the program, it just prevents the memory cycle from completing until DTACK/ is asserted (low). It's like WAIT on other processors. Why would you need an instruction-interruptible core to emulate that?

You're confusing interrupting the guest program with interrupting the host program. For most CPU cores in MAME, as with most emulators, the emulation of an instruction runs to completion before there can be any further outside influence on the emulated CPU's state.

The memory fetch occurs, and that's it. There's no facility for saying, "Whoa, wait, break out of the current timeslice for which the emulated CPU is running, and service the other running devices for now instead" while the memory-read instruction is still in-flight.