Author Topic: MacOS 9.2.2 Emulation with QEMU...we need help!  (Read 52376 times)

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #20 on: February 12, 2018, 08:18:53 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #21 on: February 13, 2018, 03:43:08 AM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.



Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #22 on: February 13, 2018, 12:29:23 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.

I'll back up.  Yes some of this I was wrong on. 
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #23 on: February 13, 2018, 01:07:04 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.

I'll back up.  Yes some of this I was wrong on. 
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).

No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-

but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.

I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #24 on: February 13, 2018, 01:59:09 PM »
however there exists a shim to use respective driver from OS 9 is another question.

Yes we are on the same page here, but the wording of this made it not clear.


If it ain't broke, don't fix it, or break it so you can fix it!

Offline Daniel

  • Gold Member
  • *****
  • Posts: 300
  • Programmer, Hacker, Thinker
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #25 on: February 13, 2018, 02:22:49 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.

I'll back up.  Yes some of this I was wrong on. 
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).

No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-

but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.

I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.

Here is what I think would be needed to write an ATA driver for the 9Serve.

It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.

We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?

We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.

Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.

Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #26 on: February 13, 2018, 04:14:52 PM »
My 9serve is standing by with eager anticipation! ;)

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #27 on: February 13, 2018, 04:56:27 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.

I'll back up.  Yes some of this I was wrong on. 
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).

No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-

but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.

I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.

Here is what I think would be needed to write an ATA driver for the 9Serve.

It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.

We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?

We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.

Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.

I don't know about the Xserve (and why it would be favoured over regular powermac g5s for this purpose).

On OS 9 I don't think there would be significant issues, OF driver calls are synchronous (which also means the performance impact would be huge), I'm not entierly sure how disk drivers are invoked in Mac OS 9-9.2.2, I do recall that the file manager was made MP safe in Mac OS 9, I think the simplest (but also fairly slow) solution would be to write a very slim ndrv that issues a sc (system call instruction) and funnel calls from a central (nano kernel) place if one would attempt the OF path.
As for drivers- I think the PCI SDK should have enough info to be able to progress on this (at least for the shim path). Unfortunately Mac OS 9 is a pain in the butt to work with when it comes to drivers. Personally I would rather prefer attempting to get something going in QEMU with a 970 target than physical hardware to start with.

Also I don't believe attempting to reverse engineer code from OF is worthwile (the FCode drivers that exist are as noted sync and just the absolute minimum to be able to operate on any arbitary device OF detects)- it's probably way easier to rip it from Mac OS X (if available. To be honest I'm not sure if the ATA kexts ever was open sourced) or Linux.

As for removing specific controllers from Mac OS 9s knowledge (if they pose a problem), perhaps I'm wrong but wouldn't dropping it from the device-tree be enough? I can't recall I ever heard of OS 9 doing hardware probes on it's own on PCI PowerMacs.

I'm not sure what you mean with how OS 9 handles interrupts? I believe (but I'm quite rusty on the area, it's been like 18 years since I last digged around deep in Mac OS, so it could be somewhat inaccurate) but I think the general architecture (as of Mac OS 8.6 and later at least) is be that the nanokernel recieves the exception (owns the physical exception vector) and either handles it directly or routes it to the active MPTasks exception handler which in case of Mac OS would be the blue task, which in turn maps it to a 68k interrupt level and hands it to the 68k emulator for processing inside Mac OS.

Offline Daniel

  • Gold Member
  • *****
  • Posts: 300
  • Programmer, Hacker, Thinker
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #28 on: February 13, 2018, 07:18:14 PM »
G5 = Mega tough
Agreed.

64/32 bit really doesn't matter with the processing and execution of code.
There is an issue with memory though. The mmu in the G5 always runs at 64bit.  Doesn't mater if its 32 or 64 bit process.

Open firmware drivers will only be used if they are OS 9 compatible. 
My understanding though is that G5's do implement PowerPC architecture.  The things that are missing are actually suggested and not required for a PowerPC architecture.  If you can point me to a place that has a required instruction/register that the G5 does not have, I would love to see the document as their will probably be lots of other cool info as well.

Depending on how you define boot (get all the way to the desktop or at least load the ROM and start executing),  I have at one point gotten the OS 9 ROM loaded and as able to get through Trampoline code and hand off to the nano kernel.  From there, kaboom.  Like big time bad.  Not sure what the fuck happened, but it left my G5 in a very sorry state.

64/32 bit does matter as it affect the EA calculations and register content... But it’s no big deal to switch a 64 bit PPC to address mode.

Open firmware drivers are per definition OS 9 compliant, however there exists a shim to use respective driver from OS 9 is another question.

No the G5 does NOT implement the entire PowerPC architecture; the most well known lacking feature is swizzle mode (pesudo little endian).
There differences documented in the OS X Internals - A system approach.
Additionally XNU (The OS X kernel) has at least the UISA breaches documented and handled here
https://github.com/epipping/xnu-kernel-sources-ppc/blob/macOS-10.5.x/osfmk/ppc/Emulate64.s

IBM never claimed the PowerPC 970 implemented anything but PowerPC UISA compatibilty (which isnt entierly correct either as noted in the emulate.s file)

VEA and OSA is very different and does not conform to Book E.

I'll back up.  Yes some of this I was wrong on. 
But I'm not conviced on the Open Firmware drivers.
What is the definition that states the compatibility?
If I understand your statement, then OS 9 should have no problem booting on the xserve without removing the bridge controller for the ATA bus controlling the hard disks (not the one the optical drive is attached to).

No I'm saying that Open Firmware has builtin drivers for accessing the disk, for reading input devices, for ethernet etc. You loose this ability as soon as you quiesce the firmware however (that essentially tells the firmware to backdown, so normally you wouldn't quiesce until copied the device tree and loaded a replacement driver)-

but the OS can restore the open firmware for a single call if it wants to (requires supervisor access however)... So what I'm saying is that technically relatively simple shims should be possible to write to have something running.

I'm not saying Mac OS 9 does this, but technically it's possible (it's very likely it never opens an OF connection again once it's quiesced it).
It is possible to do this, but it would require a bit of knowledge on how things work.

Here is what I think would be needed to write an ATA driver for the 9Serve.

It would probably be easiest to copy the code from OF and write a regular driver, rather than use OF directly. Disk drivers get called at all kinds of inconvenient times and it would be hard to make sure OF is safe. OF code is PPC and relevant code is neatly grouped in packages. It would be fairly simple to adapt the driver code to use different calling conventions.

We would need to figure out how the API/ABI for ATA drivers work in Mac OS 9. I hope that there is documentation on this, but I don't trust that there is any. Maybe we could reverse engineer other ATA drivers to figure out how they work?

We need to figure out how to make the Trampoline not freak out when it encounters the ATA device tree node in a 9serve. I have absolutely no idea how to do this, but it will involve understanding both the Trampoline and the way Mac OS 9 handles interrupts.

Once we have done all these things, we will have a device driver and a modified Trampoline. I am guessing that both of these will go in the Mac OS ROM file.

I don't know about the Xserve (and why it would be favoured over regular powermac g5s for this purpose).

On OS 9 I don't think there would be significant issues, OF driver calls are synchronous (which also means the performance impact would be huge), I'm not entierly sure how disk drivers are invoked in Mac OS 9-9.2.2, I do recall that the file manager was made MP safe in Mac OS 9, I think the simplest (but also fairly slow) solution would be to write a very slim ndrv that issues a sc (system call instruction) and funnel calls from a central (nano kernel) place if one would attempt the OF path.
As for drivers- I think the PCI SDK should have enough info to be able to progress on this (at least for the shim path). Unfortunately Mac OS 9 is a pain in the butt to work with when it comes to drivers. Personally I would rather prefer attempting to get something going in QEMU with a 970 target than physical hardware to start with.

Also I don't believe attempting to reverse engineer code from OF is worthwile (the FCode drivers that exist are as noted sync and just the absolute minimum to be able to operate on any arbitary device OF detects)- it's probably way easier to rip it from Mac OS X (if available. To be honest I'm not sure if the ATA kexts ever was open sourced) or Linux.

As for removing specific controllers from Mac OS 9s knowledge (if they pose a problem), perhaps I'm wrong but wouldn't dropping it from the device-tree be enough? I can't recall I ever heard of OS 9 doing hardware probes on it's own on PCI PowerMacs.

I'm not sure what you mean with how OS 9 handles interrupts? I believe (but I'm quite rusty on the area, it's been like 18 years since I last digged around deep in Mac OS, so it could be somewhat inaccurate) but I think the general architecture (as of Mac OS 8.6 and later at least) is be that the nanokernel recieves the exception (owns the physical exception vector) and either handles it directly or routes it to the active MPTasks exception handler which in case of Mac OS would be the blue task, which in turn maps it to a 68k interrupt level and hands it to the 68k emulator for processing inside Mac OS.
The Xserve is noteworthy because Mac OS 9 is only really incompatible with the ATA chipset on it. To boot it, you have to delete the nodes for the ATA controllers and everything is fine. I mentioned it because there is only one task that needs to be done with it. It has one component Mac OS 9 can't handle. The G5 has many, and it is not clear how to test if 1 problem is fixed when the others are still there.

Dropping stuff from the device tree is enough, but then you can't use the device you forgot about. The Trampoline crashes hard when it encounters the interrupt properties of the ATA chipset's device tree node. An understanding of how these values map to NanoKernel and Name Registry stuff is needed to properly fix those issues. I am guessing that this knowledge will be helpful for G5 stuff too, because of that "Cascading Interrupt but no Cascading Bridge" (or something like that) error message.


Offline MacOS Plus

  • Gold Member
  • *****
  • Posts: 418
  • The 9serve Lives!
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #29 on: February 13, 2018, 09:47:34 PM »
  Daniel and I are on the same page here.  The G5 is kinda like fighting a war on many fronts simultaneously.  There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully.  Good examples would be as follows:

- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB

  The G5 is a lofty goal, but should be easier with more experience under our belts.  A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9.  This would have been awfully difficult without getting the machine to boot first.  The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU.  It seems far less likely to self-destruct than a G5 too.

Offline darthnVader

  • Platinum Member
  • *****
  • Posts: 679
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #30 on: February 14, 2018, 06:57:54 AM »
  Daniel and I are on the same page here.  The G5 is kinda like fighting a war on many fronts simultaneously.  There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully.  Good examples would be as follows:

- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB

  The G5 is a lofty goal, but should be easier with more experience under our belts.  A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9.  This would have been awfully difficult without getting the machine to boot first.  The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU.  It seems far less likely to self-destruct than a G5 too.

I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.

I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.

Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.

I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.

As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.

Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.

With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.

Are the USBHID drivers open source for OS X?

Damn Apple and there non-standard USBHID device. >:(

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #31 on: February 14, 2018, 11:05:44 AM »
  Daniel and I are on the same page here.  The G5 is kinda like fighting a war on many fronts simultaneously.  There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully.  Good examples would be as follows:

- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB

  The G5 is a lofty goal, but should be easier with more experience under our belts.  A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9.  This would have been awfully difficult without getting the machine to boot first.  The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU.  It seems far less likely to self-destruct than a G5 too.

I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.

I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.

Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.

I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.

As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.

Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.

With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.

Are the USBHID drivers open source for OS X?

Damn Apple and there non-standard USBHID device. >:(

No the unimplemented SPRs messages you see when you start QEMU is due to it’s firmware attempting to access book III SPRs.
As already said the most obvious modifications to even get past the lowest level code is to rewrite the TLB setup and as I said before several times the G5 don’t have BAT registers and I know for a fact Mac OS 9 uses them. But sure you could implement them, but it wouldn’t be a G5 anylonger.

As for 3D acceleration, Apple never released any 3D acceleration driver SDK, there is no hooks/API etc so even if you had complete documentation and or source code over a particular graphics chipset; what next? Reverse engineer Apples RAVE/OpenGL extension?

The basic 2D acceleraions hooks are documented however. (And further 2D acceleration- quickdraw for example is partially reverse engineered and can be found in the Basillisk source code)

---

I retract the statement about the SPRs above, my memory was apparently wrong; so now when I actually _tried_ it I get something like this (even on a cpu model that boots Mac OS 9 in qemu)

"Trying to write invalid spr 0 (0x000) at 00f113c0
Trying to read invalid spr 0 (0x000) at 00f113c8
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938"

This is Mac OS probing the processor indeed,

spr 0 is the 601 only MQ register (used by POWER instructions that the 601 included).
https://www.nxp.com/docs/en/data-sheet/MPC601.pdf - Described at page 14

955 is SIA (Sampled Instruction Address) not essential to run the system.
959 is SDA (Sampled Data Address) same as above.

https://www.nxp.com/docs/en/data-sheet/MPC604.pdf - Described at page 19 (955/959)

Additionally compare (especially the "Memory Management Registers") to
http://www.redbooks.ibm.com/redpapers/pdfs/redp3890.pdf - Page 13 (OEA environment)
« Last Edit: February 14, 2018, 01:00:43 PM by Naiw »

Offline darthnVader

  • Platinum Member
  • *****
  • Posts: 679
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #32 on: February 15, 2018, 03:45:47 AM »
  Daniel and I are on the same page here.  The G5 is kinda like fighting a war on many fronts simultaneously.  There are a number of fundamental things we can learn more easily by attacking isolated problems on other machines first, ones where we have at least been able to boot through to the Finder successfully.  Good examples would be as follows:

- Powerbooks/iBooks - correct video, sound and trackpad behaviours
- Xserve - primary ATA/RAID controller driver or firmware resolution, support for front-panel CPU meters
- Mini - PMU driver, may simultaneously resolve the need for disabling USB

  The G5 is a lofty goal, but should be easier with more experience under our belts.  A good example of learning from another machine was when I figured out how to enable the serial port on the Xserve under OS 9.  This would have been awfully difficult without getting the machine to boot first.  The Xserve is actually a great platform for OS 9, and can use the dual 1.8GHz CPU.  It seems far less likely to self-destruct than a G5 too.

I don't think that native boot of OS 9 on a G5 will ever come, there are simply to many drivers that need to be written.

I do think that it could be done with qemu, as qemu does the G5 on a basic sawtooth machine. Tho the state of the emulated G5 is it can't boot the Mac OS, as there seem to be unimplemented spr's that the Mac OS expects to use.

Shouldn't be that hard to implement these missing spr's, I just haven't looked into it. The G5 does boot Linux in qemu-system-ppc64 on the mac99 machine.

I've pretty much figured out the graphics 'NDRV' for ATI cards in OS 9, soon I'll have an OS 9 compatible nVidia card, and I have a PowerBook6,8 with GFGO5200, so I should be able to figure out the nVidia 'NDRV'.

As for graphic acceleration, for the 9200 based systems, it should be doable, but 9550/9600/9700 likely will never do 3D under OS 9, unless someone wants to port linux's Radeon driver, and mesa to OS 9. Not an easy task as they are built on X11.

Sound seems fickle, I have and iBook G3 and an iBook G4, both have the i2s sound device in the device tree, and the iBook G4 won't boot unless " screamer" is used as the " compatible" property. Or the device is removed from the tree.

With the iBook G4 the mouse is odd, it's just a USB tracpad, and it should work with OS 9, but it doesn't. It doesn't work with Tiger 10.4.0 either, so we know that the driver was added to 10.4.2 and later.

Are the USBHID drivers open source for OS X?

Damn Apple and there non-standard USBHID device. >:(

No the unimplemented SPRs messages you see when you start QEMU is due to it’s firmware attempting to access book III SPRs.
As already said the most obvious modifications to even get past the lowest level code is to rewrite the TLB setup and as I said before several times the G5 don’t have BAT registers and I know for a fact Mac OS 9 uses them. But sure you could implement them, but it wouldn’t be a G5 anylonger.

As for 3D acceleration, Apple never released any 3D acceleration driver SDK, there is no hooks/API etc so even if you had complete documentation and or source code over a particular graphics chipset; what next? Reverse engineer Apples RAVE/OpenGL extension?

The basic 2D acceleraions hooks are documented however. (And further 2D acceleration- quickdraw for example is partially reverse engineered and can be found in the Basillisk source code)

---

I retract the statement about the SPRs above, my memory was apparently wrong; so now when I actually _tried_ it I get something like this (even on a cpu model that boots Mac OS 9 in qemu)

"Trying to write invalid spr 0 (0x000) at 00f113c0
Trying to read invalid spr 0 (0x000) at 00f113c8
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938
Trying to write privileged spr 955 (0x3bb) at 00f168c8
Trying to write invalid spr 959 (0x3bf) at 00f16930
Trying to read invalid spr 959 (0x3bf) at 00f16938"

This is Mac OS probing the processor indeed,

spr 0 is the 601 only MQ register (used by POWER instructions that the 601 included).
https://www.nxp.com/docs/en/data-sheet/MPC601.pdf - Described at page 14

955 is SIA (Sampled Instruction Address) not essential to run the system.
959 is SDA (Sampled Data Address) same as above.

https://www.nxp.com/docs/en/data-sheet/MPC604.pdf - Described at page 19 (955/959)

Additionally compare (especially the "Memory Management Registers") to
http://www.redbooks.ibm.com/redpapers/pdfs/redp3890.pdf - Page 13 (OEA environment)

Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.

Not going to happen anyway, I only bring it up whereas to say what "could" be done, not what will be done.

I forget the SPR's that qemu-system-ppc64 spits out when trying to boot OS X with the G5 CPU, like I said, I really haven't looked into it. BootX just hangs, I created a version of BootX for Tiger with logging to see where the 7447a was hanging BootX, so I could use that to see where the touble is with the G5, tho it would only be an exercise in booting the Kernel, as we'd very soon be greeted by a kernel panic. As has already been confirmed by a KVM user that tried to boot on a real G5 using mac99 machine.

Offline MacTron

  • Global Moderator
  • Platinum Member
  • *****
  • Posts: 2116
  • keep it simple
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #33 on: February 15, 2018, 06:55:36 AM »
Sorry, I'm not following this thread, but:
Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.
Just to note that this is already done. IIRC
Please don't PM about things that are not private.

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #34 on: February 15, 2018, 10:48:56 AM »
Sorry, I'm not following this thread, but:
Well, if you port Mesa to the Mac OS, you don't need to worry about Apple's OpenGL.
Just to note that this is already done. IIRC

There is some super old port of Mesa somewhere, software rendering only.
And it was concieved before Apple purchased it’s OpenGL implementation from Conix.

But you’re right wouldn’t need to worry about Apples OpenGL in case, but rather getting gcc 4.2 or later, a modern pyhton etc.

Odd, Mac OS X boots just fine for me with Qemu and KVM on a G5, haven’t tried
TCG.

Offline ELN

  • Gold Member
  • *****
  • Posts: 295
  • new to the forums

Offline Jubadub

  • Gold Member
  • *****
  • Posts: 326
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #36 on: March 28, 2018, 07:16:06 AM »
But at the same time it’s not really a proper PowerPC, it does not implement all things defined in the PowerPC architecture. It doesn’t even have all instructions, so some have to be implemented and emulated at OS level (an application wouldn’t notice though).
But MacOS 9 is not an application; and it uses a lot of the constructs that the G5 lacks (BAT registers for example. And emulating the BATs with PTEs would probably require quite some hacks in the nanokernel.

Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?

(Also, for reference, for those curious:
- Release date of the first G5s ever: June 23, 2003
- Release date of Mac OS 10.3 Panther: October 24, 2003
Source: Wikipedia 2018-03-28 11:00 AM GMT-3, Panther and PowerMac/iMac G5 articles.)

Because if Classic isn't doing such emulation, then running OS 9 on Classic (on G5) would be simply impossible, right? There's no way mere virtualization alone could handle that, correct?
... Unless they changed OS 9 itself to replace those instructions, and thus released Mac OS 9.2.2, which, by the way, I do remember reading from changelogs that it implemented "better Classic support" or so. Of course, that's just wishful thinking, but I can't discard the perfectly-valid possibility and, thus, I ask: Naiw, you mentioned OS 9 "uses a lot of the constructs that the G5 lacks", but did you verify that specifically with OS 9.2.2 or did you verify that only with some earlier version(s)?

I'm just trying to sort that stuff out. Again, I hope you don't mind my asking!

(Incidentally, I know the lack of ANY straightforward little-endian support on G5, which all 32-bit PPC processors (Motorolla's, at least) had, is not at all a problem for OS 9, but only for emulation/virtualization of little-endian architectures/OSes, which is the main reason VirtualPC is worse on G5s than G4s in, at least, an equal processor clock speed configuration.
Not that you necessarily said or implied otherwise, but I figured I'd clear that up in case anyone would be confused by this.)

Offline nanopico

  • Platinum Member
  • *****
  • Posts: 767
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #37 on: March 28, 2018, 10:12:01 AM »

Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?


OS X on the G5 emulates the instructions needed for OS 9 in the actual emulator/runtime environment in classic.
My understanding on 9 is that it may be trapping and handlig uknown PPC instructions.  So in theory, those could be trapped and handled for running on the G5.  The trampoline code can install the trap handler for that so that the core OS wouldn't need to be patched.    I may be wrong on this though.  I haven't dug too deep into it.
If it ain't broke, don't fix it, or break it so you can fix it!

Offline Naiw

  • Veteran Member
  • ****
  • Posts: 126
  • new to the forums
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #38 on: March 28, 2018, 11:08:14 AM »
But at the same time it’s not really a proper PowerPC, it does not implement all things defined in the PowerPC architecture. It doesn’t even have all instructions, so some have to be implemented and emulated at OS level (an application wouldn’t notice though).
But MacOS 9 is not an application; and it uses a lot of the constructs that the G5 lacks (BAT registers for example. And emulating the BATs with PTEs would probably require quite some hacks in the nanokernel.

Naiw, I'd like to know a bit more about this, if you don't mind my asking. If OS 9 implements PowerPC mnemonics (if I understood you correctly) not present in IBM's 970 architecture (G5) as you say, then are you suggesting that Apple's Classic application not only virtualizes OS 9 in a transparent virtual machine as we all know, but also already emulates those few required Motorolla PPC instructions, perhaps by trapping them much like how Apple handled 68k+PPC code before? At the very least since late versions of Mac OS X 10.2 Jaguar, which was the first Mac OS X iteration to be available on G5s?

(Also, for reference, for those curious:
- Release date of the first G5s ever: June 23, 2003
- Release date of Mac OS 10.3 Panther: October 24, 2003
Source: Wikipedia 2018-03-28 11:00 AM GMT-3, Panther and PowerMac/iMac G5 articles.)

Because if Classic isn't doing such emulation, then running OS 9 on Classic (on G5) would be simply impossible, right? There's no way mere virtualization alone could handle that, correct?
... Unless they changed OS 9 itself to replace those instructions, and thus released Mac OS 9.2.2, which, by the way, I do remember reading from changelogs that it implemented "better Classic support" or so. Of course, that's just wishful thinking, but I can't discard the perfectly-valid possibility and, thus, I ask: Naiw, you mentioned OS 9 "uses a lot of the constructs that the G5 lacks", but did you verify that specifically with OS 9.2.2 or did you verify that only with some earlier version(s)?

I'm just trying to sort that stuff out. Again, I hope you don't mind my asking!

(Incidentally, I know the lack of ANY straightforward little-endian support on G5, which all 32-bit PPC processors (Motorolla's, at least) had, is not at all a problem for OS 9, but only for emulation/virtualization of little-endian architectures/OSes, which is the main reason VirtualPC is worse on G5s than G4s in, at least, an equal processor clock speed configuration.
Not that you necessarily said or implied otherwise, but I figured I'd clear that up in case anyone would be confused by this.)

First of all- just make one thing clear I’m not an expert on Classic; I stopped classic Mac OS development by the time Mac OS X was released, but I did use it a few times but not to that extent that I’ve actually reverse engineered it.

But I can share what I know (either because I found out by myself or because I at some point asked someone who ought to have good insight in the implementation out of curiousity)

But I’ll try to answer this the best I can and that I remember; with reservation for inaccuracies :p

Short answer:

Mac OS 7-9 works like this (abstraction level left to right)

HW -> Nanokernel -> 68k emulator -> Mac OS

Classic.

HW -> Xnu -> Classic -> 68k emulator -> Mac OS

Long answer:

As I said before the low level parts of ”Mac OS” (ie the parts that operates in powerpc supervisor mode) is the nanokernel (the nanokernel is not really part of Mac OS technically, but that’s something I’ve argued about before and really it doesn’t matter- it exists on all PowerPC implementations and later releases of Mac OS kind of depends on its services);

Classic however don’t use the nanokernel at all- instead it uses the Mac OS X kernel with a shim (the shim is of course to intercept nanokernel calls from within Mac OS- such those made internally by the MPLibrary).
This both makes the implementation easier as well removes complexity as well as avoids the need for supervisor mode at this abstraction level.

As for instruction emulation, this is also handled by Mac OS X kernel.
But there are exceptions that could be passed to classic via the OS kernel. Although this is the area my memory starts getting vague, I can not remember if custom exception handlers installed from classic apps actually worked.

But either way- there is no mechanism to override the kernel exception table; but unhandled exceptions are propagated to the currently executing mach tasks exception port and this is how classic would have to provide this functionality if it does/did.


A mach task (which is a container describing memory layout, threads and message ports- it’s kind of equivalent to a Process on most other systems, thus Mac OS X does not really have the concept of a process- but most of the system does... but that’s another topic)
Will recieve unhandled exceptions on it’s exception port

So summarized; The Mac OS X exception handler will always be first in line to handle any exceptions, (ie handle common exceptions). Unhandled exceptions will be passed to the mach tasks exception port and can be handled at that level.

But regardless as Mac OS 7-9 never exposed a powerpc supervisor mode to applications (and the area that is affected is the nanokernel which classic replace) there is little concern about instruction emulation. UISA is about the same.

But of course technically all of this could be emulated, but it’s certainly not the most efficient nor fastest path to solve the problem. What Apple did with classic is probably the most efficient way to solve it...

Offline Jubadub

  • Gold Member
  • *****
  • Posts: 326
  • New Member
Re: MacOS 9.2.2 Emulation with QEMU...we need help!
« Reply #39 on: March 28, 2018, 03:52:36 PM »
Ah, thanks, that was a great and well-detailed reply.

That clears a few things up a bit for me, and helped me realize something about what you said in an earlier post: according to you, the G5 processors implemented the UISA (User ISA) in a PowerPC-compliant way, meaning Book I of the POWER / PowerPC formal specifications, but not necessarily the rest (Books II, III and E).

Since the User ISA is 100% compatible and implemented between G5 and earlier PowerPC processors such as G3 and G4, doesn't that actually mean that Mac OS 9, which, being an OS, runs entirely on user space (excluding the nanokernel, which you suggested should be looked at separately) and, thus, is also 100% instruction-compatible with the G5 processor?

Assuming the answer to the previous question to be "Yes.", we are left with the nanokernel which, according to you, is normally used by OS 9, but is completely disregarded or even missing altogether in regards to Classic in Mac OS X (XNU). If I understood you correctly, the instructions you believe to be missing in the G5, which are on non-user-space, are present only in OS 9's nanokernel and are most likely emulated within XNU if XNU is running in a machine that lacks the native instruction.
Since Classic is a common program/process/task like any other that runs under Mac OS X, which in turn runs in user space, and since Classic delegates all the nanokernel calls to the XNU kernel instead, that means Classic itself does not and can not, by itself, emulate any missing instruction, but rely on XNU for all its nanokernel needs, including emulation of non-UISA-instructions, if needed. Classic is then unlike, for example, Rosetta on x86, which emulates the PPC UISA in an x86 UISA environment. And Classic IS like Rosetta in the sense that all that both can hope to achieve is stuck at UISA level (AKA user space).

With all this, I mean to conclude that, necessarily, Classic is not at all relevant to us here in terms of processor architecture compatibility or lack thereof for OS 9: the XNU kernel is. Correct?

If correct, then my understanding is that to solve this processor architecture problem, an implementation on the OS 9 nanokernel is necessary to immitate whatever the XNU is doing in those cases. And the XNU only. Preferably Tiger's XNU as opposed to Leopard's, as it's the last XNU revision we know for sure that had a motive to bother keeping OS 9 nanokernel instruction compatibility. Which is not to say that Mac OS X itself necessarily didn't contain those very instructions themselves to be later emulated within the XNU on G5s.

(For emphasis, motherboard & other hardware drivers, though, are still entirely different subjects and dependencies than what I'm trying to get at here.)

All OS 9 nanokernel gurus out there and Naiw, please do correct me if I said some gibberish somewhere here. :) I'm kinda walking blindfolded on some areas, but doing my best with it.