NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/sys/atari/st/tech/5528

Text File | 1992-11-08 | 4.8 KB | 95 lines

Newsgroups: comp.sys.atari.st.tech
Path: sparky!uunet!pipex!bnr.co.uk!bnrgate!corpgate!crchh327!bnr.ca!grier
From: [e-mail] (Brian Grier)
Subject: Re: Falcon Bus
Message-ID: <[e-mail]>
Sender: [e-mail] (News on crchh327)
Nntp-Posting-Host: 131.253.206.80
Organization: Bell Northern Research
Date: Sat, 07 Nov 1992 22:35:44 GMT
Lines: 83

> What do you mean by this? It is my understanding of the 68k that the bus has
> always been asynchronous -- there is no fixed slot in the bus timing for
> reading or writing. The processor simply waits until the data has been
> transferred, when the peripheral asserts various lines to inform the 68k
> that it's finished.

> Do you mean burst mode, used for cache filling?

The 68030 supports two memory access methods syncronous, and asyncronous.
The memory controller uses a signal to inform the 68030 which type of
memory access it will support.

Syncronous memory accesses require 4 timing states to complete the access,
while asyncronous memory accesses require 6 timing states. At 16 Mhz a
timing state is 31.25 nanoseconds. Therefore using syncronous memory accesses
the CPU can accesses memory every 125 nanoseconds, while using asyncronous
memory accesses the CPU can access memory every 187.5 nanoseconds.

The 68030 instruction cache is filled by the CPU recognizing processor
states that will not access memory and will perform a memory read in advance
based on the program counter. The 68030 data cache is filled only on reads
to data space and they can not be anticipated.

I am not sure how Atari has implemented Burst Mode on the TT, but a typcial
implementation with nibble-mode-ram is as follows:
   1) On first access perform normal memory access, syncronous or asyncronous
         memory access with as many wait states as needed.
   2) On subsequent accesses, if they are sequential, remove the proper
         number of wait states, and possible switch to syncronous access.
This is actually implemented in the memory controller not the CPU.

> >My best guess is that when people get to the Falcon in the REAL world
> >they increase the number of bits per pixel, causing a lot of extra time
> >to be spent drawing things, like letters and numbers. You will pay a big
> >price in performance for more bits per pixel on Atari systems. Refer to
> >the description of pixel memory in either the developer docs or the Abacus
> >internals guide.

> Please elaborate -- why do we pay for more bits per pixel on Atari systems?

Video memory consists of some number of bit planes. The video memory designer
has several choices of memory organization, a pixel can be represented as
a bit, a nibble, a byte, or a word. resulting in 16, 4, 2, or 1 pixels per
word respectively. Which translates to 1, 4, 8, or 16 bits per pixel. Atari's
chose to use the pixel is represented by one the bit per pixel method,
allowing 16 pixels per word in memory. This means that for the ST high res
you need 1 32k byte section of memory. ST medium res requires 2 16k byte
sections of memory, and ST low res requires 4 8k byte sections of memory.
The video shifter is told what mode is being displayed and get the memory
according to its pre-programmed algorithm.

Now that every one has the basic concepts of ST video memory lets look at
what it takes to places a single dot on the screen. The X-Y co-ordinate
is turned into an offset in memory, (X*Y)/16, next the correct bit in that
word is determined, (X*Y) modulus 16, then that bit is either set or cleared
to give the desired result. Now we have only taken care of a 1 bit per pixel
system. If you are in ST high res your done, if not then you have to take
care of the remaining bits per pixel. We already have the memory offset and
the bit offset so be same bit set/clear operation must be repeated at each
of the other sections of memory that comprise your display.

To summarize, to plot a pixel the offest, memory and bit, need to be calculated.
Then for each bit plane the base address of that bit planes section is added
to the offset and the correct bit is set/cleared.

If you chose a memory configuration where all of the bits for a given pixel
are contained in the same word the number of memory access is greatly reduced.
Therefore if Atari had choosen a different implementation, 8bits/16 bits per
pixel with all the bits for a given pixel in the same word MOST applications
would run much faster.

So why would anyone implement video memory the way Atari did? The best reason
would be CAD/CAM packages, where your drawings exist in many different planes.
I can only guess at Atari's reason, so I wont. This memory organization does
have other benefits. Software blitting of sections of the screen will be faster,
horizontal lines can be drawn 16 pixels at a time, and polygons can be filled
with amazing speed.

Brian, WS1S
Bell Northern Research
Research Triangle Park, NC
[e-mail]