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

Ehy, don't worry about it the only reason I was in rom was to try and
figure out the A2024 code. :^)  There system is more elegent than mine
but it is designed with multiple (possitionable) coppper lists.  If
your interested just get an interrupt lister and then a monitor and
disassem the handler...

> 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

Oh I see.

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

I think your talking about the copperlist terminating to early?  If so
all my lists end with

	CWAIT(255, 255);
	CWAIT(255, 255);

Which handles the extra lines I belive.  If not I am all ears.  I
learned amiga HW programming when starting to work on NEtBSD so its
very possible I have overlooked certain "undocumented" features of
the HW :^)

> -Olaf.

Chris.

------------------------------------------------------------------------------