Login  •  Register


The time is now: Wed Oct 18, 2017 4:43 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 66 of 75 [ 1865 posts ]    Go to page Previous  1 ... 63, 64, 65, 66, 67, 68, 69 ... 75  Next
Print view Previous topic  |  Next topic
Author Message
PostPosted: Sun Feb 05, 2017 5:01 pm 
Offline
Granny Smith
User avatar

Joined: Thu Jan 05, 2017 6:24 pm
Posts: 108
Can you help me out with my issue? It keeps closing down me.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Feb 05, 2017 5:08 pm 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
Meow_2004 wrote:
Can you help me out with my issue? It keeps closing down me.


I can't seem to run DP2 from a build of the source code that alex linked, I think Cat_7 built the qemu.exe from that source code, I'm not sure it will run DP2.

It keeps rebooting on me, before I get passed BootX, but it maybe the Screamer mod I did to the source code.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Feb 05, 2017 8:23 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 203
Cat_7 wrote:
I don't know in what loop the audio runs, but I guess it doesn't get enough time. There is some talk on the development list about supporting sdl2 audio playback as you probably have seen. Perhaps that is a route.
Or threading. It seems there are some issues with SDL and threading.

Best,
Cat_7


I think you are on to something. There isn't any mutex locks in the screamer source code. So what is stopping two or more threads from changing the audio buffer - nothing!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Feb 05, 2017 11:41 pm 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
darthnvader wrote:
Meow_2004 wrote:
Can you help me out with my issue? It keeps closing down me.


I can't seem to run DP2 from a build of the source code that alex linked, I think Cat_7 built the qemu.exe from that source code, I'm not sure it will run DP2.

It keeps rebooting on me, before I get passed BootX, but it maybe the Screamer mod I did to the source code.


Just on the off chance it happens to be helpful, I have a recompiled version of BootX with logging here; in /theory/ it should work for DP2 (it works for Server 1.x and OS X 10.0+): https://github.com/steventroughtonsmith/BootX

(find it in the Releases tab)


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 1:32 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
steventroughtonsmith wrote:
darthnvader wrote:
Meow_2004 wrote:
Can you help me out with my issue? It keeps closing down me.


I can't seem to run DP2 from a build of the source code that alex linked, I think Cat_7 built the qemu.exe from that source code, I'm not sure it will run DP2.

It keeps rebooting on me, before I get passed BootX, but it maybe the Screamer mod I did to the source code.


Just on the off chance it happens to be helpful, I have a recompiled version of BootX with logging here; in /theory/ it should work for DP2 (it works for Server 1.x and OS X 10.0+): https://github.com/steventroughtonsmith/BootX

(find it in the Releases tab)


Thanks steven, I I've been checking out booting emu-system-ppc64 with -cpu 970fx, but it hangs at BootX, so maybe this will tell me why the mach_kernel never loads.

hmmmmm.......................

Must be missing the code for mac99_U3, or the 970fx?

Image

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=0,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=2,format=raw,media=disk -prom-env 'boot-device=ide2:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide0:9,\mach_kernel' -serial stdio

>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.


EDIT, ok, got it, for some reason the drives weren't the right index, but it didn't really tell me anything I didn't know, the kernel isn't loading:

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=1,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=0,format=raw,media=disk -prom-env 'boot-device=ide0:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide1:9,\mach_kernel' -serial stdio -g 1024x666x8


>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.
main-loop: WARNING: I/O thread spun for 1000 iterations
>> switching to new context:
>> call-method slw_update_keymap failed with error ffffffdf


Mac OS X Loader
[BOOTARGS] ide1:9,\mach_kernel
Opening partition [ide1:9]...


Last edited by darthnvader on Mon Feb 06, 2017 2:18 am, edited 1 time in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 2:06 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
I think that booting DP2 in g3beige may be more stable.(As DP1 in g3beige works fine).Didn't try myself though.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 2:23 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
I don't think I was able to boot DP2 with mac99, I think it has to be g3beige, but I was just checking if steven's BootX with logging would tell me anything useful as to why the mac99_U3 G5 wouldn't boot Panther's kernel.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 2:40 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
I used to boot DP2 in mac99 so far.Just now have tried 5 or 6 times to boot in g3beige (checking filesystem,rebooting and an error with LoginWindow).The last attempt successful(-usb -device usb-mouse and 32 bit mode on command line).
The second boot (after shutdown) successful,the third not.
MacOS.app in DP2 provides Mac OS 9.0 with Mac OS ROM 3.0.In DP1 it is MOS 8.6.
By the way,it's a proof of concept: MOS 8.6 and 9.0 can work in qemu g3beige.We only need to find the way.


Last edited by alex195812 on Mon Feb 06, 2017 3:54 am, edited 1 time in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 3:46 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
alex195812 wrote:
MacOS.app in DP2 provides Mac OS 9.0 with Mac OS ROM 3.0.In DP1 it is MOS 8.6.By the way,it's a proof of concept: MOS 8.6 and 9.0 can work in qemu g3beige.We only need to find the way.


Interesting, I thought the "Blue Box" ran in some sort of emulation, I thought I read somewhere that it didn't really boot on the real hardware, if it does, the we show be able to get OS 9 to run on a G5?

I forget how to use MacBugs, but it's not really useful, because it doesn't load till after all the toolbox calls and MacOS Rom calls?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 3:58 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
Yes it's kinda emulation,but not too sotfy (there must be many redirections to "real" hardware).
Afaik,no one has booted MOS 9 on G5.On unsupported G4 -- yes.
There's something about it at https://www.thinkclassic.org/viewtopic.php?id=46
I think the most "native" system for G5 is Leopard.And it seems that nothing yet works in qemu-system-ppc64 mac99.It's in an early state yet.


Last edited by alex195812 on Mon Feb 06, 2017 4:49 am, edited 5 times in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 4:05 am 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
darthnvader wrote:
Thanks steven, I I've been checking out booting emu-system-ppc64 with -cpu 970fx, but it hangs at BootX, so maybe this will tell me why the mach_kernel never loads.

hmmmmm.......................

Must be missing the code for mac99_U3, or the 970fx?

Image

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=0,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=2,format=raw,media=disk -prom-env 'boot-device=ide2:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide0:9,\mach_kernel' -serial stdio

>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.


EDIT, ok, got it, for some reason the drives weren't the right index, but it didn't really tell me anything I didn't know, the kernel isn't loading:

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=1,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=0,format=raw,media=disk -prom-env 'boot-device=ide0:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide1:9,\mach_kernel' -serial stdio -g 1024x666x8


>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.
main-loop: WARNING: I/O thread spun for 1000 iterations
>> switching to new context:
>> call-method slw_update_keymap failed with error ffffffdf


Mac OS X Loader
[BOOTARGS] ide1:9,\mach_kernel
Opening partition [ide1:9]...


Actually that sounds like the partition isn't being opened correctly, probably at the OpenBIOS level? It was something like this that required my OpenBIOS partition check patch on Server 1.x. It would go beyond that in BootX if the problem were the kernel itself (it tells you when it's about to jump to the kernel).

Granted I haven't tried with 10.3's kernel, only 10.1 and earlier :???:


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 5:05 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
steventroughtonsmith wrote:
darthnvader wrote:
Thanks steven, I I've been checking out booting emu-system-ppc64 with -cpu 970fx, but it hangs at BootX, so maybe this will tell me why the mach_kernel never loads.

hmmmmm.......................

Must be missing the code for mac99_U3, or the 970fx?

Image

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=0,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=2,format=raw,media=disk -prom-env 'boot-device=ide2:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide0:9,\mach_kernel' -serial stdio

>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.


EDIT, ok, got it, for some reason the drives weren't the right index, but it didn't really tell me anything I didn't know, the kernel isn't loading:

Code:
./qemu-system-ppc64 -M mac99 -cpu 970fx -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=1,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=0,format=raw,media=disk -prom-env 'boot-device=ide0:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide1:9,\mach_kernel' -serial stdio -g 1024x666x8


>> =============================================================
>> OpenBIOS 1.1 [Nov 24 2016 21:23]
>> Configuration device id QEMU version 1 machine id 3
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,970FX
milliseconds isn't unique.
main-loop: WARNING: I/O thread spun for 1000 iterations
>> switching to new context:
>> call-method slw_update_keymap failed with error ffffffdf


Mac OS X Loader
[BOOTARGS] ide1:9,\mach_kernel
Opening partition [ide1:9]...


Actually that sounds like the partition isn't being opened correctly, probably at the OpenBIOS level? It was something like this that required my OpenBIOS partition check patch on Server 1.x. It would go beyond that in BootX if the problem were the kernel itself (it tells you when it's about to jump to the kernel).

Granted I haven't tried with 10.3's kernel, only 10.1 and earlier :???:


Could be, when I tried the same thing with the 32 bit G4 and mac99, I got:

Code:
./qemu-system-ppc -drive file=/Users/jam2/Downloads/Qemu_2/Panther.img,index=1,format=raw,media=disk -drive file=/Users/jam2/Downloads/BootX_custom.dmg,index=2,format=raw,media=disk -prom-env 'boot-device=ide1:2,\BootX' -prom-env 'boot-args=-v rd=hd0 debug=0xffe kdp=2' -prom-env 'boot-file=ide0:9,\mach_kernel' -serial stdio -g 1024x666x8 -bios /Users/jam2/Downloads/qemu-scr-sun-co10012017/openbios-qemu-scr-sunM.elf -M mac99 -cpu G4 -m 768


>> =============================================================
>> OpenBIOS 1.1 [Jan 9 2017 04:56]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 768M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
milliseconds isn't unique.
>> switching to new context:


Mac OS X Loader
[BOOTARGS] ide0:9,\mach_kernel
Opening partition [ide0:9]...
main-loop: WARNING: I/O thread spun for 1000 iterations
HFSInitPartition: 2fc5b1e8
UFSInitPartition: 2fc5b1e8
Ext2InitPartition: 2fc5b1e8


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 5:26 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
I think people have Linux working on the ppc64 mac99, using 970fx, but I'm not sure.

I'm not really sure the point of trying to run 8.6 on the g3beige. The g3beige seems to be the one closest to a real mac, I've even encountered the 768MB ram limit for the Beige G3. It may need a rewrite of the mac_oldworld.c to even support Rom in Ram.

Sure, ideally, we'd love to see the g3beige support booting 8.1, 8.5, 8.6, 9.0, 9.0.4, 9.1, 9.2.1, 9.2.2, 10.0, 10.1, and 10.2.x, but it would either require incorporating the actual boot rom image of a Beige G3 into Qemu, or rewriting the g3beige emulator to make it pretty much like mac99, that is a bastard of a Beige G3, a Yikes, and a Sawtooth.

Maybe, it can be done by only modifying the Mac OS Rom, and the Systems suitcase, but, in the end, I can't think of any software that will run on a Powermac emulator in 8.1, 8.5, or 8.6, that won't run in OS 9. It's all about compatibility with older software, getting older OS's to run is pointless, without the need to run an older version, for software to run.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 5:34 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.
But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 7:11 am 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
alex195812 wrote:
BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.
But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too


BeOS definitely won't work as-is, I looked into it—the MacOS portion of the installer chain-loads a PEF bootloader from its resource fork, I believe. I ripped it out to study it; if you could boot it directly, then you don't need the Mac OS bit at all. https://www.dropbox.com/s/8khd9ycss1w1z35/BEBOOT.zip?dl=0

I believe this only supports PReP machines, not OpenFirmware (OpenBIOS), so you'd need a whole new hardware target in qemu emulating an older kind of PowerMac.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 12:03 pm 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 101
alex195812 wrote:
BeOS may be started from Mac OS ,but it seems it doesn't support Mac OS 9.That's why I want 8.6.
But booting 8.6 in mac99(with changed MacOS ROM and edited System file) fails with "bus error".That's why the hope is for g3beige.Though currently it fails,too


I think it maybe easier to get the Mac99 to boot from 8.6 than the g3biege. Years ago I edited the Systems suitcase to support 9..2.1/2 on Old World mac's I think I had a thread over at macfixit that explained what all I changed, I changed more the the patcher utilities do, as they were unstable on my PM8600, but my edits were more stable than OS 9.1 was on the same Machine.

If I can dig up the thread, I maybe able to help with the bus error.

EDIT: Seems macfixit sold out to CNet, and I had to set the wayback machine to 2009 just to reach their forum archives, but they didn't appear to have the old archives, from around 2002, so my Google assisted memory won't be of much use.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 5:34 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 1793
Programmingkid wrote:
adespoton wrote:
ProgrammingKid wrote:
The floating point unit in QEMU is slow, but I think it might be fast enough handle sound playback.


A number of months ago, when we were looking at the USB sound, we discovered that the FPU was the culprit in causing the delays to the sound buffer. I still think that the floating point unit is the culprit here (and in a number of other performance areas) and the tinycode is going to band-aid it, but not really fix the issue.

I'm not sure we can say the FPU is the problem. It was more of a theory rather than a proven fact.

adespoton wrote:
Has anyone started looking at implementing a new streamlined FPU module? It would take me a few years to do it, but if nobody else is, I might start.

I have. I tried making it so that floating point math was handled by the host floating point unit. Things did not work out. Just changing the optimization level of GCC was enough to make the code break. I could show you my patch if you want.

How would you go about making QEMU's floating point unit faster?


My plan was to start off doing a pass-through like you did, then work backwards, abstracting as needed to stabilize each instruction. The biggest part in my mind would be keeping the FPU properly synced without sacrificing performance. Based on the theory we were running with before, it seems that only a few of the FPU instructions were really involved in the slowdown... if we can find some way to cheat at those ones, we should do better.

As a totally blue sky thought... I wonder what would happen if we passed the FPU emulation off to SDL/OpenGL?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 5:36 pm 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
For me,fixing bus error is way too high.What bus,for the beginning?...It needs using debuuger,then coding.It's not my land yet.Though I suppose that it is IDE bus.Why?Booting DP1 from hd in mac99 shows "Still waiting for root device" which is surely related to IDE bus not handled.DP1 and 8.6 are contemporary systems...How do we workaround it in DP1?We don't fix IDE hardware,we just successfully boot DP1 in g3beige.So,for me, hacking around with openbios and MacOS ROM is a more realistic way.
Though it isn't easy,too.First,we often get "No valid state" trying to start OS 8 or 9.I found that adding "PowerMac1,1" and "PowerMac3,1" to "compatible" property for both mac99 and g3beige eliminates the message in many cases (By the way, it also allows booting DP1 w/o additional parameters on command line).But new error messages come:"unable to find /rtas" when loading ROMs <3.6 in both mac99 and g3beige.Loading ROMs >=3.6 in g3beige shows "cannot find interrupt controller node".ROMs >=3.6 in mac99 may work.(Though 3.6 boots successfully only from cd,not hd).
There is a patch about rtas for openbios: https://www.openfirmware.info/pipermail ... 09073.html that allows to go farther.(Interesting,that almost identical patch was proposed by Cormac O'Brian in 2015: https://www.coreboot.org/pipermail/open ... 08687.html).This patch creates /rtas in mac99(Real g3beige had no rtas at all).But it doesn't give much:passing "cannot find /rtas" it stops at "Mac OS :unable to find RTAS" as rtas is not implemented in qemu itself.
I wonder if creating "illegal" rtas for g3beige could give anything...
I wonder why ROMs>=3.6 don't need rtas neither in openbios dev tree nor in qemu?That's why we can boot OS 9 at all.
As for BeBoot file posted by Steven,to go this way also needs whole lotta digging about PEF and Mac genarally... Though some documentation is available here: https://web.archive.org/web/20020208214 ... ch-89.html and in other places.
Here is openbios version with changes I mentioned above(modified "compatible" property,rtas):
https://drive.google.com/open?id=0B69bs ... UVEQ25Vb1k
if someone's curious.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 06, 2017 10:56 pm 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
alex195812 wrote:
For me,fixing bus error is way too high.What bus,for the beginning?...It needs using debuuger,then coding.It's not my land yet.Though I suppose that it is IDE bus.Why?Booting DP1 from hd in mac99 shows "Still waiting for root device" which is surely related to IDE bus not handled.DP1 and 8.6 are contemporary systems...How do we workaround it in DP1?We don't fix IDE hardware,we just successfully boot DP1 in g3beige.So,for me, hacking around with openbios and MacOS ROM is a more realistic way.
Though it isn't easy,too.First,we often get "No valid state" trying to start OS 8 or 9.I found that adding "PowerMac1,1" and "PowerMac3,1" to "compatible" property for both mac99 and g3beige eliminates the message in many cases (By the way, it also allows booting DP1 w/o additional parameters on command line).But new error messages come:"unable to find /rtas" when loading ROMs <3.6 in both mac99 and g3beige.Loading ROMs >=3.6 in g3beige shows "cannot find interrupt controller node".ROMs >=3.6 in mac99 may work.(Though 3.6 boots successfully only from cd,not hd).
There is a patch about rtas for openbios: https://www.openfirmware.info/pipermail ... 09073.html that allows to go farther.(Interesting,that almost identical patch was proposed by Cormac O'Brian in 2015: https://www.coreboot.org/pipermail/open ... 08687.html).This patch creates /rtas in mac99(Real g3beige had no rtas at all).But it doesn't give much:passing "cannot find /rtas" it stops at "Mac OS :unable to find RTAS" as rtas is not implemented in qemu itself.
I wonder if creating "illegal" rtas for g3beige could give anything...
I wonder why ROMs>=3.6 don't need rtas neither in openbios dev tree nor in qemu?That's why we can boot OS 9 at all.
As for BeBoot file posted by Steven,to go this way also needs whole lotta digging about PEF and Mac genarally... Though some documentation is available here: https://web.archive.org/web/20020208214 ... ch-89.html and in other places.
Here is openbios version with changes I mentioned above(modified "compatible" property,rtas):
https://drive.google.com/open?id=0B69bs ... UVEQ25Vb1k
if someone's curious.


I use this to boot past the RTAS node part of Mac OS 8.6's ROM (I'm booting the ROM file directly from a temporary disk image); it then fails at finding the right interrupt controller node:

Code:
-prom-env 'boot-command=
dev /

4097 encode-int " AAPL,debug" property
" PowerMac1,1" encode-string " model" property
" PowerMac1,1" encode-string " MacRISC" encode-string encode+ " Power Macintosh" encode-string encode+ " compatible" property

new-device " rtas" device-name finish-device
dev /rtas
" rtas" encode-string " name" property
0 encode-int " rtas-size" property


boot ide2:2,\MacOSROM.8.6'


I've been using that form of device spoofing to get around boot problems on other OSes, like Rhapsody. If the RTAS can be spoofed that easily, then perhaps you needn't focus on it rather than the interrupt controller stuff (which, I presume, is just looking for a specific form of interrupt controller that the g3beige device tree doesn't have?).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Feb 07, 2017 1:43 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
I may have missed something but I saw no interrupt controller in dev tree for g3beige at all.
There is hw/intc/heathrow_pic.c in qemu source tree.
May it be that pic is simply missing in openbios dev tree for g3beige?That wouldn't affect MOSX work.
If so what should be the values for this device?
Does anybody have a real G3 Mac to see it?

Here are settings for interrupt-controller from Mac-on-linux source from file mol-0.9-72-1/mollib/oftree.nw.old:
Code:
  # **************** NODE interrupt-controller ***************
                #
                {
                    (name interrupt-controller )
                    (full_name /pci/pci-bridge/mac-io/interrupt-controller )
                    (type interrupt-controller )
                    (addrs
                        (0x00000000 0x80800010 0x00000020 )
                    )
                    (property #interrupt-cells   <word>    0x00000001 )
                    (property interrupt-controller <word>
                         )
                    (property compatible         <str>     "heathrow", "mac-risc" )
                    (property reg                <word>
                        0x00000010 0x00000020  )
                    (property device_type        <str>     "interrupt-controller" )
                    (property name               <str>     "interrupt-controller" )
                }

In MOL mac-io is in pci-bridge and hex words are used instead of int values.Hex may be converted to decimal,surely,but I don't know what to do with "reg" property as it has two numbers: 16 and 32.
And generally,would it be sufficient to place (suppose correct) values in dev tree?Wouldn't it need correspondent changes somewhere in qemu files?
Qemu has pci-bridge,too.Isn't it necessary to create pci-bridge in dev tree like in MOL?So many questions...


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Feb 07, 2017 6:23 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 1793
The reg values would be to indicate that the registers can handle 16 and 32 bit values, wouldn't they?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Feb 08, 2017 1:01 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
I don't really know;for mac99 in qemu the reg value is 00040000.

Opening Mac OS ROM from MOS 8.6 for Power Macintosh G3 cdrom in a text editor we can see:
Code:
<CHRP-BOOT>
<COMPATIBLE>
iMac,1 PowerMac1,1 PowerBook1,1
</COMPATIBLE>
<DESCRIPTION>
MacROM for NewWorld.
</DESCRIPTION>
<ICON SIZE=64,64 COLOR-SPACE=3,3,2 >
<BITMAP>
...................................................................
</BITMAP>
</ICON>
<BOOT-SCRIPT>
here &gt;r
dev /
" model" active-package get-package-property abort" can't find MODEL"
decode-string 2swap 2drop " iMac,1" $= ?dup 0= if
 " compatible" active-package get-package-property abort" can't find COMPATIBLE"
 false &gt;r
 begin
  dup while
  decode-string here over 2swap bounds ?do
   i c@ dup [char] A [char] Z between if h# 20 xor then c,
   loop
  2dup " powermac1,1" $= r&gt; or &gt;r
  2dup " powerbook1,1" $= r&gt; or &gt;r
  2drop
  repeat
 2drop r&gt;
  then
r&gt; here - allot
0= abort" this image is not for this platform"
dev /openprom
0 0 " supports-bootinfo" property
device-end
" /chosen" find-package 0= abort" can't find '/chosen'" constant /chosen
" memory" /chosen get-package-property abort" memory??" decode-int constant xmem 2drop
" mmu" /chosen get-package-property abort" mmu??" decode-int constant xmmu 2drop
" AAPL,debug" " /" find-package 0= abort" can't find '/'" get-package-property if
   false
  else
 2drop true
  then
( debug? ) constant debug?
debug? if cr ." checking for RELEASE-LOAD-AREA" then
" release-load-area" $find 0= if 2drop false then ( xt|0 ) constant 'release-load-area
debug? if 'release-load-area if ." , found it" else ." , not found" then then
: do-translate " translate" xmmu $call-method ;
: do-map  " map" xmmu $call-method ;
: do-unmap " unmap" xmmu $call-method ;
: claim-mem  " claim" xmem $call-method ;
: release-mem " release" xmem $call-method ;
: claim-virt " claim" xmmu $call-method ;
: release-virt " release" xmmu $call-method ;
1000 constant pagesz
pagesz 1- constant pagesz-1
-1000 constant pagemask
h# 004000 constant elf-offset
h# 00CDB0 constant elf-size
elf-size pagesz-1 + pagemask and constant elf-pages
h# 010DB0 constant lzss-offset
h# 1CA2E2 constant lzss-size
lzss-size pagesz-1 + pagemask and constant lzss-pages
h# 1DB092 constant info-size
info-size pagesz-1 + pagemask and constant info-pages
0 value load-base-claim
0 value info-base
'release-load-area if
    load-base to info-base
  else
    load-base info-pages 0 ['] claim-mem catch if 3drop 0 then to load-base-claim
    info-pages 1000 claim-virt to info-base
    load-base info-base info-pages 10 do-map
  then
lzss-pages 400000 claim-mem constant rom-phys
lzss-pages 1000 claim-virt constant rom-virt
rom-phys rom-virt lzss-pages 10 do-map
elf-pages 1000 claim-mem constant elf-phys
elf-pages 1000 claim-virt constant elf-virt
elf-phys elf-virt elf-pages 10 do-map
info-base elf-offset + elf-virt elf-size move
debug? if cr ." elf-phys,elf-virt,elf-pages: " elf-phys u. ." , " elf-virt u. ." , " elf-pages u. then
debug? if cr ." copying compressed ROM image" then
rom-virt lzss-pages 0 fill
info-base lzss-offset + rom-virt lzss-size move
'release-load-area 0= if
    info-base info-pages do-unmap
    load-base-claim ?dup if info-pages release-mem then
  then
debug? if cr ." MacOS-ROM phys,virt,size: " rom-phys u. ." , " rom-virt u. ." , " lzss-size u. then
debug? if cr ." finding/creating '/rom/macos' package" then
device-end 0 to my-self
" /rom" find-device
" macos" ['] find-device catch if 2drop new-device " macos" device-name finish-device then
" /rom/macos" find-device
debug? if cr ." creating 'AAPL,toolbox-image,lzss' property" then
rom-virt encode-int lzss-size encode-int encode+ " AAPL,toolbox-image,lzss" property
device-end
debug? if cr ." copying MacOS.elf to load-base" then
'release-load-area if
    load-base elf-pages + 'release-load-area execute
  else
    load-base elf-pages 0 claim-mem
    load-base dup elf-pages 0 do-map
  then
elf-virt load-base elf-size move
elf-virt elf-pages do-unmap
elf-virt elf-pages release-virt
elf-phys elf-pages release-mem
debug? if cr ." init-program" then
init-program
debug? if cr ." .registers" .registers then
debug? if cr ." go" cr then
go
cr ." end of BOOT-SCRIPT"
</BOOT-SCRIPT>
</CHRP-BOOT>

<BITMAP>..............<BITMAP> definetely contains a picture,so I omitted it.
Next follows a binary elf program and after it:
Code:
MacOS: ROM checksum failure!
/chosennvramMacOS: unable to find ihandle to NVRAM in "/chosen", opening "/pci/isa/nvram".
/pci/isa/nvraminstance-to-pathopenMacOS: unable to acquire ihandle for NVRAM node - using 0x1400 offset
sizeMacOS: NVRAM "size" method failure - using 8K.
NVRAM size = 0x%08X.
seekreadNVRAM partition offset=%08X, SIG=%02X, size=%04X, name='%12s'
NVRAM partition invalid (bad checksum).
APL,MacOS75MacOS: NVRAM size too small - using constant NVRAM offset = 0x1400.
MacOS: unable to find a usable NVRAM partition - using offset 0x1400.
writeMacOS NVRAM partition offset = 0x%x
stdout/Unable to get phandle to "/".  Device tree probably corrupt.
AAPL,debugAAPL,debug bit settings (-OR- bits together):
0x%X = Print general informative messages.
0x%X = Print formatted Mac OS tables (except config/universal info.
0x%X = Print formatted config info table (formatted).
0x%X = Dump Mac OS tables (except config/universal info).
0x%X = Print node names while copying the device tree.
0x%X = Print property info while copying the device tree.
0x%X = Print interrupt info.
0x%X = Print interrupt tree traversal info.
0x%X = Print address resolution info.
0x%X = Print NV-RAM info.
0x%X = Print Mac OS "universal" info.
0x%X = Print "special" node info.
0x%X = Allocate writable ROM aperture.
0x%X = Enable debugging output AFTER Open Firmware is gone.

AAPL,writable-ROM-aperturegetproplencopyrightCopyright  Apple Computer, Inc.Official Apple copyright message missing.
mmuMacOS: unable to find ihandle to MMU in "/chosen".
memoryMacOS: unable to find ihandle to Memory in "/chosen".
/rtasMacOS: "/rtas" not found!
rtas-sizeclaimMacOS: unable to claim memory for RTAS instantiation!
MacOS: RTAS -open- method not found or failed
instantiate-rtasMacOS: instantiate-rtas failed.
MacOS: Unable to find RTAS.  Proceed with caution, curves ahead.
MacOS: -claim- for work area failed!
translatework area logical address = 0x%X, physical address = 0x%X.
nvram-fetchMacOS: RTAS nvram-fetch token not found
nvram-storeMacOS: RTAS nvram-store token not found
get-time-of-dayMacOS: RTAS get-time-of-day token not found
set-time-of-dayMacOS: RTAS set-time-of-day token not found
system-rebootMacOS: RTAS system-reboot token not found
power-offMacOS: RTAS power-off token not found
set-time-for-power-onget-time-for-power-onevent-scancheck-exceptionread-pci-configMacOS: RTAS read-pci-config token not found
write-pci-configMacOS: RTAS write-pci-config token not found
AAPL,cpu-id/cpus/@0603-translationcpu-versionMacOS: missing cpu "cpu-version" property.
clock-frequencyMacOS: missing cpu "clock-frequency" property.
bus-frequencyMacOS: missing cpu "bus-frequency" property.
timebase-frequencyMacOS: missing cpu "timebase-frequency" property.
d-cache-sizeMacOS: missing cpu "d-cache-size" property.
i-cache-sizeMacOS: missing cpu "i-cache-size" property.
reservation-granule-sizereservation-granularityMacOS: missing cpu "reservation-granule-size" property.
cache-unifiedd-cache-block-sizeMacOS: missing cpu "d-cache-block-size" property.
i-cache-block-sizeMacOS: missing cpu "i-cache-block-size" property.
d-cache-line-sizei-cache-line-sized-cache-setsMacOS: missing cpu "d-cache-sets" property.
i-cache-setsMacOS: missing cpu "i-cache-sets" property.
tlb-sizeMacOS: missing cpu "tlb-size" property.
tlb-setsMacOS: missing cpu "tlb-sets" property.
MacOS: unable to locate "/cpus/@0"
/memoryregMacOS: unable to locate "/memory" node.
/cpus/@0/l2-cacheMacOS: missing "/cpus/l2-cache" "d-cache-size" property.
MacOS: missing "/cpus/l2-cache" "i-cache-size" property.
MacOS: missing "/cpus/l2-cache" "d-cache-sets" property.
MacOS: missing "/cpus/l2-cache" "i-cache-sets" property.
/rom/macosAAPL,toolbox-image,lzssMacOS: -claim- for toolbox image decompression area failed!
AAPL,toolbox-imageinterrupt-controllerChecking root interrupt-controller - is it Heathrow or Paddington?
/pci/mac-io/interrupt-controllerHeathrow location method better get fixed.
compatibleheathrowpaddingtonFound a Heathrow interrupt controller!
/pci8259-interrupt-acknowledge/pci/isaMacOS:  There are 26 banks of memory.  In copying ROM image, we could lose the last bank!
MacOS: can't find "/rom/macos".
ROM Phys Base Addr = 0x%X
PMR&BGsTreeMacOS: unable to find an interrupt controller node.
MacOS: could not create universal product tables.

Interrupt masks:
  Level         Raw Value  Bits active
    %d [00..31]  %08X         [32..63]  %08X   %d Interrupt vectors:
Spurious interrupt vector = 0x%X
SIOIntVect  = %d
SCSIIntVect = %d
SCCAIntVect = %d
SCCBIntVect = %d
VIAIntVect  = %d
ADBIntVect  = %d
NMIIntVect  = %d

%d bytes needed for device tree copy and other tables.

MacOS: OpenPIC -claim- failed.
mapMacOS: OpenPIC -map- failed.
intctlr_addr = 0x%X, phys = 0x%08X
MacOS: Interrupt Controller -claim- failed.
MacOS: Interrupt Controller -map- failed.
MacOS: MacROM -claim- failed.
MacOS: MacROM -map- failed.

FreeBytes address:       logical = 0x%08X
WorkArea_target address: logical = 0x%08X
SystemInfo addresses:    logical = 0x%08X, physical = 0x%08X
ProcessorInfo addresses: logical = 0x%08X, physical = 0x%08X
HWInfo addresses:        logical = 0x%08X, physical = 0x%08X
VectorTable addresses:   logical = 0x%08X, physical = 0x%08X
InterruptMasks addresses:logical = 0x%08X, physical = 0x%08X
HwInitInfo addresses:    logical = 0x%08X, physical = 0x%08X
Config info addresses:   logical = 0x%08X, physical = 0x%08X
NanoKernelEntry addresses: 0x%08X

System info:
Processor info:
Hardware info:
HardwareInit info:
Stopping at end of FCODE, as requested.
Off to MacOS.  The next (and last) call into OpenFirmware is quiesce().
quiesce @А AФ Aћ B( BД BЄ D` D D< E FT GX EЬ E\ FШ F– Bш C§ Cи E D®
Creating dynamic ProductInfo & Friends
-- Dynamic ProductInfoPtr (logical) = %08X
-- SizeOf( ProductInfo )  = %d
-- Converting UniveralInfoTableBase to 68k logical address %08X.
Initializing ProductInfo record
-- Initializing productInfoVers to %d.
Initializing static section of DecoderInfoPrivate.
Initializing DecoderTable.
-- Initializing (logical) ROMAddr (which is ALWAYS %08X).
-- Clock primitives accessed via RTAS.
-- Initializing OpenPICBaseAddr.
---- OpenPICAddr = %08X.
-- Initializing HeathrowBaseAddr.
---- HeathrowAddr = %08X.
-- Initializing VIA1 address.
ERROR - could not find address of VIA1
---- VIA1Addr = %08X.
-- Initializing SCC addresses.
---- SCC base address = %08X.
---- No SCC (of some sort) detected!
-- Initializing Mesh SCSI information.
---- Mesh SCSI base address = %08X.
-- Initializing ADB information.
---- ADB (of some sort) detected.
---- ADB base address = %08X.
---- No ADB (of some sort) detected!
-- Initializing Power Mgt information.
---- Power Mgt (of some sort) detected.
---- No Power Mgt (of some sort) detected!
-- Checking for IDE.
---- Found some form of IDE.
-- Mac-IO base address = %08X
-- Floppy controller base address = %08X
-- Initializing Sound information.
-- Has Awacs Sound Chip.
---- No Sound (of some sort) detected!

Dynamic ProductInfo Table:
Dynamic DecoderPrivateInfo Table:
Dynamic DecoderInfo Table:
parentgetpropdevice_typepciisaeisa#address-cells#size-cellsgetproplenrangesmatching assigned address:
assigned-addressesregHandleSpecialNode: SCSI device base address = 0x%08X
HandleSpecialNode: SCSI DMA base address    = 0x%08X.
AAPL,not-fastHandleSpecialNode: AAPL,not-fast detected.
AAPL,not-synchronousHandleSpecialNode: AAPL,not-synchronous detected.
HandleSpecialNode: SCC legacy base address = 0x%08X.
slot-namesHandleSpecialNode: ch-a slot-name detected.
HandleSpecialNode: ch-b slot-name detected.
HandleSpecialNode: VIA base address = 0x%08X.
HandleSpecialNode: Cuda detected, VIA base address = 0x%08X.
HandleSpecialNode: Cuda Power Mgt detected.
mgt-kindmin-consumption-pwm-ledHandleSpecialNode: PMU Power Mgt detected.
HandleSpecialNode: PCCardNode detected.
HandleSpecialNode: Cuda ADB detected.
HandleSpecialNode: PMU ADB detected.
HandleSpecialNode: ADB base address = 0x%08X.
AAPL,has-embedded-fn-keysHandleSpecialNode: Embedded function keys detected.
HandleSpecialNode: OpenPIC base address = 0x%08X.
HandleSpecialNode: Heathrow base address = 0x%08X.
HandleSpecialNode 8259.
-- 8259 master = 0x%08X
-- 8259 slave = 0x%08X
-- 8259 sense = 0x%08X.
HandleSpecialNode: Hydra base address = 0x%08X.
HandleSpecialNode: SWIM3 base address = 0x%08X.
HandleSpecialNode: Awacs base address = 0x%08X.
€€'x'И'Ш€€€€€€'®'∞'ј€€€€€€'»'–'а€€€€€€'и'р(€€€€((( €€€€(((0(@€€(H(P(X€€(`(h€€(p(А€€€€€€(Р(Ш€€€€(†(∞€€€€(ј(»€€€€(–€€€€€€(а(и(ш€€)))( €€€€)@)X)h   €€€€€€)x)А)И
€€€€€€)Ш€€€€€€)®€€€€€€)Є)–)а
€€€€€€)ш**
€€€€€€*8*P*X€€€€€€*`*h*p€€€€€€*x€€€€€€*А*Р*Ш€€€€€€*®*Є*ј€€€€€€*–*Ў*а€€€€€€*и*р*ш€€€€€€++€€€€€€escc-legacychrp,es1escc-legacych-achrp,es2serialch-bchrp,es3serialch-achrp,es4serialch-bchrp,es5serialadbchrp,adb0adbadbpmuadbadbadbkeyboardkeyboardviaviavia-cudavia-cudavia-pmuvia-pmuethernetscsichrp,mesh0scsiinterrupt-controllerchrp,iicinterrupt-controllerinterrupt-controllerchrp,open-picopen-picmac-iohydraAAPL,Hydraheathrow-atakeywest-atainterrupt-controllerheathrowinterrupt-controllerinterrupt-controllerpaddingtoninterrupt-controllerprogrammer-switchfdcswim3soundawacssounddavbuspower-mgtcudapower-mgtpower-mgtpmupower-mgtpccardti1130pccardcardbusti1210cardbususbusbOpenPIC setup: vector %d, level %d, sense %d, polarity %d
MacOS: allot fail.
getpropinterrupt-parent#interrupt-cellsparentnamenode '%s' has %d interrupt(s).
MacOS: device has more than 4 interrupts!
AAPL,requested-prioritiesRequested priorities for this node:
getproplen#address-cellsrega unit_interrupt_specifier:
interrupt-controllerinterruptsinterrupt-mapinterrupt-map-maskMacOS: "interrupt-map" larger than expected.
comparing the following specifiers:
MacOS: unit-interrupt-specifier not found in map, ignoring.
new specifier:
device_typeisaMacOS: too many interrupt sources!
AAPL,interrupt-vectorscompatibleAAPL,interrupt-prioritiesAAPL,interruptspeermodelnextproppeer prop '%s' for prop at 0x%X, offset = 0x%X
first prop '%s' for node at 0x%X, offset = 0x%X
new peer '%s' to node at 0x%X, offset = 0x%X.
childnew child '%s' to node at 0x%X, offset = 0x%X.
ROM logical address = 0x%08X, MacROM_Base address = 0x%08X.
ConfigInfo logical address in current ROM image = 0x%08X.
ConfigInfo original ROM logical address = 0x%08X.
configinfop->ROMImageBaseOffset address  = 0x%08X.
configinfop->Mac68KROMOffset address     = 0x%08X.
configinfop->HWInitCodeOffset address    = 0x%08X.
configinfop->DiagPEFBundleOffset address = 0x%08X.
configinfop->KernelCodeOffset address    = 0x%08X.
configinfop->EmulatorCodeOffset address  = 0x%08X.
configinfop->OpcodeTableOffset address   = 0x%08X.
ConfigInfo Mac ROM value in MapInfo = 0x%08X.
MacOS: boot failure - Unexpected value for MacOS ROM entry in segment table.
MacOS: boot failure - Unexpected value for MacOS ROM entry in BAT (overlay).
MacOS: boot failure - Unexpected value for MacOS ROM entry in BAT (normal).
MacOS: boot failure - Unexpected value for MacOS Emulator code entry in BAT.
ConfigInfo table:
-- CopySomeStuff:  From:  %08X  To:  %08X  Length:  %d  MaxLength:  %d
-- CopySomeStuff:  Data size (%d) exceeds maximum safe length (%d)
TakeApartFilenameTags:  IP = %08X
TakeApartFilenameTags:  Port = %04X
TakeApartFilenameTags:  Volume = '%s' (len = %d)
TakeApartFilenameTags:  DirID = %08X
TakeApartFilenameTags:  Path = '%s' (len = %d)
Processing BOOTP/DHCP tags:
  %08X:  Tag:  %d.
Tag:  %d.  Len = %d
Processing DHCP_TAG_END
  Processing DHCP_TAG_PAD
  Processing DHCP_TAG_SUBNET_MASK
  Processing DHCP_TAG_DOMAIN_NAMESERVER
  Processing DHCP_TAG_ROUTER_ADDR
  Processing DHCP_TAG_CLIENT_HOSTNAME
  or Processing DHCP_TAG_MACOS_MACHINE_NAME
  Processing DHCP_TAG_EXTENSIONS_PATH
  Processing DHCP_TAG_SERVER_VERS
  Processing DHCP_TAG_SERVER_INFO
  Processing DHCP_TAG_USER_NAME
  -- Served-supplied user name:  '%s'
  Processing DHCP_TAG_PASSWORD
  -- Served-supplied user password:  '%s'
  Processing DHCP_TAG_SSW_SHARED
  Processing DHCP_TAG_SSW_PRIVATE
  Processing DHCP_TAG_VM_FILE
  Processing DHCP_TAG_SSW_SHADOW_SHARED
  Processing DHCP_TAG_SSW_SHADOW_PRIVATE
Processing a tag (%d, length: %d) we do not care about
-- Invalid len byte (%d).  Stopping tag processing.
'Random' AFP port number = %d
Cleartxt PasswrdUsername: '%s' (len = %d)
Password: '%s'
UAM:      '%s' (len = %d)
finddevice/chosenbootp-responsegetproplenbootreply-packetclaim-- Storage for bootreply packet obtained.  Located at %08X, size = %X
getprop-- Storage for '%s' property obtained.  Located at %08X, size = %X
AAPL,LANDiskInfo-- Storage for miscellaneous information obtained.  Located at %08X, size = %X
-- ERROR: storage for '%s' overlaps bootreply packet!
-- ERROR: storage for bootreply packet overlaps '%s' buffer!
-- ERROR: BOOTP reply packet was NOT a DHCP reply packet
The BOOTP reply packet is a DHCP reply packet
No network files located.  LANDiskInfo property not created.

Property Table of Contents:
    Entry:  %08X
Creating '%s' property in the '/chosen' node
setpropAAPL,MacOSMachineNameCould not create '%s' property
AAPL,bootp-client-ip-addressAAPL,bootp-subnet-maskAAPL,bootp-gateway-ip-addressAAPL,bootp-domain-nameserverscall-methodinterpretwrite0123456789abcdef0123456789ABCDEF;Ъ хбШЦАB@Ж†'иd
-2147483648Dumping %d bytes @ 0x%08X
%08X: %08X %08X %08X %08X
%08X: %08X %08X %08X
%08X: %08X %08X
%08X: %08X

The first text part is a script in Forth language,the second are the messages printed on the screen...
As seen from the bootscript it looks for /rom device and next,/rom/macos (hardware Mac OS ROM?).Rather strange for PowerMac1,1 is kinda New World,isn't it?
The screen messages show that interrupt-controller is looked in /pci/mac-io (not /pci/pci-bridge/mac-io where it is in MOL).If we pass int-controller check will we get missing /rom/macos error?


Last edited by alex195812 on Wed Feb 08, 2017 12:08 pm, edited 2 times in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Feb 08, 2017 2:40 am 
Offline
Student Driver

Joined: Sun Jul 31, 2016 2:55 am
Posts: 11
I guess you guys are confusing things again. No "Mac OS ROM" file, from any software revision, can boot Old World machines like the g3beige. Them don't have the necessary code to do it. I though this was clear enough from the last talk.
If you really want a G3 class machine model which can boot the "Mac OS ROM" file included in the 8.6 CD, you need look at the "blue&white" NewWorld G3, which was somewhat emulated by PearPC, and port it to QEMU, that's the only way. The problem is that g3bw doesn't allow you go lower than MacOS 8.6, and is less compatible with things like Rhapsody and BeOS... And you really don't gain anything emulating OS 8.6 instead something newer like OS9.2.

steventroughtonsmith wrote:
BeOS definitely won't work as-is, I looked into it—the MacOS portion of the installer chain-loads a PEF bootloader from its resource fork, I believe. I ripped it out to study it; if you could boot it directly, then you don't need the Mac OS bit at all. https://www.dropbox.com/s/8khd9ycss1w1z35/BEBOOT.zip?dl=0

I believe this only supports PReP machines, not OpenFirmware (OpenBIOS), so you'd need a whole new hardware target in qemu emulating an older kind of PowerMac.


PReP =! OldWorld. PowerMacs never were PReP. And PowerMacs from Nitro (8600) and upwards are all them CHRP-like designs and all them have OpenFirmware, despite it being incomplete and hidden.
With that said... BeOS was tested in 7xxx, 8xxx and 9xxx PCI PowerMacs, and people says BeOS can boot in the G3 Beige, all them OldWorld machines. Is well known BeOS will not work in the G3 Blue&White and upwards, which are NewWorld machines. There are wikis and the Wayback Archive with the BeOS hardware requeriments out there.

alex195812 wrote:
Here are settings for interrupt-controller from Mac-on-linux source from file mol-0.9-72-1/mollib/oftree.nw.old:
Code:
  # **************** NODE interrupt-controller ***************
                #
                {
                    (name interrupt-controller )
                    (full_name /pci/pci-bridge/mac-io/interrupt-controller )
                    (type interrupt-controller )
                    (addrs
                        (0x00000000 0x80800010 0x00000020 )
                    )
                    (property #interrupt-cells   <word>    0x00000001 )
                    (property interrupt-controller <word>
                         )
                    (property compatible         <str>     "heathrow", "mac-risc" )
                    (property reg                <word>
                        0x00000010 0x00000020  )
                    (property device_type        <str>     "interrupt-controller" )
                    (property name               <str>     "interrupt-controller" )
                }



I checked this Device Tree dump and it doesn't look like taken from a G3 beige, but a fixed copy of oftree.nw, which is from a NewWorld machine. The clear proof is that it specifies nodes for USB... And the G3 beige doesn't have any onboard USB ports at all. It also doesn't look consistent with http://web.archive.org/web/20090107140642/http://penguinppc.org/historical/dev-trees-html/beige_g3.html, which is a checked and tested DT dump, although in an odd format.


Last edited by hyoenmadan on Wed Feb 08, 2017 3:49 am, edited 1 time in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Feb 08, 2017 3:25 am 
Offline
Granny Smith

Joined: Mon Aug 29, 2016 3:44 am
Posts: 149
In fact,we use qemu g3beige as "BW" PowerMac1,1 (adding it to "compatible" property or even change "model" to PowerMac1,1,then creating a dummy /rtas to go through) when trying to boot 8.5 or 8.6.The next stand is interrupt-controller which is missing from g3beige dev tree.
And it appears (as shown by @steventroughtonsmith) that DP1/Server/Rhapsody are more compatible just with PowerMac1,1 (we cannot boot DP1/Rhapsody in ordinary mac99 or g3beige without "pretending to be a BW").
And,also,I read that original OS for BW was 8.5.
As for BeOS,I didn't know that it doesn't work on BW.Still,there is a chance.If we manage to boot OS 8.6 in "pretended" BW,BeOS might start from it (as "really" it is g3beige).
That MOL devtree seems to be "universal", both old and new world (Power Macintosh in "compatible" property,heathrow in interrupt-controller "compatible" property,/rom...Though "model" is a NewWorld PowerMac1,1,but it's OK).As for usb,we often use -usb -device usb-mouse with g3beige in qemu for adb mouse emulation is not well with DP1.Yes,it's hacky and not "ideologically clean" but that's how it is currently.
Generally,g3beige and g3bw are rather similar and it seems that g3bw profile could be created basing on g3beige qemu code.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Feb 08, 2017 3:31 pm 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
alex195812 wrote:
In fact,we use qemu g3beige as "BW" PowerMac1,1 (adding it to "compatible" property or even change "model" to PowerMac1,1,then creating a dummy /rtas to go through) when trying to boot 8.5 or 8.6.The next stand is interrupt-controller which is missing from g3beige dev tree.
And it appears (as shown by @steventroughtonsmith) that DP1/Server/Rhapsody are more compatible just with PowerMac1,1 (we cannot boot DP1/Rhapsody in ordinary mac99 or g3beige without "pretending to be a BW").


Just to clarify — the reason my boot scripts sometimes spoof PowerMac1,1 isn't anything to do with the OS itself, but the Forth/OF boot script that runs before BootX to decide whether your machine is compatible with the OS or not. It's not a hard check for anything, it just checks the model number. You can patch the ISO if you prefer, but spoofing is easy. Oldworld g3beige is significantly different from an actual New World Yosemite-class PowerMac1,1.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 66 of 75 [ 1865 posts ]    Go to page Previous  1 ... 63, 64, 65, 66, 67, 68, 69 ... 75  Next


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
 

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group