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

[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:

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:


Phase B:


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.


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.

[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.


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 ?

[eslapion]

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


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.

[Tom]

Thanks! That is indeed a wonderful thing. Did you get any sort of digital read-out other than the graphic?

Table-based lookups appear to be problematic in GLSL but I'm sure I can find a suitable model.

(small aside: I added audio to the emulator last night; based on the latest documentation that it's produced by 8-bit shift registers running up to 1/4 as fast as the system clock that actually gives the [NTSC] machine a 255,681.75Hz audio output stream, meaning that the emulator is calculating that number of samples a second and low-pass filtering that down to your machine's audio rate. I just wish a formula were known for noise — I ran a quick brute force search to try all possible XOR linear feedback shift register arrangements but none was close to the VICE table, though I didn't check my work very thoroughly and there are hints elsewhere that VICE is wrong so who knows?)

[lance.ewing]

Anything else you'd like to see ?

I can think of a lot of 6560 oscilloscope related requests, but perhaps I should start that as a new topic under Hardware, as I can easily see it going on for pages and pages and I think it would certainly be a topic of interest in itself. So very shortly I will be creating that topic and posting my first request(s) to it.

[lance.ewing]

I added audio to the emulator last night; based on the latest documentation that it's produced by 8-bit shift registers running up to 1/4 as fast as the system clock that actually gives the [NTSC] machine a 255,681.75Hz audio output stream, meaning that the emulator is calculating that number of samples a second and low-pass filtering that down to your machine's audio rate. I just wish a formula were known for noise — I ran a quick brute force search to try all possible XOR linear feedback shift register arrangements but none was close to the VICE table, though I didn't check my work very thoroughly and there are hints elsewhere that VICE is wrong so who knows?)

Perhaps the tone generators should be the next part of the die shot that I take a look at after completing the luminance section. I was going to try to fully complete the current quarter of the die shot image that I've been looking at, but if there is an interest in the tone and noise generation, maybe I should take a look at that and see how far I get through it.

[eslapion]

(small aside: I added audio to the emulator last night; based on the latest documentation ...

Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.

[eslapion]

Did you get any sort of digital read-out other than the graphic?

What numbers exactly would you have liked to see?

(small aside: I added audio to the emulator last night; based on the latest documentation that it's produced by 8-bit shift registers running up to 1/4 as fast as the system clock that actually gives the [NTSC] machine a 255,681.75Hz audio output stream...

That should be 14 318 180 / (14 * 4) =255682 Hz

The VIC's CPU runs at 14.31818MHz /14, the color encoding is 14.31818MHz/4 and the dot clock is 14.31818MHz/3.5.

Of course, these figures are for NTSC.

[Tom]

Did you get any sort of digital read-out other than the graphic?

What numbers exactly would you have liked to see?

I guess it would now be more appropriate to follow up on that elsewhere...

(small aside: I added audio to the emulator last night; based on the latest documentation that it's produced by 8-bit shift registers running up to 1/4 as fast as the system clock that actually gives the [NTSC] machine a 255,681.75Hz audio output stream...

That should be 14 318 180 / (14 * 4) =255682 Hz

The VIC's CPU runs at 14.31818MHz /14, the color encoding is 14.31818MHz/4 and the dot clock is 14.31818MHz/3.5.

Of course, these figures are for NTSC.

I make 14.31818/14 = 1,022,727.14285714 Hz, which divided again by four = 255681.785714285 Hz. So surely neither .75 nor an on-the-dot integer?

It's just a number I'm going to copy into the code so it's not a problem to fix; however I'm more concerned with reducing audio latency right now, which is entirely about failures of authorship rather than failures of knowledge.

(small aside: I added audio to the emulator last night; based on the latest documentation ...

Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.

I found an earlier post on that; it sounded like, depending on your Vic, you'll probably get clipping at the top that clamps to somewhere between the equivalent of all four channels outputting a 1 at volume 7 and at volume 8, and that disabling a channel produces a lower output than an enabled channel that is currently outputting a zero, but not as low as a high output is high? Is there any known quantification on that?

[eslapion]

Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.

I found an earlier post on that; it sounded like, depending on your Vic, you'll probably get clipping at the top that clamps to somewhere between the equivalent of all four channels outputting a 1 at volume 7 and at volume 8, and that disabling a channel produces a lower output than an enabled channel that is currently outputting a zero, but not as low as a high output is high? Is there any known quantification on that?

The volume does not only change the amplitude of the output signal, it also introduces a DC offset.

[Tom]

Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.

I found an earlier post on that; it sounded like, depending on your Vic, you'll probably get clipping at the top that clamps to somewhere between the equivalent of all four channels outputting a 1 at volume 7 and at volume 8, and that disabling a channel produces a lower output than an enabled channel that is currently outputting a zero, but not as low as a high output is high? Is there any known quantification on that?

The volume does not only change the amplitude of the output signal, it also introduces a DC offset.

I'm a long way from getting this stuff correct then. Did I misunderstand that there's a DC offset per enabled channel?

So, my current best understanding is:

Code: Select all

channel_output = 0

for all enabled tone channels
    channel_output += dc offset for zero
    if channel outputting one then channel_output += dc offset for one
end for

channel_output += current output for noise

output = dc offset for volume + volume * channel_output

I'm sure it's not the only potential error in there, but is that channel_output += dc offset for zero correct? Or have I invented it as a misunderstanding of the DC offset simply for setting a volume?

(and my further understanding from previous discussions here is that disabling the noise channel simply freezes it in place; it starts up outputting 1 and therefore when later disabled may end up persistently outputting either a 1 or a 0)

My support for only an unexpanded Vic and reductive implementation of PRGs-as-ROMs is somewhat obscuring my ability to run most demos right now; it sounds likely that if anybody were to write a demo that outputs PCM audio then probably it'd be as simple as disabling all channels and hitting the volume? And if you haven't touched noise yet then your output will be louder; if you have then it may or may not be louder?

[eslapion]

I'm a long way from getting this stuff correct then. Did I misunderstand that there's a DC offset per enabled channel?

...

My support for only an unexpanded Vic and reductive implementation of PRGs-as-ROMs is somewhat obscuring my ability to run most demos right now; it sounds likely that if anybody were to write a demo that outputs PCM audio then probably it'd be as simple as disabling all channels and hitting the volume? And if you haven't touched noise yet then your output will be louder; if you have then it may or may not be louder?

Playing with the volume causes a DC offset shifting. Clipping begins to occur at volume 8 so you can output 4 bit PCM just by sending the data to the volume register.

Added edit: If you don't have a scope but you do have a good multimeter, I suggest you play around with the volume with no sound playing and check the audio out pin of the 6560 and see the voltage changes.

I will try to have scope captures for the audio too.

[Tom]

Attached, since I seem to be talking about it a lot without offering any substance, is the mess I currently have. To reiterate:

• the 6502 should be perfect;
• the 6560 has a bunch of issues;
• the 6522 has about a million issues;
• there is no joystick interface;
• it's NTSC only;
• it also emulates the base machine only, though even then certain aspects of the bus aren't yet exactly on the money;
• PRGs are treated exclusively as ROMs — they can't be loaded into RAM; and
• general structure is to allow for cycle-or-better accuracy but parts misbehaving somewhat undercuts that.

But money where mouth is, I think.

You'll need to find a PRG, any PRG, and File->Open it as I've not created a machine selection menu for File->New yet. A bunch of them don't work properly yet, so I tend to use one of those to get to BASIC.

I'm dithering on the order in which to tackle all of these issues and my limited file format support so it's difficult to say much more than: that I hope to.

[eslapion]

@Tom
About the 6502 and the 6522, you could begin with the VHDL models (freely available) used by Gideon Zweijtzer for the 1541 Ultimate 1/2.

They are not as good as Groepaz would like but they are pretty good.

As for "NTSC only", when I asked MikeJ to make an NTSC version of the PAL VHDL VIC-20 he published, he steadfastly refused. The usual argument is "nobody is going to tell me what to program or not" so... IMHO, return the favor and keep it for our side.

If PRGs are ROM only, this will at least allow the testing of cartridges.

[groepaz]

They are not as good as Groepaz would like but they are pretty good.

for the most part, VHDL isnt very useful when looking for a software solution :=P why not look at VICE?