Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!snorkelwacker.mit.edu!bloom-beacon!eru!kth.se!sunic!isgate!krafla!adamd
From: adamd@rhi.hi.is (Adam David)
Newsgroups: comp.sys.atari.st
Subject: Re: What the ST should be
Message-ID: <2864@krafla.rhi.hi.is>
Date: 4 Mar 91 12:39:01 GMT
References: <1991Feb28.213727.46962@cc.usu.edu>
Organization: University of Iceland
Lines: 63

>1.  It should contain a 16 MHz 68010 (at the least) so that virtual memory
>can be implemented.

Does a 16MHz one exist? I don't see it mentioned in the 68000 family reference
from Motorola. You could DMA the virtual memory with a little extra wiring.
The MMU has to generate BusErr for CPU and DMA pagefaults alike, and the DMA 
pagefault puts DMA on hold until it's been fixed up. Any time-critical DMA
transfers will have to be page-aligned.

>2.  It should contain software drivers to emulate (and a socket for)
>a 68881/68882.

This could be made available as an upgrade. Does anyone have any ideas about
plugging non-standard hardware boards into Blitter/Glue/MMU sockets? Where are
the connectors available from? Of course it's a good idea to include FPU
emulator code as standard.

>5.  As an operating system perhaps a combination of TOS 1.4 and MiNT
>would be ideal.  Any part of TOS that isn't implemented in MiNT should
>be added onto MiNT (or the other way around, whichever you prefer.) and
>then stuck into ROM.  Also the standard C libraries should be ROMed so
>that when you start multitasking each program won't require it's own copies.

Try starting with TOS 1.62, that has built-in support for all the 680x0 CPUs.
C libraries can be shared in RAM too. All you need to define is a common  access
interface. Any OS should be _general_purpose_, and fully extendable. C libraries
don't really belong in ROM because not everyone uses C. A better idea would be
general purpose high-level libraries in ROM.

The standard video drivers (low-level as well as GEM) should be dynamically
configurable for any type of screen. Screen RAM could be overlaid in the ROM
space so there is less bus contention with the video. The ST memory map allows
for up to 2MB of such RAM (less 32k of hardware registers). The design of the
screen hardware should allow for removal and exchange of hardware shifters on
a modular basis. People would then be able to choose the right screen modes for
their own use and not have to pay for megapixel colour if they only want minimal
monochrome. The whole ROM space (2MB less 32k) should be available on the
cartridge port so that TOS (or whatever) can be replaced on a cartridge module.

>From: saj@chinet.chi.il.us (Stephen Jacobs)
>Message-ID: <1991Mar03.003414.4410@chinet.chi.il.us>
>Date: 3 Mar 91 00:34:14 GMT
>
>I have a different wishlist.  I'd stick with the 68000 for a 'super-ST', in
>part because there really would be applications broken by the hardware 
>differences.

A 68010 can emulate the 68000 except for cases where cycle timing is crucial.
I'll not lecture on how bad reliance of code on cycle timing is, because you've
heard it all before anyway. If you really need 100% 8MHz 68000 ST compatiblity
you could have one in there too (piggybacked optional extra :-) so that you can
switch between it and 16MHz 68010.

I'd like support for 1.4 and 2.8 meg floppies to be in the OS and for the
upgrade to be as simple as swapping chips. PC emulator should be software
bundled with the machine, with the option of upgrading to V30 or SX386
slave boards *[* with their own memory space *]*

What are people's ideas about PD hardware?

Enough of my opinions for now,
--
Adam David.  adamd@rhi.hi.is