On video timings and interlace

[BigEd]

Nearby, Neil wrote

barnacle wrote:

As an aside, I know of _no_ personal computer from the seventies or eighties that generated 'correct' video: all of them (with the possible exception of very high-end video cards designed for broadcast TV) did away with the half-line at the end of each field which causes the interlace to happen for two very practical reasons: (a) text looks better without it flickering up and down and (b) it's easier, i.e. cheaper. So the field timing was _always_ wrong.

And many (most?) computers of the time were built down to a price and so used the cheapest crystal available as the master clock; often that would be the colour subcarrier frequency (3.57... or 4.43...MHz) and those crystals used frequencies deliberately chosen to have _no_ common harmonics with the line or sync frequency. So in many cases the line timing would be out as well.

As a counterpoint, I think Acorn's BBC Micro can do interlaced timing, and usually does, except of course games can and will do their own thing. I gather Acorn's Electron always uses interlace.

[barnacle]

Probably because the BBC micro was designed from the start to be used in live TV (it was a BBC spec for an educational computer) and the 6845 was always capable of interlaced output. I remember installing expensive boards to allow it to be genlocked to a broadcast reference so it could feed a video mixer directly, in time with all the other video sources.

Neil

[BigEd]

Indeed! (Sorry, didn't mean to be confrontational, just thought a new thread might be best)

[barnacle]

Oh, no worries. My point was just that although there are firm and fixed standards for video signals of pretty much all flavours, the displays themselves are built with Cs and Rs in 10% tolerances in the timing circuit, and long experience suggests an analogue display will work with a wide range of 'wrong' signals; and apparently so will at least _some_ digital displays.

Neil

[BigEd]

And I very much agree that video timings for various home micros are usually a bit off-standard!

[barrym95838]

I'm not an expert on the subject, but I read somewhere that Woz had to do a "stretched clock" trick for every scan line to get the Apple ]['s discrete TTL circuit output close enough to the NTSC standard to get a reliable display on CRTs. He also saved a few gates by interleaving the mapping of the display lines and translated the addresses in the firmware. It caused a cool "venetian blind" effect when loading hi-res screens from tape or disk but was a bit of a challenge for assembly language game coders.

In the Commodore 64, there were these things called "bad lines", but I never dug into the details.

I admired Atari's ANTIC chip but never got any hands-on experience with it.

Over here on the left coast in the 1980s, the BBC micro was nearly unheard of, but looking back now it was an impressive little machine that would have fit in just fine with us nerds.

[teamtempest]

Quote:

n the Commodore 64, there were these things called "bad lines"

<nerdmode>

Those were caused by the VIC-II video chip shutting down the 6510 CPU for 40 cycles at the start of every eighth scan line so it could fetch the indices of the next 40 8x8 characters it needed to display on the next text line.

If the display mode was not a text mode and instead a bitmap one, there were no bad lines to worry about.

Which is why it was sometimes advocated to turn off the display altogether when some software that needed finicky timing was running.

If you realized that you had to use text mode but the bad lines only happened 25 times while the video beam was on the visible screen, you could ignore any chance of them happening when the beam was off the visible screen.

</nerdmode>

[J64C]

barrym95838 wrote:

In the Commodore 64, there were these things called "bad lines", but I never dug into the details.

Nah, ‘bad lines’ on the C64 were purely due to the video chip to update colour information for the next 8 lines. It would halt the CPU for 40 cycles and use that additional time to retrieve colour information from RAM.

They got the name ‘bad line’ because the programmer had less time to play with on those raster lines.

[BigEd]

Acorn’s Electron also has to stop the cpu in some circumstances in order to keep video going.

For me it’s a reasonable design compromise. You can get a long way in system design by considering memory bandwidth supply versus demand

[fachat]

J64C wrote:

barrym95838 wrote:

In the Commodore 64, there were these things called "bad lines", but I never dug into the details.

Nah, ‘bad lines’ on the C64 were purely due to the video chip to update colour information for the next 8 lines. It would halt the CPU for 40 cycles and use that additional time to retrieve colour information from RAM.

They got the name ‘bad line’ because the programmer had less time to play with on those raster lines.

Actually, they were used for colour Informationen only in hires mode.

In character mode the VIC-II uses bad lines to fetch character index values for the next 8 raster lines that make up a character line.

See here for the details https://www.cebix.net/VIC-Article.txt

The effect was the same: less time for the programmer to work on game logic or other effects during those lines.

The bad lines are also the cause why the VIC20 disk drive 1540 is a tad bit faster than the C64 disk drive 1541 despite the same hardware: because bad lines disturbed the already slow serial IEC bus of the 1540, they had to make it even a bit slower, so bad lines wouldn't break it.

André

[enso1]

BigEd, I find it hilarious that you consider saying that BBC computers generate correct video signals -- is somehow confrontational!

Unless you have a constant anxiety that you may offend someone, in which case, it may not be funny at all. I certainly do not mean to make fun of mental anguish!

MIke, on the subject of Apple video: I thought that the strange arrangement of mappings of video lines to memory had more to do with being able to refresh DRAM (hitting all the rows at the right time during video output) than anything else, although I may be wrong.

[barnacle]

The joke is that I was a BBC broadcast engineer for over thirty years...

Neil

[BigDumbDinosaur]

barnacle wrote:

The joke is that I was a BBC broadcast engineer for over thirty years...

I periodically watch the BBC newscast that airs in our area (45 miles southwest of Chicago).  Been doing so since the mid-1990s, so I may have been watching while you were working.    Funny how much of what the BBC talking heads talk about seems to be focused on two individuals, neither of whom lives in the UK or is British.  I, of course, am referring to the duchess of Sussex and the president of the United States. 

[barrym95838]

I think those old DRAMs needed to be refreshed at 30Hz, so Woz was hitting all of them with a comfortable margin, regardless of mapping.

[enso1]

Mike, are you sure? My memory is a 2ms refresh requirement, so evenly spaced 128 rows call for 15 uS or so? I will have to look at the specs...

But I am probably wrong about the video layout. According to some rando on stackexchange,

Quote:

The refresh mechanism is entirely unrelated to the non-linear layout of the video system data; it would work just as well if the layout were linear. The non-linear scanning of video memory does save some circuitry in the address generation of the video system itself, however, so Woz took advantage of the fact that the the refresh system doesn't care in what order the addresses are accessed, so long as they are all accessed within a given amount of time.

... which sounds like the layout does have something to do with refresh after all.

I would have connected the RAM in such a way that scanning video you would hit every one of 128 rows, so I would be surprized why Woz would not...