Definitive Buster
                               by Dave Haynie

-----------------------------------------------------------------------------

 Editor's Note

  The following information is a text on interactions between the various
  versions of Buster chip, the Zorro III bus, and the A3640 processor board,
  kindly provided by the author himself.

-----------------------------------------------------------------------------

  System          Buster    RAMSEY    DMAC          CPU
  A3000/16        -07        -04      -01/02        68030-16/68881-16
  A3000/25        -06/07     -04      -01/02        68030-25/68882-25
  A3000T/030      -07        -04      -02           68030-25/68882-25
  A3000T/040      -07        -04      -02           A3640 3.0/3.1
                                                    (some have '030 too)
  A3000+          -09        -07      -04           68030 (68040 planned)
  A4000/030       -09/11     -07      N/A           68EC030-25
  A4000/040       -09/11     -07      N/A           A3640 3.0/3.1
  A4000T          -11        -07      N/A           A3640 3.2
  Nyx (AAA proto) -11        -07      N/A           Any CPU module

  The A3640

  The A3640 had two problems in its Rev 3.0 form. The first was a marginality
  -- its sampling of the local bus STERM* signal was marginal. This is fixed
  on Rev 3.1 with a cut and jumper. But beware, some boards marked 3.1 didn't
  get this fix, though apparently they're a small number.

  The second problem on the A3640 Rev 3.0 is a real live bug. This was a flaw
  in the bus arbiter that could allow the '040 and any local bus master on
  the local bus at the same time. Rev 3.1 incorporates -02 of the U209 PAL to
  fix this problem. It's not a perfect solution, though, in that it creates a
  potential for the local bus master to be locked out of the local bus for
  10's of microseconds, even if the '040 isn't using the bus. This was
  corrected in -03 of the U209 PAL, which makes your Rev 3.1 A3640 into a Rev
  3.2 A3640. Clearly, if you're not using cards with a DMA problem, this is
  not an issue.

  The technical detail on this is that, originally, the A3640 didn't handle a
  state of the 68040 bus arbitration scheme called "implied mastership". Most
  of the time the '040 wants the bus, it will assert either BR* (bus request)
  and/or BB* (bus busy); the former requests the bus, the latter holds it on
  the bus until it's ready to get off. However, the '040 can still claim the
  cycle after it negates both BB* and BR*. This is called implied mastership.
  The idea is that the '040 arbiter figures the current cycle will probably
  hit in cache, and decides to let another '040-like device on the bus one
  clock sooner than it might have. Other '040s understand this, and (when
  their arbiters are properly designed, at least) they can start taking the
  bus, but stop if the relinquishing '040 really isn't giving the bus back.

  The Rev 3.0 A3640 didn't handle this condition at all. So the implied
  mastership condition, which is fairly rare, would cause the bus arbiter to
  give the cycle over to a pending local bus request. The Rev 3.1 version of
  the bus arbiter prevented this, by holding the bus in this case. The
  problem with that is that when it happened, the '040 would usually hit in
  cache, but the bus would be locked against any other DMA device until the
  '040 needed the bus. A big waste, though fortunately rare. This is why the
  GVP PhonePak fails with Rev 3.1; it requires a fairly fine grained
  determinism when recording from the phone, and the Rev 3.1 card, when it
  locked up, could be off long enough to overrun any buffering it had
  available on-card. I was called in to fix this, and the Rev 3.2 board is
  the result; it handles implied mastership properly.

  Buster

  Next we consider the Buster chip. The Buster in the A3000, Rev 6 or Rev 7,
  is a well proven design. The difference between the two is only that there
  was a small bug in Rev 6 that caused it to fail at 16MHz, but it works fine
  at 25MHz. These are what we called Level I Busters; they don't support
  Zorro III DMA or Quick Interrupts, and they don't attempt to translate
  local bus burst cycles into Zorro III burst cycles.

  Starting with the unreleased Rev 8 Buster, we went to Level II, which is
  roughly twice the size of the Level I design. Level II Buster supports
  Zorro III bus arbitration, DMA, Quick Interrupts, and translation of local
  bus burst cycles into Zorro III "Multiple Transfer" cycles. There are two
  of these parts released: Rev 9 and Rev 11.

  The Rev 9 Buster has a few flaws. The primary flaw, and the main reason the
  part was revised, is that the Zorro III bus arbiter can jam under the right
  conditions. Some DMA cards, like FastLane Z3, use a workaround for this
  (they avoid the lockup condition), others don't, and will lock up when used
  with a Rev 9 Buster. There is also a potential problem with end-of-cycle
  synchronization in the Rev 9 part. Some Zorro III cards will demonstrate
  this problem, some won't. This is made worse by the STERM* sampling problem
  on the Rev 3.0 A3640. A final problem with Rev 9 Buster was introduced by
  the A4000 architecture. The integrated bus buffer, Bridgette, used in the
  A4000 can't quite guarantee the propagation times required by the Rev 9
  Buster design (done before Bridgette was proposed). In the typical case it
  works fine, in the worst case some Zorro III cards will have a problem with
  this condition.

  The Rev 9 part was the unfortunate victim of the wheels of "progress." The
  first problem was a changeover at CSG (Commodore Semiconductor Group) from
  channeled arrays to sea of gates. They had a number of screwups on these
  first parts (the Rev 5 or 6 RAMSEY was also affected), first some mask
  problems, then speed problems. About six months after I released the Buster
  design, I got back parts that ran at about 1/4 normal speed; during the
  A3000 project, we got back parts in more like one month. These problems
  were eventually fixed, just in time to suffer the change in engineering
  administration. I had a test bed project to prove all of the features of
  the Buster Level II chip, a multiprocessor board called Gemini, with two
  '030s, 4MB of RAM and an independent Zorro III hookup each. I had a
  prototype of this around the time of the slow Rev 9 Busters, but when the
  new administration took over, they wouldn't hear of any "Research
  Projects." Or projects, for that matter; they also tabled the AA project
  for 6 months, and killed the A3000+. But that's another story...

  Anyway, after the Rev 9 problems were discovered, I got to fix them, with
  the Rev 11 Buster. The Zorro III bus arbiter is fixed. All synchronization
  problems were fixed, and Rev 11 uses a double-strength driver on its STERM*
  line. Because of this, Rev 11 sometimes cures non-DMA Zorro III problems
  seen with the Rev 3.0 A3640 card -- that card's flawed STERM* sampling is
  right on the hairy edge, and the stronger driver makes Buster's STERM* fast
  enough, at least potentially, to avoid this problem. I still recommend
  upgrading to Rev 3.1, though, since it fixes the DMA problem, and the
  STERM* sampling may still be a problem in worst-case, or when RAMSEY or
  Gary drive STERM*. The bus buffer controls on Rev 11 Buster have been
  adjusted to support the A4000's buffering scheme perfectly; no properly
  designed Zorro III cards will have a data setup problem with Rev 11. This
  is especially critical for burst write cycles.

  Since it was the last chip of the A3000 architecture that we could revise,
  I figured a way to solve another A3000 problem in the Rev 11 Buster.
  There's a race condition between the end of a Zorro II DMA cycle, Gary, and
  the Amiga chips. When lost, you have problems with Zorro II devices reading
  Chip RAM during DMA. This was solved with external logic on the A4000
  series, and in Rev 11 I figured a way that Buster could play essentially
  the same trick on Gary. So Rev 11 Busters are a fix for Zorro II DMA
  problems on an A3000, but aren't needed for that alone on the A4000.

  Still Having Problems

  So maybe you're still having problems with Zorro III cards on the A4000,
  even with Rev 11 Buster and Rev 3.1 or 3.2 A3640, eh? I can think of a few
  things, though most would lie with the card design. The Rev 11 part runs a
  somewhat faster Zorro III cycle than Rev 7 did. This isn't a problem if the
  card was designed to the Zorro III spec; the A3000 architecture only
  allowed Zorro III to go at about 1/2 its potential rate. It might be a
  problem for any card designed more to "observed behavior," as defined by
  how an A3000 first behaved when released. Some cards may have a problem
  supporting burst cycles on Zorro III, since they couldn't be tested with
  the Rev 7 Buster. However, this is rare, since the only stock system from
  Commodore that could run burst on Zorro III is the A4000/030. That's
  because the A3000's Buster didn't translate burst cycles from the local
  bus, and the A3640 card doesn't translate burst cycles to the local bus.
  Also, most Zorro III cards identify themselves as "essentially I/O." These
  will get mapped as noncachable by the 68040.library, which means they don't
  get burst, even if you have an '040 card that bursts. On an '030, data
  burst is disabled by default (you can set it with a SetCPU-like tool), and
  no I/O card lives in instruction space, so still, no burst.

  A final Zorro III problem exists on some cards, including the A4091s from
  Commodore, though not necessarily DKB (eg, I don't know). Originally, there
  were a couple of ways for a Zorro III card to terminate a bus cycle. It
  could give the bus back during its last cycle or after its last cycle. This
  former mechanism can cause some problems, including bus lockups, when
  multiple masters are present. So I only recommend the latter mechanism --
  the card runs its last cycle, then unregisters the bus. This takes longer,
  but it's safe. This is only an issue when multiple bus mastering Zorro
  cards are working together.