Interware Booster 30-SE50F Info Dump
- Thread starter zigzagjoe
- Start date
zigzagjoe
Well-known member
I admit, I was pretty stoked when I got the /STERM logic functioning! It will need some testing to confirm that it behaves correctly with a Micron Xceed card too, but it should be close if it doesn't work immediately. For the IIsi use case, I've run these F91C mask CPUs at up to 67mhz on a Diimo (without L2 cache). It will require a full qualification in multiple IIsi across multiple cards and machines to confirm that 60mhz operation can be reliably expected, but there's a pretty good chance that it'll make the grade. Currently there's not even any hardware changes or different logic in use, so it may just be a matter of different connectors for the IIsi. I don't know there's a huge interest in IIsi upgrades, but more options are always nice to have!
The PDS CPLD version is now the production card (for SE/30), and they are slowly trickling into the wild. At the moment the logic is a direct port of what I'm using on the ATF(GAL)-based cards. So, exact feature parity, but there is the possibility to add later improvements like this by updating the CPLD.
The CPLD lives on the back of the card, as due to the extreme mutability of the pin assignments it means I can arrange the IOs to route favorably to the associated pins on the 68030. That's why there's so much empty space on the front of the card now!
Cost-wise, the CPLD is a hair more expensive, but the benefits are worthwhile. No need to preprogram and label SOIC chips; I can program the chip without needing to remove it from the PCB (does need to be removed from host system). Increased logic availability, IOs, and general flexibility with the CPLD should hopefully allow for better handling of audio and floppy accesses too, and possibly some other QOL tweaks.
One of the objectives for this spin was to prove that it was possible to move equations from the dumped and refactored OPALJr equations into CUPL with a minimum of changes. That was borne out; the only changes that were required were the adding the appropriate inversions on the equations making use of pin 11 (OE) as it is always inverted on GALs. So this opens the avenue of potentially doing this elsewhere with designs I've been loathe to touch (ie. socketed Diimo).
The workflow for the CPLD isn't quite ideal yet. CUPL is fine (enough), however programming is currently a mess of manual work:
(header is not normally present on production cards, I have a programming jig that is used instead)
Due to the consolidation of logic into the CPLD, I now have this cute little thing being made at JLC. Of course, it precludes the use of a higher speed onboard FPU, and for that reason I don't expect to make it a standard production model, but it's so adorable I had to do it.
The PDS CPLD version is now the production card (for SE/30), and they are slowly trickling into the wild. At the moment the logic is a direct port of what I'm using on the ATF(GAL)-based cards. So, exact feature parity, but there is the possibility to add later improvements like this by updating the CPLD.
The CPLD lives on the back of the card, as due to the extreme mutability of the pin assignments it means I can arrange the IOs to route favorably to the associated pins on the 68030. That's why there's so much empty space on the front of the card now!
Cost-wise, the CPLD is a hair more expensive, but the benefits are worthwhile. No need to preprogram and label SOIC chips; I can program the chip without needing to remove it from the PCB (does need to be removed from host system). Increased logic availability, IOs, and general flexibility with the CPLD should hopefully allow for better handling of audio and floppy accesses too, and possibly some other QOL tweaks.
One of the objectives for this spin was to prove that it was possible to move equations from the dumped and refactored OPALJr equations into CUPL with a minimum of changes. That was borne out; the only changes that were required were the adding the appropriate inversions on the equations making use of pin 11 (OE) as it is always inverted on GALs. So this opens the avenue of potentially doing this elsewhere with designs I've been loathe to touch (ie. socketed Diimo).
The workflow for the CPLD isn't quite ideal yet. CUPL is fine (enough), however programming is currently a mess of manual work:
- use ATMISP (gui program) to generate SVF file for the .JED generated by CUPL/fitter
- switch VPP on
- run erase SVF using openOCD
- switch VPP off
- possibly reset main power
- run program SVF using openOCD
(header is not normally present on production cards, I have a programming jig that is used instead)
Due to the consolidation of logic into the CPLD, I now have this cute little thing being made at JLC. Of course, it precludes the use of a higher speed onboard FPU, and for that reason I don't expect to make it a standard production model, but it's so adorable I had to do it.
Due to the consolidation of logic into the CPLD, I now have this cute little thing being made at JLC. Of course, it precludes the use of a higher speed onboard FPU, and for that reason I don't expect to make it a standard production model, but it's so adorable I had to do it.
I would be interested in this as it looks like it would fit the 3/80 much better. Lack of an FPU doesn't bother me as the 3/80 supports running the FPU at 40MHz which is good enough. I Just need to figure out how to get it to work on the machine.
zigzagjoe
Well-known member
I'd recommend comparing the status of the control lines such as AVEC on the Sun CPU which are strapped low or high against the booster schematic I posted (excerpt below). If these are used differently in the Sun that's a potential problem. Also, if the sun makes any use of /STERM, the current boosters do not implement it and that would probably cause you problems.
Got some more detailed performance numbers for the IIsi. Definitely a nice performance uplift @60mhz.
The IIsi is going to require improved cooling over the current boosters, as it turns out. The little heatsinks I've been putting on for 50mhz operation in a SE/30 are mostly to make me feel better/insurance; I have found they really aren't actually required for stable operation. However, it is a different story at 60mhz in the IIsi. A heatsink is absolutely required, the machine will barely make it to finder before the CPU starts getting too hot if one isn't present.
The little sinks certainly help, but I don't think there's enough airflow in a closed IIsi (haven't tested yet: using a freestanding fan to simulate) for it to reliably do the trick. So, I'm going to see if larger heatsinks are enough to get stability, but it's definitely a point of concern as I'd need these to be reasonably expected to be stable (prior to QC/burnin testing) and allowing for per-unit variation and a variety of use-cases. Active cooling would of course probably resolve this, but it's expensive and unattractive, and I'm not sure how many people will even be interested in an IIsi accelerator in the first place.
I don't screenshots handy, but interestingly it trades blows with the DayStar powercache (@50mhz). The Booster is faster at bus accesses (cache misses, and uncachable addresses) and of course has a raw clock speed advantage, so in certain scenarios this enables the booster to hold its own or even come up notably ahead. In others, the powercache benefits from the cache (duh) where it improves graphics performance and larger-than-internal-cache tight loops. In general, the powercache seems to give a more consistent performance boost where the booster is more spiky, but seems like the booster may be a rather competitive option for accelerating an IIsi beyond just price and availability.
Last edited:
I know just didn't have time to get to it until now. Here are the voltages I got from the board. I don't know what qualifies as in use.
A1 = 0
B1 = 1.68v
B2 = 1.795v
C1 = 1.696v
C2 = 0
C3 = 5v
D1 = 1.7v
D2 = 1.691v
D3 = 0
E1 = 19.66MHz
E2 = 4v
E13 = 0
F1 = 5v
F2 = 5v
F12 = 5v
F13 = 5v
G1 = 4.23v
G2 = 5v
G12 = 5v
G13 = 5v
H1 = 4.22v
H2 = 5v
H12 = 5v
H13 = 5v
J1 = 1.436v
J2 = 5v
J12 = 1.77v
J13 = 0
K1 = 1.437v
K2 = 5v
K3 = 1.711v
L1 = 5v
L2 = 1.72v
L3 = 1.84v
M1 = 0
M2 = 0
First thing I notice is that booster has E2 at GND but the board has it at 4v.
Last edited:
Unfortunately there are no schematics for the 3/80. A few years back someone was talking about sanding a board down to take photos of the traces but nothing came of it as far as I know. The 3/60 is a different story tho as we have full schematics and PAL equations for the board. I'll look into it this weekend but the two machines are pretty different in many ways.
zigzagjoe
Well-known member
MMUDIS dfifers... if held low, that's disabling the built-in MMU. that said, an unconfigured MMU as far as I know would default to direct mapping, so I don't know if it's an immediate issue. AVEC would be something else worth checking.
New socketed card with FPU is now on order... not quite as adorable, but still pretty cute.
I've finished testing the IIsi version booster. It does require active cooling, however the fan is quiet and lost in the sound of the system fan. Performance remains inline with the numbers from the prior post. It's quite a nice improvement! As usual one or more cards may be attached to the passthrough slot - I tested with both an SEthernet and 30Video SI card. Note that the bus speed I tested with is 20mhz. You may be able to bump that to 21, or 22mhz, but 25mhz (for 75mhz CPU speed) I doubt will work. Technically, this card would also work in a SE/30 (@47mhz) and has the new audio behavior / sterm implementation ("booster 2.0").
If anyone's interested in becoming a beta tester for the IIsi, I've got one card available - send me a PM!
With regards to the SE/30 Booster 2.0 cards, the main improvement is new handling of the audio/floppy/scc, mostly notably this means that system 7.5+ audio and the sound manager extension now behave correctly. Glider 4 sound is also resolved - thanks @obsolete for mentioning that as a test
. The silly chime is no longer, instead with an IIsi ROM the chime will sound normal or with a SE/30 ROM chime will be sped up. Either way, audio in the OS works correctly.The nature of the fix is to add 4 extra system clock cycles between each access to floppy/audio/SCC, which is very similar to the approach Daystar took. Accelerators are capable of beginning new system bus cycles with much less delay than the stock CPU, and apparently this will cause corruption/misbehavior for the SWIM and ASC. On later chipsets (i.e the IIsi), Apple correctly handled this in the system logic but the primitive GLUE on the SE/30 needs the help.
Booster 2.0 also implements /STERM so cards that require that such as the Micron Xceed cards will now work correctly too, along with some other minor improvements.
There's not a way to implement these improvements on my earlier clone cards, but for those with the original card or a replica of the original, I also designed a drop-in CPLD retrofit in place of the GALs. Thanks again goes to @obsolete for the idea
The 3/60, like most 68k workstations of the time, uses a custom MMU on the motherboard since apparently nobody liked the 68851. And I forgot to list it but AVEC is grounded. I've already done some limited testing with a normal 68030 and the machine seems to work fine, so when I have some free time I'm going to try desoldering the pins and adding bodge wires to the booster to match the configuration. Hopefully my SMD soldering skills are up to the task.
zigzagjoe
Well-known member
Hmmm.... yeah, that might be a problem.
Here's the bottom of the 68030:
And the top:
I don't plan to do so for the V1.x cards. The PDS cards would be practically impossible as one of the GALs is far away from the others, for the V1.2 socket cards it's possible but would require a lot of labor. The existing GALs and bypass capacitors would need to be removed, and then a new mini PCB with castelated holes ($$) installed containing the CPLD and a programming header. The masochist in me does sort of want to try it, but I can't see offering it as a service. Economically, I think it'd work out cheaper to build a new card.
The CPLD-based cards will be updatable, if needed, but would need to be shipped back to me for that to be performed.
Attachments
Thanks for the shoutout and for entertaining my crazy ideas. I hope you didn't lose too many hours "functionality testing" Glider 4
Sorry (not sorry) to keep doing this, but if you got some .050" right angle pins like these to solder to the SOIC pads, you could build a plug-in CPLD daughterboard for the V1.x Boosters. It would still be kind of a lot of work to install, but it would get you away from castellated holes and board-to-board soldering.
Apparently dual row headers also exist, or at least they did once upon a time: http://www.logicalsys.com/soicheader.asp. That site doesn't have a very "we're still in business" look about it, but it might be worth a phone call.
Sorry (not sorry) to keep doing this, but if you got some .050" right angle pins like these to solder to the SOIC pads, you could build a plug-in CPLD daughterboard for the V1.x Boosters. It would still be kind of a lot of work to install, but it would get you away from castellated holes and board-to-board soldering.
Apparently dual row headers also exist, or at least they did once upon a time: http://www.logicalsys.com/soicheader.asp. That site doesn't have a very "we're still in business" look about it, but it might be worth a phone call.
Last edited:
zigzagjoe
Well-known member
Haha I'm afraid I haven't played the game proper yet... just enough to test the sound. I ended up testing over 20 different games over a few versions of Mac OS to make sure it behaved correctly.
Castellated boards would be the way to do it properly. It just multiplies the PCB price by 10x, but that's still $5 per board in small quantities. I expect it would still work out cheaper and easier than those (admittedly cool) SOIC headers. I swore off doing headers and daughterboards after making the TinySCSIs as they're not a lot of fun to align. As long as the castellated boards could be hand (or drag) soldered into place, it would at least be doable. We'll see.
Castellated boards would be the way to do it properly. It just multiplies the PCB price by 10x, but that's still $5 per board in small quantities. I expect it would still work out cheaper and easier than those (admittedly cool) SOIC headers. I swore off doing headers and daughterboards after making the TinySCSIs as they're not a lot of fun to align. As long as the castellated boards could be hand (or drag) soldered into place, it would at least be doable. We'll see.
zigzagjoe
Well-known member
Drop in board for the original cards/replica cards is done. Turns out I flipped a pin in my logic. Oops. This board gives the audio and other fixes to the original design, and also enables /STERM for use with Micron Xceed and other cards if you solder a bodge as seen below.
It might also work in an IIsi, too, I haven't tested it but in theory it's possible as the logic is otherwise the same.
New socketed cards are done also, second from the bottom) These are the ones I intend to sell as opposed to the micro card below it.
IIsi cards.... Unfortunately, the 60mhz IIsi cards may not come to pass. I made two prototypes which both of those passed testing OK under pessimistic test conditions I use to guarantee they will operate in the majority of machines. One's out for field testing now.
However, both of the two production cards I've made will not operate under test conditions (~4.9V on 5V rail) and require additional voltage to be stable. They are fine on a PicoPSU which usually have a too-high 5V rail (5.2V, in this case), and of course work correctly in a SE/30. So, I probably won't make any of these as I can't bin CPUs and need to be able to guarantee reliable operation under reasonable conditions.
I might rework these boards for 40mhz (2x) operation, but as there's not been much interest in anything for the IIsi I'm not sure it's worthwhile. Though, any overclocking of the system bus will result in a speed increase of the accelerator - 25mhz would allow CPU to operate at 50mhz - might be neat.
It might also work in an IIsi, too, I haven't tested it but in theory it's possible as the logic is otherwise the same.
New socketed cards are done also, second from the bottom) These are the ones I intend to sell as opposed to the micro card below it.
IIsi cards.... Unfortunately, the 60mhz IIsi cards may not come to pass. I made two prototypes which both of those passed testing OK under pessimistic test conditions I use to guarantee they will operate in the majority of machines. One's out for field testing now.
However, both of the two production cards I've made will not operate under test conditions (~4.9V on 5V rail) and require additional voltage to be stable. They are fine on a PicoPSU which usually have a too-high 5V rail (5.2V, in this case), and of course work correctly in a SE/30. So, I probably won't make any of these as I can't bin CPUs and need to be able to guarantee reliable operation under reasonable conditions.
I might rework these boards for 40mhz (2x) operation, but as there's not been much interest in anything for the IIsi I'm not sure it's worthwhile. Though, any overclocking of the system bus will result in a speed increase of the accelerator - 25mhz would allow CPU to operate at 50mhz - might be neat.
Jockelill
Well-known member
YEAH!! love this
!!
zigzagjoe
Well-known member
I would not expect it to work. I have briefly run a 68030 at 67mhz on a Diimo, it's possible the 20mhz system clock could be bumped 1 or 2 mhz higher - but it'd be razors edge stuff.
