Interware Booster 30-SE50F Info Dump

[zigzagjoe]

Got my hands on one of these and reverse engineered it. GAL JEDEC files attached.

Vital stats: 47 MHZ CPU (x3 SYSCLK), optional 47 MHZ FPU, no additional cache.
Around 2x performance in most benchmarks. Recommend to use with System 6 - 7.1 with stock SE/30 ROMs.

Compatibility: Incompatible with Micron Xceed, possibly Shiva Etherport SE30.
Tested working with Interware GrandVimage, Asante Maccon, Farallon TP594



With accelerators in the SE/30, there are a few-timing sensitive components that will not function correctly unless compensated for. Sound and Floppy access are high on that list. Higher end 68030 accelerators (Diimo, PowerCache) recognize these addresses in hardware and slow things down there; low end accelerators such as the Dove Marathon and Sonnet Allegro rely on software fixes instead (and usually can't boot from floppy).

The Booster recognizes these accesses in hardware, like the Diimo and Powercache. The specific mechanism it uses to slow the CPU is interesting: rather than slow the CPU clock, or insert wait states directly, they choose to inhibit the CPU's cache for 3 specific ROM ranges. This means the CPU is forced to (more or less) read and execute at the speed of the system bus / ROM as it needs to fetch each instruction, with a net result of keeping timing in check for those sensitive routines.

0xE000 - 0xEFFF
0x11000 - 0x11FFF
0x25F00 - 0x25FFF

Why is this important? Well, it isn't, unless you run a ROM other than the original SE/30 ROM (or a modified version thereof) as these offsets would then differ. Predictably, floppy booting ceases to work if using an IIsi ROM. It would be possible to add a jumper to allow selecting between SE/30 and an IIsi-based ROM, but of course, need to ID these routines first and the corresponding ones in the IIsi ROM. One of these ranges I believe I localized to the Sony floppy driver, but I didn't have as much luck with the others.

This is also a problem when running newer versions of Mac OS: System 7.5x seems to patch or replace the sound driver, which then starts has minor sound glitches. So this is where a recommended max of 7.1 comes from, though otherwise 7.5x seems to function fine.

Speculation: As IIx and IIcx use the same ROM, clock speeds, GLUE ASIC, etc - I have a feeling they'll also work with this design. Will be testing this.

Card compatibility: This card does not support any PDS card that requires the STERM (Synchronous Termination) signal. Notably, this includes the Micron Xceed cards. Interware appears to have originally designed for this functionality, but I've found that the GAL connection that would have gone to it is factory cut on mine and in all other images I've seen. Likewise, the GAL equations that would have been responsible has been removed. As this is a hardware limitation, this wouldn't be easily fixed.

I've also found that if a Shiva Etherport SE30 is installed, it will hard lock when booting at the Welcome to Macintosh screen. This may be resolvable in software - this is something different from the STERM issue.


Sneak peak.... Clones will be available before too long.

 

[Andy]

Nicely done! The non pds version looks quite interesting

 

[obsolete]

Awesome work! I really like the small outline and clean layout of the PGA version. Bummer about the ROM and OS limitations. It would be nice to be able to run later OS versions with the extra speed, but 7.1 with Open Transport and Appearance Manager isn't lacking much.

What's hiding under that heatsink? I haven't seen any 030s faster than 33MHz in a QFP.

 

[zigzagjoe]

Awesome work! I really like the small outline and clean layout of the PGA version. Bummer about the ROM and OS limitations. It would be nice to be able to run later OS versions with the extra speed, but 7.1 with Open Transport and Appearance Manager isn't lacking much.

What's hiding under that heatsink? I haven't seen any 030s faster than 33MHz in a QFP.

I'm pretty sure the patches used by the other accelerators probably could be made to apply to this design, and sort that out in software, rather than hardware. It's not a big priority for me at the moment, though.

Reason for the slightly odd form factor is I was thinking to stick the socketted module on a carrier board to optionally adapt to the original PDS form-factor. Not sure that could be done as a 2 layer board, at which point the carrier idea isn't really worthwhile anymore - just make a PDS design instead. However, it'd end up more expensive due to the connectors and extra soldering required.

I'm using 25mhz rated ones - but with the F91C mask. This is the last 68030 mask and I've found they will clock to anything sensible, within thermal limitations, regardless of markings. I've run 60mhz with L2 cache on my Diimo. My thinking is the reason Motorola didn't offer higher speed grades is due to the lesser heat dissipation of the ceramic QFP package, which a small heatsink should even up.

 

[David Cook]

With accelerators in the SE/30, there are a few-timing sensitive components that will not function correctly unless compensated for. Sound and Floppy access are high on that list. Higher end 68030 accelerators (Diimo, PowerCache) recognize these addresses in hardware and slow things down there; low end accelerators such as the Dove Marathon and Sonnet Allegro rely on software fixes instead (and usually can't boot from floppy).

Fascinating!

 

[zigzagjoe]

@halkyardo had a look at those "magic" addresses... doesn't seem like anything of interest is there. Not quite sure what's going on, but the secret's in here somewhere. Output is inverted, as expected for an active-low signal. These are the address lines in the equation.

/o_CIIN_LOCAL = i_A9 * i_A8 * i_A10 * /f_A31 * i_A11 * f_A30 * i_A12 * /f_A29 * /i_A13 * /f_A28 * i_A14 * /i_A15 * /f_A18 * /i_A16 * i_A17
    + /f_A31 * f_A30 * i_A12 * /f_A29 * /i_A13 * /f_A28 * /i_A14 * /i_A15 * /f_A18 * i_A16 * /i_A17
    + /f_A31 * f_A30 * /i_A12 * /f_A29 * i_A13 * /f_A28 * i_A14 * i_A15 * /f_A18 * /i_A16 * /i_A17

Converting the equations to binary, I get:



Which in turn yields. 0100 is the ROM address range, so I've removed it for the sake of legibility. These need 0x40000000 added to turn into physical addresses.



Nothing immediately obvious lay at these addresses - my assertion that the sony driver was at one of that was mistaken, based on an error I'd made while originally transcribing the equations' values.

Unrelated: as expected, the Interware will boot A/UX, though unexpectedly both sound and floppy work fine too. I suppose it makes sense the A/UX implementations would be less timing sensitive due to having to coexist in a preemptive multitasking environment. Or, they're using the ROM routines that are slowed down.

 

[zigzagjoe]

It was human error. OE on GALs is inverted. Ranges are actually:



0x5f00 - seems to be part of _DTInstall? per macsbug
0x2e000 - .Sony DRVR for floppy
0x31000 - Something to do with Sony floppy; lots of references to SonyVars global which implies floppy/SWIM routines.

 

[eharmon]

I wonder if extracting those ranges could be useful to contribute to PiStorm. If I understand correctly, that's been slow to move on Mac because they don't know what memory accesses to run at slow speed and what patches need to be applied, which is partially what you've extracted here.

Obviously it varies per machine, but if we determined what regions of the ROM these map to, a tool could probably be built to extract the equivalent ranges for every ROM and create universal compatibility.

For instance, the PiStorm could boot, read the ROM checksum, compare that to a map, and then boot.

 

[zigzagjoe]

I wonder if extracting those ranges could be useful to contribute to PiStorm. If I understand correctly, that's been slow to move on Mac because they don't know what memory accesses to run at slow speed and what patches need to be applied, which is partially what you've extracted here.

Obviously it varies per machine, but if we determined what regions of the ROM these map to, a tool could probably be built to extract the equivalent ranges for every ROM and create universal compatibility.

For instance, the PiStorm could boot, read the ROM checksum, compare that to a map, and then boot.

That would certainly work so long as you can generalize those locations across ROM versions. The floppy stuff should be easy, the sound stuff is likely to be more problematic (and better addressed by software). I did try the Mobius sound patch on 7.5 to see if it would do anything, didn't seem to help. I may have to have a go at IDing those ranges in the IIsi ROM and see if that works to fix floppy booting...

On the topic of sound, add this to the feature list: Strange bongs. The original design does this too; some interaction between the bong code, increased clockspeed and PLL stuff, each bong slightly varies and sometimes can get quite interesting. Sad mac chines are particularly interesting too.

 

[micheledipaola]

Sneak peak.... Clones will be available before too long.

This is the part I personally find most interesting!!!

 

[zigzagjoe]

This is the part I personally find most interesting!!!

Design validation has completed and I've added support for the IIsi ROMs to its logic. Some further changes were required to enable using a newer clock generator as there are alignment requirements for the phase shift/modified duty cycle clocks. @treellama is going to find out with one of my prototypes if it works in the IIx/IIcx too - I'm thinking this will be a yes.

I'm planning to produce them in both socketted form and in a PDS form.... PDS is going to end up unavoidably more expensive due to $$ connectors and bigger boards, but not so many people have sockets or are willing to install one.



Chinese new year will delay availability of revised boards but they will otherwise be functionally identical. Technically I have one of the first batch ready for sale, with a few bodges. In order to protect the pins, I designed a little case as you can see - if 60 cents makes packing a no brainer, then that's money well spent in my eyes.

 

[obsolete]

Awesome! With IIsi ROM compatibility, I'm definitely interested. Will there be different JEDEC files to flash for use with either the original SE/30 or IIsi ROM?

 

[zigzagjoe]

Awesome! With IIsi ROM compatibility, I'm definitely interested. Will there be different JEDEC files to flash for use with either the original SE/30 or IIsi ROM?

It's seamless - either ROM will work with no changes on the accelerator. I was using that ISP simm project of mine to switch between the two - interestingly, the chime code is somewhat different between IIsi and SE/30 rom and it's audible even with the stock ROM.

 

[obsolete]

It's seamless - either ROM will work with no changes on the accelerator.

Wow! If you don't mind explaining, how'd you manage to pull that off?

 

[zigzagjoe]

Wow! If you don't mind explaining, how'd you manage to pull that off?

Nothing too fancy: identify similar routines in the IIsi ROM and watch for them also. The floppy .DRVR is a gimmie, but the other two took quite a bit of effort to figure out.

Fun fact: the Mac II ROM map from MPW is the same as used for IIx/IIcx/SE30. And also, there are a lot of mystery routines that it doesn't cover and MacsBug doesn't know about.

 

[obsolete]

Thanks. Maybe I'm just dense, but I'm still a little confused. Does this mean that you're now inhibiting cache for 6 address ranges (3 for the IIx/IIcx/SE/30 ROM, 3 for the IIsi ROM) regardless of which ROM is installed?

 

[zigzagjoe]

Thanks. Maybe I'm just dense, but I'm still a little confused. Does this mean that you're now inhibiting cache for 6 address ranges (3 for the IIx/IIcx/SE/30 ROM, 3 for the IIsi ROM) regardless of which ROM is installed?

That's the gist of it, yep, add some new ranges to look for. However, as the IIsi ROM is a 512K ROM vs SE30 256K, there's only one point of overlap between the two (of any interest to this exercise, anyways) and it's non-problematic if that routine runs slightly slower.

As another interesting point, by speedometer's reckoning, a 47mhz CPU with cache 100% inhibited is only slightly slower than the stock.

 

[eharmon]

Fun fact: the Mac II ROM map from MPW is the same as used for IIx/IIcx/SE30. And also, there are a lot of mystery routines that it doesn't cover and MacsBug doesn't know about.

They're bit-for-bit identical, so it makes sense (II FDHD/IIx/IIcx/SE/30)

 

[obsolete]

That's the gist of it, yep, add some new ranges to look for. However, as the IIsi ROM is a 512K ROM vs SE30 256K, there's only one point of overlap between the two (of any interest to this exercise, anyways) and it's non-problematic if that routine runs slightly slower.

Okay, thanks. The potential for overlap, and the resulting slowdown of access to some random/unknown ROM code is what I was worried about. I appreciate the explanation.

Next dumb question, are non-integer multipliers an option (specifically, any intermediate steps between 3x and 4x)?

 

[zigzagjoe]

They're bit-for-bit identical, so it makes sense (II FDHD/IIx/IIcx/SE/30)

Yeah, I didn't realize that about the II FDHD ROM, though it makes sense. I kind of assumed the MacII ROM would refer to the earlier ROMs which I assumed were more common. I did gather a few more ROM maps from assorted versions of MPW in my quest - attached.

Okay, thanks. The potential for overlap, and the resulting slowdown of access to some random/unknown ROM code is what I was worried about. I appreciate the explanation.

Next dumb question, are non-integer multipliers an option (specifically, any intermediate steps between 3x and 4x)?

There's no support for changing multipliers. As you saw, I did break out a pad for that on the PLL, but due to how some of the special clocks are generated there is not sufficient logic available to adjust for any change to multipliers. It was a stretch goal anyways, though the idea of a 63mhz 68030 was pretty funny. I'd managed to run one at 68mhz for a very short time on a Diimo (without L2 cache), so it's not impossible, in theory, but it'd require an expanded design, likely faster GALs, and definitely requires integral multipliers.