Clock Signal: a Vic-20 emulator for macOS and Linux

You need an actual VIC.

Moderator: Moderators

Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Clock Signal: a Vic-20 emulator for macOS and Linux

Post by Tom »

EDIT: Skip to the end: releases. Enjoy!

I am one of those. One of the flood. The glut. In bullet points:
  • C++ plus languages appropriate to your OS for binding;
  • ... with currently only a Mac binding (so, Objective-C for bridging and Swift for the main action over there, but it's a full document-model app: open as many pieces of Vic software simultaneously as you like);
  • multi-machine (but no other Commodores so who cares?);
  • cycle accurate in that all decisions are per cycle, it's just very unlikely that my 6560 or 6522 are yet making exactly the right decisions;
  • most interesting feature: video is described as its genuine composite waveform, which your GPU then decodes. For always correct aspect ratios, artefacts, full interlacing support should any piece of software ever actually use it, diagonal scans etc.
On that final bullet point: I understand from earlier posts and private messages that the VIC uses a square wave rather than a sine wave to approximate the colour subcarrier. So I've been playing with that. I'm currently emulating an NTSC machine only, which I understand means that each line in any field is generated with the same phase of colour subcarrier and that the phase alternates between fields. Is that correct? When I implement PAL my understanding is the opposite: phase alternates between lines but ends up being the same between line N on field Q and line N on field Q+1.

A bunch of screenshots are attached. I've something of a cheap trick attempt at phosphor decay so the emulator displays its normal ongoing output separately from the way that individual fields look, so I've separately captured single fields where appropriate. My CRT is very forgiving and will just believe any colour burst it sees. I'm sure some of the subcarrier phases aren't correct* but I'd be grateful if somebody with experience of the real NTSC hardware could take a quick look and tell me whether I'm even in the correct ballpark.

Added: a screenshot of Frogger. Does the real hardware really show that banding on ostensibly solid colours? It's completely eliminated if I use a sine wave, but appears with a square, so I don't know.

(EDIT: but, again, just to emphasise this: it's an actual one-dimensional composite wave that's actually decoded by the GPU. Not a post-processing effect on an initially perfect frame buffer — it's not merely some attempt to try to recreate the feel of a TV without actually having emulated one.)

* in NTSC the phases I picked ended up making a nice pattern of even colours being spaced 1/8th of a colour cycle apart and odd colours always being diametrically opposite, but I'm not necessarily convinced by that.

EDIT: the forum doesn't appear to show file names (?), so:

A sine-wave output, I guess similar to what you'd expect of a VIC-II:
Sine.png
A single field of that sine-wave output:
Sine (single field).png
What happens if I replace the colour subcarrier with a square wave:
Half-amplitude square.png
... and a single field of square-wave output:
Half-amplitude square (single field).png
That same single field with the saturation turned up:
Square.png
A screenshot of Frogger with square-wave output, showing wide-area colour banding that I suspect may be an error:
Frogger.png
All captured at full-screen resolution on my development computer, which is a c.2001 MacBook Air and on which each instance of a Vic-20 takes something like 35–40% of a core to run but doesn't have audio yet. So that'll go up a touch. Output scales to any resolution and otherwise sits in a normal desktop window, being sized and placed however you want, etc. It aims to be a completely natural native app, which is why the front-end part is platform specific. The emulation stuff is all platform neutral though.
Last edited by Tom on Tue Apr 03, 2018 12:37 pm, edited 5 times in total.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

very cool approach of emulating the CRT!
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

groepaz wrote:very cool approach of emulating the CRT!
It is the one thing, if anything, that might potentially at some point make my emulator interesting to anybody. As to Vic support, I intend to add audio and PAL mode before supplying a first build here. Then I'll endeavour to unit test to death and thereby perfect the 6522, then hopefully the 6560/1.

One of the reasons I'm poking my nose into the Vic is that I then want to try a 1540 emulation, to see how well my structure scales to multiple-CPU machines. But I'll need a much better 6522 before I can hope to look at that.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

are you actually en/de-coding QAM too? (i skipped that part in my "research" renderer, but still got quite convincing results IMHO.... however to properly get all artefacts you probably have to do it)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

groepaz wrote:are you actually en/de-coding QAM too? (i skipped that part in my "research" renderer, but still got quite convincing results IMHO.... however to properly get all artefacts you probably have to do it)
Yes. However audio and video remain completely separate (at least partly because I've yet to gain a full understanding of how one demodulates FM content).

Full process is:

The emulator itself describes the composite waveform in the abstract. Like "I output this value for X clocks", "I output this PCM stream of values for X clocks", etc. It also supplies a function to convert from the values it supplies to a composite wave. On the CPU the emulated CRT classifies syncs and runs a couple of flywheel synchronisers to determine the raster scan, then bundles that off to the GPU as "process the composite stream between X and Y, then paint it onto a scan from (M, N) to (P, Q)".

The GPU:
  • runs the machine-supplied conversion function on the input to produce the composite stream;
  • runs a lowpass and a highpass on that to separate luminance and chrominance;
  • runs a QAM decode on the chrominance to produce the two colour channels;
  • lowpass filters the two colour channels;
  • maps the resulting three channels over to RGB; and
  • paints that along the scan indicated.
With simple in-framebuffer accumulation passing for phosphor decay. So it's logarithmic and nice enough that interlaced signals work nicely enough. Actually, even that negligible approach seems to make a sufficiently decent fist of pretending to be phosphors that I've found that always updating the latest scans as and when your real-life display refreshes produces a much smoother display than the usual PAL-on-a-computer approach 3:2-pulldown-lite of having 40 of your fields last for a single frame and 10 of them last for two fields.

In VIC land the values I'm supplying are each 8-bit, with four bits for luminance and four bits for phase offset, from which the supplied function does

Code: Select all

output = luminance + saturation * [square wave](phase + phase offset)
. So the only thing I have that's at all like a palette is a table of luminances and phase offsets. It's a two-value lookup. Three-dimensional colour happens only because of the quadrature amplitude [de]modulation.

Aside on audio: one of the other machines emulated produces 125kHz audio, just as a consequence of the divider used. The applied solution is to formulate the entire 125,000Hz wave and then to lowpass it down to whatever your audio supports. Caveat though: some Mac support 192kHz audio output, so no filtering for them. Actually, I think all Macs for years have supported 96kHz, though you have to opt in, so those people will get 96kHz output. I've yet seriously to look into it but I think the Vic is generating at a much more sensible ~35kHz though, so the best possible outcome for me will be audio that sounds as good as the other emulators.

Other only-a-coder-could-care boasts: the CRT output is not only a separate thread from the machine emulation but is formulated so that it can occur at any time, whether the emulated machine is currently processing or not. Which is because it's helpful to do that: it makes window resizing completely seamless.

I probably want to move audio processing off to another thread too, as running multiple cores at a low work level is less power intensive than running one at a medium work level, but I'm dithering as to how to keep that sufficiently simple and it's just not a huge contributor to the processing cost. On the Mac side I've been able to take advantage of one of the built-in frameworks to apply the SIMD unit to the filtering so it's cheap. Actually, I think on the Mac side I'm allowed just to tell the OS that my audio is 125kHz or whatever and that, if the hardware isn't, it should deal with it. But I wasn't previously aware. So that's that.

EDIT: oh, and that GPU stuff is all fairly vanilla GLSL. It assumes real integer types and bitwise operators in a few places though, so while that's no problem on the desktop it probably means no ES 2.0 port will be forthcoming without quite a bit of pain. My development machine, being an ageing ultrabook, has just the five-year old Intel integrated GPU and runs without issue. So I don't think that what I'm doing is expensive on the GPU scale. If I were bothered about performance then the slightly awkward hoops of being cycle perfect while being multi machine are probably the more obvious issue.
Last edited by Tom on Mon Jun 13, 2016 8:45 am, edited 1 time in total.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

thats pretty awesome! will it be open source? :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

groepaz wrote:thats pretty awesome! will it be open source? :)
It is already, technically, but the Vic side of things is so embarrassing that I'd be too ashamed to post a link right now. I'll prioritise the resolution of all embarrassing parts.
groepaz
Vic 20 Scientist
Posts: 1180
Joined: Wed Aug 25, 2010 5:30 pm

Re: A heavyweight Vic-20 emulator with twists

Post by groepaz »

hehe, i know that feeling :)
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: A heavyweight Vic-20 emulator with twists

Post by lance.ewing »

This all sounds really great!! Fantastic work!

I have a question that I'll address to all readers that is related to part of what is mentioned above. Do we know yet for certain what shapes the two waveforms are that are combined to create the phase shift waveform? My current assumption is that they would be an approximation of something sinusoidal in shape, based on the output of putting a square wave through an integrator a couple of times, so would look more like "rounded triangle waves" (to quote what Bob Yannes said about the VIC-II sine wave generation). So I've been assuming up until now that the VIC-I would have had a similar approach, but maybe that assumption is wrong. Unfortunately that is a part of the die shot I couldn't work out the schematic of.

Has anyone done external measurements of the composite colour pin to deduce what the wave form shapes would have been at the point at which the phase shift is introduced? I doubt they would be square, but at the same time also not a perfect sine shape.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

lance.ewing wrote:Has anyone done external measurements of the composite colour pin to deduce what the wave form shapes would have been at the point at which the phase shift is introduced? I doubt they would be square, but at the same time also not a perfect sine shape.
I haven't done it but I can do it. My scope can trigger in NTSC sync and specific scanlines can be studied.

I can put the luma/sync on channel 1 and the chroma signal on channel 2. My scope is a Tektronix TDS-1002.

I also managed to get a place to rent me a special monitor with vectorscope capabilities built-in. Unfortunately, it doesn't have S-Video input. It has composite only.
Be normal.
Tom
Vic 20 Amateur
Posts: 63
Joined: Mon Jun 06, 2016 9:07 am

Re: A heavyweight Vic-20 emulator with twists

Post by Tom »

eslapion wrote:
lance.ewing wrote:Has anyone done external measurements of the composite colour pin to deduce what the wave form shapes would have been at the point at which the phase shift is introduced? I doubt they would be square, but at the same time also not a perfect sine shape.
I haven't done it but I can do it. My scope can trigger in NTSC sync and specific scanlines can be studied.
If you could do that then it would be amazing. Is there anything I can contribute?
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

Tom wrote:
eslapion wrote:I haven't done it but I can do it. My scope can trigger in NTSC sync and specific scanlines can be studied.
If you could do that then it would be amazing. Is there anything I can contribute?
If that's all that's required to be amazing then I guess I should do it. Just give me a bit of time to connect this setup.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

I setup the PSK VIC-20 with S-Video mod with black border and screen (POKE36879,8), then I used RVS ON to put 4 color spaces on the top left of the screen. I used yellow, blue, green and white.

A capture of scanline 55 including the sync, colorburst, and all 4 chracters looks like this:
Image
I can clearly see the luma signal beginning with the sync, then the black border, then 4 spaces of different luminance. You can also notice only the first 3 spaces have a color signal since the 4th one is white.

I then realized the phase of the colorburst signal is inverted on every video field. The colorburst cannot be captured properly by averaging samples because they cancel each other to zero. I decided to make 2 close up captures right after the sync ends; one for each phase.

Phase A:
Image

Phase B:
Image

This is the most detailed close-up of the colorburst I can give. There is a lot of noise in there and the noise is sync to the colorburst so I assume it comes from the VIC. I used a 20MHz filter to reduce garbage as much as possible.
Image

It looks like a poor man's sine wave that could either be done with a wave shaper or double integration. Given the choice, I would do it with a wave shaper as it requires much fewer discreet components than a pair of integrators.
Last edited by eslapion on Tue Jun 14, 2016 4:02 am, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

This is a capture of the chroma signal at precisely the point where the video signal shifts from yellow to blue.

You can see the shift in the luma and the sudden phase change on the chroma.
Image

As shown by the master position shift at the top of the display, this occurs 16.3us after the horizontal sync.

Anything else you'd like to see ?
Last edited by eslapion on Tue Jun 14, 2016 3:42 am, edited 1 time in total.
Be normal.
User avatar
eslapion
ultimate expander
Posts: 5458
Joined: Fri Jun 23, 2006 7:50 pm
Location: Canada
Occupation: 8bit addict

Re: A heavyweight Vic-20 emulator with twists

Post by eslapion »

This is my trick to convert a triangle wave into a sine wave:
Image

The beauty of this thing is if you remove the op-amp, the conversion is almost completely independent of the frequency of the signal, unlike an integrator but the input amplitude has to remain very stable.

I suspect the defunct MAX038 function generator chip used this trick or something similar to generate sine waves from 0.1Hz up to 20MHz.
Be normal.
Post Reply