Haiku PowerPC compatibility


#21

You are mistaken thinking that PPC was the main architecture, while it was the BeBox’s architecture, most computers running BeOS software were probably x86 due to the sheer number of them… and because of that most BeOS software is x86. And there is sometimes a PPC version also. By the time of Be’s demise, 1Ghz+ processor’s were already a thing while the PPC machines BeOS could boot on were stuck mostly in the 200Mhz range stock, with a slower system bus than contemporary x86 PCs (some machines could be upgraded to around 3-400Mhz with later cards maxing out at 700mhz, someone recently hacked a Powermac 9600 card to go up to 1.4Ghz also by swapping a newer CPU onto an older card it’s dubious if BeOS PPC would even run on such a mod though).


#22

Technically, it was still the main architecture, even if less popular. But it’s not like I knew the popularity or software library situation between the two, so thanks for the info, you do make a point.


#23

Dubba, there was no “main architecture” for BeOS… BeOS wasn’t even originally written for PPC, it was targeted originally at the AT&T Hobbit CPU, then ported to PPC, then ported to x86. Be wouldn’t have ported to x86 if they felt it was viable to stay on PPC only and continue to grow their userbase.

For instance this relatively well known demo was on x86 from around '98-'99… and even then it was definitely x86 as the primary target for BeOS, they even made a special BeOS PE version that would reboot from windows into it… which was not available for Macs (And many Macs were faster than the the BeBox comptuers). https://www.youtube.com/watch?v=s4A0Lc6DI7A


#24

Well, that’s our personal experience.

Let’s rollback a few years.

The PowerPC port was of course in our minds when working on Haiku. It made sense that it would be the first architecture to port Haiku to, besides x86, as a tribute to BeOS (even if we did not plan to be binary compatible there - we don’t want to be using Metrowerks compiler, which would be required for that).

The port initially targetted the first Mac Mini when it became available and one of the developers got his and on it. It was a not too costly and quite nice machine, it had an usable Open Firmware we could use to boot Haiku easily, etc. We never got further than the boot screen, however. These were the best nightly images you could get back then: a splash screen and maybe the kernel debugger, working on a single machine. What’s the point of keeping these online?

Later on, indeed PPC hardware became cheaper as Apple stopped supporting it. Several more Haiku devs started playing with the PPC port to revive it and bring it to more machines. Said machines all died of badly soldered GPUs and other hardware problems, and in one case, a silly attempt to switch the Open Firmware to little endian mode which completely bricked the machine in a way even Apple wouldn’t know how to fix. This is what the mentions on that page refers to. It is not a fail of PPC on its own, more of the motherboard manufacturing technologies of early ROhS days. Lead-free solder may be less polluting, it is also less long-lasting because it is less flexible. This was of course solved later on (to some extent) with… more chemical additives. Machines from this era will fail sooner or later then.

Anyways, there is now little interest in porting Haiku to 10 year old PowerPC hardware. The current focus is rather on Amiga revival machines, and in particular a Sam440 that was donated to one of our devs.

And finally a note on Haiku Inc: they own the trademark and pay for server hosting, but that’s pretty much it. There were some contracts in the past, the longest one lasting for about a year. But the Inc is not in a situation to pay a competitive price for a full-time developer, as it is funded only by user donations.

As for Talos-II, it’s quite costly hardware and none of our devs owns it. It’s as simple as that. If you want Haiku ported to it, get one machine and start hacking, or alternatively, try to give the machine to one of the devs and see if that’s enough motivation for them to start a port.

In my case, my main Haiku machine is a 12" laptop I cna carry around easily and I’m not really interested in big workstation hardware like this for my main machine.

And when it comes to experiment with porting Haiku, I will focus on hardware I already have: super cheap ARM devices, and maybe an old SPARC station that was donated to me. This should keep me busy for the next few years.


#25

Okay - revisionist history. The PowerPC was supported throughout the life of BeOS, but the PE product was created to draw in new users for the Intel platform. Why was this? Because there was a focus shift to Intel after Apple stopped co-operating with Be Inc and also stopped licensing the Mac to third parties. At that point there were no specs publicly available for any of the hardware and Be Inc decided to port to Intel to give themselves a life line. The Be Inc timeline is littered with such decisions:

  • Use Hobbit processor - processor is EOL before we get to production
  • Move to PowerPC as we have a lot of ex-Apple people who have some experience - EOL our hardware as it was too expensive and niche to gain traction
  • Port our code to Mac, as it is also PowerPC and gives us a life line - fail to sell OS to Apple, get the backlash from that and also the return of Steve Jobs and the end of the Clone era, PowerPC becomes dead int he water
  • Create an intel version to allow us to gain more market - use the wrong compiler and set ourselves back for an entire Revision by changing binary compatibility on Intel between R3 and R4
  • Realise that the Intel platform needs a boost and create the PE version to funnel sales to the Pro version - lose those sales when everyone realises PE is just fine and uses the old installer trick to get around the virtual hard disk issue and install on real hardware.
  • Decide that we are going to refocus again on IA, because there is a real market for that stuff - do this 10+ years too early and fall in to a hole financially when no one actually cares - alienate all the Desktop users in the process.

You can’t male this stuff up. It’s not the greatest timeline is it?


#26

And even the Opportunity rover went silent:
https://www.osnews.com/story/129490/the-last-power1-on-mars-is-dead/

Maybe if the used Haiku instead of some fancy RTOS it would be still working.


#28

Not sure what you mean by revisionist… nothing you said contradicts what I said. I said it was ported not that support was removed for the previous arch (though I guess it probably was for the Hobbit).

Anyway I’m tempted to get a PM9600 to go along with the BeBox… since you can upgrade one of those pretty far even though it’s still limited by the 50Mhz bus.


#29

Adding to all this, IIRC the first PPC platform tried was the Pegasos 1 which had a really buggy OF.

Also, the reason we don’t have PPC nightly builds anymore is not because we wanted to drop it, but because it broke (several times, got fixed and broke again) when we added package management, which touched a lot of areas, including the bootloader. This means there was a lot to fix to get it back to where it was. And usually when we have some time to fix it, it breaks again because of some new change on the x86 front. We’ll get there eventually, but it takes time.


#30

No chance, Haiku runs Okay-ish on dual 2 gigaherz Opterons, (about twice as effective as my old quad 2.5 ppc), and will no doubt struggle on any Ppc cores. ppc arch was awesome when it was around, but its getting fewer and fewer followers. MorphOS runs great on cetrain PPC macs, give that a holler.


#31

On the story of Be, some details to remember:

  • The port to Mac happened before dropping support for the BeBox. Indeed at the time with Daystar and other companies making Mac clones (some with 2 or 4 CPUs) there wasn’t much reason to keep manufacturing the BeBox.
  • The port to Intel was initially an effort with help from Intel, as they were interested in showing the slowness of PC compared to Mac was mostly Windows fault? That may explain the compiler choice too. Also GCC was not a mature product back then.

And I heard even MorphOS is considering switching to x86_64, so…


#33

Just ran across this… https://www.powerpc-notebook.org/2018/12/bookmark-the-date-for-pcb-donation-campaign-start/

Apparently its progressing… I wonder what the cost will be though the specs look OK and are mid range/modern. Dual threaded Quad core, MXM GPU, SATA and NVME… USB3. It checks lot of boxes.


#34

Only that waving PE around is demonstrating how Be Inc failed, not succeeded on Intel. PE was an act of desperation, not a flagship for making the platform great again.

Don’t get a 9600 unless you know what you are doing. A 9500/180MP will work no matter what and the 180MP is the dual processor version. What BeBox do you have? I used to own a 66, and the 9500 ran rings around it.


#35

I do know what I’m doing. Perhaps you are refering to the newer rev of of the 9600 for those boards > 250Mhz iirc… I believe those with the kansas board. The sub 250Mhz model should be slightly better than a 9500 though.

Also I wouldnt’ say they failed on x86… they had a great OS but where forced out of the market anti competitively. It’s not like the x86 and PPC versions of BeOS really have any differences to make you choose one over the other, beyond the greater amount of x86 BeOS software.

I don’t know what BeBox it is other than it likely being a very early one without blinkenlights and potentially unable to boot later revs of BeOS without some hackery to it’s firmware.


#36

Yeah the later revision. But you would need to know the logic board revision from the Seller as outwardly they all look the same. The 9500 is 100% supported, as is any other box with the same revision logic board (7300, 8500, etc.) in to which you could put a dual processor CPU card.

I was a powerpc hold out and used them well in to the mid 2000’s. it got used less and less. I only put my 9500 in storage when I moved about 2 years ago. I’ll dig it out at some point. The Dano build is worth finding. I have a video of it on YouTube that I linked to earlier (I don’t post much you’ll find it if you look at my posting history)

Your bebox will probably never boot past the DR’s. the boot ROM is too small. Without the original boot ROM source code, you have no chance of making PR or later booting. Maybe someone could ask ACCESS to release the bebox boot ROM source. It was a separate self contained bit of code, as was the boot ROM app and the Mac version of the boot code (Mac version compiles using CodeWarrior.)

But honestly, between a 604e and 603 processor based multiprocessor machine, the former is much faster and better experience. You could also look out for one of those quad core Mac clone beats. I always wanted one of those.


#37

I wouldn’t count too much on ACCESS, even if they still have that they’ll never take the time to dig it anyway.
IIRC the BeBox can reflash part of the bootrom, so possibly it can accept a newer image.
Also, it’s possible (and probably a good idea) to dump the current flash content just in case.
I think it should be mapped in an area somewhere in the kernel. So if you can boot you can use something like catarea (oh, why didn’t I publish this before?).


#38

From what I read, the prototypes used a smaller Flash so could not upgrade without swapping the chip.

I would dump it first of course before attempting to flash or swap out the flash/eeprom chip for a larger one.


#39

Ah ok.
What could be nice is a port of U-Boot or OpenBIOS, but that’d be quite a task, and probably too large for the flash chip…


#40

I saw that Haiku could boot on older Macs up to G3/G4 family. I had a Power Mac G5, so I started to review
these computers still being sold:

  • Apple Power Mac G5 - expandable, cheap,
  • Apple iMac G5 - all-in-one development machine, 2-2.5GB Max memory

Not as modern as an Amiga X5000, but they are cheap enough for devs to support them and get them
to other supporters. You can use the clouds to run a VM for build purposes.

Guess it just having warm (or cold) bodies or bots doing the trivial work.


#41

That probably isn’t very useful at this point; kernel-owned areas are now inaccessible from userland by default.


#42

but if you really want you can patch it in your own build.