Subject: Re: vbl handler in grfabs_cc.c
To: None <email@example.com, firstname.lastname@example.org>
From: Olaf Seibert <email@example.com>
Date: 03/15/1994 17:16:04
First: I should learn to keep my big mouth shut when I only *think*
I know about something.
I have never examined complete graphics.library disassemblies; just one
of exec, and copperlists. It was just that I recalled a news item
from around the introduction of 1.2 that related about this clever
copper trick Commodore had thought of.
firstname.lastname@example.org (Chris Hopps) wrote:
> > This improvement, first incorporated in KS 1.2 made the display much
> > more stable in event of crashes and such.
> Hmm I guess I don't understand what it has to do with crashes but I
> don't/didn't plan on having the kernel crash too often.
I was a bit vague here: I meant crashes of AmigaOS. 1.2 was lots better
than 1.1. The old way, if vbl interrupt vectors were trashed then the
display became unusable. Not that I ran 1.1 longer than I had to, of
course... (aside: this ddb thing is interesting. I met its prompt
yesterday when I did a swapinfo and /vmunix was not the currently
running kernel. I should have tried it a bit more before having it
> > And, given the fact that the NTSC/PAL test up to 1.3 gave the wrong result
> > at least 1/50 of the time, this may possibly explain the display glitches
> > I sometimes get at the bottom of my screen - they are suspiciously
> > near the NTSC/PAL or the line 511/line 512 demarcation.
> Dunno about this. But its not becuase of the above. All copper list
> in the kernel wait at *least* until vp > 12 so strobing before then is
> not a problem and as you can see from above thats the only time I
> strobe. Have I overlooked something?
The problem for NTSC/PAL tests was that for PAL the vertical counter
can overflow the 1-byte register. For NTSC the maximum value is 262
I think and they cheat a bit to keep it at 255 max. (somehing like not
counting all the lines in the blanking range) For PAL the maximum
value is about 312 I think, and the counter simply wraps around to 0.
There must be a way to detect this, but as I said my HRM is at home.
Somehow the PAL/NTSC test takes advantage of this difference.
Anyway, I can show you a program that opens a screen (under 1.3) that
is really 256 lines tall but only shows the top 213 lines. So apparently
this PAL stuff is hard to get right ;-) They fixed it in 3.0 - but that
one seems to have other problems.
> > -Olaf.
___ Olaf 'Rhialto' Seibert D787B44DFC896063 4CBB95A5BD1DAA96
\X/ There are no lemurs in this post email@example.com