Login  •  Register


The time is now: Sat Dec 16, 2017 2:58 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 67 of 77 [ 1903 posts ]    Go to page Previous  1 ... 64, 65, 66, 67, 68, 69, 70 ... 77  Next
Print view Previous topic  |  Next topic
Author Message
PostPosted: Wed Feb 08, 2017 7:54 pm 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 115
I tried to patch OS 8.6 to run on the mac99, but I just ended up with either "Unemployment Trap" or other errors.

At this point what may be needed is to use the real Beige G3 Old World Rom, in Qemu. I was told, on the qemu-ppc mailing list, there was an effort to do this, but I've been unable to find any info on it, so I don't know how far it got.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 1:05 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
Afaik,the Old World boot method is still unimplemented in g3beige.It requires one more device: /rom where OldWorld Mac OS ROM lives (in /rom/macos).It then could be started by "boot /rom/macos" command.
So far we've booted qemu g3beige a NewWold way (directly from openbios).
It seems that it isn't exhausted yet. Typing
Code:
-prom-env 'boot-command=dev / " 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'

on qemu command line when starting OS 8.6 in g3beige we get
"MacOS: unable to find an interrupt controller node".
Normally,interrupt controller should be in /pci/mac-io.For mac99 it exists there and has some properties.But in g3beige dev tree it is missing.Which is not normal.
Anyway,it would be fine to find correct values for interrupt-controller in g3beige and push them in.Hopefully it could also move the 8.6 boot process on.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 1:41 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
steventroughtonsmith wrote:
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.

Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.
It shows that BW and mac99 are really significantly different.
If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.
I read that G3B is 1 of 2 Old World machines capable of booting MOSX(offically up to 10.2,with processor upgraded to G4 up to 10.5,just like BW).It makes it very similar to New World machines besides the boot method.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 3:18 am 
Offline
Student Driver

Joined: Sun Jul 31, 2016 2:55 am
Posts: 11
alex195812 wrote:
Normally,interrupt controller should be in /pci/mac-io.For mac99 it exists there and has some properties.But in g3beige dev tree it is missing.Which is not normal.


From this commit to Linux Kernel PROM parser:
https://ford.biologie.hu-berlin.de/matz ... 0721d8b8d9

They say OldWorld MacOS machines don't have and use Interrupt Controller nodes in the DT. Linux determines this special case with extra codepath in real hardware as is seen in this commit.

alex195812 wrote:
If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.


OldWorld boot method doesn't use the "Mac OS ROM" file at all. That's only for NewWorld Macs which don't have any Toolbox code in EEPROM at all. So no OF boot script runs in this case (not at least from the OS CD).
OldWorld boot method loads both OF and Toolbox from EEPROM, and it searches for the System File once ROM is running (it also can try to read from a driver partition before if the boot media doesn't have built in driver access support).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 3:30 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
Oh,I didn;t know that about OW Macs.
Anyway,trying to use g3beige "as if" New World BW this node is needed.The values from mac99 won't do as it has openpic,not heathrow.
In that quote it was about OF script,not CD.And about DP1/Rhapsody,not Mac OS.
Though MacOS ROM on cd includes a Forth boot-script,too.
And yes,real OW Mac's do boot the way you described,but our qemu-emulated g3beige doesn't.It does boot cd:,\\:tbxi ,that is,loads Mac OS ROM from cd.

Now when I add
Code:
-prom-env 'boot-command=dev / " 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 dev /pci/mac-io new-device " interrupt-controller" device-name finish-device dev /pci/mac-io/interrupt-controller " interrupt-controller" encode-string " name" property " heathrow" encode-string " device-type" property " heathrow" encode-string " mac-risc" encode-string encode+ " compatible" property 1 encode-int " #interrupt-cells" property 0 encode-int " #address-cells" property 16 encode-int 32 encode-int encode+ " reg" property'
to qemu command-line I can see interrupt-controller in /pci/mac-io but still have
"MacOS: Boot Failure! (0xF3C481F6)
MacOS: unable to find an interrupt controller node".


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 8:44 am 
Offline
Student Driver

Joined: Fri Jan 06, 2017 10:02 pm
Posts: 19
alex195812 wrote:
steventroughtonsmith wrote:
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.

Is it that different?If you use the same spoofing with mac99 will you boot DP1 or Rhapsody?No.
It shows that BW and mac99 are really significantly different.
If the boot-script wants PowerMac1,1, doesn't it mean that the OS is targetting BW,not G3B?And still it boots.It means that BW and G3B are compatible.
I read that G3B is 1 of 2 Old World machines capable of booting MOSX(offically up to 10.2,with processor upgraded to G4 up to 10.5,just like BW).It makes it very similar to New World machines besides the boot method.


Yes g3beige and PowerMac1,1 are that different. The g3beige is a Gossamer—mach in Rhapsody DR2 onwards supports Gossamer class machines, that's why it works. However that's different from the CHRP boot script check before BootX—this is merely a gatekeeper, and doesn't necessarily have any relation to whether the OS kernel will actually work or is compatible. When you're spoofing PowerMac1,1 (Yosemite) you're not really fooling mach, just the tiny script that OpenBIOS is using to check if it should boot the disc or not. mac99 is a PowerMac3,1, a Sawtooth. Again, different enough that it has its own hardware target.

I have both a Gossamer and Yosemite; the Gossamer is a SCSI-based legacy I/O machine, Yosemite is New World/ATA/USB, etc (it's been a loong time, but I /think/ the lowest end G4 (PCI) was on a modified Yosemite config). No variant of Gossamer booted Mac OS 8.6 from OpenFirmware, nor any variant of Sawtooth/mac99, so it's perhaps unsurprising that it doesn't quite like the device tree as-is.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 9:00 am 
Offline
Student Driver

Joined: Fri Jan 08, 2016 12:27 pm
Posts: 10
As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.

Image
Image
Image

This is using QEMU 2.8 master branch compiled from source, running Mac OS 9.2.2 with 256MB of RAM. As you can see, the colours are all black & white and rather distorted. Switching this to greys in Monitors panel improves a few things but the greys are actually inverted! I'm using 8-bit depth for the monitor, as using 16-bit causes the system to never make it past OpenFirmware, hanging just after the NVram offset warning message.

The system overall is very slow, menus visibly build themselves, the mouse doesn't track correctly and I haven't got sound up and running yet. But it works! There are also a couple of errors in the terminal regarding NVram starting position and I/O running over 1000 cycles too.

Command line used:

Code:
qemu-system-ppc -boot c -m 256 -M mac99 -prom-env auto-boot?=true -prom-env boot-args=-v -g 640x480x8 -cpu G3 -usb -usbdevice mouse -drive file=/mnt/HDD/MacOS9.2.2.img,format=raw,media=disk


The Mac OS was installed on my main PC with QEMU 2.7, and simply moving the hard drive image over once installed worked wonders.

Edit: I switched the bit depth to 32 and we have colour!

Image


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 9:50 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 115
Budgiebrain994 wrote:
As an aside, I decided to try to get this up and running on my Raspberry Pi. Interesting results occurred.

Image
Image
Image

This is using QEMU 2.8 master branch compiled from source, running Mac OS 9.2.2 with 256MB of RAM. As you can see, the colours are all black & white and rather distorted. Switching this to greys in Monitors panel improves a few things but the greys are actually inverted! I'm using 8-bit depth for the monitor, as using 16-bit causes the system to never make it past OpenFirmware, hanging just after the NVram offset warning message.

The system overall is very slow, menus visibly build themselves, the mouse doesn't track correctly and I haven't got sound up and running yet. But it works! There are also a couple of errors in the terminal regarding NVram starting position and I/O running over 1000 cycles too.

Command line used:

Code:
qemu-system-ppc -boot c -m 256 -M mac99 -prom-env auto-boot?=true -prom-env boot-args=-v -g 640x480x8 -cpu G3 -usb -usbdevice mouse -drive file=/mnt/HDD/MacOS9.2.2.img,format=raw,media=disk


The Mac OS was installed on my main PC with QEMU 2.7, and simply moving the hard drive image over once installed worked wonders.

Edit: I switched the bit depth to 32 and we have colour!

Image

Benchmarks, or it didn't happen :mrgreen:


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 10:04 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
steventroughtonsmith wrote:
I have both a Gossamer and Yosemite; the Gossamer is a SCSI-based legacy I/O machine, Yosemite is New World/ATA/USB, etc (it's been a loong time, but I /think/ the lowest end G4 (PCI) was on a modified Yosemite config). No variant of Gossamer booted Mac OS 8.6 from OpenFirmware, nor any variant of Sawtooth/mac99, so it's perhaps unsurprising that it doesn't quite like the device tree as-is.

Sounds convincing especislly SCSI vs ATA part and you seem quite right about real machines but 1)in both emulated mac99 and g3beige device trees have ata,not scsi buses and those tree parts look the same;2)in my efforts boot process stops not because of those buses but because of not found interrupt-controller node;but as seen from Mac OS ROM,it knows about Heathrow pic(in MOL devtree for PowerMac1,1 its model is heathrow).Maybe I simply assign wrong values for this device or something?Looks like booting shouldn't stop so early...It could at least pass interrupt-controller part.


Last edited by alex195812 on Thu Feb 09, 2017 10:26 am, edited 5 times in total.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 10:10 am 
Offline
Student Driver

Joined: Fri Jan 08, 2016 12:27 pm
Posts: 10
darthnvader wrote:
Benchmarks, or it didn't happen :mrgreen:


Forgive me :P How do I do benchmarks? What would you like me to run? I'd love to show off some super speedy stats :lol:

Edit: Looked up in this thread, found MacBench, now finding a way to get it inside the Mac :arrow: While I'm here, are there any optimizations I can make to my command line for better performance/more options? It looks like I'll need to add the network adapter in as a start


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 10:53 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
It may be like -netdev user,id=net0 -device rtl8139,netdev=net0
Realtek driver must be installed in guest system for this to work.See viewtopic.php?f=34&t=9012


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 4:15 pm 
Offline
Inquisitive Elf

Joined: Sun Jul 31, 2016 11:58 pm
Posts: 29
Why does sungem even exist now? the realtek driver problems regarding mac os 9 have been fixed, so what's the point of the sungem patch? OS X PPC support?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 5:59 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4204
Location: Sittard, The Netherlands
Quote:
Why does sungem even exist now?


The sungem device emulates a built-in network card, hence no need for additional drivers to install as Mac OS and OSX have drivers included. To me that seems a huge benefit ;-)

It would say it is rather the opposite: why use the realtek device when there is the sungem device.
For now, the realtek is not supported in all PPC OSX versions qemu can run.

The only snag is that the sungem code is not yet in the qemu master code and therefore the "unofficial" build/patch is required.

Best,
Cat_7


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Feb 09, 2017 7:05 pm 
Offline
Granny Smith
User avatar

Joined: Thu Jan 05, 2017 6:24 pm
Posts: 108
Hi!

I have a few questions for DP3:

1. What would be the best build?
2. What should I use to format the drive? 10.0? 10.1? 10.2?


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Feb 10, 2017 1:03 am 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
1)If you mean best qemu build,then DP3 can run in August wip builds and the latest,provided by Cat_7(It's about Windows).Don't know which one is better.
2)I think any of them will do (for they all have Disk Utility).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Feb 10, 2017 8:14 am 
Offline
Student Driver

Joined: Fri Jan 08, 2016 12:27 pm
Posts: 10
Cat_7 wrote:
The only snag is that the sungem code is not yet in the qemu master code and therefore the "unofficial" build/patch is required.


Ahh! No wonder I couldn't get it working.

Code:
qemu-system-ppc: -device sungem,netdev=network0: 'sungem' is not a valid device model name


I'll get to building the unofficial patch on the Pi and see how we go. Thanks!

Edit:

Aaand here we go!

Image

Disregard the terminal in this - I'm running QEMU from an SSH terminal on my main PC. As soon as Classilla is downloaded, I'll put on MacBench and deliver some benchmarks.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Feb 10, 2017 2:36 pm 
Offline
Student Driver

Joined: Fri Jan 08, 2016 12:27 pm
Posts: 10
Raspberry Pi benchmark scores are in :)

Image


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Feb 10, 2017 3:22 pm 
Offline
Mac Mechanic

Joined: Mon Aug 29, 2016 3:44 am
Posts: 160
Not fast,but working :smile:.Network is OK,I suppose?Gaming is hardly possible I think.
Is it Rasberry Pi 2?Never played with it,only in qemu fork running RiscOS (a couple years ago).
I suppose it can run on Androids,too...A 4-core ARM would do it fine.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Feb 10, 2017 9:47 pm 
Offline
Student Driver

Joined: Fri Jan 08, 2016 12:27 pm
Posts: 10
Network is anywhere from 0 to 20Kbps, often failing completely. I had to set up an FTP server to get the files in. This is a Raspberry Pi 3B. Gaming is not an option at the moment :wink:
just with the cores, the Pi has 4 but QEMU only uses one as its guest OS doesn't support more, so the performance graph is effectively capped at 25% or so and you only get one core working for Mac OS 9. There was someone earlier in this thread who said he got it running on his phone though.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Feb 11, 2017 1:59 am 
Offline
Apple Corer

Joined: Sun Feb 01, 2009 4:55 pm
Posts: 239
It wasn't just you, QEMU 2.8 does indeed go much slower than in 2.7. I have no idea why, but it's best to find the offending GIT commit that caused the slowdown.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sat Feb 11, 2017 3:18 am 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 225
Budgiebrain994 wrote:
Image


1999 - It takes $1,499 for a computer to run Mac OS 9
2017 - $35 Raspberry Pi 3 does the job.

Be proud people, be proud...


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Feb 12, 2017 2:09 am 
Offline
Granny Smith

Joined: Sun Feb 07, 2016 4:40 pm
Posts: 115
Does anyone know the key command to invoke Macsbugs, once the OS has loaded to the Finder, it use to be Ctrl+Command+I, but that doesn't seem to work for Macsbugs 6.6.3?

EDIT: Ok, I fond a way.

Quote:
Defining an 'FKEY' Resource to Invoke MacsBug 2
Another way to invoke MacsBug is to define an 'FKEY' resource using ResEdit or MPWS().Once you have defined this resource, you can use a Shift-Command-key combination to invoke MacsBug.
To define an 'FKEY' resource using ResEdit 2.1, follow these steps:
1. Launch ResEdit.
2. Open the 'FKEY' resource in the System File.
3. Choose “Create New Resource” from the Resource menu to create a new 'FKEY' resource.
4. Type the following numbers into the new resource exactly as shown:
A9FF 4E75
A9FF is machine code for the _Debugger trap; 4E75 is machine code for the RTS instruction.
Figure 2-6 shows what the resource looks like after you’ve entered the instruction.
Figure 2-6 Defining an 'FKEY' resource to invoke MacsBug
5. Choose Get Resource Info from the Resource menu and set its ID number to a number greater than 4 and less than or equal to 9. Please remember to use a number that is not already in use. The numbers 1, 2, 3, and 4 are reserved for system functions.
6. Close and save the System file.
7. To invoke MacsBug, press Command-Shift and the ID number you have assigned the resource. For example, if you’ve assigned the resource ID 7, press Command-Shift-7 to invoke MacsBug.
This method of invoking MacsBug will only work when the application is calling GetNextEvent or WaitNextEvent regularly, which it might not do if it’s hung or frozen.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Sun Feb 12, 2017 9:28 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 1864
You can also send the interrupt signal from the keyboard. Somewhere on here, the qemu sequence to trigger the interrupt signal is listed (command-option-power?).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Mon Feb 13, 2017 9:31 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4204
Location: Sittard, The Netherlands
I'm not at all sure what you are talking about.

All builds are still up, I only updated the builds from the official source. Those does not include the empty disk and bat file anymore, because that makes it easier for me to maintain stuff. How to create an empty disk and the bat/command files is explained at length in the updated guides for both Windows and OSX.

Give them a try.

Best,
Cat_7


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Feb 14, 2017 4:04 pm 
Offline
Apple Corer

Joined: Sun Jan 31, 2016 6:01 pm
Posts: 225
I have done several tests with the screamer sound card in order to make it play audio better.

I thought a problem with it could be that the buffer might need to be completely emptied by setting all values in it to zero. So I added code to the pmac_screamer_tx_flush() function that would completely zero out the s->buf variable. This did not fix the problem.

I then tried commenting out the call to AUD_write() in pmac_screamer_tx_flush() to see if that would change anything. No change is audio quality was observed.

It then occurred to me that maybe I should inject silence into the audio stream. This is something the ac97.c file does in its write_bup() function. It could end the playback of old audio when playing a new audio file. The problem is knowing when and for how long to do this. This is just another theory. Maybe someone knows a better way to flush the audio stream of old audio?

I'm beginning to think maybe the problem is elsewhere. Maybe the macio controller?


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


Who is online

Users browsing this forum: No registered users and 1 guest


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