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

Re: A heavyweight Vic-20 emulator with twists

Post by 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
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 »

eslapion wrote: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
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 »

Tom wrote: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.
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:(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.
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 »

Tom wrote: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.
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:
Tom wrote: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...
eslapion wrote:
(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.
eslapion wrote:
Tom wrote:(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?
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: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.
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:
Tom wrote:
eslapion wrote: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?
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: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.
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 »

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.
Attachments
Clock Signal 16-06-2016.zip
(1.79 MiB) Downloaded 239 times
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
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.
Be normal.
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 »

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?
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 »

Underlying reasoning? I'm writing an emulator because writing emulators is fun. I want to be explicit about this: I have no delusions. There is no objective need for a new emulator. Probably almost nobody will ever use my emulator. VICE is a very good emulator. People should use VICE.

However, mine will be distinguishable because: I hate manual configuration, I hate applications that don't adopt the host OS's normal user interface patterns, I want to spend that CPU and GPU power in a semi-modern computer to produce a more authentic emulation. That's how I've arrived at:
  • standard document-model application architecture. Run as many simultaneous emulations as you like. Size, place, scale, however you like;
  • the machine produces a genuine composite video stream that is decoded by the emulated CRT. So all artefacts are inherently correct;
  • ditto audio is generated at the machine clock rate and filtered. VICE does this too, it appears, albeit via a different mathematical approach*.
(* mine's a windowing FIR; theirs looks like a spring-model IIR based on my superficial parsing but I don't claim to speak for them — short version is that mine's more expensive but via the SIMD unit it's not as intractable as it might feel)

My 6502's already almost certainly already perfect; it passes AllSuiteA, Klaus Dormann's tests and Wolfgang Lorenz's tests, and runs the other two emulated machines without noticeable issue. In addition mine is genuinely cycle accurate, making the exactly correct memory access every single cycle — all of them, every single one — and interleaving with the 6560 exactly like the real hardware.

The VICE 6560 is instructive but doesn't directly adapt because of the philosophical difference in what must be produced. For the benefit of fairness, VICE's currently manages the timing and behaviour a lot better than mine does. But it should be an easy fix.

(a side effect of the difference: I have no RGB or otherwise 3d colour palette. None. Anywhere.)

The 6522 could be directly lifted but for code style differences. And that doing so wouldn't be fun. Also I don't think it's all that complicated, but again to be explicit: it's not all that complicated because a lot of people much smarter than I have produced a lot of excellent documentation, because host processing power is in such abundance that I don't even have to write my code all that well, and because the trivial support for unit testing and the rest means that I don't even have to do all that much to verify it. The various communities for machines with 6522s have discovered all the edge cases and documented them thoroughly. I don't need to find the title that doesn't work, figure out what it's doing, figure out what it thinks the result should be, figure out why my code doesn't produce that result. I just need to read the documentation that says "this deprotection scheme works only because the 6522 will read $FFFF if read exactly N cycles after writing at Q"**, write a unit test for that, move on with my life.

(** a trivial example, which even the data sheet hits by quoting a 1.5-cycle reload time for repeating timers, but you get the idea)

EDIT: there's some sort of nasty CRT bug still lurking, clearly; it's to do with the sync marks passed to the GPU sometimes causing a misalignment between its reading of data and that from which the CPU reconstructed the raster timing, but occurs only under heavy load. To the extent that I hadn't even seen it prior to this morning. That being said, the best policy always being warts-and-all, here's 21 Vics more or less running at once:
Multi.png
... and here's one I blew up to full screen:
Single.png
There's phosphor persistence that means that is not a field grab as you'd normally get from an emulator. Also it's a poor example of the artefacts that a real composite stream brings because a white background has no chroma, so there are no chroma phase transitions in this image. But nevertheless zoom in to see some banding within the characters (the asterisks show it reasonably well) and note that the gradient to the left of a row is pixels is different from that to the right, and that its specific colouring depends on the exact horizontal position of the text (close together, compare the V to the 2).

I am at work so shall not be downloading any commercial PRGs. Running my own little project at all for five minutes is already a stretch but it's a distraction that's helping me to think.

EDIT2: actually, looking at my own screenshot even more closely, "blah 2 copy 15.png" shows a machine that appears momentarily to have lost horizontal synchronisation as you can see the flywheel catching back on with stereotypical sinusoidal. The frames shown aren't the full NTSC frame, they're a crop to around 90% of the centre. But, ummm, whatever the problem is, it might be worse than I think. Hmmm.
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 »

btw, i'd be happy to assist in supporting your emulator in the automatic testsuite that i am working on at the moment (mostly for VICE)... (its fairly easy, only needs a couple simple features in the emu) - let me know if you are interested :)
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:btw, i'd be happy to assist in supporting your emulator in the automatic testsuite that i am working on at the moment (mostly for VICE)... (its fairly easy, only needs a couple simple features in the emu) - let me know if you are interested :)
Yes please! I love test suites. Now that the machine is booting and playing such games as don't require a joystick, whichever thing I end up improving next, the plan was primarily to unit test the heck out of it.

(unless it was getting RAM-based PRGs working, for which my strategy is simply to observe that they overlap the RAM region, kick back the task of installing them until after the machine has booted, then issue a ghostwritten RUN at the prompt, for which I can probably rely on purely manual testing — but that'll be the difference between being able to run everything from Pouet and being able to run nothing from Pouet, so should be worth it)

(EDIT: while typing extemporaneously on this, I suspect I'm not going to support multi-part PRGs. It's too much of a problem with the modern mainstream operating systems, both of which are moving towards the model of sandboxing applications and letting them see on the file system only those things the user has positively indicated that they should be able to. So dragging and dropping title-XXXX.prg does not give you the ability to see that there's also a title-YYYY.prg if you're trying to be a good citizen such that users can be confident that you're not malware. Though I may have to consider the ramifications of this further. Is there a well-accepted storage container for multi-section ROMs? I'm guessing that at least some have anti-piracy measures such that putting them into a D64 or whatever and hence loading them to RAM is explicitly not meant to work.)
Post Reply