[Coco] real-time mouse cursor

[Roger Taylor]

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.