6560 FPGA Progress.

[JonBrawn]

I've now got all the video functionality except interlace implemented, and I've been flipping through a bunch of cartridge games to check that the right thing is happening, and so far, in the main, it is - except for a game called Polaris. Polaris, I'm guessing, is trying to sync to a specific raster value in {$9004[7:0], $9003[7]}. With a real VIC chip, the transition from the upper portion of the screen to the lower is perfect - however, the transition with my FPGA has some tearing about halfway across the line. I'm increasing the raster count at the very start of the horizontal sync sequence, right after the end of the previous line's video. Would any of you know anything about where the real VIC would be incrementing the raster count?

[tlr]

I wrote some test programs when tweaking the vice implementation, here: https://sourceforge.net/p/vice-emu/code ... lit-tests/
Try timing. It tries to sample those registers for every cycle and allow you to save the result as a file.

Note though that I have very limited experience with the NTSC VIC and I remember that there were some issue with the raster stabilization code that needed to be specifically tweaked. Hopefully timing_ntsc.prg works correctly.

There may be other useful tests here if you haven't looked yet: https://sourceforge.net/p/vice-emu/code ... ogs/VIC20/

[Mike]

I'm increasing the raster count at the very start of the horizontal sync sequence, right after the end of the previous line's video.

That would be correct for the PAL VIC-I.

Would any of you know anything about where the real VIC would be incrementing the raster count?

The NTSC VIC-I for some obscure reason increases $9003/$9004 at a mid-line horizontal position.

You should check against my B & W display routine. It splits the colour registers several times on each raster to provide an exterior border colour that is independent to VIC-I's use of the same colour register as source for multicolour %01 within the display frame (in the example, the border is yellow, in the display frame that colour source is changed to be black).

The left and right position of the change is timed to single cycle accuracy, however, the pixel serializer delays changes of the colour registers by one hires pixel (and, BTW, changes of the invert bit in $900F are delayed by 3 hires pixels).

[JonBrawn]

The NTSC VIC-I for some obscure reason increases $9003/$9004 at a mid-line horizontal position.

If I were a gambling man, I'd say that obscure reason probably has something to do with interlace, as that adds half-lines to each field (at the bottom of the odd fields, at the top of the even fields), so it might make sense to increment the raster counter at that point.

If I ever regain the programmability of my FPGA board, I'll re-implement the raster counter at the same time that I implement interlace. (My micro-USB connector fell off).

[JonBrawn]

I wrote some test programs when tweaking the vice implementation, here: https://sourceforge.net/p/vice-emu/code ... lit-tests/

I shall form a raiding party immediately - thanks for this. This is just the sort of help I'm looking for, and is greatly appreciated.

[Mike]

Interleaving GND wires in-between those signals on the ribbon cable works wonders.

I know! I'm wondering about those fancy-dancy 80 conductor IDE cables - [...]

It is possibly sufficient to provide current returns just for those high frequency signals you mentioned (i.e. the two oscillator inputs, luma, chroma), which would add (... checking the pinout ...) about 6 extra wires. And, at both ends of the ribbon cable, an adapter socket with a ground plane that extends to the extra ground wires, roughly like this:



... with the ribbon cable then carrying Pins 40, 39A, 39, 38A, 38, 37A, 1, 1A, 2, 2A, 3, 3A and then 37, 4, 36, 5, 35, 6, ..., 22, 19, 21, 20.

You might consider adding an extra SMD decoupling capacitor between ground plane and pin 40 in that socket where the VIC chip (or its FPGA stand-in) resides.


P.S. EEVblog - About ribbon cables at fairly high frequencies is also worth checking out.

[JonBrawn]

It is possibly sufficient to provide current returns just for those high frequency signals you mentioned (i.e. the two oscillator inputs, luma, chroma), which would add (... checking the pinout ...) about 6 extra wires. And, at both ends of the ribbon cable, an adapter socket with a ground plane that extends to the extra ground wires, roughly like this:

Good idea. Sounds like a job for a 50-pin IDC connector then. And yet another < 10cm cable. And a redesign of both the adapter board and the interface board. Good job I need to do the interface board anyway.

[JonBrawn]

You should check against my B & W display routine.

I've just tried this on VICE 3.6.1 in NTSC mode with 8K expansion enabled, and I'm not certain that it is working as intended.

First, you get the Red Lady:

You then get a yellow border with the lady with blue-ish cheeks:

And then two or three seconds later, you get a yellow border with the lady but with more purple cheeks:

And two or three seconds later, it flips back to blue-ish cheeks, and it keeps flipping back and forth between the two images every two or three seconds.

Is this what I'm supposed to see, or has VICE messed up?

[Mike]

I've just tried this on VICE 3.6.1 in NTSC mode with 8K expansion enabled, and I'm not certain that it is working as intended.

Indeed it is not.

These two "colour schemes" are supposed to alternate each frame. If, for some reason, only every second frame is rendered, VICE only shows one of the colour schemes, and perhaps changes to the other one should a frame be dropped once and again.

Of course this behaviour of your setup then results into an unintended time-aliasing artifact of the worst sort, but then this display mode is a nightmare for any frame rate converter anyway.

[JonBrawn]

If I use the "advance frame" feature I can see the colors flipping from one frame to the next (probably one field to the next I suspect), so if my Mac could keep up then it might do the right thing.

Anyway, now it's time for your software, a real 6560, my FPGA, and an oscilloscope to have a party together. I hope there'll be cake and ice cream...

[JonBrawn]

It turns out that the VIC-20 Interlace mode is more... unusual... than I was expecting.

What I was expecting is the same total number of lines per frame, but the odd fields ending in a half-line and so being one half-line longer, and the even fields starting with a half-line and being one half-line shorter.

The total number of lines per frame is correct. However, the lines per field are not as expected.

To illustrate this heinous allegation, here are two diagrams created from samples from my 'scope:

By convention, the field that starts with a full line is called the 'odd' field, and the other is the 'even' field. Here we see the non-interlaced video, in purple, lined up with the interlaced video, in green, showing the end of an even field, followed by the start of an odd field

If we now fast-forward to the end of the odd field, we can see the half-line at the end of the odd field and the half-line at the start of the even field:

However, an extra video line has also been tagged onto the odd field and taken from the even field. The effect of this is to shift the vertical sync to be one-and-a-half lines later (normally, one would expect it to be only a half line later). Conversely, the gap from THIS vertical sync to the next one will be one-and-a-half lines earlier (normally only a half line earlier).

This has implications for anybody that has written code that counts rasters - is this what you've observed?

[Mike]

This has implications for anybody that has written code that counts rasters - is this what you've observed?

Yes.

With the NTSC non-interlaced display, VIC-I outputs 261 lines. With the interlaced display, it outputs two different types of field with 262.5 lines each. The first 261 lines of the field that is layered "above" the other correspond to the non-interlaced output.

Put the other way round - interlace has "top" and "bottom" fields, non-interlace only shows the "top" field. The terminology used here avoids naming the fields "even" or "odd" on purpose, because that terminology does not help determining which one of the fields is layered above the other when the same contents are on screen for both types of fields.

While the non-interlaced mode physically outputs 261 full lines, what appears in $9003/$9004 is different - as I wrote earlier, the change of these two registers almost always happens mid-line horizontally, not during HSync - sole exception being a concurrent VSync, which incurs a reset of line number 261 or 262 to 0 exactly during HSync. To quote from NTSC interlace detail info needed:

• Non-interlaced fields start with a partial raster 0 ($9003 = $2E, $9004 = $00) of 32 cycles. Rasters 1 ($9003 = $AE, $9004 = $00) up to 260 ($9003 = $2E, $9004 = $82) are complete with 65 cycles each. The fields end with a partial raster 261 ($9003 = $AE, $9004 = $82) of 33 cycles.

Conversely, interlaced displays give these values in $9003/$9004:

• Type 1 starts with a partial raster 0 ($9003 = $2E, $9004 = $00) of 32 cycles. Rasters 1 ($9003 = $AE, $9004 = $00) up to 262 ($9003 = $2E, $9004 = $83) are complete with 65 cycles each.
• Type 2 starts with a complete raster 0 ($9003 = $2E, $9004 = $00) up to complete raster 261 ($9003 = $AE, $9004 = $82) with 65 cycles each. It ends with a partial raster 262 ($9003 = $2E, $9004 = $83) of 33 cycles.

By sensing the length of the last line in interlace mode (i.e. how long $9004 appears to have that raster line value), it is possible to discern the field type and put different contents for each field type on screen, which is what you need to double the vertical screen resolution. Later in the thread, we identified "Type 1" (with a "long" line 262) as being the "top" field, and "Type 2" (with a "short" line 262) as being the "bottom" field. That means, if you sense a short line 262, what gets displayed next is the top field.


Note - my B & W display routine does something akin to the VIC-I hardware interlace, but does not actually use that feature. It simply cannot, because it is supposed to work also on PAL displays.

[tokra]

It also has to be noted that it is of importance which field is displayed when switching from non-interlace to interlace-mode. My first programs that made use of NTSC-interlace from ca. 2012 depend on that behaviour, because back then I falsely assumed that line 262 is only available in one of the two interlaced fields and my routine is waiting for that line. While it works consistently we found out much later that this is only because when switching from non-interlace to interlace it always starts with the same field. So, any FPGA would have to copy that behaviour as well.

[JonBrawn]

It also has to be noted that it is of importance which field is displayed when switching from non-interlace to interlace-mode. So, any FPGA would have to copy that behaviour as well.

Yuk. Duly noted! Thanks!

[JonBrawn]

It turns out that the VIC-20 Interlace mode is more... unusual... than I was expecting.
blah... blah... blah... one field has more lines than the other blah... blah... blah...
This has implications for anybody that has written code that counts rasters - is this what you've observed?

Yeah, so the bit about different length fields for upper and lower is, as Mike has said, without actually calling me an idiot, a load of old tosh. Having taken a more careful study, I can confirm he is dead right - the two fields are the same length, and each field is one-and-a-half lines longer than the corresponding field would be in a non-interlaced display. Thanks, Mike, for continuing to explain to me until I understood; much appreciated.

I think what the NTSC spec describes as an "odd" field (the one that starts with a whole line), y'all would know as a "lower" field. If you think of the electron beam in a CRT going from left to right and top to bottom, if the travel from top to bottom is at a constant speed, then the scanline being drawn will be on a slight downward incline, going from left to right, so if you are going to introduce the second half of a scanline somewhere near the top of the display, then it only makes sense if it is above the right-hand side of the top scanline of the previous field. (this is how it is depicted in diagrams I've seen of interlaced composite video).

I then wrote:

So, based on this, can you confirm that the short line at the top of the screen is the first line of the "upper" field?

However, since then I've found:

Result: The top field follows a short line 262 (C=0), the bottom field follows a long line 262 (C=1)!

This agrees with my speculation.