• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

IIfx PDS -> PBX -> 1400/166/Cache CPU Card Accelerator

Trash80toHP_Mini

NIGHT STALKER
68040
We've been looking for a new build accelerator project. Here's myPBX is a 68030 Bus <->603e Bridge ASIC. so here's my crazed coffee deprived notion for the day.

Then again, it could be a G3/1MB Accelerator. 😬
 
. . . Here's myPBX is a . . .

Ayup, I can even make sense of things at the KBD when I'm in that state. :oops:

Anyhoo, I never really paid attention to PPC upgrade cards until I heard the PB5xx series upgrade had PBX on board IIRC. That got me thinking in terms of the 2300c Block Diagram, but not sure about the interactions there due to the memory being directly on the Processor Bus upstream of PBX.

The 1400 is different, with main memory on the fast Processor Bus on the downstream side of PBX.

PB1400_Processor-Bus-00.JPG

PowerPC 603e block is the only thing on the Processor Card in the baseline 113MHz PowerBook 1400.
ROM and two(?) banks of RAM are on the System Board.

Thinking here is that the PBX bridge ASIC is a 68040/PB5xx era integration of the logic of the IIci 68030 PDS bridge to PPC upgrade card?

Dunno, spitballin' stage at this point. Wondering if the 68030 Socket might be a better way to wedge this. Never thought of that because of the eternally recurring dead end discussion of PPC upgrade for the unclean SE/30 architecture. PPC works in the the IIci PDS, might work one of those two ways in the newer, faster IIfx?
 
PowerBooks 520/540 Block diagram.
PB520-540-Secondary-Logic-Board-RAM-Card-Block-Diagram-00.JPG
Pratt Memory Controller IC
The Pratt IC is a new Apple custom IC that provides RAM and ROM memory control
and also acts as the bridge between the MC68040 bus on the secondary logic board and
the MC68030 bus on the main logic board. The Pratt IC resides on the secondary logic
board and transparently translates MC68040 bus cycles into single or multiple MC68030
dynamically sized bus cycles. Because the Pratt IC seamlessly integrates the two buses,
the microprocessor and other bus masters operate as though they were on the same bus.
The Pratt IC supports read, write, and page mode cycles to the RAM. Pratt generates a
2048-byte CAS-before-RAS refresh cycle every 128 ms.
__________________________________________________________________________________________________

So the Pratt Bridge ASIC is on the bottom of the processor card of the Blackbirds and converts the 32bit 68040 bus to a 16bit*** 68030 system bus. PBX apparently can do that as well as 32bit?

PB520-540-Main-Logic-Board-Block-Diagram-00.JPG

Has anyone got a link to the Blackbird PPC Upgrade development thread? IISTR it was for a G3 card?

*** LEM disinformation alert: Powerbook 190
Apple eliminated the internal modem bay and the ethernet port found in the PowerBook 500 series that preceded the 190, forcing buyers to acquire these items separately. Because the PC Card uses a 16-bit bus, ethernet performance is roughly 25% slower than on the PowerBook 540.

Dunno about speed differential, but what was that again about a narrower bus being the reason for it? :rolleyes:
 
Comparison time:

PowerBook 5x0
PB520-540-Secondary-Logic-Board-RAM-Card-Block-Diagram-00.JPG

PowerBook 190
PB190-Processor-Memory-Subsystem-Block-Diagram-00.JPG



PB5300

PB5300-Processor-Memory-Substym-Block-Diagram-00.JPG



PowerBook 1400

PB1400_Processor-Bus-00.JPG


Given: Applied Engineering TransWarp (25, 33 MHz 68040) runs in the IIfx PDS . . .

So can we figure a way to get a 1400 CPU card to run in the IIfx PDS as well? Every diagram above bridges to what amounts to a 68030 PDS.

Here's the IIfx mess:
IIfx-Block-Diagram-00.JPG
 
Last edited:
Given = Taken Back TransWarp 040 looks to be a NuBus accelerator similar to the Rocket Accelerator. :confused:

Fusion Data TokaMac FX = PITA! -fusion and -plasma appended to search string doesn't help a whole lot.
 
Has anyone got very high resolution pics of both sides of the IIci PPC upgrade cards to upload here?

Been playing with the Block Diagrams in my head and thinking about issues imposed by Dueling Memory Controllers. Apple resolved any problems with the IIci implementation. Wondering how complicated doing same with the IIfx might be?
 
Details can be sussed out of various dev notes and things at your leisure, but basically:

The PowerBook Duo 280, PB 5xx, PB 190, PB Duo 2300, PB 5300, and PB 1400 share many if not most of their logic ICs. The only major differences are between 68k and PPC-based models, which use either the Pratt ('040) or PBX (PPC) bridge chip, and the inclusion or subtraction of some minor features between models (5xx has onboard ethernet and no ATA; 190, 5300, and 1400 have onboard PC card controllers and optional IR; Duos have internal modems and the dock interface).
So this means that basically the Pratt or PBX controller takes their host CPU and adapts it to the '030 bus that runs the rest of the computer. Everything in the machine outside of ROM and RAM lives on an '030 bus. Why? Because of the Duos and their Dock, which only supports an '030 bus. Instead of building multiple chipsets for various PBs Apple used the same set for all of them, which means that for some people to be able to continue to enjoy using their new 280 and 2300 with their old Duo Docks, your 5xx and 5300 had to be hobbled with a 16MHz 16-bit (or narrower depending on subsystem) internal data bus.

So for this idea it won't really work: 5xx PPC upgrades replace the Pratt '040 controller with a PBX PPC controller; the old II family and other desktop Macs don't have their onboard memory controllers replaced during CPU upgrades, and the 1400's PBX is on the logic board, not attached to the CPU card. Not as if the 1400 CPU cards are super common anymore anyway.
Desktop PPC upgrades usually used a bridge chip of some sort that directly adapted the PPC chip to 68k with no change of any existing chips. This bridge chip was an ASIC that I'm pretty sure had its own internal ARM processor to manage itself and the interface. I'm not entirely sure how it worked internally. It was probably a combination of managing whether the PPC or 68k chip was active by watching for certain bits set on startup, and dynamic bus translation when in operation.
 
Yep, got all of that already, long before I started this thread. Your assumption about hobbling the Blackbirds, 190 and 5300 to match the Duo is mistaken as I see it. Duo's are 32bit on the Docking connector with a narrow bus for only rudimentary function on the slow I/O bus that only needs 16bits. The Dock is 32bit, else NuBus could not be supported. I'd not be surprised if the Docking connector's 32bit bus is necked down for the remaining functions of the DuoDock?

IIRC, all PowerBooks had a 16bit I/O bus, nothing on that bus ever needed more than 16bits until Apple went to 24bit graphics out the video connector of the Pismo when used in clamshell mode IIRC?

The 1400 board is a full 32bit bus, but the bus is split with (high or low?)16bits heading to its Video Card Slot and the other 16bits heading to the TREX ASIC underneath the removable card cage/IR junk for the 1400. It wouldn't surprise me if the same were true of the 5300, but I've never buzzed that machine's board.

The top of the line VidCard for the 1400 is 16bit due to that bus limitation. I've long wanted to unify the 1400 bus halves and hack NuBus from the DuoDock onto it.
 
Last edited:
Thinking about it for a minute and yeah you're probably right: there was precious little in an early '90s PowerBook even capable of running at 32 bits outside of memory so it's not a big deal to run the ATA controller (16 bits), SCSI controller (8 bits), Ethernet (10b-whatever was fine on 16 bits), and PC Card (16 bits) on a 16-bit bus. The only real exception would've been for video which would've been better served on a 32-bit bus.
Also I was slightly mistaken: only the 280 and 5x0 series (including PPC upgraded) run the I/O bus at 16MHz; the PPC models run it at 25MHz. Still 16 bit maximum bus width though.
The whole reason they used the '030 host bus design for so long was because it offered byte steering and dynamic bus sizing, something the '040 and PPC buses don't (so everything would've had to be 32-bits wide to be on the same bus as the processor). So yeah it's not just the Duos (though the fact that the Dock connector relies entirely on the '030 bus for communication is a pretty big motivator for continued use), but the fact that all of the legacy chips in these machines would've required a bridge of some sort regardless. And even all this wasn't enough: the FPU and L2 caches in the full-size Docks are unusable by the Duo 280 and 2300 (obviously the FPU is moot in the 2300 and the 280's '040 doesn't support external FPUs regardless but the L2 cache would've been nice either way).
As for the 1400, it was a recased 5300 (the 1400's dev note says: "Except for the floppy disk controller IC, the architecture of the PowerBook 1400 computer is similar to that of the Macintosh PowerBook 5300 computer.") so there weren't many differences logically: 33MHz 32 bit PPC bus from the CPU to the memory/PBX, 25MHz 16 bit '030 bus out from there to the rest of the system. That whole high-16/low-16 smacks of the thoroughly debunked Performa 5xxx/6xxx left-32/right-32 thing from LEM so you're probably going to want to take that with a grain or ten of salt. I skimmed through some dev notes today but there wasn't anything concrete about exactly how the I/O bus operates (there's likely no need to get too in depth for stuff like that for average developers) but it appears to be a single flat bus, and so there's no mention of any high-16/low-16; most likely it's just sharing the same 16-bit bus (again this sort of thing is why Apple kept the '030 bus for so long: it was extremely versatile). I don't mind being proven wrong if you've got some docs I'm not privy to, though.

Anyway I don't think grafting a PBX into a desktop '030 is going to work because you'd have to disable or remove too many competing devices on the host logic board (and probably have to build custom ROMs to get the PBX to initialize itself and its new host Mac properly). You'd have better results with that whole 68040 FPGA thing being discussed in another section of the forum and just adapting the FPGA to the '030 bus instead.
 
Also, if someone with a TokaMac wouldn't mind lending it to Bolle, we could see real upgrades for the IIfx again. I'm sure the TokaMac 040 could be adapted into a PowerPC upgrade.
 
Bounced this off a couple of our resident sorcerers this morning, so may as well ask the gang here:

Wondering about my unholy IIfx/PB1400 union and memory controller conflict?
Thinking here is 68030 socket interface would be better than PDS?
___ gets 68030 entirely out of the way.
___ much easier to implement than worrying about how to use the PDS?

IIfx SIMM sockets would probably need to be empty?
__ 64MB would be implemented on the upgrade card upstream of PBX on the fast CPU bus.
__ 603e would be polling the address range, not necessarily the SIMMs at startup?
__ PBX will hopefully find it in that range, test it and get through POST?

64MB of RAM might be considered a step down for the IIfx, but having half its native memory allocation implemented in PSRAM on a 166MHz bus with cache would probably be sufficient? 😬

Anyway I don't think grafting a PBX into a desktop '030 is going to work because you'd have to disable or remove too many competing devices on the host logic board (and probably have to build custom ROMs to get the PBX to initialize itself and its new host Mac properly)
AFAIK, as a 16bit 030 bus bridge PBX just works? That'd be similar to the way my Performer's GAL interface implemented 68030 32bit bus to 68000 16bit bus just works? Not sure what the driver does initialization-wise.

IIRC Bolle said Performer should work without the 68000 on the board underneath. Haven't tested that, whether my card works or whether the card needs a driver and what it does at this point . . . a decade after discovering the Performer in my Drexel/128K/Plus. :rolleyes:

2300/5300/1400 ROMS are all the same or nearly so IIRC?
 
That whole high-16/low-16 smacks of the thoroughly debunked Performa 5xxx/6xxx left-32/right-32 thing from LEM so you're probably going to want to take that with a grain or ten of salt. I skimmed through some dev notes today but there wasn't anything concrete about exactly how the I/O bus operates (there's likely no need to get too in depth for stuff like that for average developers) but it appears to be a single flat bus, and so there's no mention of any high-16/low-16; most likely it's just sharing the same 16-bit bus (again this sort of thing is why Apple kept the '030 bus for so long: it was extremely versatile). I don't mind being proven wrong if you've got some docs I'm not privy to, though.
Didn't find it in the docs, IIRC that's what I found MANY years ago when I was trying to divine the pinout of PBX. I was buzzing the 1400 in order to replicate its PBX<->TREX/PCMCIA daughtercard setup in order to hack WiFi and HDD cards into the 2300c drive bay.

Thinking about it now, I might very likely getting hits on the soldered and expansion RAM's 32bit bus?

Dunno, hopefully I'll find paperwork on that, I think I may have lost the data when I killed a G4 drive by installing it in a Beige G3. :rolleyes:
 
edit window closed before I finished my tangent:
Didn't find it in the docs, IIRC that's what I found MANY years ago when I was trying to divine the pinout of PBX. I was buzzing the 1400 in order to replicate its PBX<->TREX/PCMCIA daughtercard setup in order to hack WiFi and HDD cards into the 2300c drive bay.
Test setup for that will someday be a Floppy MicroDock board wedded to the TREX/Card Cage in a clear plexi equivalent of the UltraDock case with its cavernous empty cubic available underneath. . . .

. . . for the announced, but never released PCMCIA UltraDock. 😬
 
Back
Top