One additional: Clock Signal

No, I've almost certainly made an error.

For file associations, Apple has tried to do some of what the Classic OS did (i.e. type determined by type metadata contained in the resource fork) while mostly doing what everybody else does (i.e. type determined by file extension). There's a major advantage to that in that you can still associate files to applications on a per-file basis but also a disadvantage in that sometimes it seems to assume a MIME type for a bunch of files, then if another application says it supports that extension but not that MIME type then it doesn't consider it to support those files. I'm sure there's a way in the Info.plist to declare yourself properly as willing to open anything with just the correct extension but I'm failing to do so. I'll put in some more reading effort. It's not usually an issue for major file formats because everybody agrees on the MIME type, it's just a hassle when they don't.

Sorry for the error. I'll try to fix it promptly. I need to spend some more time on ROMs what with my terrible MegaROM detection anyway.

I'll probably need to be back on my Mac to figure out exactly what to ask but as an immediate query. which ROMs did you try? I have all of those available from the Internet Archive so it's possible I'll be able to try to recreate.

It strikes me that there are actually two conditions for Clock Signal to open a ROM: that NSDocumentController and gang accept from my Info.plist that I support that file format, and then an internal test to determine the target machine for the ROM. It's such a common file extension that I have to inspect the contents, and it's definitely possible that my test is incorrect.

It is, currently:

• that the file is a non-zero integer multiple of 16kb in size (this is due to a typo, which I have spotted as I type while reading the source on Github to make sure I'm speaking accurately — it should be 8kb, and I'll fix it); and
• that 'AB' is found either at the very start of the file, or at location 0x4000 in the file.

So if you tried only a particular file or two, and were unlucky to try those with a few extra bytes on the end, or that are 8kb, that's part two the problem.

Random trivia because I think this is a technical audience, and therefore it might be interesting:

• the other supported platform that can accept a .rom is presently the Acorn Electron; really the Atari 2600 should too, but .a26 is more common anyway so I'm presently a bit lazy;
• all tapes are also checked for MSX meaningfulness, based on whether there's anything on them that the BIOS could load, as the assumption is that if the tape can't itself be launched then it'll be added to a machine that has been started with something that can be;
• my poor MegaROM detection is currently predicated on a recursive disassembly of the ROM code, because there's a lot more you can do if you can get a meaningful disassembly, but also some notable unambiguous failure cases that would be extremely difficult to decode this way, so it'll never be the complete plan. It's attempt one. And sometimes it throws up a complete, unambiguous, correct answer so it'll stay in the arsenal;
• disks probably should be checked for MSX launchability (likely by boot sector disassembly and/or FAT inspection) but presently aren't. When they are I think I can enable support for the HFE file format, which is that used by the HxC floppy emulator and already otherwise implemented. It's just an MFM-rate bit stream, so a little larger than a DMK but infinitely more straightforward and slightly more accurate;
• the composite bandwidth error was related to a miscalculation around the clock speed that the source machine has nominated for the composite wave. It probably gives the error away to say that the amount of bandwidth I was allowing for the MSX was exactly 1365/2048 of the correct amount. I had not noticed the error previously because while that ~66% is very obvious, the exact ratio gifted to other machines by virtue of the integers involved was never less than about 89%, which was not obvious to me. They're also generally not in-phase with the colour subcarrier, so it's much less obvious. And it's mostly in GLSL so there's no step debugger, no unit tests. And, as stated, it's forming a real composite signal and then really decoding it. So it's not like I can just say "oh, it looks a little fuzzier than I think it should, let's turn a dial down"; I actually had to figure out why it looked blurrier than I felt it should, accepting that maybe it was actually correct and I'm wrong, until I found my numerical error.

Also implementation notes on things I found undefined or chose not to believe, while I'm engaged in an info dump:

• unless and until the fifth sprite bit is set, the VDP fifth sprite status field will just hold the ID of the sprite information most recently fetched. So you can use it as a coarse horizontal counter. I could find no information on what values the field will contain when the bit is not set and considered that an acceptable guess;
• there is a sprite fetch line one before the display (with corresponding limited VRAM access) in which initial sprite data is fetched, as research says that's definitely what the SMS does and I can't think of another sensible way that sprites could ever be correct on line 0;
• although the red book documentation for TAPIN suggests it depends on phase ("This is done by locating a negative transition..."), the actual BIOS seemed to be fine even if I inverted the tape. So my version of quick loading is independent of phase;
• right now the FDC is actually a 1793, not a 2793; I've yet to check rigorously for timing differences between the two but there tends to be differences in stepping rates, head settling times, etc between members of the family. So you get 99% of the correct timing by virtue of the simple fact that there is a simulated spinning platter and the FDC has to wait for data to pass below its head, which is most of the bottleneck, but it might be off by a few ms in seek times.

No, I think you're doing everything right and the software is acting incorrectly. My fault. In its Cocoa version it really is supposed to be just an ordinary Mac application with the ordinary relationship with windows and File->Open... and dragging and dropping and all the rest. No special rules, no deviations. So when it doesn't work like that, it is at fault.

On the plus side, acceptable file types in a macOS app are listed in the Info.plist — unlike other platforms they're application metadata, not something you announce programmatically on first launch or any of that nonsense — and the Info.plist is enclosed in every application in a viewable form. So this is one area where I can just see how everybody else does it, whether open source or not. I'll read the docs first, but failing that I can just peek at everybody else's answers.

EDIT: potential trivia fact: because the Mac application tries (and, I hope, mostly succeeds) to be a native app, using the native everything, it gains the built-in feature that if you have multiple windows open then they can automatically be tabbed. It's not especially convenient or obvious or speedy, but that means this might be the first tabbed MSX emulator?

I think 1365 is correct — the composite signal is (mostly) PCM sampled, so the machine has to provide a clock rate for that. Because it's usually closer to the way these things tend to be documented, I've adopted a policy whereby the clock rate is "number of clocks in a normal-length composite line". The TMS runs at 1.5 times the NTSC colour clock, so it produces for 341.25 cycles per regulation NTSC scan line.

The fact that it signals horizontal sync only every 342 cycles is just because it doesn't exactly conform to the NTSC standard. But my pretend CRT accepts that like a real CRT would.

It's the difference between 341.25 and 342 that causes the in-phase colour artefacts by the way, which I think is what those published memos about bad colour production are referring to: if you look down a straight edge such as the road in the mini-map of Road Fighter, the fringe colour is the same all the way down because the slightly extended time between horizontal syncs means that the edge is at the same place relative to the colour subcarrier every time. If that were not the case, the colour would vary on the way down, and would vary over time, which tends to look better. That'll happen naturally with a PAL output. I guess it makes producing the colour burst a lot easier though, so it makes the 9918 cheaper. Ataris do the same thing.

EDIT: to be triply explicit, composite video is completely optional for the MSX, because it is for a real MSX. See below for a non-composite image. You'll notice it still differs from a classic emulator in a couple of ways: the pixels aren't quite square (very, very nearly in NTSC, but just not quite), and you can see the effect of my phosphor decay simulation especially in the scrolling text. Just like a real CRT, that's a lot less overt when it's moving. I might be simulating a poor CRT, but if so then not deliberately.

Hi all, I've just released a substantial update. I think it should at least lead to an interesting discussion.

The issue I sought primarily to improve was MegaROM type detection.

I am sure that others have perfected determining the type through file inspection — i.e. via static analysis. I decided it was unlikely that I was going to be able to manage the same. So I decided just to throw some processing at the problem.

Other than in a select few cases where the answer is sufficiently obvious, when you load a MegaROM the emulator the emulator will apply dynamic analysis. It runs all the possible resulting MSXs simultaneously. By watching what happens to each, at any given moment it knows which is most likely to be correct. It'll show you that one. If and when the answer becomes definitive, it'll stop running the others.

It's early days so I'm still working on the various signals and triggers, but it's already doing a much better job than it was in the last release. So this release is an improvement.