🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.micro.atari
Article #2352

Re: Bus contention

#2352
From: rex ballard
Date: Sat, 01 Feb 1986 01:30
46 lines
3021 bytes
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.
Technical Details
Message-ID: <360@ccivax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!harvard!seismo!rochester!ritcv!ccivax!rb
References: <2048@watdcsu.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!genrad!panda!talcott!harvard!seismo!rochester!ritcv!ccivax!rb
From: rb@ccivax.UUCP (rex ballard)
Newsgroups: net.micro.atari
Subject: Re: Bus contention
Message-ID: <360@ccivax.UUCP>
Date: Fri, 31-Jan-86 20:30:38 EST
Article-I.D.: ccivax.360
Posted: Fri Jan 31 20:30:38 1986
Date-Received: Mon, 3-Feb-86 04:51:23 EST
References: <2048@watdcsu.UUCP>
Reply-To: rb@ccivax.UUCP (Rex Ballard)
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 46