One additional: Clock Signal

Well that's even more excellent information. Plucking at random, I am definitely not reverting to the final processed sprite after the fifth sprite bit is cleared. So further work will be required.

Sadly not at the minute; it's 100% speed only. There is a vague technical reason for this related to the way that audio is processed but it doesn't amount to much more than that I simply haven't made the effort yet. On the plus side, it will be necessary to support a variable running rate to fit in with my plan to allow mild time warping for sync matching with machines that don't quite output at exactly the same rate as your machine. So it can turn up one day.

Otherwise, I haven't really been posting here because improvements have been overwhelmingly incremental but since I last announced a release:

• a bug in TSX parsing has been corrected such that the contents of http://tsx.eslamejor.com/ now overwhelmingly work;
• Mac users can see drive activity status indicators if your MSX has a disk drive;
• Mac users can also just launch an MSX without having to provide a piece of media to load; and
• various slightly-obscure AY input/output errors have been fixed.

Releases are always available in the usual place.

Already committed to the repository for the next release:

• a bug fix for sprite drawing in which 8x8 sprites could end up with an extra 8px of nonsense to their right; and
• joystick support — with the SDL version you can use a real physical joystick, but in Mac world it's currently only via the keyboard.

One or more of those SDL/Mac feature disparities may also be corrected. I'll see how things go. The SDL port will get drive activity indicators because that's already written even though not yet merged, but whether in the near future it also gains the ability to launch a machine without media and whether I implement physical joystick support for the Mac I haven't yet decided.

Re: the AY, the specific issues were incorrect handling of the probably-never-happens scenario of a programmer setting one of the ports as output despite it being wired for input and then reading from it as though it were input, and similarly attempting to read from the main data bus while the AY is configured to expect a write or not to expect anything. It's hard to imagine either being much of a problem with real software with the way the MSX is connected, so I don't think the fix will noticeably affect anything.

Hopefully that's more about the CPC than the MSX; on the MSX the rule is that, if the user has opted in, calls to TAPIN and TAPION are accelerated. So in effect, anything that uses the BIOS to load should load nearly instantly. Which means all CASs in their entirety, and anywhere between none and all of TSXs and CSWs (wholly dependent on the actual data on the tape, completely independent of encoding).

The CPC is the only supported platform without any sort of analogue of that, which is something I should fix. I think the CPC uses a Spectrum-compatible tape encoding (?), which is what a large number of TSXs use when not calling into the BIOS, so actually it'd potentially be a multiplatform benefit. I'd just need to figure out the half that recognises what the MSX code is trying to do; I'm hoping there'll be a fairly easy way to fingerprint these things, as probably it's just a bunch of repurposings of the same routines, but have yet to verify that hope in any capacity.

Minor follow-up; a new release is now out with:

• a fix for a TMS sprite bug whereby some games could end up with 8 pixels of garbage next to an 8px-wide sprite; and
• joystick support. On the SDL build that means real, physical joysticks will be visible as connected joysticks within the emulated MSX. On the macOS version is means that and there's also an optional keyboard-as-joystick mode.

Here as always.

It’d be nice to see MSX2(+) support if you ask me .

I like how you take a different approach from other emulators. Plus openMSX can use some competition .