Path: utzoo!attcan!uunet!peregrine!elroy!ames!pasteur!sim.berkeley.edu!heppell From: heppell@sim.berkeley.edu (Kevin G. Heppell) Newsgroups: comp.sys.nsc.32k Subject: More on build your own box (LONG) Keywords: plan ahead Message-ID: <7648@pasteur.Berkeley.EDU> Date: 21 Nov 88 22:12:15 GMT Sender: news@pasteur.Berkeley.EDU Reply-To: heppell@sim.berkeley.edu (Kevin G. Heppell) Organization: University of California, Berkeley Lines: 119 echo \$0.02 > net :-) With all of this recent discussion, since I've been planning a 32k series box for some time I thought I'd cast my vote. I'v given a summary first for the vote counters, but read the whole thing before hitting 'F' (for flame :-) 1) Definitely go with the motherboard option, instead of a plug in for some other system. While we're at it, make the motherboard an SBC: full 32032 chip set (CPU, MMU, FPU, TCU, ICU), 4 Meg DRAM in 1meg DIPs, SCSI, dual floppy, 2 serial and one parallel on board. 2) Make the board fast enough to run at 15 MHz with the 23C032 chip set. 3) Provide for expansion with 6 or 8 _NuBus_ slots. 4) With good expansion slots and an MMU (25 bit addr), we can add: - 16 meg addtl memory using simms on 1 or 2 boards - 332 or 532 co-processor boards (or both) - Ethernet (or other LAN) and more serial ports. - A CG16-based video co-processor board (details below) I'm willing to design this one. - 'foreign' co-processor cards (68k or x86, or whatever) - Other cards as desired. 5) The OS would be a variant of MINIX, with utilities (GCC esp.) adapted from other public domain sources. Now for some explanation: 1) Everybody wants to get away from brain-dead Intel architecture, otherwise why would we be trying so hard to get a 32k system up. Why fix _just_ the processor, when we can fix the whole board? I say 32032 instead of 32016 because of the improved performance for as little as $20 more. The speed hungries (myself being one of them) can put in as much performance as they like or can afford. Those who want a PC-bus card should go with Dave Rand's design, already stable with something of a user base (there was a user's group, but the contact I had has slipped a little). 2) A simple consideration which will improve performance and ease of upgrade. 3) The PC bus architecture is just as slow and awkward as the rest of the system. NuBus, at least, is an IEEE standard, supports 32 bits, and has a connector which can perform at reasonable speeds. From what I've seen of the inside of a Mac II, the AT-chassis form factor can be met with NuBus cards. Economies of scale still apply here. I think I could re-produce (with some work) most of the clone periphs on the market (at least the simpler ones) in quantity one for what I would pay at one of the local swap meets. And I thought the idea here was to split up the work to cut time and prototype costs. Besides, NuBus periphs are quantity items now. If anyone has a better bus standard, I'm open for suggestions. 4) With 25 bits of addressing, 20 out of a possible 32 Meg of space in DRAM seems reasonable. My personal preference is to use an ECC memory design, but that carries a 25-30% hardware overhead, and a wait-state speed penalty. Since I don't have a good feel for the frequency of dropped bits, this may not be necessary, but a simple parity checker that croaks anyway like the PC is not what I want. Since the 32k series is supposed to be upwardly compatible, it should not matter whether or not the on-board 032 or an added 332 or 532 is doing the work. An add-in card will keep initial costs down, allow for easy up-grade, and provide for an I/O processor with the high-perf one. For those who _really_ want a 532 based motherboard, consider this: you will get a much larger user base through the method I have suggested, which makes software and hardware support much cheaper. And by designing in the upgrade, the initial $1000 outlay doesn't disappear when you go up a class. See below for software considerations. No comments on serial I/o, except that NS16450 chips are a good choice, since one can shift to 16550s to get a FIFO buffer for better bandwidth. DMA is probably best added as an option. Apple is supposedly offering (or planning) co-processor boards for the Mac II - there is no reason (other than mass-storage overhead) why those couldn't be interfaced to this system, or a PC-emulator either. The BIOS would have to reside in RAM, with artifical hooks to the outside world, however. My personal favorite topic is the video I/O. I think it would be fairly simple to wire up a CG16 with one to eight 1Mbit pixel planes (4x64Kx4 video rams) on a single card. These could be configured in groups of 1, 2, or 4 1 Mbit blocks to provide just about any combination of pixel and color resolution, with the ability to link up to three cards (1024x1024x24bit resolution). Video data rates would also be variable by selection of time base, up to about 80MHz using AS or F shift registers. The hard part is isolating the processor from the data bus (no MMU for protection), and finding a source for the fast D/A's. Lastly, software. I would like to see full source available, without licensing costs (well, $200 is OK), and MINIX is about the only thing available _now_. I don't expect an exact port of MINIX; the memory manager would have to be written, but the file system and such are good enough to get everybody started. I think GCC is almost a necessity, but hasn't that port been done? GNU would be even better, but I don't want to wait for it (and with public domain hardware out, the FSF people may even help us port it). Consider also that with MINIX's message passing kernel and process queues, adding an additional processor is as easy as starting up another memory manager, with only one file system and kernel process. Different processors could be restricted to using different queues, i.e. with a 532, the 032 could run the fs process almost constantly. One more comment - if the interest to help design this is as big as it seems, we may have an economy of scale here - perhaps 1000 units if we consider those who haven't time, resources or skill to build one of the units, but who would gladly be willing to software hack if such a box existed. I think we could get a good deal on chips in 1000 unit quantities. I apologize for the length of this, but I saw a lot of people not thinking ahead very far, and I beleive design flexibility may be one of the strengths of the whole project. I'd be glad to help coordinate, but my time is quite limited with graduate school - isn't everybody's :-) Comments welcome, Kevin ------------------------------------------------------------------------------- Kevin G. Heppell 784 Santa Barbara Rd. ucbvax!sim!heppell Berkeley, CA 94707-2046 arpa: heppell@sim.Berkeley.EDU (415) 528-6396