[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/