PPC740L G3 CPU Daughterboard For Blackbird Powerbooks

[Paralel]

Very interesting. I'll have to look into those bridges some more...

Have to try and find one that is willing to speak 68030 bus, or the only way to talk to the 68040 side of the bus is to somehow interface with the CPU daughterboard directly...

 

[Gorgonops]

Have to try and find one that is willing to speak 68030 bus

My vague and limited understanding is the main difference that would render the Prometheus bridge incompatible with an exposed '030 PDS is that Zorro III multiplexes address and data lines (because it coexists with the 16 bit Zorro II protocol on the same connector); thus it requires a bus controller to handle the separate address and data phases, etc. So unless you're willing to cook up some Zorro III bus glue for Macintosh to stick in-between...

That said, it's really neat that an open-source PCI arbiter exists (it looks like it supports DMA between PCI cards and even has support for PCI-PCI bridges). If one was sufficiently motivated I'd be willing to bet a nickel that the Prometheus CPLD code could be used as a basis for a project this crazy.

Now doing the driver software once you have the hardware working, that's another kettle of fish...

 

[Trash80toHP_Mini]

Zorro III multiplexes address and data lines (because it coexists with the 16 bit Zorro II protocol on the same connector); thus it requires a bus controller to handle the separate address and data phases, etc. So unless you're willing to cook up some Zorro III bus glue for Macintosh to stick in-between...

Like maybe a stock TI NuBus Controller Defibrillator for the 68030 bus?

 

[kev7112001]

this bridge here works for a variety of cpus etc 

http://www.mouser.com/ds/2/100/CY7C09449PVA-AC - Obsolete-356429.pdf

and dont forget to always check out opencores.org for stuff

also VME bus based

another reason why we want to go around the amiga buster is also proper DMA

 

[Paralel]

All the parts are now in the hands of the master we are working with for assembly and testing. So, we are at the very last step in this process!

 

[Paralel]

Unfortunately, Plan A was a complete failure. Transplanting the G3 onto the NuPower 603ev-based CPU daughterboard was unsuccessful in the most fundamental sense. Once on the daughterboard, the system did not recognize the G3, regardless of what was tried. It acted like it would if no CPU was present. This really left us with nowhere to go, since one can't really proceed to diagnose an error state when the error is so fundamental that one cannot talk to the hardware in question.

So, the only hope of ever seeing a G3 in a Blackbird is to go to Plan B, making a new daughterboard. As one can imagine, this is a monumental undertaking. One, at the moment, I am in no position to undertake. I have more things in my life to handle than I have time for as it is, so this may happen some day in the very distant future, but certainly no time soon.

I thank all of you that were interested in this project for your assistance and feedback, Profound appreciation and unending gratitude go to CC_333 for providing the NuPower daughterboard, and Bolle for providing his services to transplant the G3 onto said board for testing. Without them, this theory never could have been tested. I am forever in debt to both of you for your efforts regarding this project. I am sincerely sorry that the outcome was not better.

 

[Trash80toHP_Mini]

So sorry to hear that. I've got hacks stacked to about Angels 60 before I can do anything on the 1400 processor card front. If you want to play around with that I could send you a C.A.R.E. package? Doing a bit of work on that would be the first step on the road to developing a viable interposer for a BlackBird PPC card heart transplant.

 

[Paralel]

Understanding the "black box" that is the "PBX" chip is indeed the only way forward. The fact that the 3rd party processor upgrades needed them proves that even these companies were locked into using Apple parts. It's too bad Apple wasn't more open about their old chips. Like they would ever need to use a PBX type design again.

 

[Trash80toHP_Mini]

No need to understand the black box.   We need to look at the Logic Board as an interstitial layer between PBX and the CPU board sockets of the 1400 board. After that we develop a higher end 1400 G3 card. PowerBooks are dying in droves from hinge and plastics failures. Cannibalization and new construction is the way to Blackbird heaven.

 

[Franklinstein]

Unfortunately, Plan A was a complete failure. Transplanting the G3 onto the NuPower 603ev-based CPU daughterboard was unsuccessful in the most fundamental sense. Once on the daughterboard, the system did not recognize the G3, regardless of what was tried. It acted like it would if no CPU was present. This really left us with nowhere to go, since one can't really proceed to diagnose an error state when the error is so fundamental that one cannot talk to the hardware in question.

Dredging this up because I'd like to know what may have been tried to troubleshoot the transplant. It's extremely difficult to troubleshoot BGA devices like this without special equipment (such as X-ray machines to verify the solder balls flowed correctly), especially if there's no documentation for where signals go on the board or to other chips. According to the datasheet the 740 should have been pin- and signal-compatible with the 603, but perhaps a signal wasn't where it was expected in this application; Apple does like to violate standards, after all. It's possible one of the former CPU I/O signals became simply an I or an O with the new chip, which didn't line up with what the PBX expects.

Software could be the problem: perhaps the ROM didn't recognize the new CPU and thus it was halted immediately. A number of modern Macs refuse to boot if their original 7400 or 7450 is replaced with a 7447 or 7448 because those chips are not in their original configuration info in OpenFirmware and so there needs to be a patch applied to get them to work. This doesn't seem to follow here since most Macs from this era including the PB 1400 can accept a G3 upgrade without issue. but maybe the ROMs used here were unique or an early revision that specified a 603e. Maybe compare ROM chips with the 1400 to see if they're similar?

Or perhaps the 740 won't initialize if the clocks are below a certain level (if perhaps the clocks were left at 167MHz for the initial testing rather than clocked up closer to the chip's rated speed). Some chips do have a minimum speed and don't run properly or at all if they're outside of specs. The 740 should have had no problem with the 33MHz bus but may have taken issue with the slow core clock.

At the very least, if you decided to reinstall a 603 on that card to return it to service, you could try to source a 300MHz part to put in place of the original 167MHz part. It's entirely possible that your chip was bad, too: these things are NOS from about 20 years ago and they may not have had the best storage environment in the interim. Maybe you can verify that the 740 is good by installing it in a different computer? Of course someone would need to find a reballing grid for the chip and another 603e-based board such as a Tanzania or Gazelle or a PowerBook to install it onto. Apparently the 603e and 604e shared the same BGA grid so maybe using a 604e daughter card would work? Probably need more research on that one. It's a lot of work, to be sure, but it's for science! Also I'd like to see this be successful, if only to justify the amount of effort you and others have put into it. 

 

[Franklinstein]

As for other options, the whole reason that Newer never made these G3 cards in the first place is that the molds for the processor card's connectors were destroyed. I think this was mentioned previously. Anyway because of this the only source for these connectors is old daughter cards. In order to build a new board you'd have to receive an old daughter card and harvest its connectors. Shouldn't be a big deal since there are so many dead 500 series machines and/or loose daughter cards as a result of PPC upgrades. I probably have 10 of them sitting around, mostly 25MHz modules. 

Anyway if you're going to build an entirely new card, I'd suggest scrapping the PBX and just going with an FPGA: program it to interface the 60x bus to the '030 bus and to provide a RAM controller that can use more than 32MB. You could probably program or buy the FPGA with a built-in DDR(2) memory controller, then solder on a RAM chip or four to end up with at least 128MB RAM without having to worry about a RAM slot and the associated connector for it. Use a socketed Flash chip to store the ROM and FPGA program. You could maybe run the CPU at a higher speed and wider bus to interface to the RAM but the '030 bus is sadly going to be stuck at the original 16 or 20MHz or whatever it is, so you'd definitely want the extra RAM to help the thing work without wasting too many of your CPU cycles waiting on the '030 bus. I'd recommend using a 750fx or gx since they're both very fast and relatively efficient (in addition to pin-compatible with one another). You could try a 7447 but you'd have to build a different board (it has a different BGA) and reprogram the FPGA to use the MaxBus instead of the 60x bus.

Unfortunately this approach wouldn't do much good for the 1400 since only the CPU is on the removable card; everything else is permanently affixed to the logic board, so no DDR(2) or anything for you.

Of course I say this, but the hard part is in software and you'd need people who were literate in the '030 bus, 60x bus, and/or with whatever FPGA family was chosen. Tall order there and I am not one of those guys. Unless everyone who still owns a working member of the 500 series opts in to buy one of these I don't think it would be worth the investment required.

 

[trag]

You could probably program or buy the FPGA with a built-in DDR(2) memory controller, then solder on a RAM chip or four to end up with at least 128MB RAM without having to worry about a RAM slot and the associated connector for it.

Newer Xilinx FPGAs typically have dedicated DDR2 controller cells built in.  For example, the Xilinx chips in the Pano Logic systems have four DDR2 controllers on board, although only two of them may be pinned out to the package.

The DDR2 buses on those chips are 16 bits wide.   DDR2 chips are available in capacities up to 2Gb (256MB).  A single 1Gb DDR2 chip would give 128MB of memory, albeit, only 16 bits wide, but at DDR2 speeds, one could handily string two operations together for every 32 bit access, although that would add a bit of logic. 

Alternatively, two DDR2 controllers could be used, each 16bits wide to yield a 32 bit wide bus, but the controllers are physically separated on the FPGA, so splitting the 32 bit operations, to essentially stripe them across the two DDRs might be a bit tricky and/or create performance/timing issues.

Xilinx has/had a memory configuration tool that could create a DDR2 controller out of generic logic.  That tool was capable of creating (IIRC) arbitrary bit width controllers, but certainly, up to 64 bits wide to access a standard DIMM.   That might be a better option, but using the dedicated hardware, if present is more economical of logic.

 

[Franklinstein]

Just so we're clear, here are my goals for one of these Plan B cards:

1. Simplicity for both design and production, which generally means 2. minimal component count, which in turn achieves 3. a relatively inexpensive project compared to pie-in-the-sky objectives. Ultimately the card would be designed to fit within the same dimensions and using mostly the same original heat spreaders and things while operating near the original TDP. This is so we can run the thing without having to remove the keyboard or add fans or something to vent the excess heat and to potentially run on batteries for more than 30 minutes before they're exhausted. While I do appreciate people who go bananas with some of this (1GHz+! G4! 8GB RAM! USB!), there's not much in the way of potential sales in a Frankenstein'd model that can't be used as a laptop as originally intended (not to mention you'd have to hack OS 9 onto it to use AltiVec anyway); if someone Kickstarter'd up a simple and functional drop-in upgrade, you'd get more interest and thus could recoup more money on your investment. 

Anyway, it's good news about the DDR2 memory. Two chips for 256MB would be all that a 5x0-series machine could need, so I'd be of a mind to not include a RAM expansion slot; just solder the two chips down, wire them to the onboard controller (which apparently would provide a 32-bit bus, yeah?), and call it good. If a 750fx or gx doesn't operate properly with a 32-bit memory width, either the FPGA can buffer for the extra bits or the design can be extended to four 1Gb chips to create the necessary 64-bit bus with 512MB of total RAM. Could you imagine? Over 12x the original maximum RAM. No need for VM or RamDoubler here.

 

[Nathan]

I would think the only point of throwing an actual memory slot on there would be the possibly of using existing memory sticks and replacements if failure should occur. Any time a component is soldered down it becomes significantly more complicated to replace if it fails.

 

[trag]

Anyway, it's good news about the DDR2 memory. Two chips for 256MB would be all that a 5x0-series machine could need, so I'd be of a mind to not include a RAM expansion slot; just solder the two chips down, wire them to the onboard controller (which apparently would provide a 32-bit bus, yeah?),

Not exactly.  If you use the dedicated DDR2 controller cells built into the FPGAs, you'd have two separate 16 bit buses.   You could stripe your 32 bit operations across the two controllers, using the FPGA logic, but you'd have to include that in your development.  You wouldn't just be sending 32 bit transactions to a single controller.    Of course, you'd probably develop that by creating a logical 32 bit controller that stripes 32 bit transactions across the two physical 16 bit controllers.  That might add a little latency, but at DDR2 speeds, it probably doesn't matter.

If you use the development tool that creates a custom DDR2 controller (and ignore the built-in controllers) then you could have a true 32 (or 64) bit wide  controller, which has the advantage of saving some IO pins (no duplication of address/control pins) but the disadvantage of using more of the FPGAs general logic.  There's so much logic available these days, that may not matter.  

DDR2 memory chips are available in 512Mb, 1Gb, and 2Gb sizes, or were.  It's been a few years since I was a DDR2 driver monkey.   Every capacity chip is available in 4, 8 and 16 bit widths.

So, a 32 bit wide DDR2 controller could be populated with eight X4 chips, four X8 chips or two X16 chips.

In practice, the only reason to use anything other than the X16 chips is if you are trying to increase your total capacity.

So you'd use two X16 chips for a 32 bit wide bus, or four X16 chips for a 64 bit wide bus. 

and call it good. If a 750fx or gx doesn't operate properly with a 32-bit memory width, either the FPGA can buffer for the extra bits or the design can be extended to four 1Gb chips to create the necessary 64-bit bus with 512MB of total RAM. Could you imagine? Over 12x the original maximum RAM. No need for VM or RamDoubler here.

Xilinx typically takes a given FPGA chip/die and makes it available in several different packages.  The different packages have different numbers of pins/balls and so affect how many I/O pins/balls are available.

So, for example, a given series of Xilinx FPGA might come in versions with 25K, 50K, 100K and 200K configurable logic blocks (CLBs), perhaps with some number of DSP slices and DDR2 controllers on the chip.    Then every one of those versions might be available in 144, 208, 256, 484 and 586 pin packages.   The above numbers are made up, but in the neighborhood.   The larger pin numbers yield more available IO pins to be used.  So the ratio between on-chip logic and IO pins can vary greatly.

The Xilinx chips I looked at recently contain four DDR2 controllers, each 16 bits wide.   Which, on the face of it, would suit the above needs well.   However, two of the DDR2 controllers are not pinned out except in the largest (most expensive) packages (packages with the most pins/balls).   You might need those largest packages any way, in order to get enough I/O pins, but it's just something to note.  In effect, these chips only have two available DDR2 controllers, except in the largest two packages.

But regardless of all that, you could satisfy any of these needs with a single X16 DDR2 controller, by, as you noted, buffering the transactions up to the required width.   Additionally, DDR2 transactions are performed in a Burst, typically of four reads or writes.   The Burst is going to happen (take up time) no matter what.   If some portion of the data is not needed those portions of the burst are signalled to be ignored, but they still happen and still take up time.

So, if your controller is doing every 16 bit transaction in groups of 4 anyway, it's always going to be taking time to read or write 64 bits.

All that said, I think soldering the DDR2 memory chips down is definitely the way to go.  They're reliable and tiny, like 12.5mm X 10mm X less than 1mm high.

 

[Trash80toHP_Mini]

Ultimately the card would be designed to fit within the same dimensions and using mostly the same original heat spreaders and things while operating near the original TDP. This is so we can run the thing without having to remove the keyboard or add fans or something to vent the excess heat and to potentially run on batteries for more than 30 minutes before they're exhausted.

Check power and cooling requirements of the CPUs you're considering before worrying about all that. Sonnet's Crescendo G3/PB processor card in the 1400 uses less power, extending battery life and likely producing less heat than Apple's stock 1400 processor cards. That may also be the case when comparing CPUs on Blackbird PPC upgrade cards to lower power PPC 750 variants?

https://everymac.com/upgrade_cards/sonnettech/crescendo_g3_pb/crescendo_g3_pb_333.html