On Monday, August 29, 2016 at 9:19:40 AM UTC+10, Norman Davie wrote:

My plan was to do all the drawing on the "hidden" graphics page, then do the page flip when I detect we're in the vertical blank. I don't think there is sufficent cycles to draw anything significant during the VB period.

I know this conversation was while back now, but thought I'd jump in. When I was young back in the 80's I had an Apple //c (came with the mouse card or similar). I remember experimenting with the VBI back then and managed to get a mouse pointer the
size of the original Mac arrow pointer (copied from studying magazines at the time) to move when I moved the mouse on a hi-res screen.
It was super cool to have this code "running in the background". I couldn't get anything more than a around 2 bytes x 14 pixels (or so). My ASM wasn't the most efficient though, so I'm sure guys here could get a bit more out of it. I do remember using
lookup tables to draw to the screen though. Wish we had access to the internet back then. I had to rely on the odd magazine like Softtalk to help me out....

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, March 16, 2023 at 3:35:50 AM UTC-7, Dave Kay wrote:

I know this conversation was while back now, but thought I'd jump in. When I was young back in the 80's I had an Apple //c (came with the mouse card or similar). I remember experimenting with the VBI back then and managed to get a mouse pointer the

size of the original Mac arrow pointer (copied from studying magazines at the time) to move when I moved the mouse on a hi-res screen.

Nice!

It was super cool to have this code "running in the background".

Yup, one can do all sorts of neat stuff if/when you have a proper Vertical Blanking Interrupt.

I couldn't get anything more than a around 2 bytes x 14 pixels (or so). My ASM wasn't the most efficient though, so I'm sure guys here could get a bit more out of it. I do remember using lookup tables to draw to the screen though. Wish we had access to

the internet back then. I had to rely on the odd magazine like Softtalk to help me out....

Fantavision also has a 10x14 px mouse cursor. I should RE/rip that mouse display graphics code someday ...

Michael.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I know this conversation was while back now, but thought I'd jump in. When I was young back in the 80's I had an Apple //c (came with the mouse card or similar). I remember experimenting with the VBI back then and managed to get a mouse pointer the

size of the original Mac arrow pointer (copied from studying magazines at the time) to move when I moved the mouse on a hi-res screen.

Nice!

It was super cool to have this code "running in the background".

Yup, one can do all sorts of neat stuff if/when you have a proper Vertical Blanking Interrupt.

I couldn't get anything more than a around 2 bytes x 14 pixels (or so). My ASM wasn't the most efficient though, so I'm sure guys here could get a bit more out of it. I do remember using lookup tables to draw to the screen though. Wish we had access

to the internet back then. I had to rely on the odd magazine like Softtalk to help me out....

Fantavision also has a 10x14 px mouse cursor. I should RE/rip that mouse display graphics code someday ...

I use the 4-byte wide color cursor in dbl-hi-res mode. it's big but it gets the job done.

For example :

$2000 : BD BD BD BD BD BD BD BD BD BD BD BD BD BD BD BD
$2010 : BD BD BD BD BD BD BD BD BD BD BD BD BD BD BD BD

Waiting Routine :

TOP_SCREEN LDA $C070
CMP $#BD
BNE TOOP_SCREEN

You need several pattern because the LDA / CMP /BNE takes few cycles and you can miss the BD. With sevral ones, you will catch it without any doubt.

I still have questions regarding the sync bytes and vbl.
Does this work on both hi-res screens?

And on a IIe with the $C019 soft switch, Instead of racing the beam (or staying ahead of the refresh), isn't it better to start drawing when the beam is finished refreshing and is at the bottom of the screen, about to go up, and start drawing to the
screen then. Doesn't this do the same thing but offers a little more time to draw to the screen before the screen gets updated on the next time around? This surely would allow the computer instructions to stay ahead of the next refresh cycle.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Does this work on both hi-res screens?

For HGR2, change the $2000 addresses to $4000 addresses and BIT $C055 before the wait routine.

And on a IIe with the $C019 soft switch, Instead of racing the beam (or staying ahead of the refresh), isn't it better to start drawing when the
beam is finished refreshing and is at the bottom of the screen, about to
go
up, and start drawing to the screen then. Doesn't this do the same thing
but offers a little more time to draw to the screen before the screen gets updated on the next time around?

Timing is everything and is fraught with peril.

http://www.deater.net/weave/vmwprod/megademo/cycle_switching.html

https://rich12345.tripod.com/aiivideo/softalk.html

https://web.archive.org/web/20150706084550/http://hoop-la.ca/apple2/2015/winterwarmup/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)