dmcanzi@watdcsu.UUCP (David Canzi) (01/28/86)
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 Severeid's Law: The chief cause of problems is solutions.
jan@looking.UUCP (Jan Gray) (01/28/86)
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
dlm@iheds.UUCP (Daryl Monge) (01/29/86)
> 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
I6191008@DBSTU1.BITNET (01/29/86)
No, the timing is so good that the processor and the videochip are not disturbing each other when accessing the bus. Johann Zuschlag (I6191008@DBSTU1.BITNET)
jutz@pogo.UUCP (Curt Jutzi) (01/30/86)
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
rb@ccivax.UUCP (rex ballard) (02/01/86)
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.
G.DYER@SU-SCORE.ARPA (Landon Dyer) (02/03/86)
Don't bother "poke-blasting" the memory controller ("MMU") address
space. There's nothing interesting there. If you don't believe me,
then go ahead.
The 68000 makes a bus request every 4 cycles. This means that there are
3 other cycles available for doing stuff. 2 of these cycles are used for
video DMA. 1 more is used for disk DMA.
Now, it is NOT true that the 68000 makes a memory access every 4
cycles (I lied.) The processor is given a window every 4 cycles,
and it is stopped if it makes a request that is out of line. It
quickly falls back into step. This means that the processor loses
cycles occasionally, but very occasionally.
(If you don't beleive me, go ahead: write some assembly language
benchmarks and count cycles. THEN you can start talking numbers
about "occasionally".)
Multiport RAM on a consumer machine? Yick. How much does that COST?
-landon
-------jhs@MITRE-BEDFORD.ARPA (02/03/86)
COMPUTE! Magazine's "product description" of the 520ST, I believe in the October, 1985 issue, described the CPU/DMA interface to memory. What they described sounded like essentially a time-multiplexed form of dual-porting: neither the CPU nor the DMA controller ever (much) has to wait for memory access. (They pointed out that because the 68000 accesses memory asynchronously, it will OCCASIONALLY happen that it will have to wait, but so rarely that you will never see it in terms of throughput.) -John Sangster jhs at mitre-bedford.arpa