One additional: Clock Signal

Page 1/4
| 2 | 3 | 4

By TomH

Master (196)

TomH's picture

14-01-2018, 04:55

Minor announcement because I think MSX emulation is already well covered, but I've just released a new MSX 1 emulator for UNIX-like operating systems with SDL 2 and, separately, for macOS.

Potentially interesting features:

  • built for cycle accuracy;
  • a signals processing approach is taken where appropriate:
  • audio is calculated internally at the full AY clock rate, then low-pass filtered down to whatever your computer can do. If it's a Mac, that definitely means at least 96Khz if you want it, but probably the usual 44.1 or 48;
  • it also rejects the idea that an emulator needs to produce an entire frame of output and then magic that to the display in one blast, because that's not how CRTs work. Instead video appears as-it-comes, with phosphor decay. If you have a 144Hz gaming monitor, you can enjoy very low-latency 144Hz emulation;
  • I'm also generally against emulators that try in themselves to be interesting as all you really want to do is use the emulated software, so there's no custom UI whatsoever. On the Mac it's an ordinary document-centric application: run as many MSXs at once as you care, do whatever you want with each window as to sizing and positioning, etc. The SDL version is intended to be launched by the command line in principle, but In practice is expected to be assigned a file association. Just double click your file and go.

Supported file formats are what I take to be the current standard bunch:

  • CAS and TSX for tapes. Optionally with ROM-intercepting turbo loading, and even though TSX is the worst;
  • DSK and DMK for disks. At their real speed only, I'm afraid. A full spinning platter and PLL is emulated;
  • ROM for cartridges. Its autodection of MegaROMs is currently dreadful though, being wrong almost half the time. So good luck. SCC support is there, but it's a theoretical perfect SCC, so work to do.

The target audience is explicitly: people who want to use MSX software. I don't really care for options, or debugging features, or anything like that. I'm all about the user just being able to nominate the piece of media they want to run, and whatever is on it appearing as quickly as possible. No need for any prior knowledge of an MSX. At the minute the effect of that is little beyond that it'll automatically type whatever is correct to load a tape, but I hope it helps to frame the future development that will occur, if any: it'll all be in terms of making sure that additional software runs.

Ordinarily at this point I would make a bunch of boasts about the composite video emulation: if you opt to have your MSX connected via composite then the emulator calculates the real composite video stream, and then really decodes it, for the real effects of composite video. It's not me mucking about with artistic filters because that's what I think the composite video is, it's the real maths with the real flaws.

However, the particular timing of the TMS appears to have betrayed a precision problem somewhere in that stack. So it's doing all of that, but the result is a little lumpier than it should be. So it's not presently exposed on the Mac port. I'm working on it.

Also, your emulated MSX will always be a 60Hz model for now.

If anybody tries it, feedback would be lovely. Thanks!

Login or register to post comments

By Grauw

Enlighted (7243)

Grauw's picture

14-01-2018, 15:56

Nice! No wav for tapes?

By TomH

Master (196)

TomH's picture

14-01-2018, 16:33

I keep prevaricating on WAV but I think it'd be easy to add WAV support for the SDL target and all OS-supported audio formats support for the Mac. Other than one platform, which I could exclude for now, the code is smart enough to be able to tell which computer a tape is for based only on its contents so I don't think it would break my just-click-the-thing ethos. I'll check it out. If that all works, I could also enable at least CSW support for the MSX, which is about a million times better an idea than TSX.

By Grauw

Enlighted (7243)

Grauw's picture

14-01-2018, 18:26

I think in general WAV is the most true-to-origin file format… Can’t get simpler than that, it will capture all the original data, and is easy to record and play back without any specialised tools (possibly platform-dependent and/or closed-source).

File size is the only real concern, but if they’re cleaned up they’ll compress to something tiny. Btw, openMSX supports loading gzipped (maybe also zipped) wav files directly.

By TomH

Master (196)

TomH's picture

14-01-2018, 20:04

Agreed on WAV (or MP3 or AAC or...) as being the most convenient option for users to capture; I'd just like to make sure I can make it equally easy to launch.

If my code works as well as I hope it does then hopefully the process should be no more complicated than go to file -> open, select your WAV, then the emulator realises it's MSX format, determines that whether the user is intended to use CLOAD, BLOAD or RUN to load the first thing on the tape, performs that command and intercepts ROM calls so that as much as is easy loads near-instantly.

So I'll put that on my TODO list. Currently along with figuring out what error I've made in composite video, and improving MegaROM detection. Then, one day, maybe MSX 2 support. If it weren't for that VDP command unit, it'd be a no-brainer.

EDIT: to expand on that thought, because the it's very easy in the VDP loop to say "do I have a read/write pending, and if so then is there an access slot anywhere in the coming period*", but less so to actually have a full coroutine ongoing, for a unit without well-known timing. (* but, yes, it's a cycle-perfect emulator, just not a dumb lockstep one: if the CPU last spoke to the VDP at time n and now does so again at n+m then the VDP is run just-in-time for m cycles, because they're independent other than for those sync points)

EDIT2: as to composite video, a screenshot is immediately below. Somewhere, somehow, the effective colour subcarrier seems to be reduced to something like 145/line. And yet the TMS still manages to stay in phase, so the prevision must be dropping out fairly late in the pipeline. Frustratingly that stuff is all in GLSL so a major pain to debug. So this is even lower bandwidth than normal NTSC video. Which makes it look a bit like it's defocussed. So it's fairly painful, and not representative of a real TV. If you're using the SDL build then please don't think that I really think this is what composite video looks like.

By ren

Paragon (1123)

ren's picture

14-01-2018, 20:42

Ha, couldn't have guessed from the title this was a new MSX emu announcement Smile
Cool, see some interesting features listed, will look into it!

By Pencioner

Hero (609)

Pencioner's picture

14-01-2018, 21:01

TomH wrote:

EDIT2: as to composite video, a screenshot is immediately below.

Frankly, i have watched a pic look like your screenshot when i connected VG-8020 to some modern TV while ago, though... looks so familiar. Thus, i confirm that it emulates some real world cases Smile Maybe not what you expect, like i didn't expect when used 8020 with tv...

By TomH

Master (196)

TomH's picture

14-01-2018, 21:18

ren wrote:

Ha, couldn't have guessed from the title this was a new MSX emu announcement Smile
Cool, see some interesting features listed, will look into it!

It's difficult to come up with reasons why somebody might particularly want a new MSX emulator, especially of the MSX 1 only, so I thought I'd just sort of sneak it in here.

Pencioner wrote:
TomH wrote:

EDIT2: as to composite video, a screenshot is immediately below.

Frankly, i have watched a pic look like your screenshot when i connected VG-8020 to some modern TV while ago, though... looks so familiar. Thus, i confirm that it emulates some real world cases Smile Maybe not what you expect, like i didn't expect when used 8020 with tv...

Then maybe I shouldn't worry about it so much, but there are some odd aliasing artefacts and if I grab one of the intermediate composite buffers, I count only 135 cycles of the colour subcarrier in the visible area, when there should be closer to 200. The two are related because my intermediate buffers are sized relative to the NTSC signal, not whatever computer is attached. So I'm investigating, at least.

By FiXato

Scribe (1438)

FiXato's picture

14-01-2018, 21:41

Regarding tape support: keep in mind that userdata tapes for ROMs such as Metal Gear, don't need the emulator to type anything to load, as they need to be loaded from inside the game. Smile

By TomH

Master (196)

TomH's picture

14-01-2018, 21:55

True, and the workaround is to double click the ROM to launch the emulator, then add the tape to that running machine by drag and drop.

I definitely do not presently have enough imagination to come up with a reliable means by the emulator could spot that two files it was being asked to open at once are actually both part of the same title, and launch one machine instead of two. It's something that the rest of the code could do, but the module that picks and configures a machine prior to launch — the static analyser — essentially believes that one file = one instance of a machine.

By TomH

Master (196)

TomH's picture

16-01-2018, 00:56

I found the error in my composite video handling, and have provided a new release. As it happens, I was providing only around 2/3rds the real NTSC bandwidth. Proper Road Fighter shot attached. Compare and contrast with the previous.

Since it is now working, the Mac version now provides a composite video option. The SDL version always did.

Page 1/4
| 2 | 3 | 4
My MSX profile