6560 FPGA Progress.

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

I don't suppose you know if it starts with an upper field or a lower field, or is this going to be another exciting adventure with the 'scope?

[tokra]

I could not remember, so I checked the thread with the answer:

viewtopic.php?f=2&t=10125&start=15#p114048

Essentially try my NTSC-demos to confirm correct behaviour:

https://www.pouet.net/prod.php?which=61101
https://www.pouet.net/prod.php?which=59081

[JonBrawn]

The interlace flag essentially adjust the point at which the vertical counter is reset. If interlace is off it resets somewhere on line 261 to generate 261 lines/'field' and if it is on it resets somewhere on line 262 to generate 262.5 lines/field.
In fact you can trick the NTSC VIC so that the reset is never triggered by turning on interlace, and then turning it off when $9004 reaches 131 (262/2). Then turn interlace back on later. (Similar to opening the borders on a C64.)

this will also generate video output consisting of 512 lines per frame, so it will also confuse most (all?) monitors.

Oof. THAT is going to be really tricky to recreate.

[JonBrawn]

https://www.pouet.net/prod.php?which=61101
https://www.pouet.net/prod.php?which=59081

From where I sit in my cozy study in Austin, TX, both appear to have fallen off the internet - I'm getting "301 Moved Permanently" errors, but there's no forwarding address! Is there another location I can pick them up from, please?

[tokra]

https://www.tokra.de/vic/viccanagain/
https://www.tokra.de/vic/retinacolor/

[groepaz]

this will also generate video output consisting of 512 lines per frame, so it will also confuse most (all?) monitors.

please make a test program for this!

[tokra]

There is a bare-bones test-program by mathop in the original post:

viewtopic.php?f=2&t=10125&start=15#p114218

Just about 30 bytes. I tried this once and believe I got a rolling picture.

[groepaz]

Looks like a said the same before too. Memories...

[Mike]

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?

Not actually, at least not from the visual result, but see below:

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

However, as I have already stated, $9003/$9004 change mid-line most of the time. In non-interlaced mode, you always get whole physical lines, and the horizontal offset between HSync and changes of $9003/$9004 remains the same in interlace mode - please check out "NTSC Interlace Test 7a": viewtopic.php?t=10125&start=10.

The test image does not change the contents between the two types of fields. If you look closely, the green rectangle vertically fits exactly within the black frame. In both fields, it is triggered at exactly the same (double-)raster line value of $9004.

If we refer to $9003/$9004 as raster line count (RLC) in the range 0..261 for non-interlaced display and 0..262 for interlaced display, we get two RLC values for a physical screen line, like thus for the "top" field ("short" RLC 262 has been sensed last time):

Code: Select all

0 ...              ... 0 | 1 ...              ... 1      physical line 0, "top" field

1 ...              ... 1 | 2 ...              ... 2      physical line 1, "top" field

2 ...              ... 2 | 3 ...                         physical line 2, "top" field


                 ... 260 | 261 ...          ... 261      physical line 260, "top" field

261 ...          ... 261 | 262 ...          ... 262      physical line 261, "top" field

262 ...          ... 262                                 physical line 262 (incomplete), "top" field

... and, conversely, this layout for the "bottom" field ("long" RLC 262 has been sensed last time!):

Code: Select all

                           0 ...              ... 0      physical line 0 (incomplete), "bottom" field

0 ...              ... 0 | 1 ...              ... 1      physical line 1, "bottom" field

1 ...              ... 1 | 2 ...                         physical line 2, "bottom" field


                 ... 259 | 260 ...          ... 260      physical line 260, "bottom" field

260 ...          ... 260 | 261 ...          ... 261      physical line 261, "bottom" field

261 ...          ... 261 | 262 ...          ... 262      physical line 262, "bottom" field

You see, the only time where $9003/$9004 change with HSync is, when there is the VSync from bottom to top field.

Now, we combine both fields into one frame - with the given that the same RLC numbers appear left|right and the relative vertical position of fields is honoured as described:

Code: Select all

                           0 ...              ... 0      physical line 0 (incomplete), "bottom" field
0 ...              ... 0 | 1 ...              ... 1      physical line 0, "top" field
0 ...              ... 0 | 1 ...              ... 1      physical line 1, "bottom" field
1 ...              ... 1 | 2 ...              ... 2      physical line 1, "top" field
1 ...              ... 1 | 2 ...              ... 2      physical line 2, "bottom" field
2 ...              ... 2 | 3 ...                         physical line 2, "top" field

                 ... 259 | 260 ...          ... 260      physical line 260, "bottom" field
260 ...          ... 260 | 261 ...          ... 261      physical line 260, "top" field
260 ...          ... 260 | 261 ...          ... 261      physical line 261, "bottom" field
261 ...          ... 261 | 262 ...          ... 262      physical line 261, "top" field
261 ...          ... 261 | 262 ...          ... 262      physical line 262, "bottom" field
262 ...          ... 262                                 physical line 262 (incomplete), "top" field

Even though the top-most, incomplete, line would suggest it is part of the top field (as from the electron beam sweep scheme you described), it is actually the display order of the complete line pairs with identical RLC patterns that defines what is top and bottom.

This was not clear for me at the time I wrote the other test in the linked-to post, "test8a.prg", but in hindsight, the effective field order found by that empiric test and the frame I composited above are consistent.

[JonBrawn]

Even though the top-most, incomplete, line would suggest it is part of the top field (as from the electron beam sweep scheme you described), it is actually the display order of the complete line pairs with identical RLC patterns that defines what is top and bottom.

...and with that definition, it all suddenly makes way more sense.

That, and those diagrams. I feel I can now go ahead and implement interlaced mode in all its madness, thank you!

[JonBrawn]

Today I implemented the game paddle logic. I have failed to implement the extreme and rhythmic jitter of the actual VIC chip, but I have managed to collect some random jitter anyway. With the few experiments I've done, I can clearly see that nobody is going to be turning a VIC-20 into an ohmmeter. I picked some resistors, and connected them to the game port, first the Pot X input, then the Pot Y input, for both a 6560 and my FPGA. The following table shows the rounded average from reading the register 50 times (in BASIC):

Code: Select all

R	VIC X	VIC Y	FPGA X	FPGA Y
0Ω	0	0	0	0
100KΩ	63	77	67	72
150KΩ	94	115	99	107
220KΩ	137	175	147	159
330KΩ	208	250	224	243
470KΩ	255	255	255	255
∞	255	255	255	255

So I'm fairly happy with the values I'm reading, given the difference in values for the X and Y capacitors and the probable difference in threshold voltage between the 6560 and the FPGA board.

I measured the minimum and maximum values read back for a 220K resistor over 1000 samples in all four scenarios - this gives a rough idea of how jittery things are:

Code: Select all

220KΩ Jitter				
	VIC X	VIC Y	FPGA X	FPGA Y
Min	128	152	140	155
Max	154	181	151	162
Range	26	29	10	7

So while what I've got isn't as jittery as the real thing, its definitely got plenty.

Oh, and with the VIC 6560, the values would gradually drift as things warmed up...

[tlr]

A little thought here: As a 6560/6561 replacement you own the generation of the system clock. Wouldn't it be possible to have the system switchable between PAL and NTSC video timing regardless of the system it is in?
Granted it will still modulate the chroma as PAL on a PAL Vic20, but many monitors will accept 60 Hz PAL, and I assume there are NTSC monitors that accept 50 Hz.

I think this would be really cool, allowing either video standard on the same computer.

You'll need to either completely generate the video clock from your 100MHz reference, or depending of FPGA use an internal PLL/DCM/MMCM/etc... to generate it from the external one. Should be doable. Am I missing any other crucial system differences?

EDIT: come to think of it, everything outside the VIC-I to the video connector is just analog, maybe you can even make PAL and NTSC chroma on either machine.

[Mike]

Am I missing any other crucial system differences?

You would still need to switch the KERNAL to accommodate different init values for the VIC registers and different VIA jiffy clock and RS232 timer values. Also, something like PAL60 would create a new platform with no pre-existing software and hardly a crucial advantage over NTSC.

A jumper setting for either 6560 or 6561 operation and getting the original feature set right should cover most use cases. IMO.

[tlr]

Am I missing any other crucial system differences?

You would still need to switch the KERNAL to accommodate different init values for the VIC registers and different VIA jiffy clock and RS232 timer values. Also, something like PAL60 would create a new platform with no pre-existing software and hardly a crucial advantage over NTSC.

A jumper setting for either 6560 or 6561 operation and getting the original feature set right should cover most use cases. IMO.

I was thinking one could actually test NTSC software on a PAL machine (and vice versa), at least for development purposes. I think the PAL Kernal will at least run in an NTSC machine but then with incorrect screen position and interrupt timing. Should a fully compatible configuration be required, a switchable kernal could be added to the machine.

[JonBrawn]

Conceptually I can generate most "reasonable" Frankensteinian video formats with corresponding CPU clocks, or, indeed, other CPU clocks.

There's nothing that strictly says that the CPU clock has to be in lockstep with the video sub-carrier frequency when you're generating them all yourself, so you could create a VIC that runs the CPU faster or slower than normal, however, at higher CPU frequencies there will be access time issues with some of the slower components (yes, MOS Character Generator ROM, I'm talking about you). When you start changing the CPU clock frequency relative to the video clock though there are issues - you can no longer do the just-in-time fetch the character+color info this cycle, fetch the chargen bits the next cycle, and then display it the cycle after that - you're no longer in sync, so you'd have to buffer data - either so you can start fetching early (if your CPU clock is slower than expected) or keep hold of data that was fetched early (because the CPU clock is faster). Doable, but do I want to? I'm not sure if there's a practical application, as every piece of clever software that messes with the VIC registers or memory contents based on where it thinks the raster is at the moment is going to have potential issues. Well, I suppose one advantage would be the bragging rights for owning The Turbo VIC, complete with go-faster stripes, flames painted over the wheel arches, and furry dice hanging on the monitor...