🚀 go-pugleaf

In article <2048@watdcsu.UUCP> dmcanzi@watdcsu.UUCP (David Canzi) writes:
>To refresh a 640 by 400 bit screen 70 times per second from memory 16
>bits wide requires reading memory 1.12 million times per second.  It
>takes 4 clock cycles (minimum) for the processor to read a word from
>memory.  I would assume the same applies to the screen logic, *plus*
>the time it takes to get control of the bus before reading, and
>relinquish it after reading.  With an 8 megahertz clock, the screen
>must be slowing down the processor by at least a factor of 2.
>
>Or have I made a mistaken assumption somewhere?
>
>David Canzi

Yes.  Although it takes 4 clocks for the processor to read a word from
memory, that doesn't mean it takes 4+4=8 clocks for both the processor
and the video display circuitry to get a word from memory.  If memory
is fast enough, it is possible to run the processor at ALMOST full
speed and insert video display cycles in between processor cycles.

A rough (from memory) diagram of a 68000 memory access:

(ns)	0	       125	       250	       375	       500
(clock)	|	1	|	2	|	3	|	4	|
	|		|		|		|		|
	| setup address	| start memory	| wait for mem	| deassert address
	| and control	| cycle		| acknowledge	| and control	|
	| signals	|		|		| signals	|

The 68000 only needs access to the RAMS during clocks 2 and 3 (as I have
indicated them above).  If hardware was clever enough, and memory
fast enough, you could sneak in a video fetch during cycles 4 and 1.

This is exactly what the ST, Macintosh and Amiga do.  They all have fast
memory (250 ns -- ST, 280ns Amiga, ?? Mac) and stick a video (or whatever)
cycle in there with the processor access.

Why did I say "ALMOST full speed"?  The 68000 is an asynchronous part
(that is to say, its not synchronized with the bus), but the scheme
I presented above IS synchronous!  The arbitration circuitry inserts
wait states until the processor gets synchronized to the bus.  So long as
the 68000 executes instructions which take a multiple of 4 clocks, it will
stay synchronized.  Unfortunately there are a few instructions which
take 2 (mod 4) clocks, and which cause the hardware to insert wait states
(effectively throwing away 2 clocks).

Jan Gray		Looking Glass Software		(519) 884-7473

> To refresh a 640 by 400 bit screen 70 times per second from memory 16
> bits wide requires reading memory 1.12 million times per second.

Yes, and that is merely 892 ns cycle time.  The memory according to BYTE
is 125 ns cycle time.  Plenty of spare time.  Controller chips and other
interesting things keep the CPU from occupying the memory for more than
one cycle.


Daryl Monge
AT&T
Bell Labs, Naperville, Ill

...!ihnp4!ihelp!dlm

In article <2048@watdcsu.UUCP> dmcanzi@watdcsu.UUCP (David Canzi) writes:
>To refresh a 640 by 400 bit screen 70 times per second from memory 16
>bits wide requires reading memory 1.12 million times per second.  It
>takes 4 clock cycles (minimum) for the processor to read a word from
>memory.  I would assume the same applies to the screen logic, *plus*
>the time it takes to get control of the bus before reading, and
>relinquish it after reading.  With an 8 megahertz clock, the screen
>must be slowing down the processor by at least a factor of 2.

What's wrong with duel ported memory?

		Curt Jutzi
		tektronix!pogo!jutz

In article <2048@watdcsu.UUCP> dmcanzi@watdcsu.UUCP (David Canzi) writes:
>To refresh a 640 by 400 bit screen 70 times per second from memory 16
>bits wide requires reading memory 1.12 million times per second. 
>It takes 4 clock cycles (minimum) for the processor to read a word from
>memory.
>With an 8 megahertz clock, the screen
>must be slowing down the processor by at least a factor of 2.

Three possibilities here:

1: The hi-res mode is really 70 hz interlaced.
	At the 70HZ rate you could not tell visually, you would have to use a
	high speed camera and a short persistance monitor to even tell.
	Some very high resolution video and CAD/CAM systems have used this
	successfully to attain very high resolution when bus bandwiths
	are to slow for say 4096x4096 by 4 colors.

2: The MMU chip may include a syncronous address multiplexor (SAM) circuit
	similar to the 6883 used in the TRS-80 color computer.  This circuit
   	allows a second device to use the memory during the period that the
	CPU is "announcing addresses".   The MMU provides VMA 
	to allow the CPU to continue the set up, when everything is ready,
	all of the CPU signals get sent to the memory at the same time,
	then DTAK is dropped.  The effect is to cause the two different
	processors to access memory 180 degrees out of phase with each
	other and latch/tri-state the various signals.  TI does this
	in their dual-ported video RAMS for systems where a SAM is not
	practical.

3: Other assistance, such as FIFO's in the video chip
	(8275 style), or in the MMU chip can compensate for the irregular
	timing of the CPU fetches.  This would also allow video or DMA
	circuitry additional access during CPU execution cycles, ROM
	access cycles, and other "RAM-Idle States".

There is a good possibility that all of the above were incorporated.  As
evedenced by the requirement for fast (120ns) rams, 'raster crawl' visible under
a magnifying glass, and the fact that the video doesn't "Glitch Out" during
things like timer loops, which demand heavy buss acess.  I suppose we'll
have to wait for Atari to divulge the finer points of these not too well
documented chips.  Or wait for a good hacker to try "poke-blasting" the
MMU/Configuration addresses.  512 of these are indicated but not well
described in "Presenting the Atari ST".

Hardware is my hobby, so a good engineer may have a better answer for you
than this.