Re: A86: 5MHz


[Prev][Next][Index][Thread]

Re: A86: 5MHz




I've seen that as well.  That kind of flicker on certain scanlines.  Like
when you would move a sprite past a certain line it just dissapears.  It
only happens on really fast code like you said, and never seems to affect
anything important.

> While writing a mouse routine for several different programs, I found that
> certain places in the screen would not always refresh at the right time,
so that
> the mouse would virtually disappear until you stopped moving it. I tried
it with
> several sprite routines, all with the same result.
> An example:
> KeyLoop:
>  ;clear the sprite
>  ;check a bunch of keys (ports)
>  ;draw the sprite
>  ;save coords
>  jr KeyLoop
> The key checking was quite extensive, but the routine seemed to be
extremely
> fast. If i put a crapload of halts in the loop, then the mouse
disappearace went
> away.
>
> Dont know if this has any relevance, but I thought I would share it in
case it
> does.
>
> Later,
> Chicane
> Aaron Curtis wrote:
>
> > I'm not going to claim to know anything about hardware, but I'm pretty
> > sure the CPU doesn't pause during a screen refresh.  A while back I
> > tried some code that was set up like this:
> >
> > loop:
> >         ;draw a sprite
> >         ;halt
> >         ;erase it
> >         ;minor amounts of code...
> >         jr loop
> >
> > If the sprite was near the top of the screen, you could see it; if it
> > was near the bottom, you couldn't.  The screen update occurs when the
> > halt is broken by an interrupt, I think we can agree on that...  So what
> > I figure was going on, was that the top of the screen was refreshed
> > while the sprite was still in video mem, but the bottom was done after
> > the sprite was erased.
> >
> > David Phillips wrote:
> > >
> > > My guess is that the answer to your question, and the solution to
Kirk's
> > > "problem", would be that the calc uses the chip that generates
interrupts to
> > > do the screen refreshes.  Even if interrupts are disabled, the chip
still
> > > runs at the same frequency, which is why the screen still works.  This
is
> > > supported by the fact that when you change the interrupt rate, the
screen
> > > gets distorted.  It probably uses DMA to transfer the data, which is
why the
> > > screen must start on an 256 byte boundary.  Since the memory is not
dual
> > > port, meaning only one thing can access it at a time, the CPU is
paused
> > > during the DMA transfer.
>
>
>



References: