One additional: Clock Signal

Page 5/5
1 | 2 | 3 | 4 |

By TomH

Champion (272)

TomH's picture

13-09-2018, 22:24

EDIT: Ugh, I've started a new page. I'll recap the emulator briefly:

Clock Signal is an MIT-licensed emulator of the MSX 1 (and various non-MSXs) available here. It has both macOS (with a native Cocoa UI) and SDL (UI-less for file association and/or command-line use) targets .

It tries to do a bunch of things in a way very different from other emulators:

  • audio is calculated at the MSX clock rate and resampled to your computer's output;
  • video output is not frame-driven, but is predicated on a virtual CRT which can be snapshotted at arbitrary intervals, to avoid 50-on-60, 60-on-144 stutter, etc, and to provide latency that scales with your computer refresh rate so that a gaming machine offers a better gaming experience;
  • the primary means of launching is to say which game you want to load — the tape, disk or cartridge. The emulator will inspect the media and pick and configure a machine automatically, then type whatever the loading command is;
  • it'll try to do that for all included machines, so you can even try some non-MSX software without consulting some other machine's manual; and
  • in general it tries at length to be exactly like any other application. E.g. the macOS version uses a completely native UI, allowing you to open arbitrarily many pieces of original media into arbitrarily many different machines at once, each having an independent window for you to size and place wherever you want, or make fullscreen, or arrange as tabs, or whatever.

Like other modern emulators, everything it implements it seeks to do so with complete accuracy to the original machine — it aims for subcycle accuracy. I'm fallible, but often it succeeds.

The emulator has almost no dependencies, so it's super easy to build — on macOS it has none whatsoever that aren't native frameworks. The SDL version requires SDL 2, OpenGL, and scons to build.

Given that of the MSXs, only the MSX 1 is modelled, this emulator does quite a lot less than other MSX emulators, no mater how much it might do some of those things in novel ways*. Probably the only thing it does well that others do not is full support for TSX, in addition to the more standard CAS, DSK, DMG.

(* of potential technical interest: dynamic analysis for cartridge type detection. Just run all the possibilities simultaneously and show the user whichever one is working best, killing off those that aren't working at all.)

The originally scheduled reply now follows:

Re: the MSX 2, I've just kind of boxed myself into a corner with the current TMS implementation by trying to be too clever. It's process-on-demand (e.g. if you write a program that writes to the VDP every q cycles, the emulated VDP will itself run in q cycle bursts), but as written it takes a bunch of steps to run for exactly q cycles but avoiding undue cost by doing all colour fetches in that period as one step, all name table fetches as another, etc. It's efficient only if you make the assumption that there's at most one write to fit somewhere into that sequence.

With a command engine, there's arbitrarily many writes to fit into that sequence. So you can't so trivially reorder it.

What I should have done is something more like: (ignoring the border) there's this pattern of 16 cycles of activity that repeats eight times. And, actually, it doesn't really matter whether I run for exactly q cycles, I can treat those building blocks as atomic and just complete all the ones that have finished prior to now. Nobody can ever tell that there are, say, 13 cycles of activity that I should have done now but actually won't do until later because the data they depend upon can't actually mutate before I do the work.

Then I'm not reordering but I'm also not really trying to create a coroutine. And the atomic blocks pattern scales up to incorporating a command engine a lot more easily than does reordering.

I mean, the whole thing is only 730 lines, with copious commenting, and of course it's completely independent of every other part of the machine implementation. So not a big deal to change, I think. Just a mental burden.

In terms of hassles, on the not-specifically-MSX front I've got the whole making OpenGL optional task ahead of me. Thanks, Apple. But it'll be a really good thing to do because the way that multithreads is really naive and really slow. It's at least an order of magnitude more mutex navigations than it needs to be, and the scheduling of the two threads isn't even intelligent. Having to reopen that box will be a very good thing.

Fingers crossed some of that makes sense.

By Manuel

Ascended (14888)

Manuel's picture

13-09-2018, 21:59

I like your approaches! Quite refreshing.

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