[Coco] real-time mouse cursor
devries.bob at gmail.com
Sat Jan 26 08:45:59 EST 2008
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
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.
my blog: http://bdevries.invigorated.org/
More information about the Coco