Timothy Miller wrote:
On 7/20/06, James Richard Tyrer <[EMAIL PROTECTED]> wrote:
The only issue is that you don't want refresh of memory to conflict with
refresh of the screen.
I see what you're saying. Let's see. Worst case, refresh will take:
read2precharge + precharge2refresh + refresh2activate + activate2read,
which is something like 5 + 3 + 14 + 3 = 25.
Can we stand to have 25 cycles inserted randomly into video? What is
the typical length of tie between a video request and when the data is
needed? (i.e. how many scanlines per second are most video modes?)
Yes we can. The question is whether it will complicate things
significantly. IIUC, a refresh cycle is:
Forcing idle by blocking new memory requests.
Simultanious precharge of the four banks.
Invalidating the four row registers.
Refresh.
Then you will probably have four row misses sometime.
With evenly distributed refresh, these occur each refresh. I think that
this would total more than 25 clocks. With refresh on sync (actually it
would be a modified sync signal shifted slightly forward in time)
everything except the refresh would occur only once per scan line
(actually with 480i, it would occur slightly more than once per scan
line -- when the refresh post counter gets to 7, refresh needs to be
forced).
Scan frequency is 15,750 Hz for 480i. Everything else is faster with
the possible exception of legacy modes. High resolution is going to get
down to 1 to 2 refreshes per scan line or less.
The logic cost of generating and using the refresh enable appears to be
small. It is turned on when the last pixel of the scan line is loaded
into the FIFO and turned off a fixed number of clocks before the end of
horizontal sync (to allow for the start of fetching the pixels for the
next line).
--
JRT
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
