Jump to content

PPC740L G3 CPU Daughterboard For Blackbird Powerbooks


Recommended Posts

2 hours ago, Trash80toHP_Mini said:

Unfortunately, it looks like they did custom bridge logic.

The "Mediator" bridges for the Amiga have a welter of CPLDs on them. The closest thing to an off-the-shelf mass-produced solution seems to be the aforementioned Qspan2 by Tundra:

https://www.idt.com/products/memory-logic/ehb-embedded-host-bridges/ca91l862a-powerquicc-pci-bridge

 

That targets several products with 68040-like busses. (It's mildly interesting to note that this includes some PowerPC-core processors, although they're feeble little pipsqueaks that wouldn't be at all interesting prospects for Mac CPU upgrades despite having 68040-ish busses.) Given how cheap programmable logic is this day I don't see any particular advantage of using that device, particularly if your goal is to have the bridge try to paper over some of the software gaps you'll obviously run into in trying to graft PCI slots onto a 68k Mac that has no idea what they are. (In principle at least you could probably design a bridge that maps PCI devices' I/O into the assigned Nubus Superslot spaces via some programmable registers; obviously you'll still need to write drivers for whatever devices you intend to plug in.)
 

2 hours ago, kev7112001 said:

ther is another PCI bridge that just became fully opensource

Are you referring to the Prometheus bridge?

 

2 hours ago, kev7112001 said:

make a faster PCI to 030bus since at the moment the mediator board we use goes through the old slower Zorro bus which is a big loss atm since we only get a max 13MB/s bandwidth

Maybe it's worth pointing out that there's a limit to what you can reasonably expect to get out of an 030. Using 68020-compatible asynchronous bus transfers the 030 takes a minimum of three bus cycles to transfer a word, which makes the best you could ever possibly expect out of a baseline 16mhz '030 is something around 21MB/s. Synchronous transfers would get you to 32MB/s, but something tells me the Amiga chipset doesn't use those anywhere on the motherboard, but I could be wrong. (I'm also skeptical the "030 bus" in the Macintoshes that are subject to this thread use them either.) You certainly might gain *something* by going upstream of the Buster chip, but...

Link to post
Share on other sites
  • Replies 174
  • Created
  • Last Reply

Top Posters In This Topic

yes i know all about the bridges and yes the prometheus with latest firmware is out there and we are not using 030 cpu's just amiga's bus design is based on it

zorro can do fast as pci its the "BUSTER" controller that limits you this is why the Phase5/DCE GREX/visions series were fast as they had there own pci bridge to 040/060

 

http://www.e3b.de/prometheus/

Edited by Bunsen
excess quote
Link to post
Share on other sites
6 minutes ago, kev7112001 said:

zorro can do fast as pci its the "BUSTER" controller that limits you this is why the Phase5/DCE GREX/visions series were fast as they had there own pci bridge to 040/060

See, this is where I always sort of start losing the plot with Amiga upgrades, because essentially what you're describing in these systems is having a stand-alone single-board computer sitting on a PCI bus with the actual Amiga (IE, all the bits that actually make an Amiga an Amiga) just sort of sitting off to the side "over there". So is the resulting computer actually even an "Amiga" anymore (what *is* an Amiga, anyway...?) but... whatever, never mind.

In any case: you're the one who said:

Quote

in my other project we are trying to make a faster PCI to 030bus since at the moment the mediator board we use goes through the old slower Zorro bus

And:

Quote

just FYI Zorro bus is basically a 030 bus

which lead me to (apparently mistakenly) believe that actually communicating with stuff sitting on the actual '030 bus inside the old Amiga motherboard was something you actually cared about? You can look in the Motorola 68030 manual and read up on what transfer modes are possible on the '030 and you'll find the only circumstance under which you can even remotely approach the ridiculously optimistic "150MB/s" that's claimed Zorro III is capable of (which so far as I can tell is based on some rather unrealistic math and presumes a couple of not-68030-based targets communicating privately with each other) would be using synchronous stream mode on a 50mhz-ish '030 against a high-speed cache, and hitting that would depend on having hardware on the bus utterly different from anything that ever shipped in anything outside of some very exotic workstation.

Just out of curiosity, what is the fastest thing that supposedly sits on a Zorro III bus? The fastest "Fast RAM" memory benchmark I could find on this page is in the ballpark of 60MB/s, and that's to the onboard fast RAM in a Cyberstorm PPC. If it can only talk to RAM at 60MB/s how is it as fast as 32 bit PCI@133MB/s?

Link to post
Share on other sites
34 minutes ago, kev7112001 said:

yes i know all about the bridges

And also, just a note: Your tone seems very combative, perhaps you might want to take a deep breath or drink less coffee. I only posted the link to the Prometheus bus (and Qspan2) because Trash was asking for more specifics about 680x0-to-PCI bridge solutions and since you seemed like you might know I thought it'd be worth checking with you if that was the "open source" bridge you were talking about, verses some other project.

I'm sorry I apparently completely misunderstood whatever it is you're apparently doing when I extemporized about what sort of performance I thought was realistic to expect out of an '030-to-PCI bus that sits on a motherboard that incorporates chips designed for the '030 (and therefore imposes their speed limits on it), but, again, it seems to me like you're taking it as some sort of attack. Chill. Please. We're all friends here.

Link to post
Share on other sites
Just now, kev7112001 said:

um you must be mistaken about me and converting a bus into another is what all computers are doing i think you need to calm down 

For the record, you're talking to a moderator. Don't want to swing that around, but I think that's worth putting out there.

If you want to talk about Amiga bus converters in whatever detail you want by all means do so. But I think everyone would appreciate it if you'd actually do so in a way that contributes to the overall conversation rather than just dropping catty little content-less remarks and unverifiable vague claims.

Link to post
Share on other sites

He's a mod, you're not, think about it. [;)]

 

Back on topic:

 

I'm playing around with buzzing connections between PBX and the 603e on the 2300c board. Cleaned up the decapitated CPU pads and I've got a setup for pulling one leg off at a time for torturing that little PBX bugger. [}:)]  Five down, 235 to go. 603e-240 maps to PBX-1 as expected. Of course it's OVDD and 603e-239 maps to PBX-2 which is GND. Next three are all n.c. but no biggie. Haven't looked at the signal descriptions yet, but they don't sound like they head to the 030 I/O bus. I'm expecting beaucoups n.c. results on this go round. Whatever direct connections I find won't need to have wire test leads soldered to the pads on CPU or PBX sides of the board. That should simplify things, making buzzing the fast and slow buses a lot easier.

 

edit: dammit Eudi, you beat me to it! :p

Edited by Trash80toHP_Mini
Link to post
Share on other sites

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

Edited by Paralel
Link to post
Share on other sites
57 minutes ago, Paralel said:

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

Link to post
Share on other sites
1 hour ago, Gorgonops said:

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?

Link to post
Share on other sites
  • 4 weeks later...
  • 2 months later...

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.

Edited by Paralel
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Edited by Paralel
Link to post
Share on other sites

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.

Link to post
Share on other sites
  • 1 year later...
On 5/2/2019 at 2:04 PM, Paralel said:

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. 

Link to post
Share on other sites

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.

Link to post
Share on other sites
23 hours ago, Franklinstein said:

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
On 6/5/2020 at 1:14 PM, Franklinstein said:

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. 

 

Quote

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.

Edited by trag
Link to post
Share on other sites
On 6/5/2020 at 2:14 PM, Franklinstein said:

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...