6560 FPGA Progress.

[Mike]

[...] 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 [...]

It should go without saying that changing the operating frequency of nearly all "VIC side" mainboard components outside their specified limits will mess up things, big time. CBM surely entertained similar thoughts at that time with the 6562, and ultimately they ended up with the C64.

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...

You might spare a look at the 65F02.

...

That being said, the VIC-I is about the only irreplaceable component in the VIC-20. Having a FPGA version of it opens a way to repair otherwise unrepairable VIC-20 units. This is especially important as the VIC-20 is the only computer that used the 6560/61 as video chip. The only remaining source are NOS chips, sometimes with questionable origin (if they've been taken from other VIC-20 units we'd be none the wiser).

[tlr]

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

Sure, but I was not thinking of any franken-timings. Only selectable standard NTSC or standard PAL regardless of the machine the chip is in. Possibly with franken-chroma carrier for convenience.

This will require you to generate the reference clock rather than rely on the external oscillator on the motherboard.

[JonBrawn]

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

Sure, but I was not thinking of any franken-timings. Only selectable standard NTSC or standard PAL regardless of the machine the chip is in. Possibly with franken-chroma carrier for convenience.

PAL-60 seems fairly Franken to me!

The goal is to produce an FPGA board that supports both 6560 NTSC @ 60Hz and 6561 PAL @ 50Hz, selected either by a jumper or by cunning skullduggery. If you select PAL, you'll always get PAL @ 50Hz with the PAL color subcarrier frequency, line rate, and frame rate. Likewise for NTSC. The electronics on the mainboard remain unaltered (unless you alter them for an S-video hack or something).

[groepaz]

That will not work - The videotiming is tied to the timing of the machine. (Unless you want to implement a framebuffer in the FPGA and output video async)

[tlr]

That will not work - The videotiming is tied to the timing of the machine. (Unless you want to implement a framebuffer in the FPGA and output video async)

Good point. I was thinking getting at least some color on my PAL composite monitor with NTSC timing. It supports the timing but not the NTSC chroma. I assume that is common.

EDIT: or did you mean cpu clock vs dotclock? That is under the control of the VIC-I.

[groepaz]

I mean cpu clock (NTSC) vs cpu clock (PAL)

[tlr]

I mean cpu clock (NTSC) vs cpu clock (PAL)

Ah, ok. Both could be arbitrarily generated by a custom 6560/6561, regardless if the VIC-20 board is PAL or NTSC.

[JonBrawn]

Do we know if, when interlace is turned off, raster 0 is 32 or 33 cycles in length? Likewise, I assume raster 261 is also reported as being short and must be 65 - the length of raster 0.

Have any of you taken a look at line 9 when the interlace bit is turned on?

[Mike]

Do we know if, when interlace is turned off, raster 0 is 32 or 33 cycles in length? [...]

To re-quote from this post, viewtopic.php?t=10396&start=26:

• 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.

Once again, this is merely what shows up in $9003/$04 - VIC-I outputs complete physical lines and the pattern occurs because $9003/$04 are incremented mid-line (except on VSync, where the change from line number 261 to 0 happens on HSync).

Have any of you taken a look at line 9 when the interlace bit is turned on?

Not specifically, as tokra and I did not expect any surprises there. What makes you suspect something is special about line 9?

[JonBrawn]

Have any of you taken a look at line 9 when the interlace bit is turned on?

Not specifically, as tokra and I did not expect any surprises there. What makes you suspect something is special about line 9?

In the "real" world, when interlace is turned on, line 9 is the line that is the first scan line after the VSYNC sequence, so it is the line that is short for an even field and normal for an odd field, in much the same way line 262 is short for an odd field and normal for an even field, so I was wondering what happens in the {$9004[7:0],$9003[7]} value around there. In VICE the answer is "nothing", so I'm investigating on a real VIC, to ensure "nothing" is the right answer.

[Mike]

I'm investigating on a real VIC, to ensure "nothing" is the right answer.

If it helps you, the file interlace_2021-08-16.zip (also referenced in this post in the other thread "NTSC interlace detail info needed") contains test programs that do a roll call of all cycles per raster line, for no-lace, lace-top and lace-bottom.

Line 9 shows no irregularity. The value is there in $9003/$04 for 65 cycles, just like with the other non-0, non-end-of-field raster line numbers. This has been confirmed on real hardware (tokra's NTSC VIC-20).

[groepaz]

MMMh but didnt "we" verify the tests match real VIC and VICE?

[JonBrawn]

Line 9 shows no irregularity. The value is there in $9003/$04 for 65 cycles, just like with the other non-0, non-end-of-field raster line numbers. This has been confirmed on real hardware (tokra's NTSC VIC-20).

...and I can independently confirm this. This makes things quite tedious - I'm going to have to have a 'this is the scanline we are really on' value and a 'this is some made-up number that bears no resemblance to reality, but let's call it "raster".'

[Mike]

'this is some made-up number that bears no resemblance to reality, but let's call it "raster".'

The value in $9003/$04 is about as real as it gets.

This morning (local time), I messaged tokra about a possibly visible consequence of that "mid line changing" behaviour of $9003/$04: if one moves the left edge of the display window to the right, over the middle of the screen (preferably keeping the right edge of the window at its original position), the Y comparator should detect the equality of the vertical start position one physical raster line earlier.

Surely enough, tokra could confirm that suspected behaviour: if you do POKE36864,29:POKE36866,138 (or 36866,10 for +8K RAM expansion or more), the display window jumps one raster upwards!

The easiest explanation is, VIC keeps a separate X counter which governs certain actions (HSync, left and right edge of display window), and the value in $9003/$04 also is incremented or reset at various horizontal positions, depending on operation mode. That should also have consequences what is latched in the lightpen registers.

[mathop]

...
if you do POKE36864,29:POKE36866,138 (or 36866,10 for +8K RAM expansion or more), the display window jumps one raster upwards!
...

That would make sense, the vertical counter is increased when X=1 on PAL, and on NTSC it's at X=29.
The same effect can be observed on PAL, where if you do POKE36864,0 the display scrolls down one line.
I think this is actually broken in VICE; in NTSC mode the display scrolls up when you go from 0 to 1, where it should scroll up if you go from 28 to 29.