68kMLA Classic Interface

This is a version of the 68kMLA forums for viewing on your favorite old mac. Visitors on modern platforms may prefer the main site.

Click here to select a new forum.
68030 accelerator for the Macintosh Portable, redux.
Posted by: SuperSVGA on 2025-02-18 06:49:56
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.
Posted by: MeTheMac on 2025-02-18 19:41:22
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?
Posted by: LaPorta on 2025-02-19 04:53:56
All power is drawn from the battery, so that’s what all that depends on.
Posted by: Trash80toHP_Mini on 2025-02-19 09:08:53
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:

PerformerLaguna-0001-AI9-c.jpg
Posted by: resident_cat on 2026-07-08 20:39:30
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.
Posted by: resident_cat on 2026-07-10 17:14:32
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.
Posted by: zigzagjoe on 2026-07-10 17:35:37
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.
Posted by: Froggy814 on 2026-07-10 18:23:39
So how would it even work? I don't quite follow the thread.
Posted by: Froggy814 on 2026-07-12 08:56:42
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.com

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 github.com
Posted by: Builder68 on 2026-07-13 16:16:53
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!
Posted by: Froggy814 on 2026-07-14 15:31:12
So you're saying it would be okay hardware wise, but you would have to change the code on the programmable IC's?
Posted by: Builder68 on 2026-07-14 18:34:34
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.
Posted by: Froggy814 on 2026-07-14 18:42:38
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?
Posted by: Builder68 on 2026-07-14 18:55:17
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.
Posted by: Froggy814 on 2026-07-14 18:56:23
Bummer.
Posted by: Builder68 on 2026-07-14 19:24:00
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.
Posted by: Froggy814 on 2026-07-14 19:59:02
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.
Posted by: Trash80toHP_Mini on 2026-07-14 21:33:36
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:

Radius16-68020-Cache-Accelerator-NO_ASIC-r.jpeg

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?
Posted by: twelvetone12 on 2026-07-15 02:50:18
Or use a Powerbook 100 accelerator design?
Where any of these actually ever produced?
Posted by: Builder68 on 2026-07-15 05:22:34
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.


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.
< 2 >