6560 FPGA Progress.

[JonBrawn]

VIC-I sound is kind of fiddly, especially the noise channel. Nippur72 did some previous FPGA work on this referenced somewhere here: thread. I seem to remember that there was still some discrepancies to be resolved, but I'm not certain.

I've started with the code from the VICE emulator, as that contains a definition of the noise generator, and if you poke it enough with a stick, it does run freely, producing sort of random length pulses. I have the feeling that I'm going to have to use my logic analyzer to sample a long sequence of randomness and then see if I can spot the repeat length and correlate the sequence against that produced by the VICE code (and the FPGA). I'm sceptical about the 6560 noise LFSR being 16 bits, as implemented in VICE, which seems excessive for a noise generator from the 1970s that is contemporary to the three other voices of the VIC I, which are not particularly sophisticated in their default output. I would have expected ten or perhaps twelve bits.

Edit: I've looked at the thread about viewing the die pictures, in particular the section on the sound, and yeah - 16 bits it is.

One problem I have is I got the DAC implementation for the audio on my current interface board wrong - it references the 3v3 line rather than the 5v line, so instead of having the dynamic range of 0V to 4.5V with a DC offset of 2.5V, I've got a range of 0V to 3V with a DC bias of 1.5V, which is quite a bit lower. My next interface board will fix this, but it's yet another IC to add to the board. In the meantime, I'll have to turn up the volume on the telly.

[JonBrawn]

Now I've got to go back through everything and make sure it all still works

I've scanned through all this thread and found some things I need to check:

• mathop posted about turning interlace off at RASTER[8:1] == 131 and then back on to obtain a 512-line field (which will freak out your monitor). I need to confirm (or otherwise) that the FPGA does the same thing. I can think of nothing useful you can do with this, but that means somebody more imaginative than I will.
• Mike posted about the screen jumping up one raster line if you move the left margin right past the centre of the screen. I can use this to confirm that my positioning of the raster break at column 32 is at the correct column 32.
  In the same post, Mike mused about the consequences of this property on the lightpen.
• tlr told me about the lightpen.prg program that mapped the value reported for each possible lightpen trigger position. I'll run this and compare results, but I'll also do empirical lightpen experiments because, well, playing with a lightpen might be fun.
• Mike indicated that changes to the colour registers being observed one dot clock late and changes to the reverse bit being observed three dot clocks late. I have no idea what I can do with this information. Mike - any idea how I'd craft a test scenario to observe this?
• tokra said I should run all the vic* programs in the Sourceforge VICE repository.
• beamrider upset me terribly by posting about whacky happenings when you move the text area off the edges of the screen. I don't know if I want to implement this, as the effect seems to be produced by what, to me, seems to be broken-but-not-too-badly-broken logic in the 6560.
• Mike informed me of what happens to the raster count on certain transitions into and out of interlace mode. I believe I've already captured all of this, but I've got to check because if you don't test it, it's broken.
• tlr forewarned me of the terror that is Impossiblator 3.

[tlr]

VIC-I sound is kind of fiddly, especially the noise channel. Nippur72 did some previous FPGA work on this referenced somewhere here: thread. I seem to remember that there was still some discrepancies to be resolved, but I'm not certain.

I've started with the code from the VICE emulator, as that contains a definition of the noise generator, and if you poke it enough with a stick, it does run freely, producing sort of random length pulses. I have the feeling that I'm going to have to use my logic analyzer to sample a long sequence of randomness and then see if I can spot the repeat length and correlate the sequence against that produced by the VICE code (and the FPGA). I'm sceptical about the 6560 noise LFSR being 16 bits, as implemented in VICE, which seems excessive for a noise generator from the 1970s that is contemporary to the three other voices of the VIC I, which are not particularly sophisticated in their default output. I would have expected ten or perhaps twelve bits.

The noise generator implementation in vice (assuming you're checking a recent source) is based on that work by Nippur72. The critical finding is that there is in fact the same looped back 8 bit shift register in the noise channel in the same way it is implemented on the other three oscillator channels, and that this SR is clocked by the output of the LFSR.

This "explains" the weird behaviour where you suddenly get lasting timbre changes on the noise channel. Presumably a residual pattern will stick in the looped back SR, analogous to the so called Viznut waveforms obtainable on the oscillator channels. Using this behaviour in a controlled manner on the noise channel doesn't seem to have an easy solution though.

[JonBrawn]

VIC-I sound is kind of fiddly, especially the noise channel.

With the reservation that my DAC has the wrong reference voltage (3.3 instead of 5), I believe I've got the sound working identically to how it works in VICE xvic. And yes, that noise LFSR + SR combination is fiddly to get spot-on right indeed - but it is very easy to hear when you haven't. Getting the four bitstreams out of the shift registers is only half the story, though - there's the gain and DC offset to consider. I spent plenty of time with 'scope and notebook working out what really happens and then abstracting that to something that "would be good enough", in my case ", multiply by 1.53125 and add 130", which makes for some interesting logic. This gives the same "clip the signal very aggressively and distort like heck" behaviour as the real thing.

However, what did fall out of the equations is that if I move the DC offset 'Add' from being the very last step to before the gain multiplier (suitably scaled), then I end up with values in the range of 15 to 255, which conveniently map onto the 8-bit DAC I'm using, so I've implemented a secret mechanism that allows you to poke a magic sequence into the VIC registers to flip it into secret "do not clip" mode, which is retained until you power cycle the VIC or you write another magic sequence to the registers. This setting will survive a reset.

[tlr]

With the reservation that my DAC has the wrong reference voltage (3.3 instead of 5), I believe I've got the sound working identically to how it works in VICE xvic.

That sounds good. What I hinted in my earlier post is that in the thread linked Nippur72 seems to still see some discrepancies to HW after a while. I'm not sure that has been fully explained and solved. If not, the vice code should have the same issues.

You should compare the behaviour with actual hardware. I'm thinking here about the anomaly when the timbre changes some times. This happens in many songs, but it's not entierly obvious what triggers it.

You could try these for testing: datapop or perhaps VIC20-AR89-1.prg.
The latter is probably a cleaner display of the timbre change but it wasn't tested on NTSC. It should work, but the display might be messed up.

[JonBrawn]

beamrider upset me terribly by posting about whacky happenings when you move the text area off the edges of the screen. I don't know if I want to implement this, as the effect seems to be produced by what, to me, seems to be broken-but-not-too-badly-broken logic in the 6560.

I was at the Central Texas Commodore User's Group meeting on Sunday. I think we found a game that relies on specific behaviour when you scroll the display up off the top of the screen, and the FPGA and the 6560 do different things.

[Mike]

I was at the Central Texas Commodore User's Group meeting on Sunday. I think we found a game that relies on specific behaviour when you scroll the display up off the top of the screen, and the FPGA and the 6560 do different things.

Would you care to disclose the game's name, so people can take a look at it and possibly infer which VIC registers are involved in the trickery?

• Mike indicated that changes to the colour registers being observed one dot clock late and changes to the reverse bit being observed three dot clocks late. I have no idea what I can do with this information. Mike - any idea how I'd craft a test scenario to observe this?

The delay of 1 hires pixel for colour register changes with respect to half-character boundaries can be observed in test7a.prg. The partial black frame is crafted so the 16 pixels width of the green rectangle are supposed to fit exactly within that frame.

Actually, the screenshot indicates the displacement may not be a full hires pixel, tokra and I suspect an analogue effect inside the VIC-I here.

For the 3 hires pixels delay of the invert bit in $900F, I should be able to produce a similar test program with an appropiately moved test frame (two extra pixels to the right) within the next days. Stay tuned.

[JonBrawn]

I was at the Central Texas Commodore User's Group meeting on Sunday. I think we found a game that relies on specific behaviour when you scroll the display up off the top of the screen, and the FPGA and the 6560 do different things.

Would you care to disclose the game's name, so people can take a look at it and possibly infer which VIC registers are involved in the trickery?

That's what you get for editing your posts. I did originally put in that it was Video Vermin, a cartridge game, but I appear to have then edited that out again. Ho hum. Let's just put that down to British eccentricity, shall we? Sounds so much better than "the man's a damn fool". Anyway, when you've managed to die often enough, and the game ends, the picture scrolls up off the top of the screen, smoothly. On the FPGA, it scrolls smoothly, but there's a burst of random character data displayed as a brief flash as it scrolls. I'll try to get a screen capture of that tomorrow. Or maybe Thursday.

• Mike indicated that changes to the colour registers being observed one dot clock late and changes to the reverse bit being observed three dot clocks late. I have no idea what I can do with this information. Mike - any idea how I'd craft a test scenario to observe this?

The delay of 1 hires pixel for colour register changes with respect to half-character boundaries can be observed in test7a.prg. The partial black frame is crafted so the 16 pixels width of the green rectangle are supposed to fit exactly within that frame.

Actually, the screenshot indicates the displacement may not be a full hires pixel, tokra and I suspect an analogue effect inside the VIC-I here.

Now THAT I definitely recognize. With a minor amount of twiddling, I've got a green rectangle that perfectly fills the black corner borders. I could get it to be too far to the left, too far to the right or slap bang on target, but what I couldn't do is get it just a smidge off, as the real VIC 1 does. I'll go along with it being an analogue effect, as I'd have to resort to using the 28.6262MHz clock (XOR of what would be the 14.318181MHz clocks if I were able to use them) to shuffle the rectangle out of place by that small amount.

For the 3 hires pixels delay of the invert bit in $900F, I should be able to produce a similar test program with an appropriately moved test frame (two extra pixels to the right) within the next days. Stay tuned.

Looking forward to that - It'll be interesting to see what the current FPGA code makes of it.

While we're waiting for Mike's code, anybody that is a fan of his FLI graphics images (what does that stand for, by the way? And Flinale?) might want to pull HTTP://www.brawn.org/VIC-20/fli.zip. You'll need to add 'boot' and a modified version of 'view' from a flinale_ntsc archive (the modification involves changing the names in the DATA statement to match the names of the files you've got on the disk image). If you're making .d64 images or real floppies, you'll only be able to put five images per disk. If you've got a PI1541 (and if not, why not?), then you can bung the whole lot in the 1541 directory, add a couple of extra DATA lines to the view program and sit back and watch the whole lot in one sitting. The demonic zombie hellhound with the empty eye sockets is called Sheena, and she has large black patches around her eyes. Not particularly conducive to this process, I'm afraid, but I thought I'd include it so you can use it to scare your children. She is way cuter in real life. Oh, and I'm a direct descendent of one of the pictured people - I can't imagine it'll be too hard to work out which one.

[Mike]

(what does [FLI] stand for, by the way? And Flinale?)

FLI stands for Flexible Line Interpretation, meaning the attribute data being used by the video chip is not fixed for whole (text) lines, but is redefined more often.

On the VIC-20, the VIC-I chip re-reads the colour RAM anyway on each raster, the 'software' FLI modes change the colour RAM contents on-the-fly, the 'hardware' VFLI mode uses extra address lines going to the 16Kx4 SRAM to change the colour RAM bank on each raster, which allows for more horizontal resolution - 208 vs 104 pixels on PAL - and more remaining CPU time for the user program while the picture is on display, ~20% vs 0% (yes, zero %) on PAL.

On the C64 and C128, VIC-II normally caches the attribute data for a whole text line, but can be forced to re-read the attribute data each raster by appropriate writes to $D011. Otherwise the workings and uses are quite similar to the VIC-20 FLI modes.

...

"FLInale" obviously is a pun on both "FLI" and "finale".

[Mike]

Stay tuned.

Here we go: https://dateipfa.de/.Public/denial/tools/test11.zip

[JonBrawn]

Every picture tells a story...

This is a genuine 6560:

test11_6560.png (42.08 KiB) Viewed 1127 times

This is my FPGA:

test11_fpga.png (76.16 KiB) Viewed 1127 times

I'll have to tinker with things a bit.

[JonBrawn]

Video Vermin

Here are links to two short clips from video vermin, a cartridge game.

The first shows the "end of life" scrolling on a 6560, the second on the FPGA:

HTTP://www.brawn.org/VIC-20/video_vermin_6560.mov
HTTP://www.brawn.org/VIC-20/video_vermin_fpga.mov

and a somewhat worse example - scroll all the way through to see noisy random stuff mid-scroll:

HTTP://www.brawn.org/VIC-20/video_vermin_fpga_2.mov

You should load each into a video editor that allows frame-by-frame scrubbing. Look at the bottom of the frame at the very start of the scroll, and you'll see random mush from the FPGA but not from the 6560.

[JonBrawn]

YouTub video tour of the first prototype board
https://www.youtube.com/watch?v=3AXc7ECx_70

[JonBrawn]

This is a genuine 6560:
test11_6560.png

Weird. On a TV, the 6560 appears "correct", but when captured by my $19 Composite video capture thing, it comes out like that, which is odd.

Anyway, I claim my prize:

However, I'm a bit mystified about why the values I've used work. The value in question is "Delay tap 11". That means I've delayed the visibility of the reverse bit (and just the reverse bit) by twelve ticks of the fast clock (taps 0 to 11). The fast clock is the clock you get when you notionally XOR the two 14.318181 MHz clock phases together - it zips along at 28.636363 MHz and is used so that the dot clock comes out as a whole multiple, seven cycles of the fast clock. The 14.318181 MHz clock isn't good enough for this purpose, as the dot clock would have to be 3.5 cycles... but I digress. So, the reverse bit is delayed by 12 of these fast_clk cycles. A pixel, as mentioned, is seven fast_clk cycles. A single cycle of the CPU clocks is 28 fast_clk cycles. 12 fast_clk cycles aren't anything that I can think of as being relevant.

[JonBrawn]

I'm still working on this - I'm pulling together a new interface board for a different FPGA (one that money CAN buy), and once I've got that up and running, I'll need to get some child labour in to play games and spot things that aren't right.