Re: A86: 5MHz
[Prev][Next][Index][Thread]
Re: A86: 5MHz
This somewhat supports the DMA theory however, because (at least some) DMA
can be in cycle steal mode, which means that it executes (as an example) one
instruction and then one DMA cycle. For example, the Z80185 DMA controller
executes 3 regular t-states followed by 6 DMA in cycle steal mode.
----- Original Message -----
From: Aaron Curtis <acurti1@umbc.edu>
To: <assembly-86@lists.ticalc.org>
Sent: Tuesday, December 28, 1999 12:55 PM
Subject: Re: A86: 5MHz
>
> 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: