Path: utzoo!utgpu!attcan!uunet!cs.utexas.edu!rutgers!ucsd!ogccse!orstcs!jacobs.CS.ORST.EDU!throoph
From: throoph@jacobs.CS.ORST.EDU (Henry Throop)
Newsgroups: comp.sys.apple
Subject: Re: Problems for a new IIGS owner (II)
Message-ID: <13895@orstcs.CS.ORST.EDU>
Date: 20 Nov 89 07:08:12 GMT
References: <1137@godot.radonc.unc.edu> <5659@wpi.wpi.edu> <5256@sdcc6.ucsd.edu>
Sender: usenet@orstcs.CS.ORST.EDU
Reply-To: throoph@jacobs.CS.ORST.EDU.UUCP (Henry Throop)
Organization: Oregon State University - CS - Corvallis Oregon
Lines: 45

In article <5256@sdcc6.ucsd.edu> pa1017@sdcc13.ucsd.edu (Nick Lenz) writes:
[...]
<theoretically you could implement something like overscan video
<given enough speed. Sure, you'd spend a LOT of processor time
<keeping track of the softswitches at $C02E AND $C02F. Right now it
<is possible to check the softswitch at $C02E to find out (within 2
<scan lines) which line of the screen is being updated and modify the
<text, border or background colors as you wish thus creating a type
<of overscan video (at least vertically). My guess is that, given a
<sufficiently fast GS you can also keep track of the horizontal
<counter at $C02F and also know exactly which scanline is being
<redrawn (one of the bits of the vertical location is stored in $C02E
<so that's why you can get within two line accuracy using $C02E).
<Using this info you could (theoretically, of course) get overscan
<video using the 16 colors available for text, border and background.
<Anyways, my point in this lengthy (and first) posting to the net is
<to say that it would be possible to do overscan if you could read
<the aforementioned softswitches with time to act on what is in them
<before they change again. Processor-intensive? Yes, but neato-keen,
<too.
<
<Nick Lenz               "How would you feel about life if Death was

Rather than watching $c02e and $c02f, it should be faster (but harder to 
program) to just count the cycles, maybe with scan-line interrupts turned
on every couple of lines so that other interrupts don't get the timing too
badly off.  One hitch is that the border color is in the low nibble of $c022;
I don't think it's a real good idea to mess around with the clock register in
the upper nibble (but maybe it's ok).  For just incrementing one nibble it takes
around 25 cycles, which means that you can only change the border color once
or possibly twice over the length on the side of the screen.  If you don't need
to worry about the clock register, it only takes a few cycles to change the 
border color.

Someone mentioned that 'drawing' on the border was done in the ACS demo, which
I haven't seen - has that been posted, or could someone mail it to me?

Henry




---
Henry Throop
Internet: throoph@jacobs.cs.orst.edu