Re: Information on the //e VBL

["Ole Voss" <ole.voss@netrogue.de>]

To be honest, I would have to check my //c reference manual and see if I can
still find the manual that came with the mouse card (it's gotta be here
somewhere)...


"Jon Co" <jon@i-manila.com> schrieb im Newsbeitrag
a2c2f792.0303182236.42bc6580@posting.google.com">news:a2c2f792.0303182236.42bc6580@posting.google.com...
> I got a follow up to this.  I just installed a //e mouse card in slot
> 4.  Would it now be possible for my //e to generate vbl interrupts the
> way the //c does?  what software uses this on the //c so i can verify
> its functionality on my //e + mousecard.
> "Ole Voss" <ole.voss@netrogue.de> wrote in message
news:<b583g8$27ffop$1@ID-118921.news.dfncis.de>...
> > I just thought this subject should get a thread on its own, seeing that
the
> > Contiki thread is getting difficult to read ;-)
> >
> > Well, back in the old days I used the VBL quite extensively to get my
> > scrolling routines smooth. This did, ofcourse, make them extremely
slow -
> > but they were elegant all the same. The programming is quite easy:
> > $C019 holds the VBL bit (bit 7) When this is low (<128) the Vertical
Blank
> > is active (beam blacker than black returning to home position top-left).
As
> > soon as the VBL goes high, the screen is being drawn. The problem with
using
> > this as a technique for timing is obvious. First, you never know where
the
> > actual VBL is taking place. That is, it could be anywhere within its
blank
> > period (I don't recall how long that is - but maybe somebody would like
to
> > look that up) or anywhere within its normal 'drawing' period. Back then
I
> > used to poll the VBL and wait for a definite change between high and
low.
> > Only after the change had occurred, would I actually change screen data.
> > Ofcourse this meant that I would often skip an entire cycle.
> >
> > Will this help anybody?
> >
> >
> > Cheers,
> >
> > Ole.