FPGA 6561 - PAL Questions

[tokra]

Tokra, Mike - if I added Interlace to the PAL FPGA, do you think you'd be able to put together a demo that shows it off?

Hehe, "able to" - yes, probably. Should not be much different than NTSC. However I am not really interested in doing so
Effectively this would only work on your FPGA VIC and no other system. Also: Interlace itself is hard to display with all the new flatscreens and HDMI-connections. Best case scenario the display-device automatically weaves the interlaced lines to a full frame without flicker.

So my opinion on this: If the original chip supports it, the FPGA should too. Everything else is feature creep and will likely result in the project not coming to fruition at all.

[groepaz]

I think it would be fun to have it available, assuming it doesn't break anything.

If i learned one thing in 25+ years of fiddling with emulation, it is: if it doesnt work 100% exactly like the real thing, it *will* break something. And yes, that includes everything "irrelevant" or "unused"

[JonBrawn]

if it doesn't work 100% exactly like the real thing, it *will* break something. And yes, that includes everything "irrelevant" or "unused"

That's a fair point, definitely. There are a couple of features that I'd like to add - one is having several palettes available, and another is fixing the horrible audio clipping. I think I've got a way of "unlocking" these features that will make it less likely that they get triggered accidentally, but of course you can never guarantee that some funky demo isn't going to write unexpected stuff to unexpected locations. I'm monitoring the two lightpen locations and the two paddle locations, these are read-only values in the 6560/1. If 'VIC' gets written to the first three then the last location is unlocked and palette and clipping options can be set. Writing anything else to those locations locks the register. Values set will be preserved across reset and run-stop/restore, but not across power cycling.

[groepaz]

of course you can never guarantee that some funky demo isn't going to write unexpected stuff to unexpected locations

Very often its not those "funky demos" - but old games. The Demos mostly are coded very clean and made by people who knew exactly what they are doing - other than the games, which were often made by people who were just learning the system and didnt have good documentation.

That said, for the chameleon we used a 3-register chain for unlocking extra stuff:

- first register disables the extra stuff (any value written)
- second register enables the extra stuff, when a magic value is written
- third register disables the extra stuff (any value written)

that way a loop that just writes too far is very unlikely to trigger the activation

[JonBrawn]

I'm struggling to count scan lines. Does a PAL VIC-20 have 312 or 313 rasters per field? Or is it something more interesting than that?

[mathop]

PAL VIC-20 is 312 lines

[Dr.OG]

Hi!

I own a German VC-20 assembled with VIC 6561-101, 0184. I also have a Medusa (retro scandoubler): http://medusa-sc.org/index.php?title=Main_Page

It measures the VIC's video signal to be slightly non-standard, as seen on the attachment (HFREQ: 15.609kHz, VFREQ: 50.1Hz) Calculated line number (HFREQ/VFREQ) is 311.56 lines/field.

[Mike]

(HFREQ: 15.609kHz, VFREQ: 50.1Hz) Calculated line number (HFREQ/VFREQ) is 311.56 lines/field.

The display of VFREQ only shows 3 significant digits, its true value could be anything between 50.05 Hz and 50.15 Hz. Similar thoughts apply to HFREQ. Assuming both displays are calibrated (which they likely are not!), you arrive at the following possible 'range' for the lines/field:

Code: Select all

minimum: 15608.5 lines/s / 50.1500 fields/s = 311.24 lines/field
maximum: 15609.5 lines/s / 50.0500 fields/s = 311.88 lines/field

... with the true value of 312 lines/field just being outside that interval.

Anyway, as the PAL VIC-I only outputs non-interlace, this has to be a whole number of lines, and those 312 lines/field have been confirmed long ago by other means than a quasi-analogue measurement of two frequencies, both of which are subject to calibration errors.

Incidentally, pixel rate and colour carrier frequency are the same on the PAL VIC-I, 4.43361875 MHz. One line has 71 CPU cycles, one CPU cycle corresponds to 4 pixels, which gives 284 pixels/line (total, i.e. including Hsync signal, colour burst, black porches, and anything visible), so these values below are what is to be expected:

Code: Select all

4433618.75 pixels/s / 284 pixels/line = 15611.33 lines/s (HSync rate)
15611.33 lines/s / 312 lines/field = 50.04 fields/s (VSync rate)

[Dr.OG]

I understand what you mean, but that's the difference between theory and practice.
Can anyone else measure the actual parameters of the VIC20's video output?
Using an OSSC perhaps? I know that during measure calibration and rounding errors may occure of course.
I'm really curious, as different VIC chips may produce different values (f.e. there exists an earlier 6561E version of VIC).
Besides, as I see, every VICs are different, and during aging these differences may increase.
But calculated values are non-precisely standard as well, although the difference is minimal (15611.33 lines/s should be 15625, and 50.04 Hz should be 50.00 in according to PAL standard).

[Mike]

I understand what you mean, but that's the difference between theory and practice.

First of all, you took the displayed digits for an exact value, which they are not. They reflect a rounded measuring result, where the actual analogue value (ideally!) lies within an interval +/- 0.5 of the last digit. Then, simple rules of statistical math (error propagation, etc.) tell you, that one cannot give more significant digits in the result than what was given by the input data.

I'm really curious, as different VIC chips may produce different values (f.e. there exists an earlier 6561E version of VIC).

No. 6561E and 6561-101 have the same timings. If it were otherwise, that would have shown up long ago already with all the existing code that relies on cycle exact behaviour.

Besides, as I see, every VICs are different, and during aging these differences may increase.

The only thing relevant here would be the aging of the quartz oscillator, which might shift the master clock by a few Hz.

But everything else, especially "cycles per line", and "lines per field", is derived from the master clock by digital counters. These will not out of a sudden produce non-integer intervals. If they actually do that, the chip is defective.

[JonBrawn]

The timing of the VIC 6560 and 6561 are locked to the incoming crystal oscillator frequency.

The relationship between VSYNC frequency, HSYNC frequency, lines-per-field, HSYNC pulse width, dot clock frequency, and indeed absolutely every piece of timing related to the video (and audio!) comes from the incoming clock.

What DOES vary is the incoming crystal oscillator frequency, both because of variation in the crystal frequencies from crystal to crystal and because you can "pull" that frequency using the little trimmer capacitor next to the crystal. If you take a plastic or ceramic screwdriver and tweak that trimmer backwards and forwards, you can observe perturbations in the displayed colours.

The other thing that varies - greatly - is the analogue components of the signal:

The levels presented at the luma output pin of each VIC chip may be different for a particular brightness, so if you were to swap from one VIC to another VIC on the same display, then you may see a slight difference in brightness.
The chroma amplitude can vary, so colour saturation from one VIC to another may be different.
The chroma angle that governs the hue observed for a particular colour can also vary (e.g. 'cyan' can vary from very green to very blue).