Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!hpfcdc!hpldola!ritchie From: ritchie@hpldola.HP.COM (Dave Ritchie) Newsgroups: comp.sys.atari.st Subject: Re: Atari Memory Upgrades (was Re: SLM804 woes) Message-ID: <11830031@hpldola.HP.COM> Date: 23 Jan 89 07:32:57 GMT References: <1497@psu-cs.UUCP> Organization: HP Elec. Design Div. -ColoSpgs Lines: 106 >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.