[Coco] real-time mouse cursor

[Bob Devries]

Roger,
Steve Bjork wrote a series of articles and source code for a graphics
mouse in the Rainbow way back. I can't quite remember the issues... I
don't have them handy, and they were for the Coco1/2 (though it did
work on the 3), but I wonder if these would be a good reference work?

On Jan 26, 2008 6:11 PM, Roger Taylor <operator at coco3.com> wrote:

> At 11:03 PM 1/25/2008, you wrote:

>

>

> >The number of CPU cycles per H-scanline will depend on the size of

> >the screen. The vertical blanking pulse may change size depending on

> >the screen size as might the horizontal pulse. Determining the exact

> >values for 320x200 (if that is the size you are using) probably can

> >be done experimentally with a program. If not, a high quality

> >oscilloscope will be required.

> >

> >There is some data in the MESS source code and Sockmaster probably

> >knows some of this information.

>

>

> Ah... I found an e-mail from Sock to me back from Aug 2001 stating

> that you get 114 cycles per scanline.  Anytime he was explaining

> something technical about video tricks I tried to hang on to those.

>

>  From just rough figuring I think my total cycles for saving the

> background and plotting the cursor, but not erasing yet, is Way under

> 144 cycles x 19 sprite lines.

>

> If the GIME VBORD signal happens at the bottom border, it means I'm

> drawing my cursor on time for the raster beam to wrap around but I'm

> erasing too quick which can be seen by inserting intentional delay

> loops right after the drawing code.  This has a bad effect of slowing

> down the program since it's happening inside of a FIRQ, but the

> slower the delay the more visible the cursor is over Y more raster lines.

>

> Now I'm actually seeing a working cursor for the top 25% of the

> screen but FIRQ is taking up way too many total cycles because of the

> delay I had to insert between the draw and erase code.

>

> I need to figure out a way to do this without using a delay between

> the drawing code and restoring code.  This will depend on if VBORD

> happens at the bottom or top border.  My initial scanline count (set

> by IRQ) needs to be pretty close to where VBORD is actually happening

> and also considering how long it takes my code to get to the point

> just before it starts drawing the cursor.  I'm sure this will require

> some major experimenting to track the raster beam like that, but I'm

> sure it can be done if my starting scanline is tweaked to account for

> a bottom-of-screen VBORD signal.  I need to fine tune it to where the

> cursor is fully drawn at least when the raster beam is halfway behind

> the code in raster lines, so a minimal amount of cycles are wasted

> before the erasing starts (which is a QUICK job).  If I slow down the

> erasing code so it doesn't pass up the raster beam, I should be able

> to get this to work.

>

> Perhaps the first ever CoCo mouse cursor of this sort?  Seeing it

> work for 25% of the screen is pretty amazing when the background is

> changing right underneath it with no corruption.

>

>

>

> --

> Coco mailing list

> Coco at maltedmedia.com

> http://five.pairlist.net/mailman/listinfo/coco

>




-- 
Regards, Bob Devries, Dalby, Queensland, Australia

Isaiah 50:4 The sovereign Lord has given me
the capacity to be his spokesman,
so that I know how to help the weary.

website: http://www.home.gil.com.au/~bdevasl
my blog: http://bdevries.invigorated.org/