Question: How powerful of a graphics card will work in a beige Power Macintosh G3?

[DearthnVader]

We would load the PEF from an unused partition of the disk, probably using deblocker seek and read commands or read blocks directly like in
https://68kmla.org/bb/index.php?threads/the-great-gazelle-pci-hack-thread-part-2.38360/post-466428

That's pretty interesting, I always wondered how XPF loaded BootX.

Is a .pef file something that OF understands, or is that something the nanokernel in the BootROM deals with?

I assume we have to get that .pef file onto the device tree for our cards so the nano kernel can pick up its properties and draw the screen. OF doesn't do anything with it, it's just the driver,AAPL,MacOS,PowerPC .property in OF.

Is that correct?

So how do we take the file from disk and load it into the driver,AAPL,MacOS,PowerPC property?

 

[DearthnVader]

Apple's old documentation on 'NDRV's said you could just place a file on the disk( assuming in the Extensions folder ) and it did not need a resource fork, but I was never able to get that to work.

Maybe a .pef would load from the Extensions folder, I never tried. I think in this case we have to load it as the driver,AAPL,MacOS,PowerPC property before we hand off control to the nanokernel otherwise it won't be able to draw the screen.

Of course we'll need to open the screen first:

" pci/@f/@0/@0" 2dup find-device open-dev to my-self

This worked, and I was able to draw the rectangle.

but this was a default catch:

" pci/@f/@0/@0" 2dup find-device open-dev . dup to my-self

Testing on the GF6600.

 

[joevt]

That's pretty interesting, I always wondered how XPF loaded BootX.

XpostFacto's BootX is loaded by classic Mac ROM boot methods. I think it's the boot code pointers setup in the Apple Partition Map?

Is a .pef file something that OF understands, or is that something the nanokernel in the BootROM deals with?

Neither. PEF is used by Mac ROM only, outside of OF and nano kernel. It's toolbox stuff - Resource Manager, Code Fragment Manager, etc.

I assume we have to get that .pef file onto the device tree for our cards so the nano kernel can pick up its properties and draw the screen. OF doesn't do anything with it, it's just the driver,AAPL,MacOS,PowerPC .property in OF.

The pef needs to be somewhere to get loaded. Either a property in the OF device tree or a resource in the resource fork of the Old World ROM (similar to how it is a resource in the New World ROM?).

So how do we take the file from disk and load it into the driver,AAPL,MacOS,PowerPC property?

I wouldn't store it as a file on disk because Old World Open Firmware can't read files from partitions. I would use the `dd` command in OS X to put the PEF into some blocks of a unused partition.

An nvramrc script can do it. You open the disk device, read the blocks containing the PEF into an area of RAM (one of the nvram variables has a load address which you may need to map before using - or use the more complicated virtual memory allocation routines in my compressed Nvidia 7800GT ROM).

Apple's old documentation on 'NDRV's said you could just place a file on the disk( assuming in the Extensions folder ) and it did not need a resource fork, but I was never able to get that to work.

Maybe a .pef would load from the Extensions folder, I never tried. I think in this case we have to load it as the driver,AAPL,MacOS,PowerPC property before we hand off control to the nanokernel otherwise it won't be able to draw the screen.

I don't know where the ndrv needs to be in order for it to get used. A device tree property or rom resource or system file resource or extension file. One of those should work. Maybe all of them can work.

Of course we'll need to open the screen first:

" pci/@f/@0/@0" 2dup find-device open-dev to my-self

This worked, and I was able to draw the rectangle.

but this was a default catch:

" pci/@f/@0/@0" 2dup find-device open-dev . dup to my-self

Testing on the GF6600.

That second one should be:

" pci/@f/@0/@0" 2dup find-device open-dev dup . to my-self

It prints the ihandle result of open-dev before assigning it to my-self
The result is expected to be not 0 which indicates that the chain of opens succeeded.

You would use a similar command to open a disk device (entire disk) or partition device (specify a partition in the path) before using read-blocks or seek and read (the last two use byte offsets while the first one uses block index.

 

[DearthnVader]

My GF6200 PCI doesn't like to play nice with the SiL3112.

Doesn't work with these two cards in my G5 and now my Beige wants to disable the GF card when the SiL card is installed too.

Sometimes it works fine in the Beige and sometimes it doesn't with the SiL card. Not sure is both ROM's are using FCode compression and that is causing the issue or what.

I never really tested it much, but there is a conflict there sometimes.

The GF6600 in the PCI to PCI-E bridge does not seem to be effected, tho it really seems to slow down the PCI bus.

 

[DearthnVader]

Did anyone ever notice the Beige G3 can Deep Sleep?

Only seems to do it for me under Mac OS 9.2.2, and even then only sometimes.

I guess it's not really deep sleep, but the power light flickers, just parking that ATA drive, the PSU and fan are still on.

 

[joevt]

Not sure is both ROM's are using FCode compression and that is causing the issue or what.

I wonder if the Sil uses compression and what memory it uses to decompress? My Nvidia fcode compression uses virtual memory (claim) to avoid using the OF dictionary (allot) and OF heap (alloc-mem). Would be interesting to patch byte-load so it reports how much memory (virtual, physical, heap, dictionary, stacks) each executed fcode image is using.

 

[LightBulbFun]

Did anyone ever notice the Beige G3 can Deep Sleep?

Only seems to do it for me under Mac OS 9.2.2, and even then only sometimes.

I guess it's not really deep sleep, but the power light flickers, just parking that ATA drive, the PSU and fan are still on.

its not really deep sleep, the first Mac to support proper deep sleep was the Sawtooth generation (Uni-north) only those macs can truly turn off all the fans etc and go into a standby state

the G3 beige will sleep per say, but as you say all the fans etc will keep running

 

[DearthnVader]

Well, right now the most powerful Graphics card you can use a a Beige G3 is the NVIDIA 7800 GT.

At least until @joevt hacks out some FCode for the 7800GTX/Quadro 4500/X1950 XT.

 

[LightBulbFun]

Awesome! nothing like Graphical overkill, I hope the Quadro FX4500 or X1900/X1950 cards can be made to work, that will give us Dual Dual Link DVI ports, stick 6 of those cards into a Power Macintosh 9500 and you can drive 12 30 inch cinema displays from a 1995 beige mac

I am curious on the ATI Radeon front, did anyone ever figure out how those ROM's work, as in how for example it knows how many ROPs to enable etc?

because the X1900 G5 card is a bit weird bugger that I have never been able to quite figure out what it is, its often said to be an X1900 GT, but the actual card/specs never give it a suffix, it had the Device ID of an X1950 XTX IIRC but I *think* its only a 36/12 card like an X1900 GT vs the full 48/16 of an X1900 XT/X1950 XT etc

so obviously while you can flash an X1950 XT with the G5 ROM and it works, I do wonder if we are leaving quite a bit of performance on the table? by way of un-enabled ROPs/TMU's? I know the X800 XT/X850 XT Mac ROM does the reverse of this, in that those are fully enabled R420/R481 16/16 cards but the FireGL X3 is a cut down 12/12 card, yet from what I have seen the Mac ROM force enables all ROPs/TMU's etc on an FireGL X3 even without having to do any sort of pencil modding etc

(I am curious if anyones benchmarked a Mac Pro X1900 XT against an X1900 G5 and flashed X1950 XT card?)

 

[DearthnVader]

Awesome! nothing like Graphical overkill, I hope the Quadro FX4500 or X1900/X1950 cards can be made to work, that will give us Dual Dual Link DVI ports, stick 6 of those cards into a Power Macintosh 9500 and you can drive 12 30 inch cinema displays from a 1995 beige mac

I am curious on the ATI Radeon front, did anyone ever figure out how those ROM's work, as in how for example it knows how many ROPs to enable etc?

because the X1900 G5 card is a bit weird bugger that I have never been able to quite figure out what it is, its often said to be an X1900 GT, but the actual card/specs never give it a suffix, it had the Device ID of an X1950 XTX IIRC but I *think* its only a 36/12 card like an X1900 GT vs the full 48/16 of an X1900 XT/X1950 XT etc

so obviously while you can flash an X1950 XT with the G5 ROM and it works, I do wonder if we are leaving quite a bit of performance on the table? by way of un-enabled ROPs/TMU's? I know the X800 XT/X850 XT Mac ROM does the reverse of this, in that those are fully enabled R420/R481 16/16 cards but the FireGL X3 is a cut down 12/12 card, yet from what I have seen the Mac ROM force enables all ROPs/TMU's etc on an FireGL X3 even without having to do any sort of pencil modding etc

(I am curious if anyones benchmarked a Mac Pro X1900 XT against an X1900 G5 and flashed X1950 XT card?)

I have the flashed X1950 XT, but sold both my PCI-E PowerMac G5's a few years back.

I will say it preforms better than one would expect in my Dual G5 2.0 Ghz in with the 66Mhz bridge in 66Mhz Mode in one of the PCI-X 100Mhz slots.

I just had to order a Yikes motherboard to see how well it will fair in the Yike 66MHz slot, but sadly ZIF G4's are hard to come by in the higher speeds. All I have is a MPC7400 v2.6 that maybe I can get to 450MHz, so I'm going to be CPU bound.

In the G5 both CPU's get pegged out running 3D games with the card in the PCI-X slots. So it's not a bunch of wait states where the CPU is waiting for data to reach the GPU because of the limitation of bandwidth.

I've seen this before testing 33MHz PCI, CPU only 50% utilized waiting on data to clear the bus. I think the other CPU is working on the PCI-X controller while one is running the 3D game, but I'll have to dig into it more.

My Beige PCI bus seems pretty slow with the GF6600 or 7800GT in the Bridge on the Bus, I think the GF6200 PCI may outperform them, I'll have to test, but it can't drive a 30".

 

[LightBulbFun]

I will say it preforms better than one would expect in my Dual G5 2.0 Ghz in with the 66Mhz bridge in 66Mhz Mode in one of the PCI-X 100Mhz slots.

does that work in Leopard? my X1950 XT flashed to X1900 G5, works with G3 Blue and white in its 66Mhz slot via a startech adapter just fine under tiger (tho I have not explicitly benchmarked it)

PowerMac G4 Fun! Part 2!

I present to thee the most graphically over powered PowerMac G3 blue and white ever LOL the french X1900 GT was a dud, but I managed to win the above X1950 XT a couple days ago, and successfully flash it :) where I am very pleased to report it does indeed work with my PCI to PCIe setup and...

forums.macrumors.com

but when I tried it in my MDD under Leopard it kernel panicked

https://forums.macrumors.com/threads/powermac-g4-fun-part-2.2246307/page-4?post=31593588#post-31593588

 

[DearthnVader]

does that work in Leopard? my X1950 XT flashed to X1900 G5, works with G3 Blue and white in its 66Mhz slot via a startech adapter just fine under tiger (tho I have not explicitly benchmarked it)

PowerMac G4 Fun! Part 2!

I present to thee the most graphically over powered PowerMac G3 blue and white ever LOL the french X1900 GT was a dud, but I managed to win the above X1950 XT a couple days ago, and successfully flash it :) where I am very pleased to report it does indeed work with my PCI to PCIe setup and...

forums.macrumors.com

but when I tried it in my MDD under Leopard it kernel panicked

https://forums.macrumors.com/threads/powermac-g4-fun-part-2.2246307/page-4?post=31593588#post-31593588

Works in the G5 under Leopard, but I had not tested in the QS or MDD other than OF video.

It would need the FCode updated for the Beige, the bridge shows up, but no card.

Have you checked to see if you StarTech card is 66MHz compatible?

Reggie SE select the bridge in the PCI tab and read the command registers.

 

[joevt]

Well, right now the most powerful Graphics card you can use a a Beige G3 is the NVIDIA 7800 GT.

What's the timebase-frequency of your Beige G3?

It should be in the CPU node of the device-tree.
It should match the value of @startvec A4 + @ in OF 2.0f1 and @startvec >tbclock @ in OF 2.4.

 

[DearthnVader]

What's the timebase-frequency of your Beige G3?

Not sure, the bus was set to the stock 66MHz and 33Mhz PCI.

If you tell me where to look for the timebase I'll look it up for you. Only app that I know showed the timebase was Skidmarks GT and I don't have it installed right now.

On that note did anyone notice that if you install Xcode from the Tiger DVD you get the Benchmarks folder with Skidmarks GT and I think Cache Basher, but if you update Developer Tools it deletes that folder and the two app?

Really annoying when something us use gets deleted by an update without asking you. Kind of reminds me of Windows Defender....

 

[joevt]

Not sure, the bus was set to the stock 66MHz and 33Mhz PCI.

If you tell me where to look for the timebase I'll look it up for you. Only app that I know showed the timebase was Skidmarks GT and I don't have it installed right now.

On that note did anyone notice that if you install Xcode from the Tiger DVD you get the Benchmarks folder with Skidmarks GT and I think Cache Basher, but if you update Developer Tools it deletes that folder and the two app?

Really annoying when something us use gets deleted by an update without asking you. Kind of reminds me of Windows Defender....

It should be in the CPU node of the device-tree.
It should match the value of @startvec A4 + @ in OF 2.0f1 and @startvec >tbclock @ in OF 2.4.

 

[LightBulbFun]

as an aside to all this, I have finally got my behind into gear and have been getting to grips with the DingusPPC emulator you have been helping create, its very awesome to see an accurate macintosh emulator being put together that can boot real Mac ROM's and behave literally as the real machines, bugs and all (I often wondered if QEMU might go down that route, I know there was at one point a fork of QEMU that could boot the G3 beige ROM to OpenFirmware, it would be fun in time to be able to boot the Mac99 emulated Sawtooth with a real Sawtooth ROM, or see DingusPPC manage to do uni-north machines, I am not fussy which emulator it is specifically )

but where I am going with this is all this has got me wondering if in time one would be able to pass through physical PCI devices to DingusPPC as one can do in QEMU? I figured that might be quite handy for debugging this sort of stuff

as an quick aside to the aside I tried to boot MacOS X Server 1.2v3 on dingus via the g3 beige machine and it seemed to hang on ethernet, not sure if thats a known bug or not so just thought I would quickly mention it, I also notice that OS X Server fails to detect the clock frequencies properly (this is something I know will break OS X server in itself, if you run it on real hardware thats too fast (for exmaple a real Sawtooth with a 1Ghz~+ CPU, these calculations also fail and then it runs *really* slowly as its internal clock/timing gets all screwed up, although in this DingusPPC case it did not seem to be running slow)

 

[joevt]

as an aside to all this, I have finally got my behind into gear and have been getting to grips with the DingusPPC emulator you have been helping create, its very awesome to see an accurate macintosh emulator being put together that can boot real Mac ROM's and behave literally as the real machines, bugs and all (I often wondered if QEMU might go down that route, I know there was at one point a fork of QEMU that could boot the G3 beige ROM to OpenFirmware, it would be fun in time to be able to boot the Mac99 emulated Sawtooth with a real Sawtooth ROM, or see DingusPPC manage to do uni-north machines, I am not fussy which emulator it is specifically )

but where I am going with this is all this has got me wondering if in time one would be able to pass through physical PCI devices to DingusPPC as one can do in QEMU? I figured that might be quite handy for debugging this sort of stuff

as an quick aside to the aside I tried to boot MacOS X Server 1.2v3 on dingus via the g3 beige machine and it seemed to hang on ethernet, not sure if thats a known bug or not so just thought I would quickly mention it, I also notice that OS X Server fails to detect the clock frequencies properly (this is something I know will break OS X server in itself, if you run it on real hardware thats too fast (for exmaple a real Sawtooth with a 1Ghz~+ CPU, these calculations also fail and then it runs *really* slowly as its internal clock/timing gets all screwed up, although in this DingusPPC case it did not seem to be running slow)

View attachment 2394499

There's lots still to be done in DingusPPC. Some stuff is not emulated yet. Ethernet, Serial DMA, etc. Some emulation needs improvement.

For PCI pass through, an emulator can translate PCI BAR accesses made by the emulated CPU but that's all. This may be sufficient for a graphics card in Open Firmware which doesn't use 2D or 3D acceleration. PCI pass through gets difficult for bus mastering PCI devices which can access system RAM without using the CPU. For example, a graphics card with 2D or 3D acceleration may read pixel data from system memory. The problem is, the guest OS programs the PCI device with guest physical addresses which have no relation to host physical addresses, so you need a translator between that PCI device and host memory. Another problem is interrupts where we want the guest OS to handle the interrupt generated by the PCI device. An IOMMU is supposed to be able to handle both cases.
https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d
Totally guessing without doing any research: I would assume that an IOMMU sees a "PCIe address + physical address" packet and translates that to a host physical address somehow. So the emulator would need to setup mappings for the PCI device that point to host physical addresses that represent the guest physical addresses.

 

[DearthnVader]

as an aside to all this, I have finally got my behind into gear and have been getting to grips with the DingusPPC emulator you have been helping create, its very awesome to see an accurate macintosh emulator being put together that can boot real Mac ROM's and behave literally as the real machines, bugs and all (I often wondered if QEMU might go down that route, I know there was at one point a fork of QEMU that could boot the G3 beige ROM to OpenFirmware, it would be fun in time to be able to boot the Mac99 emulated Sawtooth with a real Sawtooth ROM, or see DingusPPC manage to do uni-north machines, I am not fussy which emulator it is specifically )

but where I am going with this is all this has got me wondering if in time one would be able to pass through physical PCI devices to DingusPPC as one can do in QEMU? I figured that might be quite handy for debugging this sort of stuff

as an quick aside to the aside I tried to boot MacOS X Server 1.2v3 on dingus via the g3 beige machine and it seemed to hang on ethernet, not sure if thats a known bug or not so just thought I would quickly mention it, I also notice that OS X Server fails to detect the clock frequencies properly (this is something I know will break OS X server in itself, if you run it on real hardware thats too fast (for exmaple a real Sawtooth with a 1Ghz~+ CPU, these calculations also fail and then it runs *really* slowly as its internal clock/timing gets all screwed up, although in this DingusPPC case it did not seem to be running slow)

View attachment 2394499

Server required special handling with Qemu, we had to work on it awhile before patches were upstream.

BTW Joe got the B&W machine working to, just no hard disk support, yet. So the Sawtooth or other New World ROM's are completely doable, tho I think the G5 would be a real challenge as even all these years later very little is really known about the logicbaords and even Qemu on the Mac99 machine with the 970 CPU's fails to get past BootX, even in KVM mode.

I got about that far trying to boot Mac OS 9 in KVM mode on the G5, I get the Welocome to the NanoKernel message and thing just completely halt there. I think I tried my BootX with logging, it just sends each stage of BootX to the screen, but I got nothing but the grey apple screen.

Pretty sure it had to do with unimplemented SPR's.

 

[LightBulbFun]

Server required special handling with Qemu, we had to work on it awhile before patches were upstream.

BTW Joe got the B&W machine working to, just no hard disk support, yet. So the Sawtooth or other New World ROM's are completely doable, tho I think the G5 would be a real challenge as even all these years later very little is really known about the logicbaords and even Qemu on the Mac99 machine with the 970 CPU's fails to get past BootX, even in KVM mode.

I got about that far trying to boot Mac OS 9 in KVM mode on the G5, I get the Welocome to the NanoKernel message and thing just completely halt there. I think I tried my BootX with logging, it just sends each stage of BootX to the screen, but I got nothing but the grey apple screen.

Pretty sure it had to do with unimplemented SPR's.

it is worth pointing out that the G3 beige and G3 Blue and White are very similar in terms of hardware platform, they are both MPC106 based machines, and so is the Wallstreet, PDQ, Lombard, and Tray Loading iMacs for that matter, so it should be relatively trivial to add those to DingusPPC but the Sawtooth is a Uninorth+Keylargo machine a completely different platform, however since QEMU has managed it, I am sure DingusPPC people can and once Uninorth+Keylargo emulation aced, then it will be relatively trivial to emulate all of the G3/G4 PPC macs

if IDE works on the G3 beige then it should work for the G3 blue and white? I mean of course the main Ultra/33 bus is via a CMD646 controller which I understand may not be implemented yet in DingusPPC, but there is a ATA bus from the Heathrow derivative, Paddington Southbridge, usually used to feed the Optical drive and Zip drive, but it is fully bootable, I have booted hard drives off of it myself on my real G3 Blue and White (all of mine are Rev A's sadly so the main CMD646 ATA bus can be quite buggy) so I wonder if thats working in DingusPPC and can be used?

as for G5 emulation, I do wonder if that might be easier then one realises simply by way of the fact the PCIe G5's use an off the shelf main Northbridge funnily enough like the G3 Beige in the PowerMac11,2 case its the IBM CPC945 and there is documentation out there on it, so I would like to think that might make life easier when it comes to emulating such a system, but I am far from an expert in such matters!

 

[LightBulbFun]

There's lots still to be done in DingusPPC. Some stuff is not emulated yet. Ethernet, Serial DMA, etc. Some emulation needs improvement.

For PCI pass through, an emulator can translate PCI BAR accesses made by the emulated CPU but that's all. This may be sufficient for a graphics card in Open Firmware which doesn't use 2D or 3D acceleration. PCI pass through gets difficult for bus mastering PCI devices which can access system RAM without using the CPU. For example, a graphics card with 2D or 3D acceleration may read pixel data from system memory. The problem is, the guest OS programs the PCI device with guest physical addresses which have no relation to host physical addresses, so you need a translator between that PCI device and host memory. Another problem is interrupts where we want the guest OS to handle the interrupt generated by the PCI device. An IOMMU is supposed to be able to handle both cases.
https://en.wikipedia.org/wiki/X86_virtualization#Intel-VT-d
Totally guessing without doing any research: I would assume that an IOMMU sees a "PCIe address + physical address" packet and translates that to a host physical address somehow. So the emulator would need to setup mappings for the PCI device that point to host physical addresses that represent the guest physical addresses.

yeah I just thought i'd report it just incase it gave useful info, I am not sure if anyone else has tried booting MacOS X Server 1.2v3 in DingusPPC before now? I thought i would try because I like that OS for the fact its Mac OS X but platnium but also because it does not try and use any real form or accelerated graphics so I thought might be a good fit for the incomplete rage emulation, but obviously it falls over long before then, is there a flag I can pass to the emulator to remove the ethernet device all together to see if it gets any further?

along similar lines I then tried switching to a PowerSurge based machine, but it seems like while the ToolBox ROM can boot Classic Mac OS 9 no problems and I am able to set the right OpenFirmware variables with System disk to try and boot OS X Server 1.2v3

open Firmware however cannot seem to load from a SCSI device, I am not sure 100% sure however if this is an issue with my images I am using or the emulator, but this is what I get the debugger enabled

and this is what OpenFirmware is saying while thats going on/its failing to boot

 

[joevt]

if IDE works on the G3 beige then it should work for the G3 blue and white? I mean of course the main Ultra/33 bus is via a CMD646 controller which I understand may not be implemented yet in DingusPPC, but there is a ATA bus from the Heathrow derivative, Paddington Southbridge, usually used to feed the Optical drive and Zip drive, but it is fully bootable, I have booted hard drives off of it myself on my real G3 Blue and White (all of mine are Rev A's sadly so the main CMD646 ATA bus can be quite buggy) so I wonder if thats working in DingusPPC and can be used?

The DingusPPC IDE works. I can boot CDs in the DPPC B&W G3 but not HDs. I don't know why. There's no emulation of the CMD646 in DingusPPC yet.

as for G5 emulation, I do wonder if that might be easier then one realises simply by way of the fact the PCIe G5's use an off the shelf main Northbridge funnily enough like the G3 Beige in the PowerMac11,2 case its the IBM CPC945 and there is documentation out there on it, so I would like to think that might make life easier when it comes to emulating such a system, but I am far from an expert in such matters!

Need to add PowerPC 970 emulation, plus all the hardware emulation. The G5 has an IOMMU (DART).

 

[joevt]

yeah I just thought i'd report it just incase it gave useful info, I am not sure if anyone else has tried booting MacOS X Server 1.2v3 in DingusPPC before now? I thought i would try because I like that OS for the fact its Mac OS X but platnium but also because it does not try and use any real form or accelerated graphics so I thought might be a good fit for the incomplete rage emulation, but obviously it falls over long before then, is there a flag I can pass to the emulator to remove the ethernet device all together to see if it gets any further?

Maybe try editing the server installation so it doesn't have the Ethernet driver/kext?

along similar lines I then tried switching to a PowerSurge based machine, but it seems like while the ToolBox ROM can boot Classic Mac OS 9 no problems and I am able to set the right OpenFirmware variables with System disk to try and boot OS X Server 1.2v3

open Firmware however cannot seem to load from a SCSI device, I am not sure 100% sure however if this is an issue with my images I am using or the emulator, but this is what I get the debugger enabled

I believe the SC53C94 (Curio) SCSI controller used to work in Open Firmware in DPPC Power Macs, but there's currently a problem so you have to stick with DPPC Power Macs that support IDE or wait for mesh SCSI controller emulation to be added.

 

[LightBulbFun]

Maybe try editing the server installation so it doesn't have the Ethernet driver/kext?

I have never really been able to figure out how to mount a Mac OS X Server 1.x drive/partion/image file in another OS to do such things sadly

but I decided to attack the issue from the other end so to speak and disabled the ethernet in OpenFirmware, well I deleted a few of its properties namely the name property and compatible property, that managed to stop OS X Server 1.2v3 from complaining about the ethernet, however now it just hangs at registering cuda like so

and heres what debug output looks like and it also stops here

(this is with the g3beige machine as previously)


good to know that SCSI is currently borked in OpenFirmware, saves me chasing my tail in regards to that

 

[Rairii]

The DingusPPC IDE works. I can boot CDs in the DPPC B&W G3 but not HDs. I don't know why. There's no emulation of the CMD646 in DingusPPC yet.

B&W G3 open firmware only uses one of the two paddington IDE controllers. Anything else (ie, OS drivers) that specifically use both of them will still work.

This is the main reason why I hacked in bondi blue support in my dingus tree, its open firmware does use both of the paddington IDE controllers. (although it won't use the IDE controllers at all if the media bay ID isn't 0x30)

Another weirdness in bondi blue's bootrom/OF (bug?): when checking RAM size it checks the first RAM DIMM twice.

 

[Rairii]

...oh

there's a bug in dingus, the actual IDE devices don't receive the device number, so on the device side they're all device 0

AtaBaseDevice::set_host() and IdeChannel::register_device() need to be changed to fix this, with that done ide0/@1 will work lol