Glad the PDFs were useful. I have some more stuff to scan (less interesting, mostly release notes for the early releases, but also the “Welcome” letter from JLG). I’ll get around to that later this week hopefully.
I have a whole bunch of ROM upgrades … mostly in the form of update floppy images which can reflash the ROM to the following versions:
- Advanced Access PR
I must also have the PR2 ROM somewhere as my box was running PR2 until last night. Maybe it’s on the installation CD somewhere (I think they are normally in /etc/beos/?)
Drop me an email (will “at” sowerbutts.com) and I can send you copies.
I’ve now reflashed my BeBox to the R4 ROM. I’m not sure this was a good idea – if I boot the system with my Matrox Millennium II card installed it appears to hang at the “Be” logo. With no hard disks connected it would normally time out and shows the boot device selection screen, but this doesn’t happen. If I swap the Millennium II for a #9 GXE64 card this does happen and with disks connected it boots normally. I don’t have a keyboard connected (my PS/2 to AT adapter hasn’t arrived yet) so maybe this is related.
I understand that R4.5 comes with a ROM update on the CD so I will try to install that when I get a chance. I read somewhere over the weekend that R5 does not have a ROM update so I think R4.5 (referred to as “R4.1” in the documentation I read) is probably the last version released.
The PR2 ROM worked well for me and would boot almost any version of the OS I could find. I wanted to try booting R5 from the R5 Pro CD, but it won’t boot it. My guess is that it can’t understand the Hybrid ISO9660/HFS+/BeFS CD format, and that the R4.5 ROM added support for this feature.
If anyone knows how to get the R5 installation media to boot on a BeBox I would be very grateful to learn how to do so, specially which ROM versions it works with.
I would love to see Haiku ported back to the BeBox. I must say I expect this to be a great deal of work as the 603/603e CPU doesn’t support the full MESI cache coherency protocol, only MEI. This has pretty serious performance implications.
This article on the PPC-750 has a quote which explains it nicely:
Quoting: Dominic Giampaolo of Be explained the situation most clearly: “The PPC-750 is a terrible choice for an SMP environment because it only supports the MEI (Modified-Exclusive-Invalid) cache-coherency protocol. The lack of a Shared state for the cache means that multiple 750’s will continually cause cache invalidates to other processors even if they’re just reading the same data. The slow down this causes is tremendous. While it is true that the BeOS is a fine SMP system, we also learned from painful experience on the BeBox that the 603 family (of which the 750 is a derivative) will actually slow down when doing certain very common tasks in parallel. […] On a BeBox you can write a program that takes 1 second when run on one cpu and 50 seconds when run on two cpu’s. The potential slow down on the 750 is even worse because its clock speed is so much higher. The presence of the backside cache does not alleviate the problem and in fact it makes it even worse (the larger the cache the more likely you are to have common items in other caches thus causing even more cache invalidates).”