don@vax1.acs.udel.EDU (Donald R Lloyd) (08/06/90)
Just a semi-random thought that hit me not too long ago...
How cheap/easy would it be to make an '030 board for the 3000? This
would be much cheaper than similar 2000 products -- no need for 32-bit
RAM or SCSI controllers on board. Since the 3000's processor slot allows
the '030 that's already there to work in conjunction with whatever's on the
accelerator, you could have a 33, 40, or 50 MHz '030 & optional '882 of similar
speed running with the 25 MHz handling some of the menial i/o type tasks.
This would probably be a good bit cheaper (though not as fast, of course)
as an '040 board, and would be do-able with chips that are already available.
A few empty sockets for some SRAMs for a small cache would be nice, too...
(If you like my idea, buy me a 3000 and I'll let you use the idea
without threat of a Look & Feel suit... :-)
--
Gibberish .sig for sale or lease.
is spoken Contact don@vax1.acs.udel.edu for more information.
here. DISCLAIMER: It's all YOUR fault.donb@bushido.uucp (Donald Burnett) (08/06/90)
Actually that same concept is what will keep down the cost of 040 boards for the A3000. The Supra 040 that I saw at the show (en mock-up) will run between $1200-$1500 which isn't bad and should keep costs down. Note:Supra I am not trying to speak for you, I am just estimating cost via a projected figure you gave me at AmiExpo. -- ****************************************************************************** ***** ***** ***** ***** ***** *****
david@twg.com (David S. Herron) (08/10/90)
In article <6812@vax1.acs.udel.EDU> don@vax1.udel.edu () writes: >the '030 that's already there to work in conjunction with whatever's on the >accelerator, you could have a 33, 40, or 50 MHz '030 & optional '882 of similar >speed running with the 25 MHz handling some of the menial i/o type tasks. naaaaahh... don't leave it to the menial i/o tasks ... make Amiga DOS a fully multi-processing OS ... that is, let both processors run processes ... I mean, after all, that's probably the next `neat' thing that the Apple people will try to invent. So therefore the Amiga needs to Blaze This Trail! :-) -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
dailey@kira.uucp (Chris Dailey) (08/16/90)
In article <7727@gollum.twg.com> david@twg.com (David S. Herron) writes: >In article <6812@vax1.acs.udel.EDU> don@vax1.udel.edu () writes: >>the '030 that's already there to work in conjunction with whatever's on the >>accelerator, you could have a 33, 40, or 50 MHz '030 & optional '882 of similar >>speed running with the 25 MHz handling some of the menial i/o type tasks. >naaaaahh... >don't leave it to the menial i/o tasks ... >make Amiga DOS a fully multi-processing OS ... that is, let both processors >run processes ... >I mean, after all, that's probably the next `neat' thing that >the Apple people will try to invent. So therefore the Amiga >needs to Blaze This Trail! Multiple processors bring up many other problems. For one, what about memory access? If each processor eats up bandwidth, that would only allow each processor to access memory when the other can't. If you had two totally separate memory areas, then that would make graphics stuff hard. To sum up, HEADACHES! ><- David Herron, an MMDF weenie, <david@twg.com> ><- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> ><- Sign me up for one "I survived Jaka's Story" T-shirt! -- /~\ Chris Dailey (CPS Undergrad, SOC Lab Coord, AMIG user group Secretary) C oo dailey@(cpsin1.cps|frith.egr).msu.edu (make WP5.1 for the Amiga) _( ^) "I am thankful for one leg. To limp is no disgrace -- / ~\ I may not be number one, but I can still run the race." -from B.C.
david@twg.com (David S. Herron) (08/20/90)
In article <1990Aug16.163645.26072@msuinfo.cl.msu.edu> dailey@kira.uucp (Chris Dailey) writes: >In article <7727@gollum.twg.com> david@twg.com (David S. Herron) writes: >>In article <6812@vax1.acs.udel.EDU> don@vax1.udel.edu () writes: >>>the '030 that's already there to work in conjunction with whatever's on the >>>accelerator, you could have a 33, 40, or 50 MHz '030 & optional '882 of similar >>>speed running with the 25 MHz handling some of the menial i/o type tasks. >>naaaaahh... >>don't leave it to the menial i/o tasks ... >Multiple processors bring up many other problems. For one, what about >memory access? If each processor eats up bandwidth, that would only >allow each processor to access memory when the other can't. If you had >two totally separate memory areas, then that would make graphics stuff >hard. To sum up, HEADACHES! er.. isn't that why Commodore hired such a wonderful hardware-guy like Dave Haynie ;-) to work out such things? Seriously.. Multi-processing is a very doable thing but it takes more effort to design one of those systems which would probably drive the price out of the low-cost ballpark. Fortunately AmigaDOS is already written (or mostly so) handle most (all?) of the potential problems in guarding against multiple accesses to data structures. Since it's multi-tasking internally AmigaDOS has had to guard against other DOS tasks mucking with data structures & it has (assumably) a bunch of semaphore-like tricks to do it. As for the hardware part of it ... (I'm not an expert on parallel processors, but I have studied the subject and I was sysadmin on a sequent for a few years..) There's a few types of parallel systems .. The Sequent is a "tightly coupled" system but with comparatively few processors to some systems (the Connection Machine, for instance, has upwards of 32,000 processors and is conceptually any number of them). The processors share a common bus (based on Multi-bus II), there are two processors per board. Current systems use 80386's running at 16MHz. On each board is a cache, that is assumably a write-through cache. Out on the bus is the main memory & peripherals. Yes concurrent processor access to the bus is a problem. But that's what caches are for .. to limit processor access to the bus. This is useful not only for sharing two equal processors in a multi-processing OS, but also for letting peripherals do their stuff without getting in the way of the processors. A problem with having two seperate caches in a system is consistency between the caches. A solution is, as I mentioned above, to use write through caches. That is, when a write is made to a cache it is also immediately written out to main memory. Er.. this also means that the other cache(s) will have to listen in on the bus to catch changes of memory locations it also has cached. All these are techniques I've heard of being used in commercial systems .. This won't be cheap to design ... If a dual-processor Amiga can be brought out for < $10,000 ... BTW.. (to give some impetus to going for a dual-(more?)-processor Amiga) ... Things like ray-tracers and animation programs would benefit a **LOT** from parallelization. For instance.. you could pre-calculate motion of the objects which will let frame rendering be done without having to depend on results in other frames. This lets you drop frame renderings onto other processors pretty much at will. In fact -- one of the things I wish I had time to do is to do exactly that kind of thing here. We've got all these workstations sitting idle at night y'see.. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!