Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[darthnVader]

The Nano Kernel debugger and message log default to the serial port, but you can get it to also output to the screen, but you have no way to enter the interactive debugger without a serial port.

I think the modem can be put into serial mode for the nano_kernel debugger, but I never figured out how to do that?

[nanopico]

I haven't done much with the G5 and OS 9 for a while, but my last attempt I was able to get it fairly far, by disabling a lot of devices in Open Firmware and booting from a CD.  If I remember correctly the point of failure I hit was hardware related as I had disabled so much there was nothing to run the system.   I also recall something with the way the G5 addresses memory even in a 32 bit mode that made OS 9 freak out.

Do you remember what G5 model it was? I am very sure that booting from CD is not the best device with G5. Firewire might be only possible boot device and that with installed OS. Do you remember how much that G5 had memory?

It was a Dual 2.0 GHZ with the 4 memory sockets and PCI-X and it had 2GB of RAM at the time.  it was the only G5 I had at the time.  I know have a 1.6 GHZ PCI G5 which I suspect would be the easiest to get working, but not sure.

[teroyk]

The Nano Kernel debugger and message log default to the serial port, but you can get it to also output to the screen, but you have no way to enter the interactive debugger without a serial port.

So Xserve G5 2Ghz with serial port will be good choice for debugging. But who has that?
Actually, Powermac G5 1.6Ghz has 56k-modem port, can we change it to serial port?

[teroyk]

Do you remember what G5 model it was? I am very sure that booting from CD is not the best device with G5. Firewire might be only possible boot device and that with installed OS. Do you remember how much that G5 had memory?

It was a Dual 2.0 GHZ with the 4 memory sockets and PCI-X and it had 2GB of RAM at the time.  it was the only G5 I had at the time.  I know have a 1.6 GHZ PCI G5 which I suspect would be the easiest to get working, but not sure.

Yes 1.6 GHZ PCI would be best. Your setup might have 2 potential problems Dual processor and PCI-X, but I am not 100% sure. Also from IBM PPC Manual "Processors that implement the 64-bit bridge divide the 32-bit address space into sixteen 256-Mbyte segments " so good start would be with one segment, just only 256 MB memory. It also might help that no need for BAT-array(!).

[LarsG5]

No AGP card used in any of the G5 machines is OS9 compatible per se. FX5200 works in a Cube, true, but no 2d/3d acceleration renders it useless anyway. So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

[teroyk]

So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...

[IIO]

silly qustion but what happens if you put a x4 AGP card in the G5?

[LarsG5]

So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...

True, but still, it would only be a proof of concept rather than a great breakthrough. Still cool though.

On the other hand, flashing some PC video cards, that are potentially OS9 compatible and use "universal" x4/x8 AGP interface is also an option.

[teroyk]

silly qustion but what happens if you put a x4 AGP card in the G5?

It's not silly question...has anybody tested?

[LarsG5]

In best case scenario a Mac wouldn't power on, like it happens when you put an x8 card in x4 slot.
In x4 specs, pins 3 and 11 are left unused, but due to power draw of ADC monitors, they decided to supply some additional power via those two pins in x8 specification. Thats why you tape those two ping over when installing an x8 card in an x4 slot - otherwise the machine doesn't power on and simply acts like it's dead.

So yeah, best case scenario: the machine refuses to power on
Worst case scenario: magic blue smoke.

[teroyk]

So maybe better use PCI for graphics card in the some first tests, but has somebody PowerMac G5 with PCI-slots for test?

[LarsG5]

That's exactly what I pointed out several posts earlier 🤣
It would be just much much easier this way - one less hassle to tackle 🤷🏼‍♂️

[Jubadub]

This is a great initiative and pursuit, @teroyk, I'd love to hear more about your attempts and findings. Also, @nanopico, I hope you are doing better by now. And I'm also envious of your G5 collection.

So, let's see, to get things started, the ideal setup is:
- 1.6GHz 1st gen single-processor G5;
- A single 256MB RAM stick;
- PCI GPU Card, avoid AGP;
- Booting pre-installed OS 9 via FireWire preferred, at least at first. (Thoughts on USB?)

I was completely unfamiliar about processor-level hardware differences like the BAT registers. Goes to show what I really know about these processors. Now I wonder what else might be there that may pose a challenge. At worst, something(s) may have to be emulated or, alternatively, OS 9 itself to be patched.

Also, as I half-jokingly suggest here, could spoofing machine info (report it as an MDD, G4 processor etc.) have some potential of aiding down the line, I wonder?

So we would have to resort to PCI video cards, which kinda defeats the whole purpose other than to prove a point...

But it would be some kind of starting point...

True, but still, it would only be a proof of concept rather than a great breakthrough. Still cool though.

ROFL, this heavily understates the HUGE breakthrough it would be to boot OS 9 on G5s. 🤣

[teroyk]

- A single 256MB RAM stick;

I think memory have to be in pairs with G5 so two 128MB RAM sticks (And if I am right that was the default min. setup for G5 1.6Ghz)

- Booting pre-installed OS 9 via FireWire preferred, at least at first. (Thoughts on USB?)

And maybe via Firewire 800-port, because MDD2003 and some alu-Powerbooks see Firewire 800-port as Firewire 400 port with Mac OS9 and Firewire400 doesn't work, but maybe have to test both.

I was completely unfamiliar about processor-level hardware differences like the BAT registers. Goes to show what I really know about these processors. Now I wonder what else might be there that may pose a challenge. At worst, something(s) may have to be emulated or, alternatively, OS 9 itself to be patched.

Actually that BAT-register problem can good thing too, It can be help us to go "G5-side" for debugging time to time and that helps with another problems.

And actually how much Mac OS 9.2.2 use BAT-registers?
Is there little possibility that when Apple prepare for Classic between Mac OS 8.5-9.2.2 they drop use them as much that possible?

[darthnVader]

Running Linux with KVM and Qemu will get you a lot further as far as G5 CPU support.

It uses the mac99( G4 AGP Sawtooth ) machine model, so you won't have to go about debugging and disabling all the hardware in the device tree that the Mac OS ROM doesn't know what to do with.

This will allow you to focus on the CPU.

You can check my thread:

http://macos9lives.com/smforum/index.php/topic,4600.msg36426.html#msg36426

I got the nano_kernel boot log, but never debugged any further to see why booting halted at the first line of the log.

[teroyk]

Running Linux with KVM and Qemu will get you a lot further as far as G5 CPU support.

Yes, but can I emulate with Qemu the Powermac G5 PCI 1.6GHz/256MB  from very beginning from boot from firewire?
And of course that kind of environment can have it's own errors.

I am interested is it started in 64-bit bridge (32-bit compatible) mode ? And what is first thing that crash, is it illegal instruction trap (because use of BAT-register) or what?
If it not start in bridge mode we have to put it in that mode before load OS and maybe setup illegal instruction trap to emulate BATs.

[darthnVader]

From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.

[Jubadub]

From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.

I'm pretty sure teroyk already knew there will be a rough road ahead. The roughness of it will be there regardless of the approach being via QEMU or real G5 hardware, like you pointed out. Disabling stuff just to get to the point it would start from QEMU is a relatively minor point, because that is the "easy" part.

And "no source code" or "pretty much, no source code", not exactly. Again, consulting with/porting over GNU/Linux, BSD and/or even MorphOS drivers & other code for G5s is still a possibility, for anyone serious. (Although even without any source code, it'd still not be impossible, but "just" a lot harder.)

As long as the individual is committed and serious enough about it, there is nothing to stop it from happening. That goes for nearly everyone regarding nearly everything.

[darthnVader]

From what I've read, you have to strip the device tree of major road-blocks like USB, leaving you with no means of I in IO.

I'd assume there could be some way of adding a true serial port to the G5, to overcome the lack of USB, if that's the rout you decide to take, but you are going to strip things way down just to get over the trampoline and to the nonokernel.

At some point you are going to have to go back and rewrite most of the Parcels file drivers, then you'll have to deal with the Mac OS drivers, with, pretty much, no source code.

I'm pretty sure teroyk already knew there will be a rough road ahead. The roughness of it will be there regardless of the approach being via QEMU or real G5 hardware, like you pointed out. Disabling stuff just to get to the point it would start from QEMU is a relatively minor point, because that is the "easy" part.

And "no source code" or "pretty much, no source code", not exactly. Again, consulting with/porting over GNU/Linux, BSD and/or even MorphOS drivers & other code for G5s is still a possibility, for anyone serious. (Although even without any source code, it'd still not be impossible, but "just" a lot harder.)

As long as the individual is committed and serious enough about it, there is nothing to stop it from happening. That goes for nearly everyone regarding nearly everything.

Having a working debugger like GDB is pretty much mandatory.

[teroyk]

Having a working debugger like GDB is pretty much mandatory.

GDB is not option (or is not good debugger anyway (my biased opinion)).

Very beginning of start we have to use Open Firmware debugging, some information might be here: http://www.dialectronics.com/Words/OF_Part_II.shtml
And here some information if somebody want use open firmware debug thru ethernet with telnet connection: https://www.fenestrated.net/mirrors/Apple%20Technotes%20(As%20of%202002)/tn/tn2023.html