68030 accelerator for the Macintosh Portable, redux.

[SuperSVGA]

SE PDS cards run in an expansion chassis for the Portable, whose PDS is ostensibly the same as the SE PDS. I'm not lookin' as I'm a bit burned out with other projects ATM. If one of you guys want to take a look at the Luggable/SE PDS address ranges, finding them identical could be a big step forward I'd think?

There's a good chance the expansion chassis likely rewrote address access to PDS cards since the SE and Portable address spaces aren't quite the same. It's hard to say for sure because I've never seen one outside of a picture I have in a magazine.
There are some "free" address spaces that overlap between the Portable and SE, but those are in the Portable's upper RAM space, so if you use those you could end up limiting the Portable to 5-6MB of RAM rather than the full 9MB, unless you give the accelerator additional RAM. There are some Portable PDS cards around that do this since having that much RAM was uncommon at the time.

 

[MeTheMac]

RAM would definitely great on-board if it was compatible with the original Apple-branded 1MB, (Kingston, I think) 4MB, and Androda/MacEffects 8MB and 7MB cards. If replaced with a BlueSCSI, would it still need an external PSU? Do we know around how much power the Portable provides, and how much the Accelerator PDS card would take?

 

[LaPorta]

All power is drawn from the battery, so that’s what all that depends on.

 

[Trash80toHP_Mini]

If replaced with a BlueSCSI, would it still need an external PSU?

Battery only state vs. battery plugged in/charging state was a concern from the start. Wedging a circuit to hijack power from the battery/charger interface for running in that state, but leaving the accelerator somnolent in a battery only state was another idea as was straight up powering acceleration from a second wall wart plugged in when in charging state.

from upthread:

I'd figured that power to run an adapted SE Accelerator in the Portable would be harvested from a takeoff on the 12V rail available on the HDD connector. stepped down via Buck Converter. Dunno, at the time I'd figured the 5V rail would be more limited and SCSI2SD replacement of the HDD.

Manual switch for low power mode and 68000 specific boot partition option also considered:

 

[resident_cat]

I would love to be able to accelerate my backlit Mac Portable so I could run SSH. It’s just such a cool looking machine. I’d pay a pretty penny for an 030 acceleration path.

 

[resident_cat]

I would love to be able to accelerate my backlit Mac Portable so I could run SSH. It’s just such a cool looking machine. I’d pay a pretty penny for an 030 acceleration path.

The original Conner HDD draws about 35 watts at peak, if you integrate a scsi to SD solution ala BlueSCSI in the acceleratior that gives you some decent power to work with. Also I upgraded my battery to a lithium-ion battery with BMS built in and substantially extended the battery life while reducing weight so battery life wouldn’t be an issue.

 

[zigzagjoe]

The original Conner HDD draws about 35 watts at peak, if you integrate a scsi to SD solution ala BlueSCSI in the acceleratior that gives you some decent power to work with. Also I upgraded my battery to a lithium-ion battery with BMS built in and substantially extended the battery life while reducing weight so battery life wouldn’t be an issue.

You might have dropped a decimal point. Those drives do not pull 35w, around 10w peak on spin up and 2-4w in normal use is what you would see.

 

[Froggy814]

So how would it even work? I don't quite follow the thread.

 

[Froggy814]

So, @Trash80toHP_Mini said that the SE, and I know that the Plus has a similar architecture. And the pinout of the machines for PDS slot is basically the same pins to the Portable, so I am wondering, could I be able to modify this accelerator to fit in the portable, would it work?

GitHub - TheRealBolle/Performer-SE-PL-CL: 16MHz 68030 accelerator for Macintosh Plus, SE and Classic

16MHz 68030 accelerator for Macintosh Plus, SE and Classic - TheRealBolle/Performer-SE-PL-CL

github.com

 

[Builder68]

It’s not going to be a drop-in, plug-and-play situation, for sure.

The underlying 68030 architecture is there, but the devil is entirely in the details of how the two machines map their hardware and in the machine state synchronization.

To make it actually work, it would first require diving into the PLD logic and modifying how it handles address decoding. The Portable has a completely different memory map compared to the SE.

To give an example, signals like CIIN (Cache Inhibit Input) would need to be carefully adjusted so they align correctly with the host machine's layout.

Another big hurdle would be the state machine synchronization. The Macintosh Portable doesn't run at 8 MHz; it runs at 16 MHz (15.6672 MHz), meaning the state machine equations in PLDs U6, U5, and U4 would need to be completely recalculated to handle the faster host bus.

The state machine would likely need to be split across two PLDs running on opposite clock phases. That would give more granularity for the state transitions, allowing signals to be registered on the half-cycle of that 16 MHz clock. It would definitely be quite a challenge!

 

[Froggy814]

So you're saying it would be okay hardware wise, but you would have to change the code on the programmable IC's?

 

[Builder68]

So you're saying it would be okay hardware wise, but you would have to change the code on the programmable IC's?

It's actually a bit of both.

In these vintage chips, the "code" we write to the PLDs physically changes how the internal hardware behaves.

But because the Portable runs twice as fast as the SE, just adjusting the code for a different memory map (like CIIN decoding) isn't enough. We would also have to add more hardware. Specifically, we would need to add extra PLD chips, plus transceivers to isolate and decouple the host address and data buses.

The Performer board relies on the accelerator clock (16 MHz) and the host clock (8 MHz) being perfectly in phase and matching this 2:1 cycle ratio. Its state machine logic (PLD U4) is tailored specifically to this setup, meaning, for example, that signals originating from the host side, like DTACK, depend on those clocks being synced.

More advanced 68030 accelerators (like the Gemini line) use fully asynchronous handshaking to let the host devices and the accelerator CPU talk to each other. Building the logic to translate between two independent clock domains is a whole different beast.

So, it is less of a simple software update, and more of a major hardware redesign.

 

[Froggy814]

So is there a better board to model then that one? Like that would have all of the IC's in asynchronous phase and all you have to change is code?

Or would it be better to start from the ground up?

Or use a Powerbook 100 accelerator design?

 

[Builder68]

So is there a better board to model then that one? Like that would have all of the IC's in asynchronous phase and all you have to change is code?

Unfortunately, no. There’s no magic donor board out there where you can just reprogram the chips and call it a day.

 

[Froggy814]

Bummer.

 

[Builder68]

Bummer.

Yeah, unfortunately.

Plus, on the Portable, that 16 MHz system clock is dynamically managed. If an accelerator tries to take control or mess with the timing without keeping the power manager's sleep signals and state machines perfectly happy, the system will instantly crash or reset.

Any 68030 accelerator for the Portable (or the PowerBook 100) would probably also need to bypass or hook into those power-management routines using custom driver INITs, just so the OS doesn't panic when the ROM trap detects the upgraded CPU.

 

[Froggy814]

So, you have to tap off of the 16mhz of the motherboard and you can't change it? Is that what you mean? Or you need to figure out how to use the reserved pins?

Or do you mean it has to enter sleep mode when the /Sys.PWR pin says so.

 

[Trash80toHP_Mini]

I gave up on this one, also running the16MHz reference clock on the SE PDS thru the Performer's speed doubling Gal to get 32MHz out of Performer/SE. @Bolle tried it, but the timings wouldn't work so we stuck with the vanilla Performer clone. So it goes . . .

Dunno if it may be a better place to look, but the Radius 16 is the only other Accelerator I know of which might be cloned. The others that have been cloned are all for 68030 machines, no? Gemini and the like were of the CPLD scourge generation? ASICS?

It's a 68020/16 so only a CPU bump, no clock bump. Luggable already has FPU on board, so that's not the big win it was for Plus/SE. It has cache on board, so it's doubtful what might come of it running on a 16MHz machine. All kinds of holy hell when it comes to timings? It's there to make up for the 8MHz memory access bottleneck. If you need the full 68030 code bump for SSH then it's no answer at all, but here's what it looks like in all its CPLD/ASIC free glory:



Why on earth it has an odd number of SRAM chips has me stumped, but I'd dearly love to get this puppy cloned and then into FPGA.


edit: are there other accelerators simple enough to be cloned for 68000 machines. Could be very wrong about this?

 

[twelvetone12]

Or use a Powerbook 100 accelerator design?

Where any of these actually ever produced?

 

[Builder68]

I gave up on this one, also running the16MHz reference clock on the SE PDS thru the Performer's speed doubling Gal to get 32MHz out of Performer/SE. @Bolle tried it, but the timings wouldn't work so we stuck with the vanilla Performer clone. So it goes . . .

Dunno if it may be a better place to look, but the Radius 16 is the only other Accelerator I know of which might be cloned. The others that have been cloned are all for 68030 machines, no? Gemini and the like were of the CPLD scourge generation? ASICS?

Actually, I was just sharing some thoughts on this in another thread recently.

The Gemini Ultra/Integra and the Vandal Extreme seem like very promising candidates for a full clone, at least for the core accelerator logic, if we leave out the VGA video interface. @Bolle already published the JEDEC files for the Vandal Extreme, which seems to be a clone of the Gemini Ultra/Integra.

From here, the main hurdles are reverse-engineering the schematics from the PCB and dumping the configuration PROM to figure out exactly how the Xilinx XC2018 handles host bus management. @Phipli mentioned that dumping that PROM should be possible.

Post in thread '[Development] 4MB 32-bit SRAM for the MicroMac Performer'

Jun 18, 2026

Circled is the XC1736A Xilinx configuration PROM. I've extracted the contents from similar chips using an Arduino to verify the contents. They just spit out the next bit after every clock if I remember. At least, the one I was looking at did.

• Phipli

My hunch is that we could translate that key host data bus management logic into a couple of standard PLDs and use 74646s for data bus isolation and buffering, similar to how previous TS 68030 accelerator boards before the Ultra did it, like the Gemini II.

Reverse-engineering the Gemini II itself is probably a dead end because its GAL22V10s can't be dumped. But since the Gemini Ultra is the natural evolution of the Gemini II, it is highly likely that the Xilinx XC2018 simply replaced the 74646 transceivers and their control logic to help reach higher clock speeds.

Regarding the Micromac Performer, I think there might be a good chance of making its handshaking with the host fully asynchronous, which could let us push the clock speed up to 33 MHz.

We could do this the hard way by redesigning the state machine logic from scratch and adding address and data transceivers on the host side.

Alternatively, and preferably, we might be able to adapt that key host bus management logic from the Gemini Ultra to upgrade the Performer’s logic instead.