-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Interware Booster 30-SE50F Info Dump
- Thread starter zigzagjoe
- Start date
zigzagjoe
Well-known member
Fits like a glove! I'm super excited that worked as expected.
micheledipaola
Well-known member
ok breaking the piggybank in 3, 2....
I was lucky enough to get my hands on one of zigzagjoe's prototype boards and have a couple of notes to share.
My main interest in getting my hands on one was to validate my ethernet card with it - on that front, I'm happy to say that it works really well, and the faster processor does wonders for network throughput, confirming my suspicion that networking performance on the SE/30 is largely CPU-bound, rather than IO bound.
However, the same can't be said for my RasterOps ColorBoard 264. With the accelerator installed, it never displays its splash screen, and the system locks up hard at the point in the boot process where the driver would normally load. We chased this down to an *extremely* lazy DSACK rise time - so slow that it was causing the bus cycle *after* an access to terminate prematurely because it was still at a logic-low voltage well into the next cycle, with often disastrous counsequences.
The channels in the attached scope trace are:
It's still a bit of a mystery as to why the rise time is so slow on that card specifically - adding extra pullup resistors to /DSACK made things a little bit better but didn't fix it entirely. I was able to get it mostly working by adding some external logic to explicitly drive /DSACK0 and 1 high during the period between /AS getting deasserted and the next cycle starting. With this brute force 'fix' in place, the card mostly works, but occasionally has display glitches as though some writes aren't quite making it through. I suspect that it's just not quite up to the tighter timing requirements imposed by the faster processor.
C'mon DSACK, you're letting the side down!
Success! (sort of)
My main interest in getting my hands on one was to validate my ethernet card with it - on that front, I'm happy to say that it works really well, and the faster processor does wonders for network throughput, confirming my suspicion that networking performance on the SE/30 is largely CPU-bound, rather than IO bound.
However, the same can't be said for my RasterOps ColorBoard 264. With the accelerator installed, it never displays its splash screen, and the system locks up hard at the point in the boot process where the driver would normally load. We chased this down to an *extremely* lazy DSACK rise time - so slow that it was causing the bus cycle *after* an access to terminate prematurely because it was still at a logic-low voltage well into the next cycle, with often disastrous counsequences.
The channels in the attached scope trace are:
- Board select (/AS & addr=0xFBxxxxxx)
- /DSACK0
- /DSACK1
- /AS
It's still a bit of a mystery as to why the rise time is so slow on that card specifically - adding extra pullup resistors to /DSACK made things a little bit better but didn't fix it entirely. I was able to get it mostly working by adding some external logic to explicitly drive /DSACK0 and 1 high during the period between /AS getting deasserted and the next cycle starting. With this brute force 'fix' in place, the card mostly works, but occasionally has display glitches as though some writes aren't quite making it through. I suspect that it's just not quite up to the tighter timing requirements imposed by the faster processor.
C'mon DSACK, you're letting the side down!
Success! (sort of)
Last edited:
zigzagjoe
Well-known member
Great writeup. This is the exact same symptom I experience with an old Shiva Etherport SE30 card - unfortunately I don't have quite as much visibility into the signal quality, but I'm suspecting it's a similar issue where a signal gets held too long and rolls into the next 47mhz clock cycle. Hopefully I can tweak on the GAL logic when I have a new testbed card in hand to try to get some better behavior.
Spoke a little bit too soon about getting the ColorBoard working - the rise time issues are only half of the story, it also appears to be holding DSACK asserted for too long as well. Most of the time, my fast rise-time hack was enough to make it work, but in some cases, the ColorBoard was still holding DSACK down for long enough to interfere with subsequent cycles. Most of the time this would just cause graphics corruption, but it will occasionally just crash the machine outright.
There are a few other options to explore, still - tweaking the GAL logic on the accelerator is probably the most promising way to resolve this, we're working on some ideas there.
There are a few other options to explore, still - tweaking the GAL logic on the accelerator is probably the most promising way to resolve this, we're working on some ideas there.
Cost-cutting / didn't read the CPU manual properly (I'm betting the first!)
Quoting from the '030 UM on asynchronous bus cycles:
That's negate, not tri-state or deassert. The device should actively drive the signal to logic 0 (so +5V) before tri-stating for the next bus cycle, as relying on pull-ups only might be too slow. IIRC I have a design document somewhere explaining this more thoroughly than Motorola's documentation (or is it for the '040? same idea). I suspect your card doesn't do it and for a sufficiently slow clock, sufficiently strong pull-up, and sufficiently low capacitance, DSACKx are negated in time so it all works. Change something, and things go seriously haywire...
zigzagjoe
Well-known member
Huh. I didn't realize about the negate part. I've got a project underway that I hadn't immediately planned for that on, so that may get interesting...
The documentation doesn't make it obvious in any one place, other sources are sometimes clearer. The important bit is a note right at the beginning of the UM in the preface:
(emphasis mine).
In the flowchart the negation of /DSACKx (or, in my case, /STERM) is also explicit, as it is in the text, but the exact meaning it not repeated and the subsequent tri-stating (which is also indispensable!) is not there either, hence the potential ambiguity.
IIRC, both SBus and NuBus (which are both IEEE standard, this might explain that) are much clearer on the subject and so I was forewarned when doing the IIsIFPGA and QuadraFPGA.
Huh! That would make sense, I suppose.
I took a closer look at the rise time on my own card, and it's also pretty marginal. In my case it was easy enough to add a 'fixup' state to drive DSACK high between being deselected and /AS next going low. Very glad I switched to a CPLD for my glue logic!
zigzagjoe
Well-known member
Updated card compatibility list:
Known good:
Interware GrandVimage
Asante MacCon
Farallon TP594
@halkyardo SEthernet
Carrera 040 (Yes: You can switch between the ~50mhz 68030 and the 68040! Isn't that a hoot?)
Known incompatible:
Shiva Etherport 30
Rasterops Colorboard 264
Micron Xceed (All models)
Known good:
Interware GrandVimage
Asante MacCon
Farallon TP594
@halkyardo SEthernet
Carrera 040 (Yes: You can switch between the ~50mhz 68030 and the 68040! Isn't that a hoot?)
Known incompatible:
Shiva Etherport 30
Rasterops Colorboard 264
Micron Xceed (All models)
zigzagjoe
Well-known member
Yep, it's straightforward enough to add the sensitive addresses to the existing logic so as to support IIsi ROM also - just requires a bit of ROM spelunking
zigzagjoe
Well-known member
ATF -15ns work perfectly (they are more like 10ns, anyways...)Nice
