Conference hydra::amiga_v1

    Wow!
    
    This is interesting. I have a 16MHz 68881. Do you know what 68020's
    are going for? Is this thing Zorro? How fast? (14.xxxMHz I assume?)
    Does it have 32 bit memory or cache or what? Does Abel carry it?
    
    Can you tell I want a '020 board?
    
    Can you say "eager?"
    Thanks,
    dov

    
    MC68020RC12B (12 MHz)   $199.95
    
    Jameco Electronics
    415/592-8097
    
    (see September, 1987 BYTE pp. 346-347)

    The same outfit in .2 sells the 68881 chip (12 MHz) for $149
    

    No good!
    
    I need 14MHz+ if I want to be in sinc. with Chip RAM. I really want
    16Mhz. Keep looking guys!
    
    dov

    re.: .4
        are you going to supply your own clock to the '020?  How?

    16 MHz version of both the '020 & '881 are available from ACP Inc,
    who advertise in Computer Shopper.  Expect to pay an extra $50 for
    the 16 MHz versions.
    
    If Mr. Kruger can come up with a working proto, would anyone be
    interested in pooling some money to have some boards spun by an
    outside shop?  I have no experience in this matter, but if a bunch
    of people could chip in hundred dollars or so, it might be
    cheaper than buying a Gemstone, Hurricane, or CSA board, all of
    which run for around $750 W/O a faster clock.
    
    Anyone interested, or am I being hoplessly naive??
    
    Ed.
    
    
    

    re.: .6
    Sure! ...but...
    
    	I have some literature on sticking a 68020 into a 68000 socket
    from a "Design Ideas" column in EDN (I think).  I also have a populated
    CSA 68020/68881 board in the wrong form factor for the Amiga; I
    did a mechanical kludge that sort-of works.  Believe me, based on
    cost of materials there is no way the simpler processor cards are
    worth more than about $50. unpopulated.  They consist of sockets
    and a couple of PALs.  
    	What I think would be neat is a 68020/68881 board with a clock
    and an SCSI adapter, as I recall seeing for the MACs; you could sneak
    the SCSI flat cable out of the case somehow, and have most of the
    bells and whistles you need in your A1000 except fast ram.  
    	For a hundred or so boards you could probably get them at about
    $10.  That's $100. investment each for ten gamblers among us.
    	Let's go!
    John

    
    	I already have a clock, a SCSI I/F, a winie, and empty sockets
    	for 4mb of RAM (basically a Supra 4x4)... but I can definitely
        see your point.
    
    	If we could get a PC board and some PALs to support sockets
        for a
    
    		68020 @ 14MHz (2xAmiga) and 68881 @ 16MHz
    		SCSI port
    		clock w/ni-cad
    		.5 mb of "A500" type memory (semi-FAST RAM?)
    
    	you would have all the basic features you need for a really
    	functional system in one box.
    
    	The circuit board could be populated to support different desired
    	functionalities.
    
    	...sounds neat!

    sounds good to me too... pity you can't toss a few more ram chips
    on it though..
    
    -dave

    I'm interested and willing too.  One possible problem - I'm getting
    an A2000, but if I can hack it to fit....

    re.: .10 
    >    sounds good to me too... pity you can't toss a few more ram chips
    >    on it though..

    O.K  Dave, will you do the dram design? 
    

    re: .12
    
    picky, picky, picky...  i'm just a poor software person, dram
    designing is not for mere mortals such as myself :-)  

    maybe someone else might be interested in doing it??
    
    -dave

    I think I have the DRAM design in hand. I intend to include 32 bit
    DRAM if at all possible. The 68020 has a fantastic design that will
    allow it to access 16 bit memory (slower, but the processing still
    goes faster) and 32 bit (VERY fast RAM, as opposed to merely FAST
    RAM!)
    
    However, having designed and having experience with a 68000 system,
    my first step is to find
    a Zorro board and build a faster (10-12MHz) 68010 machine. Another
    beauty of the 68xxx architecture is that it is completely asynchronous
    and thus, an external processor can be as fast as you like although
    it will have to wait for internal memory. But you don't even have
    to work at that -- it waits until the internal memory says "ready."
    
    When I have successfully debugged the intermediate board, then I
    will be prepared to modify it for warp speed. I came to this conclusion
    after learning the price of the '020. I don't want to have to deal
    with a new processor, and hooking my DRAM system in at the same
    time. And I want to minimize the chance of frying something, when
    the processor is going to cost $200+. However, let me point out
    that even the interim solution will be approximately 70% faster
    than the Amiga 68000, (assuming 12MHz) as long as it is accessing
    VFR (Very Fast RAM).
    
    Another reason for the interim system: with wirewrap, 12MHz is the
    outside limit. Any more and I will have to etch a PC board, which
    I have never done. Yet another reason to be cautious.
    
    re .?
    
    I don't remember who asked, but someone was saying would I have
    my own clock. The answer is "Yes." The clock is the trivial part!
    However, I still have to work out under which conditions one actually
    loses speed by not being in sych. It may actually not be worth running
    at 16 MHz (as opposed to 14.2xx) because an extra wait will be
    mandated. However, that is all cerebral for now, due to the
    aforementioned problems.

    I'll take a gamble and go in on this one.

    I missed something in the earlier question about clock frequency.
    The Amiga actually runs at 7.138*2, or 14.2xxx MHz. The 68000 sees
    half that. The blitter runs during the other cycles. Most of the
    68020  boards that I have seen claim a 14.2xx Mhz clock (CSA for
    example)
    
    Still hoping someone will manage to find a vendor of Zorro cards.
    So far, I've been looking without success. I do have an ace in the
    hole though....

    What kind of performance increase do you think one would see by
    just replacing the 68000 or 68010 with an 8MHz 68020 (clocked at
    7.138*2)?  Increases due to architectural extensions, on chip cache,
    superior internal design, etc...
    
    CSA claims the Turbo Amiga is 4x a 780 (~8600/8530) in numerical
    computations, but that is dependent on the 68881 FPU...

    
    RE. .16
    
    	If you can't find a source for Zorro I cards I will sell you
    one of mine ( never used ).
    
    
    		Steve Peters
    

    re: .17
    
    err, I guess I ment to say ...with an 8MHz 68020 clocked at 7.138
    MHz  (that is, off the existing 680xx clock circuitry)?
    

    
    What about building a multiprocessor 68020 board that would work
    with the existing 680xx CPU.... Maybe support "n" 68020 chips...
    I smell Simetrical Multiprocessing.....
    
    It would be dirt-simple to support this with the existing Exec...
    given that there is no VM...
    
    Really!  What a great idea... all we would need is just some basic
    circuit to supply power, clock, and buss-access to another "n"
    68020/68881 chips and some sort of an "interprocessor doorbell"
    interrupt!!

    re.: ...yea, and then we could put it in a tube and shoot it into
    space;  piece of cake!

    
    OK... lets scale back then...
    
      How hard would it be to add two more 68010 chips to the buss (running
      at the system buss speed (7.XXX MHz))?
    
      Given this, how hard to decode two lines (from each 68010) to
      run from each of these chips to the Amiga interrupt priority
      generator chip (see Interrupts section of RKM Volume 1.) and
      likeswise run a line from the Amiga interrupt priority generator
      chip to each of the two 68010's IRQ lines..?
    
      You would then have three 68010's, each able to interrupt the
      other... (presumably so some system software could schedule tasks
      and such against each.)
    
      The power and interrupt stuff would seem easy... it seems like
      the buss interface (the clocking itself) would be the difficult
      part..
    
         let's hear it from you hardware types!

    re .19
    You could run at 14.2x MHz NO PROBLEM. The bus is completely
    asynchronous, ie processing goes as fast as the clock and waits
    until memory sends the ready signal. The on chip cache might give
    you as much as 2x the 68000 performance, if you count the higher
    clock and 32-bit operations in a single bus cycle as well. (Don't
    forget, one thing that hampers the 16 bit 68000 is the fact that
    pointers are longwords and are therefore expensive to manipulate.)
    
    re later comments on multiprocessing:
    you might be surprised how easy the hardware part is. There is
    asynchronous bus arbitration. Each processor could assert its bus
    request line, and be granted the bus by the reigning processor.
    The problem is two fold. First, to get good performance, you would
    need a fair amount of cache or a large local memory. That is tougher
    to build. Second, you would need some nasty software to distribute
    the load. As far as I know, that is very non-trivial as the VMS
    boys and girls are finding out.... So, if anyone's got any ideas,
    I'm willing to come up with the arbitrator schematic. YOU can build
    and debug the system!
    
    About CSA performance --
    it should be roughly 3.5 MIPS and I guess they claim more like 4
    in some best case scenario. Computationally, it really should be
    something like 4 VAX780's. The interesting thing that I've seen
    in benchmarks and in real life experience is how much faster
    performance dies on a 68020 with virtual memory and a VAX. The VAX
    can take 10 users and be running faster than a 20MHz Sun
    with 5. I've heard a professor guess that this is because the VAX
    caching strategy is much more sophisticated. Anyone got any ideas?
    Has anyone else observed similar behavior?
    
    Don't get me wrong -- the thought of owning 4 VAXen makes me DROOL!
    And my machine supports only 1 user -- albeit with 10 windows....
    8-) dov

    
    To make Exec do multiprocessing, I would need some sort of
    interprocessor-interrupt to allow a (new) CPU supervisor
    to implement some sort of memory-interlocking primitives.
    
    Its then just a matter of modifying the Exec kernel to schedule
    tasks against three CPUs instead of one.  Some changes to the existing
    interrupt handlers would also be necessary.  (Basically, all Supervisor
    Mode stuff would half to be reevaluated.)
    
    I don't think that Exec would have the same type of problems VMS
    has had going to SMP because there is no fork-type processing going
    on inside of Exec.  All of the devices are implemented as processes
    which communicate via "message passing".   Once the initial interrupt
    has come in from a given device (on one of the CPUs) some basic
    arbitration would have to go on as to which CPU has a handler declared
    to process that interrupt.  The interrupt would then be handled
    on that CPU (which presumably would have the device-driver process
    for that device on it.)  The device driver would then handle the
    I/O normally.
    
    The only gray area I still see would be how to avoid two processors
    writing to the same memory location at the same time.  The VAX has
    buss interlocked instructions to provide for this.  I don't know
    if the 68000/68010 have this (I am pretty sure the 68020 has them.) 

    I think we should scale back this topic to the hobbyist hacker level;
    I don't think its appropriate to discuss VAX internals with regard
    to improving the Amiga.  What seems like common knowledge to those
    familiar with the VAX guts may indeed be trade secret information,
    which this conference may help to compromise.  I would like to improve
    my Amiga, but not for the ultimate benefit of DEC's competition
    at the expense of the family jewels.  A more fruitful pursuit might
    be the following idea that I'd like to work on:
    	Expand the Amiga chip ram to 512k bytes per screen.  The bank
    switching required would be synchronized to the horizontal retrace,
    which is practical because all screens are the entire width of trace.
    This ram could be fast ram until allocated for the special purpose,
    and the video function could work out of a second ram port.
    John

    > I would like to improve my Amiga, but not for the ultimate benefit
    > of DEC's competition at the expsense of the family jewels.
    
    Who said anything about competition?  And besides, there are many
    symetrical multiprocessing 68000 based systems out there: Convergent
    Technologies makes one that comes to mind called the MegaFrame.  
    
    As long as all of this is non-commercial and for internal academic
    purposes only, it really benifits our company for us to be creative
    with ideas like this.  Who knows, perhaps one of us will concieve some
    great new DEC product as a result of our Amiga hacking!!!
    
    I thought this topic was on 68020s anyway... lets drop SMP.

    re: super computing
    
    too much one-plusing. 
     Suggestions: 
       1. first implement the 68020 as a replacement cpu.
       2. Then based on the knowledge gained by that, implement it as
          a co-processor board with 32 bit memory.
       3. Then you use them together to implement a two CPU SMP.
    
    By the time you get to step 3, Commodore may have already added
    extensions to the OS to support SMP, and maybe even protected mode
    memory.
    
    re: more ratholes
    i like the bank switched chip ram tied to screens idea.  The problem
    is that not just graphics comes out of chip ram.  Any other programs
    using it would be in for a nasty suprise when switched out.  How
    about implementing virtual memory for chip ram?  That way you can
    allocate all the memory you want, and let the OS worry about making
    sure it is swapped into chip memory when it is needed.  This of
    course could be as much fun to implement as SMP :-)
    
    -dave

    There's been some concern that this conference might be revealing some
    deep dark secrets about Symmetrical MultiProcessing.  I'm not too
    worried.  For one thing, SMP isn't new in the industry.  GE was doing
    multiprocessing on its 600 series 20 years ago.  For their own
    operating system, GECOS (later 'GCOS' after merger into Honeywell),
    they chose to be symmetrical except for the fielding of interrupts,
    which all came to the master processor.  Multics, which was built on
    the same basic hardware, chose to be fully symmetrical.  Note that
    neither CPU implemented some of the niceties like interlocked queue
    instructions; GCOS was originally controlled entirely by the ability to
    interlock the LDAC (Load Accumulator and Clear (it)) instruction.
    
    When processor cache was added (10 years ago), new strategies were
    needed to deal with synchronization of the cached images of control
    structures, but that problem too has long been solved.  The biggest
    problem is trying to retrofit multiprocessing disciplines on software
    which was written assuming a uniprocessing environment.  That's where
    the VMS crowd (and many, many others) have had their work cut out for
    them. 
    
    I believe that Asymmetrical MultiProcessing would be sufficient for the
    Amiga.  That is, any/all processors would share equally in dispatch of
    the various active tasks, but only the first processor would bother to
    field interrupts.  It might take some cleverness to have application
    processors initiate I/O requests such that the interrupts comes back to
    the first processor.  It's obviously important for the system's task
    synchronization mechanism to work across processors, so any programs
    which take short-cuts would be problemmatic.

    SMP was also implemented in DEC's 36-bit machines at least 10 years
    ago.  The 68020 has some appropriate instructions, too: TAS, CAS
    and CAS2.  However, you are also talking about a rewrite of the
    operating system kernel.  Who is volunteering for that?
    
    I agree with -.few that it's better to approach this gee-whiz stuff
    in steps.  When the brave designers (whoever they may be) get to
    adding 32-bit memory, they should have lots of fun with DMA between
    the 16-bit expansion bus and the 32-bit memory.

     SMP was also done by Univac and Burroughs in the early sixties.  DEC
has done it with TOPS-10 and RSX, although the RSX version never sold.  The
comment in .-1 is rather, er, curious - the DEC SMP products were strictly
upward compatible with regard to applications.  I shudder to think what
applications on God's Chosen Operating System (:-) were doing that caused
them to get bit the by the uniprocessor to multiprocessor transition.

     Regarding interprocessor interrupts, the TOPS-10 version of SMP was
done without any hardware mods to speak of - there were no interprocessor
interrupts.  Maintaining cache coherency during I/O is indeed a pain if
ya don't have coordinated caches, a feature present in nearly all more recent
hardware designs for machines intended to run SMP.  Anyway, instead of having
interprocessor interrupts on TOPS-10, I/O that needed to run on another
processor was simply queued to that processor and each processor checked
its queue every 60th of a second.

     Another interesting point is that the operating system that AmigaDOS
is partially based on, Tripos, was multiprocessor operating system.  I wonder
how much delobotomization would be required. . .
								whatever,

								   RP

    
    RE: .27
    
    I agree entirely...  It makes good sense to implement an Amiga
    SuperMini in stages.  I am really not a big fan of SMP vs. more
    MIPS anyway.  Perhaps after a successful M68020 replacement
    board, we could look into fast memory and higher clock frequencies
    (someone mentioned a 20MHz 020!)  At that point, I think the Amiga
    custom graphics chips would start to become the bottleneck, so it
    probably doesn't make much sense to go on to SMP.
    

    re: .30--I don't know about Univax, but the Burroughs multiprocessor
    of the early 60s (the B5000 and B5500) wasn't symmetrical: the second
    CPU couldn't run the kernel--an attempt to enter supervisor state
    (or whatever it was called, it's been a long time) on the second
    CPU would cause it to halt and send an interrupt to the master.
    The master would execute the kernel and its scheduler could dispatch
    the second CPU.
    
    The B6500 and later systems were SMP, but they weren't available
    in the early 60s.
        John Sauter

     Actually, the Burroughs I read about being SMP wasn't their civvy
computer, it was some high availability military job with 3 digits in
the name insteada 4 (I dunno how many back issues of which magazines
I'd have to dredge to find the sucker).  Regardless, the point is it ain't
that uncommon, historically speaking.  And multiprocessing was was once in
Tripos, before Tripos got put on the Amiga.  Maybe it can be put back in. :-}

    re .29
    
    I don't believe that there is DMA to fast RAM. DMA, like all other
    non-68000 operations, happens only to chip RAM. Is this not true?
    In any case, even if DMA can access fast RAM, I don't see the trouble.
    Like all the rest of the memory, it is asynchronous and the DMA,
    being used to such things will wait until it gets the ok. It shouldn't
    be a problem if the memory is faster than expected. If the memory
    was extra *slow* I might expect some trouble. Still, it's an
    interesting point that I'll have to check on. Gotta find them docs
    buried since the move....
    
    dov

Re: .34

The DMA provided but the custom chips does indeed go only into chip ram.
However, an external DMA controller can transfer into fast ram.  For example,
the Commodore hard disk controller (also used the by Byte-by-Byte) does DMA
transfers into fast ram.

    re .31
    
    While I shudder to think of the horrendous complexity involved,
    you can actually get 25MHz 68020 parts. How much they cost, and
    what you have to do to shield them from noise, I don't know. I'll
    bet it isn't easy to get them to work :-(
    
    dov

re: < Note 703.30 by MOSAIC::PRAETORIUS "_636741600744_" >
                                 -< old hat? >-
    
    Er, and another computer company slightly larger than this one
    introduced MVS on SMP 158-2s in 1977.  I believe that DG's largest
    machines are SMP and so are Spurrough's.
    
    SMP Amigas would be real neat...
    
    BoBW
    

    IBM was shipping SMP before the 370/158.  Does anybody remember
    the MP65 option of OS/360?  It ran on the System/360 model 65
    with special mods to let two CPUs share memory and an inter-CPU
    doorbell.  It was introduced in the late 60s, if I remember correctly.
    Not the first multi-processor, by any means, but one of the first
    SMPs, since both CPUs could run the kernel.
    
    DEC's first MP system was the 1044, built from two KA10 processors
    sharing memory.  It was ASMP since only one CPU could run the kernel.
    
    It isn't very hard to convert a single-CPU operating system into
    an ASMP operating system.  I did it for the Stanford AI lab in 1968,
    using a KA10 and a PDP-6 processor (the 166).  If we had sources
    for AmigaDOS we could probably add ASMP support without much trouble.
    SMP is much harder, since you must now interlock the kernel's data
    structures against other kernel threads.  With ASMP there is only
    one kernel thread.
        John Sauter

    re .30-.33
    
    The machine was the Burroughs D825 Modular Processor.  I hate to
    admit to being this old, but I was one of the designers.
    
    Bill

    On SMP on KA10s...a group of hackers in sweededn have it running
    on v703 - see the TOPS notes file...
    
    BobW
    

    somehow i get the impression there might be a few folks in this
    notesfile who know how to implement SMP.  Since that sounds like
    a mostly software project... how about the new Amiga SMP 1500?
    (superglue a 500 to the top of a 1000, connect the buses)
    
    That would give you off-the-shelf identical processors, memory,
    etc.  Having a keyboard, monitor, and disk attached to the second
    processor might make debugging the SMP a little easier.
    
    -Dave

    re .41
    
    That's an interesting concept! Communication by fast RAM transfer,
    huh? You would need fast RAM, though, and a tiny bus contention
    circuit. It's actually not very different from putting a 68010 or
    68000 up on the expansion bus except there is less wiring (no memory).
    Almost all the signals are the same. But if you don't have memory that
    would present a little problem. Maybe a small static cache? (16k) Or
    queue? Hmmmmm....
    
    How much would you have to change the kernel to make SMP work? There
    aren't too many windows of vulnerability are there?

    re: .42--"How much would you have to change the kernel to make SMP
    work..."
    
    That depends a lot on the design of the kernel.  TOPS-10 and VMS
    needed a lot of changes to make SMP work, and I suspect OS/360
    did too.  Without an opportunity to examine the AmigaDOS sources
    I wouldn't make any commitments about how long it would take.
    
    ASMP, on the other hand, is much simpler.  Burroughs showed the
    way with the B5000, and all ASMP designs that I am aware of used
    the same approach (though with less hardware support).  ASMP could
    be implemented with just an inter-processor doorbell in a few months.
        John Sauter

    Interesting news!
    
    The 68030 is starting to trickle out to developers in small quantities.
    Price is $900 for a 16 or 20MHz part (that is the one part of my
    information that is hazy).
    
    Clock for clock, the 68030 is supposedly yielding *4* times the
    performance of the 68020. Since the 80386 is about on a par with
    the '020 (although weird and biased benchmarks in Byte may show
    differently) this means that once again, Motorola is a generation
    ahead of Intel.
    
    Put that in your SMP pipe?

    For those who wish to do it themselves, Motorola has finally issued
    Ap Note AN944/D

        "MC68020 and MC68881 Platform Board for Evaluation in a 16-Bit
    	 System"
    
    This describes a little board which plugs into a 68000 socket and
    contains a 68020, 68881, 4 PAL chips and 6 pullup resistors.  On
    Moto's base CPU board, an M68KVM02 running many wait states at
    8 MHz, the '020 with cache on performed better than 50% faster on
    all benchmarks except two with a lot of branching.
    
    This design does _not_ include 32-bit memory and was not tested
    at faster than 10 MHz.  From sketchy descriptions, it is plausible
    that both the Gemstone (Emerald?) and Hurricane commercial boards
    were based on draft versions of this ap note.
    
    If anyone wants a copy and can't get it quickly from Motorola, please
    request one from me by e-mail.
    
    If someone is willing to swap the ap note for a 16 MHz '020 chip,
    I will _hand_deliver_ their copy  :-)  :-)  .

    Wes Plouff