> Hi there. I hope I haven't mailed stuff to hazy so that it's missed > you. Actually, I think George set up an system-wide alias so I get 'hazy' mail now too. > When gerard was last out, he mentioned a project one could describe as > a 500-'020. > Is this your baby? Sounds great. I have some questions. I don't want to > sound like I'm second guessing you, and I assume that any point of view > I might have has probably been raised, but I can't help myself. Can > you indulge me? This sounds more along the lines of what George was talking about for his "A800", or whatever the name originally was. > I haven't heard one way or the other, but is this machine planned to be > a stripped down box, or will it be deluxe? That is to say, is there an > MMU in there, and any fancy expansion stuff? I personally hope not. > What I'd like to see (just consider it an unweighted vote) would be > the cheapest and fastest closed box you can build. Maybe some > special access to fast/wide rams internally, but no special goop, > no wait states. They had specified a very cheap, probably hand-made MMU if any. Basically, a fast 68020 inside, normal Amiga 16 bit bus externally, maybe a meg or two of internal memory and expansion by another two of 32 bit wide memory in the box, normal 16 bit stuff outside. He was also looking at 16Mhz 68000s, but I think that's basically a dead-end right now. > You mentioned on the net once, that a goal of building a box that > whupped the MacII should'nt be too hard. I assume that means getting > one or both of the wait states out of there. You could beat them > even running at 14.5, right? Yup; with 1 wait state, 14.5 comes out faster than their 15.8 at 2 wait states. > Now, I've heard someone say that BobW's MMU won't introduce a wait state. > Possible? And I don't know what expansion bus plans you guys have for > the 020 2000. For my money, I'd settle for special 32-bit memory > bus with good old Zorro-16 for expansion, like some of the 386 > clone makers are doing. Low risk, high utility. I'm officially the guy on that project, called the A3000 at present, though all this 68020 add-on stuff has kept me from doing anything more than planning at this stage on the A3000. I do plan to complete a system spec this month for review by as many folks as possible. The Welland MMU/Cache set is a pretty interesting thing. It lets the 68020 run asynchronously to the expansion bus, from what I know so far, somewhat like the 68881 runs with the 68020. So I can run the 68020 faster, like maybe 16.667 or whatever the parts we get go up to, and get a faster system when running from on-chip cache. While the jury is still out in reality, simulations state that we should be able to run a 68020 at around 14-16MHz and talk to the MMU with no wait states, at least most of the time. When you think of wait states, they're really nasty. A 14.2Mhz 68020 is really going more than twice as fast as the 7MHz 68000, 'cause it can complete most memory cycles in 3 clock ticks vs. 4 of the 68000, if allowed to. So with two wait states, you're up to 5 clocks, with three, 6 clocks. So really, for expansion bus accesses on a Mac II, the 68020 is running at half speed. > So give me a clue and an education. It sounds to me like the > simpler the box, the cheaper, faster, and sooner. I can't see running > UNIX on a 500 (since I'd want the slots on my workstation), so if > you are planning on an MMU, fill me in on why. The cheap MMU idea is for UNIX, best as I can tell. George and Welland are serious UNIX-heads; sometimes I feel like I'm the only one in hardware that has ever even used AmigaOS, much less programmed in it. > One problem with the fastest box, is that it would be faster than a 2000 > with 020 and MMU, which might not please all of the people. At least > not all of the time. That's certainly true. I guess we have to do a 68030 add on for the A2000 after that, just to keep up. Another consideration is memory speed; we can just about get 1 wait state with 100ns parts and a 14.2Mhz clock, even without the MMU in the way. Any faster may cost too much. That's why the A3000 Cache is so nice; even with 7Mhz 16 bit DRAM on the bus, you'd still run respectably as things get cached. > Whatever you're up to, kick some Jack-butt while you're at it. Ahhh. Just what we have planned in the A3000. There's one more feature of the Welland MMU, and that has to do with the expansion bus it defines. Right now, I'm planning to have 5 or 6 slots fully compatible with the 16 bit stuff. A separate connector on some will give you access to the MMU defined 32 bit bus, which will share data line but probably not address lines with the 16 bit bus. The real magic of this setup starts when you have mainly 32 bit devices on the bus, especially RAM cards. The MMU can access 4 longwords from such a RAM card, using a nybble-mode feature most DRAM, in not much longer than it takes to access 1 longword at normal 14Mhz speeds (the MMU bus is self-clocked at around 14Mhz, vs. 10Mhz for the Mac II bus. Not only does this improve operations with the cache, it reduces 32 bit bus contention dramatically. So the main CPU, running at full load, may only access the bus 10% of the time. The other 80%-90% of the bus time can be used by other 32 bit cards without getting in the way of the main CPU. So maybe you add a card with 4 additional 68020s and MMU chips. This may not have immediate use under AmigaOS, but we're already thinking of porting the single CPU version of CMU's Mach OS, and CMU is already demonstrating their multiple CPU version. So there's already an OS on the way that we can use to support parallelism, and this kind looks to be much more useful than Jack's Transputers, at least at the moment, if anything ever does come of them. Also proposed are other 32 bit devices, like video cards and vector processors that can use this extra bandwidth. The vector processor was another Welland idea; a few of these and you may have around the floating point speed of the Cray 1; at least, that's the idea. Maybe real-time raytracing in a few years. > Cheers, man. I look forward to whatever you build. > jimm