🚀 go-pugleaf

>Dave Ritchie asks:
> 
>>Don't get me wrong... I really like my Atari (and that other computer
>>I own that starts with a 'A'). But the marginal cost of upgradability
>>for the capability gained - why wasn't this done to begin with?  
>
>It would cost Atari Corp. close to  $0.00  to add the sockets necessary
>to make the 520 expandable to 1 Meg, and the ST2 expandable to 4 Megs, but
>then they would only sell you ONE computer, and make only ONE profit.
>

  The usual consequence of such policies that they will only sell you 
ONE computer (fool me once, shame on you - fool me twice, shame on me). 

  Unfortunately, Atari needs to learn several lessons from some of their
more successful competitors (DEC, IBM and Apple). If you look at the history
of successful personal computers (and I will give these in chronological 
order - the PDP-11*, the Apple II and the IBM-PC), they were all expandable
machines that got the software basics mostly correct (this is not say that
they didn't suffer from calcification as they got older - the initial
things were correct however). The big plus was that they were flexible
(unlike the Atari ST) in that they had a well specified, well documented
hardware interface architecture which was not hidden from the user (unlike 
the ST, in which the user had to jump thru a multitude of hoops in order 
to get internals docs). THIS IS STILL A PROBLEM FOR THE ST. Also, they
all encouraged the users to stretch the capabilities of the machine. If you
had had to wait for DEC/IBM/Apple to make many of the boards that are 
available today for these machines, you would still be waiting. 

  Atari could still make a contribution in the market with a little
intelligent thought. There is a gap in the 68000 hobbyist market that
neither the ST or the Amiga fills. These are the things I see as being
desirable in "Son of ST". (The other computer that starts with "A"
suffers from many of these same problems).

1)  Use a buss on the next machine so that the user has some flexability
    to configure the machine for various uses. Place the video section
    on a card on the buss to allow upgrading as time and funds permit.
    Don't place small limits on amount of memory (however, place as much
    space for memory on the motherboard as possible). If you look at
    your competitors, memory size is growing past the small limits that
    has been set on the Atari. What is your future? Make expansion cards
    available early on that do the canonical set of things (HD, parallel,
    serial, MIDI, ThinLan, video of various flavors). Put n>5 of these slots
    on the motherboard.

2)  Use standard busses for perpherial connections (i.e. no mock SCSI
    for the HD interface).  SCSI would allow other perpherials
    to be used, unlike the AHDI interface which greatly increased the
    cost of an Atari (a computer w/o a HD is a toy at best). 
     
3)  Dump the 68000 for the 68010 (at least). The 68000 is a prototype
    for the real thing. Fix TOS's problems (like malloc, etc.) The 68010
    could help here by getting around the problem of the trap vectors
    being at 0 (load a new page table for "old TOS" compatibility
    problems and have the best of both worlds). Use a faster processor
    even if requires wait states to memory (switch selectable # of wait
    states of course). 

4)  Add at least a rudimentry memory protection capability. This allows
    others to use this platform for OS development, and it necessary be
    multitasking is really useful. Demand paged would be best, but base-
    limit protection would be adaquate (full task swapping) if memory
    is large enough.

5)  Make a TOS with support for networking. These are things
    that your competition (Macs and IBM) have had for some time.

6)  Make a multitasking TOS. Make it version number smart so that
    it can adapt to old rev's of the OS (i.e. tasks would have headers
    tell the OS what version that they were coded for).

7)  Realize that software sells hardware - not the opposite. Make an
    development environment that allows people to develop code, not 
    debug other people's OS faults. I suspect the problems in TOS have 
    alienated many developers. 

8)  Respect Ritchie's Law of Computers: (*blush*)

       You Don't Have Time To Do It Yourself

    and its corollary:
       
       Most Times You Don't Need To Do It Yourself - Someone Else Already Has 

    Simply stated - if the industry has de facto standards in a certain
    area - use them. If TCP/IP is a standard protocal, use it. If Novell
    has a standardized PC file server protocol, use it. If NFS or RFA is
    it, use it. For Pete's sake, don't use a proprietary protocol -
    it slows your time to market, and it doesn't talk to standard 
    peripherials and other machines. Atari did this somewhat - DOS
    format disks are a smart idea, a Hercules compatible TTL monitor
    would be a great idea :->, a 1k by 1k video card for cheap would be 
    a *fastastic* idea, etc.

					Dave "I have a dream" Ritchie


P.S. Was shown TOS 1.4 by a friend of mine who is a developer. This
     is good stuff! When does it become 'real'? Also, does 1.4 fix
     problem that when an ESC is used to reread a floppy, the first
     change of current working directory on that floppy fails? 
-----------------------------------------------------------------------
* You may not classify a PDP-11 as a PC, but if you look at it historically,
it was often used in many of the same sorts of tasks in the scientific 
community, and had a similar cost-performance benefit at the time.