ken@gatech.edu (Ken Seefried iii) (05/16/88)
I have been reading the '532 manifesto' with great interest. I think that the idea behind it is superb, and i am willing to contribute whatever i can to seeing it realized. However, i have some commentary to render on the system. I do not mean this as an attack on the idea or any individual, and these are my own personal opinions. It is most deinately NOT a flame.... *Physical Configuration: While designing the system as an AT motherboard replacement has many virtues, I feel that it would be more constructive to design the board with a much more useul and versitile bus. There are many chips now which vastly simpliy the interfacing of cpu and bus, for example the VME interface chips from Motorola or the Multibu II chips from Toshiba. However, there is a much simpler and cost effective way. I the back of the 32000 series reference book, there is the plans for a Multibus I interface. This would be a quick and easy way to get some very good expansion capacity. These days, Multibus I boards are very inexpensivequite reliable and generic enough so that they should work with the '532. There are also a huge number of different board types. We should remember that the PC/AT bus is slow and inefficient, and many AT boards probably will not work with a '532. *Display: I don't think much of EGA. I think that it would be much more interesting to design in one of the new graphics controller chips. I am particularly fond of the TI 34010, but another choice could be the Intel 82786. these chips are very versitile and support a wide variety of standards. They are also extremly fast and would compliment the '532 nicely. They also dont cost that much (sic) and can live in the same memory as the CPU if they have to (ie no expensive VRAMs). As a matter of interest, the TI 34010 can do more than graphics. It can CCITT group 3 & 4 image compression. People are using it in systems where it is the only processor, handling the graphics, communication and keyboard. This is one HOT chip.... On the other hand, if people decide that they want one of the IBM graphics standards, I would suggest looking at the Trident Microsystems VGA chip. It looks quite good and the sales person that I spoke to at Comdex mentioned that there was a company working on a 68000 board that uses this chip for video, so we know it works in an alien enviroment (from a Intel chip). Trident is willing to sell the chip alone and development kits for it. *Hard disk and tape: SCSI is the optimal solution... *Serial ports: I consider serial ports to be very important, and i dont really want to see them religated to an expansion card. Personally, I would like to see at least 2 (up to 6) 19.2k ports on the motherboard, if not RS-422. *Memory: Er, "tough shit" if i need more than 8MB memory? I for one DO need more than 8MB. I'd like to run ObjTalk (OO Lisp variant) and its not real happy with less than 10MB. This is a minor point for most people, as 8MB is a real good amount of memory for most situations. The only reson i bring it up is to point out that if we went with a solution like Multibus I for expansion, those of us with outlandish memory requirements can have it (at some performance penalty, of course). Realisticly, of course, it is unlikely that i would be able to afford 10MB of memory for quite some time...;'} *OS: I guess this is were some real religion comes in...sorry if i step on some toes. System V: I don't see this as a solution. Who is going to slap down $50K to buy the source license so that we can all get unix? Someone has to do it, correct me if i am mistaken. In any case, I would like to have the source to my operating system. BSD: Ditto above... Minix: A toy operating system never intended to do anything but educate (ask Tannenbaum). Not something I'd want to cripple a '532 with. Mach: This is a marvilous job. Well though out and well executed. Even better, it doesn't cost anything. Mach, from CMU, is a rewrite from (almost) the ground up of BSD 4.3. Mach does nifty computer science-y things like lightweight processes, advanced memory management and a buch of other goodies. The catch is that the group that wrote Mach didn't want to write certain things like device drivers, so they used AT&Ts. That means you have to have a source license to get mach going. I have heard that the GNU guys are working on removing the AT&T stuff from Mach so that it really will be free. I have my finger crossed. Perhaps we sould lend them a hand so we can use Mach on our little beasty....... V: Stanfords little toy. A dark horse, but a very interesting one. V is based on a very small and efficient kernal. It is claimed that it is readily portable, but i don't know for sure. I believe that it is inexpensive to get (media cost, perhaps?). I will research V some more, but I have heard some really good things about it. *DMA Daryl McDaniel mentioned the fact that he has been designing '532 systems with the AT&T 32104 DMA chip. The more i look at the specs for the 32104, the better this sounds. I vote for DMA. I really think for a chip with the speed of the '532, we need it. Thanks Daryl... *FPU I personally would like to see some way to add a floating point unit. This sould be an option however. The best thing i can think of is to bring all of the '532 lines out to a PGA connector, and then build a little daughter bord with the FPU that plugs in. This would make it easy to add a '381, '581 (if such a thing ever materializes) or perhaps a Weitek chipe set... Theres no such thing as "to much floating point"...;'} *Summary: There, for what it is worth, are my humble thoughts. In summary, my dream 32532 system would be: Physical: SBC with 2-6 Multibus I slots CPU: NS 32532 FPU: Optional socket SIO: 2+ 19.2kbps RS-232 GDP: TI 34010 ( or Intel 82786 or Trident TVGA ) DMA: AT&T 32104 Memory: 2MB expandable on motherboard to 8MB (32-bit) Mass Storage: SCSI Keyboard: IBM PC standard keyboard port OS: Mach ( or V ) I welcome commentary and constructive criticism. I also offer whatever assistance i can render. **DISCLAIMER: I am not a part of, nor do i represent any of the companies or institutions or products that I have mentioned. ken seefried iii ken@gatech.edu
yuval@taux01.UUCP (Gideon Yuval) (05/16/88)
> *FPU > > I personally would like to see some way to add a floating point unit. > This sould be an option however. The best thing i can think of is to bring > all of the '532 lines out to a PGA connector, and then build a little daughter > bord with the FPU that plugs in. This would make it easy to add a '381, > '581 (if such a thing ever materializes) or perhaps a Weitek chipe set... All you need is a socket that supports the 32381 and the 32580 Weitek interface chip (yes, the two are compatible, and one socket can support both -- here's 1 boo-boo we DIDN'T make). Once you have that socket, you can leave it empty, or plug a 32381 in, or -- for real FPU power -- plug in a 32580/Weitek pair. -- Gideon Yuval, yuval@taux01.nsc.com, +972-2-690992 (home) ,-52-522255(work) Paper-mail: National Semiconductor, 6 Maskit St., Herzliyah, Israel
boykin@encore.UUCP (Joe Boykin) (05/17/88)
In article <17145@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: > Mach: This is a marvilous job. Well though out and well executed. >Even better, it doesn't cost anything. Mach, from CMU, is a rewrite from >(almost) the ground up of BSD 4.3. Mach does nifty computer science-y things >like lightweight processes, advanced memory management and a buch of other >goodies. The catch is that the group that wrote Mach didn't want to write >certain things like device drivers, so they used AT&Ts. That means you have to >have a source license to get mach going. I have heard that the GNU guys are >working on removing the AT&T stuff from Mach so that it really will be >free. I have my finger crossed. Perhaps we sould lend them a hand so we >can use Mach on our little beasty....... Unfortunately, not quite true... For the present, look at MACH as two operating systems rolled into one, BSD 4.3 and MACH. The MACH portion, things like threads, IPC's, etc. is all new stuff. In addition, the BSD virtual memory system has been rewritten. The BSD portion, little things like open, close, read, write, creat, socket, pipe, the network, etc. while modified, is straight from Berkeley. CMU (and others) might like remove the requirement of an AT&T license, but that's a long way in coming. Even if the kernel was rewritten, what about all the utilities? Who's going to rewrite nroff, csh, sh, sed, awk, lex, c, ed, vi, etc. etc. etc? Sure there's some public domain stuff which is quite good, but the job is not even close to being finished. The MACH kernel will need an AT&T license for some time to come and the utilities which we all know and love will need to be replaced. ---- Joe Boykin Encore Computer Corp Research Group Chairman, IEEE Computer Societies Technical Committee on Operating Systems UUCP: encore!boykin ARPA: boykin@multimax.arpa
lars@myab.UUCP (Lars Pensj|) (05/18/88)
In article <17145@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: > > Daryl McDaniel mentioned the fact that he has been designing '532 >systems with the AT&T 32104 DMA chip. The more i look at the specs for the >32104, the better this sounds. I vote for DMA. I really think for a chip >with the speed of the '532, we need it. > We have considered designing a 532-system with 32104 DMA. However, there are problems with this chip: 1. It has another byte order than 532. That means that you have to swap the bytes in the system bus interface (nobody want tapes with swapped bytes). Now the software have to swap bytes in addresses. Ugly (and some overhead) ! 2. The data sheets (WE 32104 DMA Controller Information Manual) says: "Memory-to-peripheral transfers should not use request chaining if there is multiple channel activity". My interpretation of this is that you can not use data chaining if you use more than one channel. This is intolerable, because data chaining is very important if you want fast I/O. 2. The data sheets (WE 32104 DMA Controller Information Manual) says: "The source address of memory-to-peripheral transfers must be word-aligned (i.e., addresses divisible by 4)." If you use SCSI with disconnect-reconnect, the dma have to be able to restart on any byte boundary. Also when you do a 'raw' transfer from user memory, the data can have any alignment. It is not acceptable that the driver have to check and fix these problems. Now I wonder: are there really no DMA chip which do not have these problems ? -- Lars Pensj| {decvax,philabs}!mcvax!enea!chalmers!myab!lars
grenley@nsc.nsc.com (George Grenley) (05/24/88)
This is an interesting discoussion, but it is missing a couple of pertinent facts... Regarding the byte swapping issue, NSC's VME532 (and 332) boards "swap" the bytes, i.e., we put byte 0 where a 68xxx would expect to find it. This way test files transfer from 68xxx Unix (or whatever) machines to 32000 machines with no hassle. Obviously you want source level compatibility. The binaries come out "wrong", but we couldn't run 68000 binaries any way, so no loss there.... In article <355@myab.UUCP> lars@myab.UUCP (Lars Pensj|) writes: >In article <17145@gatech.edu> ken@gatech.edu (Ken Seefried iii) writes: >> >> Daryl McDaniel mentioned the fact that he has been designing '532 >>systems with the AT&T 32104 DMA chip. The more i look at the specs for the >>32104, the better this sounds. I vote for DMA. I really think for a chip >>with the speed of the '532, we need it. >We have considered designing a 532-system with 32104 DMA. However, there are >problems with this chip: Heurikon is about to release their 52532 based VME board, which uses the AT&T device. I don't know if that's where Daryl McDaniel works or not, but if it isn't perhaps some Heurikon engineer on the net would care to comment... >1. It has another byte order than 532. That means that you have to swap > the bytes in the system bus interface (nobody want tapes with swapped bytes). See above discussion re byte swap, go get pencil and paper, and see for your self. I can't expalin it in text, you need to look at a diagram. Also, consider that the DMA is only moving the data, not trying to interpret it, so it doesn't care about byte order. > Now the software have to swap bytes in addresses. Ugly (and some overhead) ! We haven't found the overhead to be any problem. If ou put DMA on the same "side" of the byte swap as the CPU, it will see the pointers the same. >Now I wonder: are there really no DMA chip which do not have these problems ? >-- > Lars Pensj| > {decvax,philabs}!mcvax!enea!chalmers!myab!lars There is one - "SW DMA". Seriously, the advantage of a DMA exists ONLY in systems where the DMA and the CPU can operate simultaneously. If you have to stop the CPU while DMA runs, you have gained nothing - remember, the 532 can move 4 bytes in 132 nsec at 30 mhz (R+W) - faster than DRAM anyway. So if you are building a low cost system, you don't need a DMA. Heurikon's board is aimed a performance conscious users, and since VME is multi master, and their on-board DRAM is dual port, it makes sense to have DMA - the 532 can still run, with some waitstates, maybe, but still running. A good choice for Unix and specialized real time applications. So why doesn't NSC have a DMA on our VME board? Easy - we couldn't fit it on. We have two boards FULL of chips already..... 'nuff George Grenley NSC (408) 721-5513... call me and buy a board! disclaimer: I hate IBM mainframes, especially PROFS.
cwwj@ur-tut (Clarence Wilkerson) (05/24/88)
and what would be an approximate price for the cheapest version ( I only need 6 mhz plastic). Clarence Wilkerson