Forums

I have recently been working on a new emulator, and it's starting to hang together, so here goes nothing.

It's called Clock Signal, and releases are here. That's a GitHub link. It's MIT-licensed open source.

A video of the emulator is here.

On the Mac it's a fully-native Cocoa application — no additional frameworks or libraries — that obeys the ordinary document model. So open arbitrarily many games, in arbitrarily many windows, to size and place however you want, collect in tabs, whatever. Just use File -> Open..., drag and drop over the application icon, associate the appropriate file types, etc. No attempt is made to be anything other than an ordinary application.

Under Linux, BSD et al it's an SDL application with no UI. Set up a file association in your favourite file manager, and launch your games by double clicking them.

In both cases the objective is that the fact of emulation be as invisible as possible. Keep the games themselves on disk as if they were applications, launch them as if they were applications, etc.

It's naturally imperfect as a first release, but in theory it obeys all known timing constraints; and, similarly, displays CRAM dots, etc. Actually, I think it might be latching the blank display bit at the wrong time. So caveats apply.

Also potentially of interest: audio (SN only as currently implemented) is sampled at a multiple of its natural clock rate and FIR sampled down to size. No special cases for high frequencies, no other shortcuts.

There's a composite video mode. Which means actual composite video — a [GPU-assisted] composite encoding and decoding. So the artefacts are the real artefacts; this isn't the usual "NTSC filter" snake oil of just blurring things up a bit. Though there are some aliasing issues in NTSC mode, so more work to do here.

For now that means OpenGL 3.2+ is required. That's deprecated on the Mac so I'm intending to add alternative paths, which might also open the door to ES 2.0 and Raspberry Pi/etc support.

I have no doubt there are a thousandfold more deficiencies that I'm simply blind to; all feedback is greatly appreciated!

sonic_161.png (274.4 KB)

Sonic (PAL; composite)

dizzy_161.png (206.76 KB)

Dizzy (PAL; composite)

road_rash_324.png (245.25 KB)

Road Rash (PAL; composite)

alex_kidd_us_not_composite_161.png (155.62 KB)

Alex Kidd (NTSC; RGB)

chase_hq_161.png (178.81 KB)

Chase HQ (PAL; composite; CRAM dots in evidence)

The video degradation looks pretty realistic - are you adjusting the pixel aspect ratio for even more accurate reproduction? Similarly the SN output needs to be filtered, there's definitely some high and low pass filters but I'm not sure what values are most accurate.

Any danger of a version that runs on evil operating systems?

The aspect ratio should be correct, though I haven't calculated what it should be or verified that. As per the theme of it looking like composite video because it is composite video, what the VDP outputs is a linear signal; the [virtual] CRT has to spot and distinguish syncs like a real CRT would, and paints the display in virtual raster scans. Other than on your screen once all that has been put together, there's no frame buffer. So no explicit resizing to a pixel aspect ratio, just one that emerges.

I added a low-pass filter to the audio at about 8khz by ear but I'm really not convinced by that number. There's no high-pass filter at present. Any guidance here would be welcome.

I haven't used Windows in about 15 years and don't own a licence. Those are the main obstacles! I keep meaning to look into it though; I just don't want to do it unless I can do a good job.

Allowing for the limited potential audience for the software itself, I'll indulge myself by providing some further implementation details; I think it's a pretty technical audience here, so that might make for a more interesting thread? Also I'm sat underground on a train right now, so the selfish distraction is no bad thing.

The Z80 is either half-cycle or part-machine cycle accurate. Either one is a valid description it decomposes its actions info machine cycles, and splits those anywhere it would sample or load the bus. The lengths are measured with half-cycle precision, because that's as precise as the timing diagrams made it look like I needed to be. The Master System doesn't in practice use either, but I was looking at WAIT and the BUS REQ stuff in particular. Anyway, it has no concept of any particular machine, of the existence in the world of memory, etc. It just announces the partial machine cycles (thereby giving complete insight into the bus signalling) and samples or loads when it should. It's effectively microcoded internally.

The VDP is similarly oblivious to anything outside its world, but as well as current state it will answer enquiries as to number of cycles until an interrupt per the current state.

The Master System itself is the bus between these things. It receives the partial machine cycles from the Z80 and loads or stores as commanded, including connecting to the VDP, cartridge, joypads, etc. It also signals interrupt lines back up to the Z80.

The outer thing, which is per-OS provides input and output, and owns the run loop. So all of that sits outside the machine logic.

With one exception! When originating the project, three-ish years ago and long before I added the Master System to my aspirations, I decided it would use OpenGL directly as the graphics library. Now that Apple has deprecated it, I'm going to use that as a pretext for properly decoupling that. If it ever allows me to use Metal natively, that should even be a performance win, as Apple's OpenGL is not exactly the best.

Threading observations: all audio processing is on a separate thread, on your CPU. Composite encoding and decoding both happen on the GPU. Issuing proper commands to generate the OpenGL output is also handled on its own thread. That includes resource submission, so CPU work may be involved.

The mediation between the main thread and the OpenGL thread is implemented poorly though. So that's a real performance drain. I need to address it.

That all being said, I develop on an original Retina MacBook, so something pretty underpowered by most standards — it's a 1.1Ghz Core M plus the integrated Intel GPU — and processor utilisation hovers around 35%. So I think modern technology has saved me!

Ummmm, otherwise potentially interesting: the triggers for "do some more work" are either of (i) host vertical sync; or (ii) audio buffer exhausted. So keeping enough audio data in flight is decoupled from anything to do with the frame rate. Latency on that is therefore only 5–10ms, regardless of your monitor's frame rate. Thin of the frame output as like pointing a virtual camera at the virtual CRT. The output rate is decoupled from the input. So if you have a 144Hz gaming monitor, video latency should be 1/144th of a second.

Such as to the feelings some may have about that: there's a version of image decay in there, so no hard tears in any event. But given the realities, an emulator's options are: (i) motion aliasing and latency; or (ii) softness. I prefer the latter, especially for the huge latency win it gives to anyone who has invested in an expensive screen presumably because they care about latency.

All aspirations subject to fallibility, of course!

(EDIT: I've uploaded a video of it in action to Youtube and added a link to the original message; now you can form your own opinion without having to download a thing)

Minor thing, but I discovered a potential stability issue resulting from the randomisation of VDP startup position; this has now been fixed and a new release uploaded to the same place.

I am otherwise working primarily on the precision issues with composite output.

Quick update on this: I've put out a new version of the emulator that resolves the luminance aliasing that was visible when playing NTSC-mode titles. It was a particular menace on anything cartoony (i.e. with sharp verticals) that scrolls horizontally. So, you know, quite a lot of things.

It's still available exactly where it was.

Minor update: this emulator is still where it always was, but now makes an attempt at FM audio. It's a completely new implementation and very preliminary, but quite a few things sound good.

In the interim I've also done some work on overall latency, both input and output. On the Mac version, where the available timers have a much higher precision, average input latency should now be around 0.8ms and vertical sync where available* is achieved by spacing processing out such that emulated and host syncs align rather than by the classic means of e.g. double buffering and buying into however much latency flows.

EDIT: Here’s a sample of FM output as it currently stands, specifically the Japanese BIOS:

* i.e. wherever the Master System's output is within a short distance of being an integer multiple of your display's.

A couple more notes on this:

The macOS version of this emulator now uses Metal for all GPU work, including the composite encoding and decoding, which hopefully future-proofs it on that platform.

In addition to its previous SDL support, there is now also a Qt port for X11, giving you easier runtime controls (and a lot more configuration options for platforms that aren't the Master System). Either build for yourself from source or, if you're a Snapcraft user, just download the Snap.

For the latter option, note that if you're using Ubuntu or a related distribution then quite probably Snapcraft is the thing sitting behind the on-desktop app store. So just open that and search. Besides anything else, this emulator seems to be the only thing that comes up for 'master system emulator'.

Author	Message
TomHarte Joined: 24 Sep 2018 Posts: 66	New emulator: Clock Signal for the Mac and Linux/BSD Posted: Sat Oct 27, 2018 2:14 am Last edited by TomHarte on Sat Oct 27, 2018 4:07 pm; edited 1 time in total
TomHarte Joined: 24 Sep 2018 Posts: 66	I have recently been working on a new emulator, and it's starting to hang together, so here goes nothing. It's called Clock Signal, and releases are here. That's a GitHub link. It's MIT-licensed open source. A video of the emulator is here. On the Mac it's a fully-native Cocoa application — no additional frameworks or libraries — that obeys the ordinary document model. So open arbitrarily many games, in arbitrarily many windows, to size and place however you want, collect in tabs, whatever. Just use File -> Open..., drag and drop over the application icon, associate the appropriate file types, etc. No attempt is made to be anything other than an ordinary application. Under Linux, BSD et al it's an SDL application with no UI. Set up a file association in your favourite file manager, and launch your games by double clicking them. In both cases the objective is that the fact of emulation be as invisible as possible. Keep the games themselves on disk as if they were applications, launch them as if they were applications, etc. It's naturally imperfect as a first release, but in theory it obeys all known timing constraints; and, similarly, displays CRAM dots, etc. Actually, I think it might be latching the blank display bit at the wrong time. So caveats apply. Also potentially of interest: audio (SN only as currently implemented) is sampled at a multiple of its natural clock rate and FIR sampled down to size. No special cases for high frequencies, no other shortcuts. There's a composite video mode. Which means actual composite video — a [GPU-assisted] composite encoding and decoding. So the artefacts are the real artefacts; this isn't the usual "NTSC filter" snake oil of just blurring things up a bit. Though there are some aliasing issues in NTSC mode, so more work to do here. For now that means OpenGL 3.2+ is required. That's deprecated on the Mac so I'm intending to add alternative paths, which might also open the door to ES 2.0 and Raspberry Pi/etc support. I have no doubt there are a thousandfold more deficiencies that I'm simply blind to; all feedback is greatly appreciated! sonic_161.png (274.4 KB) Sonic (PAL; composite) dizzy_161.png (206.76 KB) Dizzy (PAL; composite) road_rash_324.png (245.25 KB) Road Rash (PAL; composite) alex_kidd_us_not_composite_161.png (155.62 KB) Alex Kidd (NTSC; RGB) chase_hq_161.png (178.81 KB) Chase HQ (PAL; composite; CRAM dots in evidence)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Sat Oct 27, 2018 6:40 am
	The video degradation looks pretty realistic - are you adjusting the pixel aspect ratio for even more accurate reproduction? Similarly the SN output needs to be filtered, there's definitely some high and low pass filters but I'm not sure what values are most accurate. Any danger of a version that runs on evil operating systems?

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Sat Oct 27, 2018 12:46 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	The aspect ratio should be correct, though I haven't calculated what it should be or verified that. As per the theme of it looking like composite video because it is composite video, what the VDP outputs is a linear signal; the [virtual] CRT has to spot and distinguish syncs like a real CRT would, and paints the display in virtual raster scans. Other than on your screen once all that has been put together, there's no frame buffer. So no explicit resizing to a pixel aspect ratio, just one that emerges. I added a low-pass filter to the audio at about 8khz by ear but I'm really not convinced by that number. There's no high-pass filter at present. Any guidance here would be welcome. I haven't used Windows in about 15 years and don't own a licence. Those are the main obstacles! I keep meaning to look into it though; I just don't want to do it unless I can do a good job. Allowing for the limited potential audience for the software itself, I'll indulge myself by providing some further implementation details; I think it's a pretty technical audience here, so that might make for a more interesting thread? Also I'm sat underground on a train right now, so the selfish distraction is no bad thing. The Z80 is either half-cycle or part-machine cycle accurate. Either one is a valid description it decomposes its actions info machine cycles, and splits those anywhere it would sample or load the bus. The lengths are measured with half-cycle precision, because that's as precise as the timing diagrams made it look like I needed to be. The Master System doesn't in practice use either, but I was looking at WAIT and the BUS REQ stuff in particular. Anyway, it has no concept of any particular machine, of the existence in the world of memory, etc. It just announces the partial machine cycles (thereby giving complete insight into the bus signalling) and samples or loads when it should. It's effectively microcoded internally. The VDP is similarly oblivious to anything outside its world, but as well as current state it will answer enquiries as to number of cycles until an interrupt per the current state. The Master System itself is the bus between these things. It receives the partial machine cycles from the Z80 and loads or stores as commanded, including connecting to the VDP, cartridge, joypads, etc. It also signals interrupt lines back up to the Z80. The outer thing, which is per-OS provides input and output, and owns the run loop. So all of that sits outside the machine logic. With one exception! When originating the project, three-ish years ago and long before I added the Master System to my aspirations, I decided it would use OpenGL directly as the graphics library. Now that Apple has deprecated it, I'm going to use that as a pretext for properly decoupling that. If it ever allows me to use Metal natively, that should even be a performance win, as Apple's OpenGL is not exactly the best. Threading observations: all audio processing is on a separate thread, on your CPU. Composite encoding and decoding both happen on the GPU. Issuing proper commands to generate the OpenGL output is also handled on its own thread. That includes resource submission, so CPU work may be involved. The mediation between the main thread and the OpenGL thread is implemented poorly though. So that's a real performance drain. I need to address it. That all being said, I develop on an original Retina MacBook, so something pretty underpowered by most standards — it's a 1.1Ghz Core M plus the integrated Intel GPU — and processor utilisation hovers around 35%. So I think modern technology has saved me! Ummmm, otherwise potentially interesting: the triggers for "do some more work" are either of (i) host vertical sync; or (ii) audio buffer exhausted. So keeping enough audio data in flight is decoupled from anything to do with the frame rate. Latency on that is therefore only 5–10ms, regardless of your monitor's frame rate. Thin of the frame output as like pointing a virtual camera at the virtual CRT. The output rate is decoupled from the input. So if you have a 144Hz gaming monitor, video latency should be 1/144th of a second. Such as to the feelings some may have about that: there's a version of image decay in there, so no hard tears in any event. But given the realities, an emulator's options are: (i) motion aliasing and latency; or (ii) softness. I prefer the latter, especially for the huge latency win it gives to anyone who has invested in an expensive screen presumably because they care about latency. All aspirations subject to fallibility, of course! (EDIT: I've uploaded a video of it in action to Youtube and added a link to the original message; now you can form your own opinion without having to download a thing)

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Oct 30, 2018 2:28 am
TomHarte Joined: 24 Sep 2018 Posts: 66	Minor thing, but I discovered a potential stability issue resulting from the randomisation of VDP startup position; this has now been fixed and a new release uploaded to the same place. I am otherwise working primarily on the precision issues with composite output.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Sun Mar 03, 2019 3:05 am
TomHarte Joined: 24 Sep 2018 Posts: 66	Quick update on this: I've put out a new version of the emulator that resolves the luminance aliasing that was visible when playing NTSC-mode titles. It was a particular menace on anything cartoony (i.e. with sharp verticals) that scrolls horizontally. So, you know, quite a lot of things. It's still available exactly where it was.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Mon May 11, 2020 2:40 am
TomHarte Joined: 24 Sep 2018 Posts: 66	Minor update: this emulator is still where it always was, but now makes an attempt at FM audio. It's a completely new implementation and very preliminary, but quite a few things sound good. In the interim I've also done some work on overall latency, both input and output. On the Mac version, where the available timers have a much higher precision, average input latency should now be around 0.8ms and vertical sync where available* is achieved by spacing processing out such that emulated and host syncs align rather than by the classic means of e.g. double buffering and buying into however much latency flows. EDIT: Here’s a sample of FM output as it currently stands, specifically the Japanese BIOS: * i.e. wherever the Master System's output is within a short distance of being an integer multiple of your display's.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Wed Oct 07, 2020 2:15 am
TomHarte Joined: 24 Sep 2018 Posts: 66	A couple more notes on this: The macOS version of this emulator now uses Metal for all GPU work, including the composite encoding and decoding, which hopefully future-proofs it on that platform. In addition to its previous SDL support, there is now also a Qt port for X11, giving you easier runtime controls (and a lot more configuration options for platforms that aren't the Master System). Either build for yourself from source or, if you're a Snapcraft user, just download the Snap. For the latter option, note that if you're using Ubuntu or a related distribution then quite probably Snapcraft is the thing sitting behind the on-desktop app store. So just open that and search. Besides anything else, this emulator seems to be the only thing that comes up for 'master system emulator'.

Forums

View topic - New emulator: Clock Signal for the Mac and Linux/BSD