[net.micro.atari] ST memory management

ravi@eneevax.UUCP (Ravi Kulkarni) (09/25/85)

The memory management unit on the ST is more of a memory controller. It
handles refresh for up to 4 megs of memory organized as two banks. Even
if you have different amounts of memory in the two banks it will configure
it as one contiguous segment. The only memory management that it does
that I know of is that certain areas of memory such as i/o space and
and the first 1k of memory where the exception vectors are located are
protected from writing when in user mode. Of course there could be
undocumented features that we don't know about but then they could have
easily made the text area of the operating system read only which I
don't think is the case.


>If this is the case, does that mean that the 512K in the machine is
>really the CACHE for an external RAM disk?

You may not be far off the mark. Rumors indicate that atari already has
in prototype form an expansion box with a 32bit graphics processor. The
ST might in this case be used as an i/o processor for the keyboard,
disk, etc. Using the 512k as a cache would be very useful in speeding
up the effective access times of todays slow hard disks.

>I noticed that 1.33Mbytes/sec is about 10Mbit/sec, anybody know of an
>Ethernet to SCSI interface?

I know that this has been done. For example sequent has an ethernet
controller off their scsi interface. I am very interested in this
application. If somebody knows more about the atari interface and
how it compares to SCSI please post it to net.micro.atari.

>'Presenting...' describes the BIOS vectors and the BDOS vectors, where is
>VDI?  Is it a 'trap vector', a 'run-time library', or a 'link-time library'?

The vdi or gsx calls are done via traps. I believe it uses trap#2. That
is why you have to allocate those silly arrays when you use vdi calls
since that is how you pass parameters.

>Does VDI use the Graphics chip to do the painting, or does it 'bit bump'
>like the MAC?

The graphics processor is not documented very well(if at all) so the
following is mere speculation. The graphics processor handles the 
generation of the video signals for both rgb and monochrome outputs.
For monochrome output it uses a an internal crystal to generate the
70hz non-interlaced video. It also handles the 512 color palette
for the rgb mode. The atari also has something called bit block
transfer. There is a possibility that the graphics processor does
this through a dma transfer. This is not an ordinary transfer since
it involves non-contiguous sections of memory. A couple of things
point to this. One try moving an open window on the desktop. You
will notice that you cannot move it by single pixels in the
horizontal direction but by small fixed increments implying word
boundary limitations typical of dma operations. Also there are
two screens one logical and one physical used for animation.
Line drawing is done in software though.

-- 
ARPA:	eneevax!ravi@maryland
UUCP:   [seismo,allegra]!umcp-cs!eneevax!ravi

henry@utzoo.UUCP (Henry Spencer) (10/01/85)

> >I noticed that 1.33Mbytes/sec is about 10Mbit/sec, anybody know of an
> >Ethernet to SCSI interface?
> 
> I know that this has been done. For example sequent has an ethernet
> controller off their scsi interface...

Not so, sorry.  The Ethernet controller and the SCSI interface are on the
same board in the Sequent machines, but they are entirely independent.
The Ethernet controller is not on the SCSI bus.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry