kurto@cc.usu.edu (03/01/91)
Okay, it's been a while since anyone has posted their wants as to
what they think that the Atari ST should be, so I'll post what
I think they should be! ;-) (I'll try and make this as
realistic as possible.)
1. It should contain a 16 MHz 68010 (at the least) so that virtual memory
can be implemented. This would also require a MMU that generates
interrupts when the CPU makes accesses to memory that isn't there,
this also might cause some problems with DMA handling. Since this
would also require a hard drive then there could be some interference.
Anybody have any thoughts on this?
2. It should contain software drivers to emulate (and a socket for)
a 68881/68882. This would allow compiler writers and assembly
programmers to create one set of code for floating-point mathematics
which would take advantage of a coprocessor if it exists. And if it
doesn't then the software drivers would take care of it.
3. As for memory it wouldn't need a lot, but at least 2 Megs would be
good. By implementing virtual memory there would be little need
for any more (unless you need REAL speed.)
4. Since it is having virtual memory (assuming that DMA wouldn't
be a problem) then there would be the requirement of a hard drive,
at least 30 megabytes, having it internal would be good too.
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.
I guess this means kicking them up to 256K.
6. To enhance networking an Ethernet interface would have to be
added, along with TCP/IP drivers. Also some sort of network file system
should be tacked on with this.
7. For video output I would personally prefer something along the lines
of 64 colors with a resolution of 1024x768 (at least). This could
be made upgradeable to 256 colors/grays at 1256x1024, or whatever people
are calling standard these days. This would allow for the addition
of windowing systems (like X, and MGR, or whatever).
If you leave out items 6 & 7 then it shouldn't cost much more than
$3000. I also think that there should be some kind of mini developers
kit made available that contains a bunch of tools and some documentaion
on the system. If someone was to rewrite the assembler from
the Sozobon C package so that it was more user friendly then just bundling
Sozobon with a set of books describing the operating system, then
it would be enough.
Anyway that's what I think should be done as a low {middle} end ST.
Maybe I'm nuts but that's what I think. If anyone has anything to say
let me here it.
Kurt Olsen
slh85@cc.usu.edu internet
slh85@USU bitnetcarter@cat27.cs.wisc.edu (Gregory Carter) (03/03/91)
I think your first request on a 68010 is OK, but I find a 68000-16Mhz perfectly fine. And I think that is a good new base for a low cost machine for wide appeal. A co processor for the low cost machines is not an issue I don't think as most people who buy them, aren't going for math intensive operations. I think 2 megs is a good start on any base model. As for the operating system, Wow you really blew it there. Who wants MiNT or TOS when UNIX/X-Windows is available. I already have an AppleTalk caompatible port on my machine so I think ATARI is working toward the right direction, also Mr. Small has hardware you can addt to get really high performance network hardware. There are TCP/IP drivers acrd hardware you can buy now too that you can add on. For video output, I agree. atari should be putting out 640x480x16 color machines as the new base for video standard. 640x400 kinda sucks, but one can certainly live with it. --Gregory
saj@chinet.chi.il.us (Stephen Jacobs) (03/03/91)
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. I'd like to see available memory increased to 16 MB, with the
starting configuration about 1 MB. A megapixel monochrome mode and something
around 640 x 400 x 64 colors from a large palette would be nice for video, and
it would be cost-effective to tune the details so they could run on popular
multisync monitors. It would be VERY nice to see TOS re-done to include the
best of the extensions (or at least the best of the PD extensions). I'd like
the developers' compiler to be GNU C, with Atari-developed libraries so it
wouldn't be necessary to link with GNU libraries. If at all possible, I'd
like 1.4 meg floppies and a built-in rudimentary PC emulator (or some kind
of Atari-label PC emulator). I have the highest regard for suppliers of host
adapters, but Atari should put a Mac-style SCSI port on the machine (as on
the TT). Room in the box for a hard disk, and a way to support virtual memory
would be nice, but a built-in hard disk and VM out-of -the-box don't sound like
basic features (I know VM with a 68000 requires hardware support--still sounds
better than going to a 68010). I'd consider 16 MHz the minimum acceptable
speed for a brand new machine, and would like to see more. Networking needn't
be built in, but again, should be available with Atari label accessories, and
compatible with SOME standard that's out there already.
Basically, I thing the Mega STe is a great beginning, but only a beginning.
Steve saj@chinet.chi.il.usbarry@speaker.metaphor.com (Barry Friedman) (03/03/91)
In article <1991Mar3.001625.22154@daffy.cs.wisc.edu> carter@cat27.cs.wisc.edu (Gregory Carter) writes: > >I think 2 megs is a good start on any base model. > >As for the operating system, Wow you really blew it there. Who wants >MiNT or TOS when UNIX/X-Windows is available. UNIX/X with 68010 and only 2 megs would be an incredible dog. 68030 with 4-8 megs would run UNIX/X tolerably. Maybe Mach would be a better choice, I think it is on its way to being PD. Throw NextStep on top of that, and it would be really cool. -- +=========================================================================+ | Barry_Friedman(); /* "Why stop now, just when I'm hating it?" | | - Marvin the Paranoid Android */ | +------------------------------+------------------------------------------+ | Barry Friedman | friedman@m4.metaphor.com | | Software Engineer | barry@speaker.metaphor.com | | Metaphor Computer Systems | ...!{decwrl|apple}!metaphor!speaker!barry| | Mountain View, CA | ...!{decwrl|apple}!metaphor!friedman |
adamd@rhi.hi.is (Adam David) (03/04/91)
>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
jcav@ellis.uchicago.edu (john cavallino) (03/05/91)
In article <2864@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes: >>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. One thing to remember re: 68010 is that Motorola appears to want to phase it out soon. They've always had problems with the part in terms of production yield and performance. (no, there is no 16mhz 68010). The rumors I've heard are that Motorola is trying very hard to convince the few designers still looking at the 68010 to switch to the 68020 instead, to the point of pricing the '20 below the '10. IMHO this is the right way to go. Especially if the price is comparable, the 68010 has NO advantages over the 68020. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
vsnyder@jato.jpl.nasa.gov (Van Snyder) (03/05/91)
In article <1991Feb28.213727.46962@cc.usu.edu> kurto@cc.usu.edu writes: >Okay, it's been a while since anyone has posted their wants as to what they >think that the Atari ST should be, so I'll post what I think they should be! >5. ... Also the standard C libraries should be ROMed so that when you start >multitasking each program won't require it's own copies... ^^^^^^^^^^^^ I think you mean multiprogramming. Multitasking alone doesn't imply separate images. Even with multiprogramming, the 68881 can handle shared segments, if the library and OS collaborate appropriately. Multics could do it in '68, so why can't Unix do it now? (Actually Mach can). -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
vsnyder@jato.jpl.nasa.gov (Van Snyder) (03/05/91)
In article <2864@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes: >>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. > PLCC PLUGS (not sockets) are available from Mackenzie technology, in Sunnyvale, CA (I think). They have all the common sizes. -- vsnyder@jato.Jpl.Nasa.Gov ames!elroy!jato!vsnyder vsnyder@jato.uucp
hyc@math.lsa.umich.edu (Howard Chu) (03/05/91)
In article <1991Mar4.163632.353@midway.uchicago.edu> jcav@ellis.uchicago.edu (john cavallino) writes: >One thing to remember re: 68010 is that Motorola appears to want to phase it >out soon. They've always had problems with the part in terms of production >yield and performance. (no, there is no 16mhz 68010). The rumors I've heard >are that Motorola is trying very hard to convince the few designers still >looking at the 68010 to switch to the 68020 instead, to the point of pricing >the '20 below the '10. IMHO this is the right way to go. Especially if the >price is comparable, the 68010 has NO advantages over the 68020. Well, for us lowly ST owners, it has one advantage - pin-compatibility with the 68000. Although I guess even that's not true for all the 68000 package configurations now. (Which kinda sucks for us STe owners, where TOS 1.6x can cope with the 68010 but you can't get one in the proper packaging/pin configuration. What a drag... [Hm. Why doesn't someone market an adapter socket or something? Sheesh!]) Back to the wish-list... How 'bout some dual-ported RAM, none of this Video-always-wins bus hogging. I don't really understand what's going on in the video hardware, obviously. Why does the video need to run at 16MHz to produce an image on a 15.75khz display? What's really going on here? I've seen mods that use an additional shifter chip to extend the pallete. How 'bout doubling the clock rate on the shifter so we can get more resolution? How 'bout giving us 8 or more bitplanes instead of just 1, 2, or 4? Ok, moving right along... DRAM is pretty cheap now, even at reasonably fast speeds. Why did the Mega STe require caching for 16MHz operation, why doesn't the entire system allow normal accessing at 16MHz? Double all the relevant clock rates, while you're at it - DMA bus, for example. I wonder how long it'll be before we see an even faster version of the TT. (Ok, so ya can't run at zero wait states with a 50MHz 68030 using human-priced DRAMs. But it'd be nice to head that direction, eh?) -- -- Howard Chu @ University of Michigan Flame all you want - we'll take more.
mjs@hpfcso.FC.HP.COM (Marc Sabatella) (03/06/91)
>Even with multiprogramming, the 68881 can handle shared segments, if >the library and OS collaborate appropriately. Multics could do it in '68, so >why can't Unix do it now? (Actually Mach can). Many Unix's can and do. DomainOS, then SVR3, then SunOS, then AIX, and SVR4, and soon HP-UX, and OSF, and probably others, all support shared libraries. The "Unix-ness" of the implementations vary; almost all provide makefile compatibility for basic programs, and almost none allow programs that make assumptions about the layout of the process in memory (most notoriously Gnu Emacs) to work without source changes, or makefile changes to disable shared libraries. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
kls30@duts.ccc.amdahl.com (Kent L Shephard) (03/06/91)
In article <519@cronos.metaphor.com> barry@speaker.metaphor.com (Barry Friedman) writes: >UNIX/X with 68010 and only 2 megs would be an incredible dog. 68030 with >4-8 megs would run UNIX/X tolerably. Maybe Mach would be a better choice, ~~~~ >I think it is on its way to being PD. Throw NextStep on top of that, and it ~~~~~~~~ >would be really cool. > By George! I think he's got it. You just described my '030 NeXTcube. Yep, I like it and have my PC-Clone sitting next to it. (no pun intended) >-- >+=========================================================================+ >| Barry_Friedman(); /* "Why stop now, just when I'm hating it?" | >| - Marvin the Paranoid Android */ | >+------------------------------+------------------------------------------+ >| Barry Friedman | friedman@m4.metaphor.com | >| Software Engineer | barry@speaker.metaphor.com | >| Metaphor Computer Systems | ...!{decwrl|apple}!metaphor!speaker!barry| >| Mountain View, CA | ...!{decwrl|apple}!metaphor!friedman | -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
adamd@rhi.hi.is (Adam David) (03/08/91)
In <1991Mar5.014330.10601@math.lsa.umich.edu> hyc@math.lsa.umich.edu (Howard Chu) writes: [about 68010] >Well, for us lowly ST owners, it has one advantage - pin-compatibility >with the 68000. Although I guess even that's not true for all the 68000 >package configurations now. (Which kinda sucks for us STe owners, where >TOS 1.6x can cope with the 68010 but you can't get one in the proper >packaging/pin configuration. What a drag... [Hm. Why doesn't someone >market an adapter socket or something? Sheesh!]) You mean somebody doesn't make an adaptor socket? I seem to remember reading about how to fit 64-pin MPU boards (SST from Gadgets for instance) to the STE. As for the 68010 they should be available as 68-pin PLCC according to Motorola docs. Maybe they are just not stocked any more (real drag). If you can find one it should drop straight in to an STE and work just fine. 16 MHz might require good luck and some extra cooling though for the 12.5 MHz part to be reliable. >Ok, moving right along... DRAM is pretty cheap now, even at reasonably fast >speeds. Why did the Mega STe require caching for 16MHz operation, why doesn't >the entire system allow normal accessing at 16MHz? Double all the relevant >clock rates, while you're at it - DMA bus, for example. I wonder how long >it'll be before we see an even faster version of the TT. (Ok, so ya can't run >at zero wait states with a 50MHz 68030 using human-priced DRAMs. But it'd >be nice to head that direction, eh?) If that memory were to be interleaved it could run at full tilt inserting wait states only for non-consecutive addresses, but I suppose that's really just another form of caching/prefetching. It could be done pretty much with a single PAL chip. To be really effective it would need to be buffered separately for code and data, it might be necessary to arbitrate the bus also. Will we ever see a 68040 TT, or something more exotic? (dirt cheap of course:-) -- Adam David. adamd@rhi.hi.is