Clock Signal: a Vic-20 emulator for macOS and Linux
Moderator: Moderators
Re: A heavyweight Vic-20 emulator with twists
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?)
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?)
-
- 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
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.eslapion wrote:Anything else you'd like to see ?
-
- 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
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.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?)
- 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
Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.Tom wrote:(small aside: I added audio to the emulator last night; based on the latest documentation ...
Be normal.
- 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
What numbers exactly would you have liked to see?Tom wrote:Did you get any sort of digital read-out other than the graphic?
That should be 14 318 180 / (14 * 4) =255682 Hz(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...
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.
Re: A heavyweight Vic-20 emulator with twists
I guess it would now be more appropriate to follow up on that elsewhere...eslapion wrote:What numbers exactly would you have liked to see?Tom wrote:Did you get any sort of digital read-out other than the graphic?
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?eslapion wrote:That should be 14 318 180 / (14 * 4) =255682 Hz(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...
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.
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.
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 wrote:Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.Tom wrote:(small aside: I added audio to the emulator last night; based on the latest documentation ...
- 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
The volume does not only change the amplitude of the output signal, it also introduces a DC offset.Tom wrote: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 wrote:Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.
Be normal.
Re: A heavyweight Vic-20 emulator with twists
I'm a long way from getting this stuff correct then. Did I misunderstand that there's a DC offset per enabled channel?eslapion wrote:The volume does not only change the amplitude of the output signal, it also introduces a DC offset.Tom wrote: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 wrote:Me and v1and3 noticed an asymmetric waveform clipping starting to occur when the volume is above 8.
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
(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
- 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
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.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?
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.
Re: A heavyweight Vic-20 emulator with twists
Attached, since I seem to be talking about it a lot without offering any substance, is the mess I currently have. To reiterate:
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.
- 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.
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 268 times
- 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
@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.
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.
Re: A heavyweight Vic-20 emulator with twists
for the most part, VHDL isnt very useful when looking for a software solution :=P why not look at VICE?They are not as good as Groepaz would like but they are pretty good.
I'm just a Software Guy who has no Idea how the Hardware works. Don't listen to me.
Re: A heavyweight Vic-20 emulator with twists
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:
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: ... and here's one I blew up to full screen: 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.
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*.
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: ... and here's one I blew up to full screen: 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.
Re: A heavyweight Vic-20 emulator with twists
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.
Re: A heavyweight Vic-20 emulator with twists
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.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
(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.)