I end up with this screen:Amiganaut wrote:What happens if you do a clean install rather than upgrade? I clean installed all mine without a hitch, but I'm using the OS X build.
I tried the same combos as above.
Moderators: Cat_7, Ronald P. Regensburg
I end up with this screen:Amiganaut wrote:What happens if you do a clean install rather than upgrade? I clean installed all mine without a hitch, but I'm using the OS X build.
The cocoa interface also has this mouse problem with rc5. The parameter that controls the refresh rate is located in hw/misc/macio/cuda.c. It is called CUDA_ADB_POLL_FREQ.kataetheweirdo wrote:I can confirm a regression in the mouse control between QEMU 2.7.0 rc5 (built by Stefan) and QEMU 2.8-devel (built by Cat7). The mouse is harder to control in fullscreen, particularly when the user is trying to click and drag on an anything, including a window for the OS.
In this case, I am using Mac OS 9.2.2 with 64-bit Windows builds of QEMU. I am using an old laptop (>5 years old) with 64-bit Windows 10.
Trying to resize a windows in QEMU 2.8-devel is very difficult. Normally, in Mac OS 9.2.2, you can resize a Finder window by dragging its bottom-left corner. However, doing so in QEMU 2.8-devel jerks the mouse all over the screen (possibly because of CUDA or the PMU). The mouse seems to have this tendency of trying to move to the corners. I'll definitely have to get a QEMU environment set up to test this out.
By contrast, QEMU 2.7.0 rc5 allows me to set the size windows by dragging along the bottom-left corner of a windows.
Setting the mouse speed with the mouse control panel does not affect this either.
In neither build does the mouse work correctly when windowed in either GTK or SDL.
I suspect this could also do with the refresh rate in QEMU, although I don't see any parameters that allow me to set this.
Hmm. That's the same error I was getting after installation when I started with QEMU.sidoh wrote:I end up with this screen:
Hmm, this problem still happens with both the 10.2 and 10.3 WWDC builds:Cat_7 wrote:The problems with the windows builds seem to be solved when you set the compatibility of the qemu executables to Windows7. I can now partition and install reliably.
Please give it a try and report back.
Best,
Cat_7
Heh, I'm trying something to see if it works. If it still doesn't, I'll post the command line here.Cat_7 wrote:No way of helping without the command line
Best,
Cat_7
Code: Select all
qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk
Code: Select all
qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot c -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=macosx1037a179.raw,format=raw,media=disk
Code: Select all
qemu-img create -f raw macosx1037a179.raw 4G
OK, I'll try that. BTW, my only Mac is an iBook G4 which only supports 10.3.5-10.5.8. That's why I'm using the Windows build in the first place.Amiganaut wrote:That's much the same as mine, except I used 1G ram and the openbios-qemu-wip bios. Maybe try that and see?
I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.
There can be a problem when you mix those qemu and bios builds. Try with openbios-qemu-wip.elf file for bios and use the mac99p model.qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk
Set the qemu program compatibility to windows7 and your disk problems should be solved.I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.
From the thread:Cat_7 wrote:Ben Herrenschmidt will get his builds included in the qemu source as a submodule. And now you know why. If I recall correctly from the discussion on the board, he currently builds the vga driver in Mac OS, not OSX But that might change, seeing this:Then I looked at the IDE file... CodeWarrior 5 !?!? I guess I could try and dig out my copy of CodeWarrior, but that's an XML file, and I don't recall my copy of CodeWarrior 10 using XML -- which means this must be something more recent.
http://lists.nongnu.org/archive/html/qe ... 00024.html
Best,
Cat_7
Has anyone told him about this?In fact I don't think Apple XCode can either, which leaves us with CodeWarrior (commercial) or MPW (which I think at some point became free but I didn't find it and it doesn't work on OS X afaik).
Nope, I still get the same problem here (see the above image). Also, with Mac OS X Developer Preview 4 and 10.1 Build 5F24, I can't boot up from the install disk. It looks like some problem with the disk drivers:Cat_7 wrote:There can be a problem when you mix those qemu and bios builds. Try with openbios-qemu-wip.elf file for bios and use the mac99p model.qemu-system-ppc-wip -bios openbios-ppc-rtas -L pc-bios -boot d -m 256 -M mac99 -prom-env "auto-boot?=false" -g 1024x768x32 -cpu G3 -drive file=Disc1p.iso,format=raw,media=cdrom -drive file=macosx1037a179.raw,format=raw,media=disk
Set the qemu program compatibility to windows7 and your disk problems should be solved.I did find the Windows version a lot buggier. Especially with disk handling. Which is why I stick with the OS X build.
Best,
Cat_7
68k version only it seems. This needs to be updated for PowerPC.CharlesS wrote:Has anyone told him about this?
https://github.com/ksherlock/mpw
That's how it looks, but generally ends being annoying complex and a hell to maintain. For example, I remember ReactOS used to have in-home crafted tools for all their development, except compilers, taken from MinGW. But soon maintenance for these tools became an annoying hell. They ditched their homemade build system and linker patches for CMake, and gave on trying to construct their own debugging system. Almost all them even gave on fixing GDB to cooperate with their NT kernel. Nowadays almost all them use Visual Studio CL compiler + Cmake as development toolbox, and WinDBG for their debugging capabilities .adespoton wrote:That said, the format doesn't look too complex; we could probably compile the code to objects and write a linker in Python.
Code: Select all
qemu-system-ppc-wip -L pc-bios -bios openbios-qemu-wip.elf -boot c -M mac99 -m 256 -drive file=testimg.img,if=ide,media=disk,format=raw,index=0,copy-on-read=off,werror=report,rerror=report
Code: Select all
qemu-system-ppc-wip -L pc-bios -bios openbios-qemu-wip.elf -boot c -M mac99 -cpu G3 -m 256 -drive file=testimg.img,if=ide,media=disk,format=raw,index=0,copy-on-read=off,werror=ignore,rerror=report,cache=writethrough -usb -device usb-mouse -sdl
I know that's an overly simplistic question, but isn't it possible to develop some sort of wrapper for ROM images that could be used in conjunction with QEMU? So in a sense, the user is responsible for providing the ROM images of whatever computers they want and the data is just fed into the emulator somehow. This would allow not only Macintosh but a myriad systems to be emulated. So instead of wrapping the whole emulator, just wrap the ROM and feed the emulator.hyoenmadan wrote: Isn't about us here, being copyrightnazis or such. Is about QEMU and Apple. QEMU isn't like the other emulators or MAME/MESS. They actually have strict rules about their emulated hardware targets requiring copyrighted code to even initialize, let alone boot. Doesn't help a lot that actually QEMU is part of commercial projects and drives actually the core of many commercial VM solutions. Sure, you can fork and do your own work outside moding the code for your needs, but you really don't want to do that in this case, because mac99 and g3beige are still targets in development.
The other side is that Apple actually can be as Nintendo with relation to their copyrighted works if you annoy them enough, or they think you are doing them a sort of damage. Sure, Apple doesn't care about niche emulators and fan communities, but this could change if this sort of resource appears in a widespread product like QEMU, which actually has commercial VM solutions based on it.
I haven't proceeded with your advice yet, but I think you are absolutely right. Many thanks.Amiganaut wrote:It sounds like you've imaged the volume, but not the whole disc, so it's missing the partition map required to make it bootable.
I was unable to find my original Tiger DVD, which was grey, so I've used a copy that I made when I bought it. In order to install classic, I've used the second Panther CD-ROM (grey) that came with my Power Mac G5. I suppose that's OS 9.2.1. So I imagine Software Update will offer me 9.2.2 soon enough.Amiganaut wrote:Yeah the first reboot can be slow. Are you using a retail or "grey" disc? IIRC, grey discs should have a Classic installer on them.
Best,It works as advertised, but only when there are two systems on the same partition. It does not when you have two partitions with separate installations of OSX/MacOS. Furthermore, the restart option inside the OSX preferences panel doesn’t work. Only restart for the main menu works. After selecting another boot disk on the Mac OS side, clicking restart leads to a black screen. Shut down and new start of Qemu does change the OS to be booted.
Many thanks for that and for the continued support you've been providing for so long. Do you have any insider knowledge as to how far sound is for OS 9/X running on Qemu in El Capitan? Is anyone working on that?Cat_7 wrote:If you are going to install a classic system folder on the OSX partition, you can try this openbios. It allows you to use the startup disk control panel in both Mac OS and OSX.
http://www.open.ou.nl/hsp/downloads3/op ... er.elf.zip