Editor's Note
The following information is a text on interactions between the various versions of Buster chip, the Zorro-3 bus, and the A3640 processor board, kindly provided by the author himself.
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-3 DMA or Quick Interrupts, and they don't attempt to translate local bus burst cycles into Zorro-3 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-3 bus arbitration, DMA, Quick Interrupts, and translation of local bus burst cycles into Zorro-3 "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-3 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-3 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-3 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-3 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-3 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-3 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-3 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-3 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-3 cycle than Rev 7 did. This isn't a problem if the card was designed to the Zorro-3 spec; the A3000 architecture only allowed Zorro-3 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-3, 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-3 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-3 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-3 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-3 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.