kim@amdahl.UUCP (03/29/87)
[ "Send lawyers, guns, and money ..." ]
A few days ago, I received a 10 page flyer from ASDG entitled "The ASDG
NewsLetter", and dated as "Issue 1, March 1987". I guess this means that
ASDG received my $10 registration fee for the "Recoverable Ram Disk" (you
did send in your's, didn't you?)
Anyway, there is a lot of information about ASGD's plans for the future,
some of which I will summarize here, along with some personal thoughts
and comments. Please note that I'm trying to present *information* here,
not marketing hype, nor commercial endorsements.
First, here is what ASDG has planned for the A2000:
2MI - 2 Meg memory board (equivalent to the A1000 2M product)
8MI - 8 Meg memory board (equivalent to the A1000 8M product)
20XI - 68020 processor board
SDPI - smart disk processor
SIOPI - smart I/O processor
The newsletter stated that there would be A1000 equivalents for the 20XI
and SDPI (called 20X and SDP, natch). The 2M and 8M A1000 products are
already available (8M in April). No mention of an SIOP card for the A1000,
but then ther was nothing in the newsletter about this card other than the
above one liner. And you already know that ASDG has committed to building
the 2000-and-1 A1000 expansion box.
The 20XI/20X 020 board:
To quote ASDG, "Right now, the board (which we'll be calling the 20X and
20XI) is vaporware. But the feature list of the product is already well
defined. So in the following article, bear in mind that the first printed
circuit board has yet to be built. What you're reading is preliminary."
Extracted from the article, here's what I see as the "facts", with my comments
in []'s:
o Designed with a proprietary decoupling scheme that provides a
processor board with *minimum* clock speed of 14 MHz, and a
maximum clock of 25 MHz. The board will operate at any speed
in between. [25 MHz !!!!!]
o Will have on-board 32-bit DRAM, with zero wait-states (at 14 MHz).
Comes with 1 Meg on-board, expandable to 4 Meg.
o Socketed for a 68881 floating-point processor [damn, no Weitek's :-) ! ]
o Some "stuff" that allows an "N" MHz board to be 10 to 20 percent faster
that current 020 boards running at the same clock (code dependent).
[Sounds like an on-board caching scheme, to me.]
Sounds like a *very* impressive piece of h/w, but I've saved what could be
the best for last (and *this* is really what prompted this posting). I
quote from the newsletter:
"Now here's where direct customer contact comes into play. Do you think
we should add a demand paged MMU? If so, what would you use it for?
Would you port System V/4.x BSD to our board? And you thought getting
this newsletter meant no work on your part!
"Seriously, we want to know if there's any interest in having an MMU on
the 20X and 20XI. Designing it in and then leaving it [the chip itself]
off the board uses up only a little board real estate but adds at least
thirty dollars to the suggested retail (that is, to have the empty
socket on your 20X subtracts $30 from your pocket).
"Please fill out the customer feed back request and tell us what you
think."
At the risk of starting up the old MMU wars again, ASDG *is* asking us what
we want. Though Perry doesn't miss much that's posted here :-), I will
collect feedback that is posted and/or emailed to me, and make sure it gets
to ASDG. Religious discussions on the merits of MMU's vs. no-MMU's will be
summarily sent to /dev/null.
For myself, I will *demand* having an MMU on my next system, and $30 for
the *capability* seems a small price to pay on a board that will likely
cost more than $1K in it's minimum configuration.
But ... I said *system* above, and that includes an OS that can *use* the
MMU in an *intelligent* manner. *I* won't be porting UNIX(R) to the Amiga
myself (BSD please!), and only CBM has the *real* AmigaDOS source (as well
as the *shipping* AmigaDOS/MetaComCo source).
Although UNIX(R) is quite popular and might seem like a good choice for a
machine of this power, it isn't ideal for the Amiga. LOTS of work would
have to be done after getting a vanilla version up to support all the
Amiga specific h/w (blitter, audio channels, etc.). Then there are the
compatibility issues ... whaddya mean, I can't run DPaint on AmigaUNIX?!
To be successful on the Amiga, I think *any* OS is going to have to support
the features and *kind* of s/w we've come to expect to see on the Amiga ...
if UNIX(R) is all I'm after, there are PClones with Microport/XENIX/etc.
that already provide that (though I'd like to run 4.x BSD in a window
next to MS-DOS!)
Now, CBM has stated that they too are working on an 020 board for the A2000's
86-pin unbuffered "co-processor" slot [could this work in an ASDG 2000-and-1
expansion box Zorro I slot, Perry?] It has also been said that CBM's 020 board
MAY have some kind of MMU support (my impresion is that CBM's MMU would fall
far short of providing demand paging, but would provide segmentation or
maybe just simple memory protection). In any case, CBM will have to support
any such scheme in AmigaDOS.
All of which is leading up to a suggestion to ASDG, CBM, and any other h/w
vendors who may have similar plans ... WORK TOGETHER to define an ARCHITECTURE
for 020/MMU support! What we don't need are a bunch of totally incompatible
implementations! I know that such cooperation may be a novel idea, but without
it, nobody will win. Such an approach could specify several implementation
levels, from simple memory protection, all the way thru virtual memory with
demand paging. Developers could go for the high end or the low end without
limiting their creativity. Customers could buy the amount of machine they
need now, and upgrade when they need more. And it would all fit under one
umbrella and work together (though certain s/w might require at least some
minimum level of implementation). Now *that's* an upgrade path!
Whew ... this got longer than I expected awfully fast, and I haven't even
talked about the SDPI board or the 2000-and-1 box ... I think I'll make
them a seperate posting.
Lastly, I pleased ASDG is asking for input on their products ... what do
y'all say ... want an MMU?
/kim
P.S. Nope, I'm not associated with ASDG in any way, except I use their
indespensible RRD, and sent in my registration fee for it!
--
UUCP: kim@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
CIS: 76535,25
[ Any thoughts or opinions which may or may not have been expressed ]
[ herein are my own. They are not necessarily those of my employer. ]kim@amdahl.UUCP (03/29/87)
[ For all you do ... this line's for you ... ]
Continuing with the technical information gleaned from ASDG's March
NewsLetter, along with some comments of my own ...
The SDP/SDPI hard disk controller features:
o Peak transfer rate close to 2 Mb/sec to/from the Amiga, with sustained
transfer of 400 Kb/sec from a SCSI drive, and 400 Kb/sec from an ST506
drive simultaneously.
o Subjective performance should be faster than ASDG's RRD (on writes),
but not quite as fast as ram:, due to ...
o 1/2 Meg of on-board local ram, which lives in I/O address space, not
the Amiga CPU's address space, and it's own ...
o On-board 68000 (or 68010) 8 MHz processor, which together are used to
provide ...
o Smart disk caching, which sorts (orders) the requests for blocks from
hard disk in such a way that the hard disks heads need only make one
pass across the disk instead of back-and-forth, back-and-forth. If I
read the newsletter correctly, the disk caching algorithms will also
provide for pre-fetching of blocks before they are actually requested.
[ I hope ASDG will provide enough information and "hooks" to allow
users to install their own pre-fetch/replacement/ordering algorithms,
or otherwise tune and optimize the system based on individual requirements.
E.g., for some applications, an LRU (Least Recently Used) replacement
algorithm might provide superior performance, while in another user's
environment, first-in-first-replaced might be better, etc. Then there are
questions like store-thru vs. non-store thru, but I digress ... any
comments, Perry? ]
o The controlling "firmware" for the above will be downloaded at boot
time, to allow for changes in the file system format, bug fixes, etc.
o The "base" versions will allow up to 8 SCSI devices to be attached to
the controller [isn't that really 7, one being the controller itself?]
An extended version (the SDP/ST and SDPI/ST) will also support two
ST506 devices.
o Available with and without drives.
As with the 020 board I described in my previous posting, this sounds like
a dynamite controller. I suppose it's asking for alot, but it would be
even more impressive if it used the new RLL encoding schemes used by people
like Perstore and Adaptek in the PClone world. (RLL increases the effective
storage available on a given ST506 type drive by 50 to 90 percent. I dunno
if it works on SCSI drives, or not).
The 2000-and-1 expansion box for the A1000:
This has been described on the net before, but to reiterate, it will provide
5 A2000 slots (or Zorro II, as ASDG calls them), 4 PC/AT slots, and 2 Zorro I
(A1000) slots. The A2000 and PC/AT slots are "layed out in the same manner as
on the A2000", which I guess means they "overlap" by two slots thusly:
| | | |
| | | | <---- PC/AT slots
| |
| | | | |
| | | | | <---- A2000 slots
| | | | |
There is no mention of an unbuffered CPU slot like the A2000 has (though I
suppose one of the Zorro I slots would work for some applications), nor of
a seprate Video slot (naturally). It will also have space in it for two
hard disk drives, and a power supply that will be able to "power a fully
loaded 2000-and-1". It will *not* be painted black (hot pink, Perry?!)
Now for some personal criticism of this box (as well as the A2000 itself).
There aren't enough slots! If we assume I add a Bridge card, I can have
either 3 PC/AT slots and 3 A2000 slots left over, or 2 PC/AT slots and 4
A2000's.
Now lesee, on the A2000 side, I will add more memory, a HD controller, and
an 020 board. That leaves me only ONE measly slot for all those nifty things
that will be forthcoming (TWO in an A2000, if I use CBM's 020 board in the CPU
slot). Where will I be able to find room for addiitional parallel and/or
serial ports, *and* a frame-grabber/buffer, *and* a real-time digitizer, *and*
an Ethernet board, *and* who knows what else next month? Sigh.
At least the A2000 *seems* to have left the door open for additional expansion
(did you notice a "knock-out" connector cover behind the CPU slot in the Byte
pictures?)
On the PC/AT bus, it looks worse, since there are most likely only two slots
available, but at least (if this bus is *truly* up to PC/AT specs) you can add
on an external PC expansion box in 6, 8, and 12 slot sizes from I-Bus Systems,
or others! BTW, if you're thinking of putting a hard-card in one of the PClone
slots, be advised that *most* hard-cards take up two slots due to their width
(though I have seen at least one that only requires a single slot).
So anyway, CAN WE PLEASE HAVE MORE SLOTS, PLEEEEEESE!!! Slots, like ram, like
disk space will always get filled, and 4 just aren't enough for all of the
exciting products that the Amiga is capable of supporting. Not nearly!
And will ASDG and/or CBM and/or another h/w vendor PLEASE get busy and design
an expansion box for the A2000 itself? It will be needed sooner than you think!
Does anyone else feel this way, or am I alone in my quest for slots?
Hmmmmm ... this posting is almost as long as my last one. Time to cut it
off. BTW, this ASDG NewsLetter that I've refered to was prepared on an A2000
using Gold Disk's PageSetter program. Nice job, guys! There's alot more info
on the products (without *too* much hype), ASDG's history, new Warranty policy,
etc.
/kim
P.S. I'm *still* not associated with ASDG (except as a registered RRD user),
nor do I have anything to do with I-Bus Systems, nor Perstore, nor
Adaptek ...
--
UUCP: kim@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ihnp4,seismo,oliveb,cbosgd}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
CIS: 76535,25
[ Any thoughts or opinions which may or may not have been expressed ]
[ herein are my own. They are not necessarily those of my employer. ]fnf@mcdsun.UUCP (03/30/87)
In article <6043@amdahl.UUCP> kim@amdahl.UUCP (Kim DeVaughn) writes: >For myself, I will *demand* having an MMU on my next system, and $30 for >the *capability* seems a small price to pay on a board that will likely >cost more than $1K in it's minimum configuration. Same here. This is one of the things Apple did right with their new Mac II. But besides just having an MMU, having a standard 68K family MMU is also a big win. This means that ports of minix, GNU (the OS), Sys V Unix, BSD Unix, and whatever, that are sure to be available for the Mac II, will be quickly and easily portable to the Amiga with such a 68020/68881/68851 combination. Given that there is already a port of X windows to the Mac II, that should come over pretty easy also. Ports to such a standard configuration will be very attractive to companies that specialize in such services. Probably none of this will be true with the custom MMU path that C-A is apparently following. Sigh. -Fred -- = Drug tests; just say *NO*! (Moto just announced new drug testing program) = = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = = seismo!noao!mcdsun!fnf (602) 438-5976 =
perry@sfsup.UUCP (04/01/87)
In article <6043@amdahl.UUCP>, kim@amdahl.UUCP (Kim DeVaughn) writes: > Now, CBM has stated that they too are working on an 020 board for the A2000's > 86-pin unbuffered "co-processor" slot [could this work in an ASDG 2000-and-1 > expansion box Zorro I slot, Perry?] Actually, the 68020/Unix(tm) board from CBM would go nicely into the 86 pin unbuffered ``cpu'' slot that we will provide in the 2000-and-1. Re: MMU The responses we've gotten so far indicate that people would like to have the option of putting an MMU on our 20X and 20XI. Nearly everyone recognized from the start that the MMU could not take advantage of future AmigaDOS changes by CBM since they will be working with their own proprietary MMU design and thus any code they develop will not be portable to a standard MMU ASDG or any other third party could provide. Most people's desire to have an MMU option on the 20XI stem's from their de- sire not to close off options should some entity actually port a larger o.s. to the 20X series. If the MMU option is there, people feel some unkown party will not be able to resist the temptation of porting some larger o.s. to the Amiga at some future time. (a sort of chicken before the egg dealie true but the rational is that if the MMU option is there, someone will ultimately use it). (is convergent technologies or unisoft listening?) Perry Kivolowitz
fnf@mcdsun.UUCP (04/02/87)
In article <1279@sfsup.UUCP> perry@sfsup.UUCP writes: >Most people's desire to have an MMU option on the 20XI stem's from their de- >sire not to close off options should some entity actually port a larger o.s. >to the 20X series. If the MMU option is there, people feel some unkown party >will not be able to resist the temptation of porting some larger o.s. to the >Amiga at some future time. (a sort of chicken before the egg dealie true but >the rational is that if the MMU option is there, someone will ultimately use >it). > >(is convergent technologies or unisoft listening?) I can assure you that Unisoft would be fully *capable* of porting their brand of Unix to an Amiga 2000, set up with a 68020/68851 card and hard disk, within about 6 to 8 weeks after receipt of hardware. When I worked there, they were just starting to get interested in "speculative ports", rather than their bread and butter "prepaid contractual ports". Whether or not they would decide to go ahead with such a port is something I obviously have no knowledge about now, as many things have changed in the last year. For an unknown and untried MMU (I.E. custom MMU for C-A's own 68020 board) the porting time and costs are dramatically increased, thus I would be surprised if they would port Unix to that configuration on a "speculation" basis. -- = Drug tests; just say *NO*! (Moto just announced new drug testing program) = = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = = seismo!noao!mcdsun!fnf (602) 438-5976 =
billd@crash.UUCP (04/02/87)
[]
Fred,
Something I wonder about with all this talk of standard versus
custom MMU's, if the standard MMU for the '020 is so great, how
come none of the companies making '020 boxes use it? From what I've
gathered by talking with people from Sun, SGI, and Masscomp, to name
a few, they all use custom MMUs because there is a SIGNIFICANT penalty
involved in using the standard chip. Is this correct, or is it just
an excuse to limit software portability?
Any personal opinions on this issue, I don't expect you to speak for
Motorola, but I'm sure that there is a lot of interest if you could
get an official reading from.
--
_ /|
\`o_O'
( ) Aachk! Phft!
U
(serious self-portrait?)
Opinion? I thought you said onions.
UUCP: {akqua,hplabs!hp-sdd,sdcsvax,nosc}crash!billd
ARPA: crash!billd@nosc
INET: billd@crash.CTS.COMgrr@cbmvax.UUCP (04/03/87)
In article <969@crash.CTS.COM> billd@crash.CTS.COM (Bill D'Camp) writes: > >Something I wonder about with all this talk of standard versus >custom MMU's, if the standard MMU for the '020 is so great, how >come none of the companies making '020 boxes use it? The biggest problem is that it was in vaporware status for so long that the various manufacturers couldn't wait and had to implement their own idea of an MMU. Since the device is farily complex, if not baroque, most opted for simpler, non-compatible mechanisms rather than trying to emulate it. Of course it isn't the fastest thing in the world either, so I you want to run at maximum speed or implement fast cache memory it just gets in the way. -- George Robbins - now working for, uucp: {ihnp4|seismo|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
jec@iucs.UUCP (04/03/87)
The problem with the 68020 is that it doesn't have an MMU (this is supposedly fixed by the 68030). The "standard" Motorola chip that was out there when the 68020 came out was the 68451 MMU. It was a real dog if you were trying to implement something like UNIX. The newer chip, the 68851 sounds a lot better and I suspect that the 68030 MMU will look a lot like that it. So, the current standard MMU for the 68020 is probably the 68851 and the reason people didn't use it in their workstations was that it wasn't available at that time.
fnf@mcdsun.UUCP (04/06/87)
In article <969@crash.CTS.COM> billd@crash.CTS.COM (Bill D'Camp) writes: >Fred, > >Something I wonder about with all this talk of standard versus >custom MMU's, if the standard MMU for the '020 is so great, how >come none of the companies making '020 boxes use it? From what I've >gathered by talking with people from Sun, SGI, and Masscomp, to name >a few, they all use custom MMUs because there is a SIGNIFICANT penalty >involved in using the standard chip. Is this correct, or is it just >an excuse to limit software portability? > >Any personal opinions on this issue, I don't expect you to speak for >Motorola, but I'm sure that there is a lot of interest if you could >get an official reading from. I have an MC68851 Manual that has been sitting on my bookshelf collecting dust for the last six months. Maybe I should read it sometime :-) (tells you what I know about the details of the chip itself). I can speak from my experience at Unisoft. Only a relatively small number of companies that implemented MC68000/MC68010 systems a few years ago used the standard Motorola MMU available at the time (MC68451) precisely because of performance penalties and limitations of the chip itself. As fate would have it though, since that *was* the standard at the time, ports to the systems using the *451 were very straightforward (after the first one) and Unisoft actively sought out such customers because of this. I expect the situation re the 020/851 to be much the same. As far as the performance considerations go, perhaps we could coerce someone at Apple to release dhrystone figures for the new Mac II under their implementation of Unix. I don't have any figures for percentage of *current* 68020 designs that use the 68851, but my impression is that the 851 has a much higher acceptance in the hardware development community than the 451 ever had. I believe the main impediment to its use is still low availability. I hope this helps to clarify things. Again, remember that these are my personal opinions only. The last time I did any hardware design was around the time the first Mac came out and Unix was something most people outside of the university environment had never heard of. It would be interesting to get some opinions from current system designers. -Fred -- = Drug tests; just say *NO*! (Moto just announced new drug testing program) = = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = = seismo!noao!mcdsun!fnf (602) 438-5976 =