We've got you coveredDo you have a link to that SDL Windows version?
http://www.emaculation.com/forum/viewto ... =34&t=9028
Please remember to set program compatibility to windows 7.
Best,
Cat_7
Moderators: Cat_7, Ronald P. Regensburg
We've got you coveredDo you have a link to that SDL Windows version?
Well, if you consider SS has not been developed for some 8 years, that statement is a little bit unfair. Also, one could argue SS is older than that.william341 wrote:The funny thing is that QEMU (which managed to develop this crap in less than a year) is more stable than a 9 year old emu (SheepShaver)
Sweet! Thanks.Cat_7 wrote:We've got you coveredDo you have a link to that SDL Windows version?
http://www.emaculation.com/forum/viewto ... =34&t=9028
Please remember to set program compatibility to windows 7.
Best,
Cat_7
Yeah, I considered making a whole topic on the Sheepshaver forum dedicated to dissecting its source code. However, considering how much time it takes and there doesn't seem to be a lot of popularity for it, I was hesitant. There are some notes scattered around, but I'm sure that's not the whole thing either.sentient06 wrote: Well, if you consider SS has not been developed for some 8 years, that statement is a little bit unfair. Also, one could argue SS is older than that.
I guess SS was always the black sheep emulator, sort of an altered Basilisk nobody really cared to document and introduce steady improvements. Geddit!? SheepShaver! Black sheep!
But seriously now, QEMU was already in a good shape, if we look back. All it needs is some fine-tuning and stuff will progressively get better. SS is less concerned about emulating and more about patching ROM, I believe, and I think that's why it is unstable.
I'd like to add that qemu supporting OS 9 may have looked like an event of the past year, but the original GSOC where all of this really got started was in 2010 -- it just took until this year for enough of the basic parts to be in place for accelerated development to be possible. So that's 6 years to get to something stable and functional.sentient06 wrote:Well, if you consider SS has not been developed for some 8 years, that statement is a little bit unfair. Also, one could argue SS is older than that.william341 wrote:The funny thing is that QEMU (which managed to develop this crap in less than a year) is more stable than a 9 year old emu (SheepShaver)
I guess SS was always the black sheep emulator, sort of an altered Basilisk nobody really cared to document and introduce steady improvements. Geddit!? SheepShaver! Black sheep!
But seriously now, QEMU was already in a good shape, if we look back. All it needs is some fine-tuning and stuff will progressively get better. SS is less concerned about emulating and more about patching ROM, I believe, and I think that's why it is unstable.
So, I’ve tried SheepShaver, Basilisk II, Mini vMac & now Qemu (on Windows). The game always freezes when you get the key out of the Church door. Seems like a bug with the game itself. It's a pretty big problem because they key is an essential item to continue in the game.Cat_7 wrote:We've got you coveredDo you have a link to that SDL Windows version?
http://www.emaculation.com/forum/viewto ... =34&t=9028
Please remember to set program compatibility to windows 7.
Best,
Cat_7
Search this thread for USB audio and you'll find the appropriate flags.william341 wrote:Anyone know how to get audio semi-working?
I hadn't heard of that game, so I googled it. It seems to be a Sierra SCI game, so I wonder if it would work in ScummVM.celebi23 wrote:So, I’ve tried SheepShaver, Basilisk II, Mini vMac & now Qemu (on Windows). The game always freezes when you get the key out of the Church door. Seems like a bug with the game itself. It's a pretty big problem because they key is an essential item to continue in the game.Cat_7 wrote:We've got you coveredDo you have a link to that SDL Windows version?
http://www.emaculation.com/forum/viewto ... =34&t=9028
Please remember to set program compatibility to windows 7.
Best,
Cat_7
Risking going slightly off-topic here, and perhaps touching a subject I think was discussed elsewhere: can some QEMU code, as of today, be recycled as to improve SheepShaver? I was thinking MMU, but perhaps there are other components that could be used. It would be nice.kataetheweirdo wrote: Yeah, I considered making a whole topic on the Sheepshaver forum dedicated to dissecting its source code. However, considering how much time it takes and there doesn't seem to be a lot of popularity for it, I was hesitant. There are some notes scattered around, but I'm sure that's not the whole thing either.
It isn't just ROM patches, but RAM patches as well. I could try to rewrite it, but there's little motivation to do so. Given how scarce documentation on Apple's hardware is (like the sound chips), it's not surprising Sheepshaver doesn't have more development. The documentation is out there, but it took a lot of Google searching to find out some of the more obscure bits of the pre-Intel and G5, but post-Mac II Macintoshes.
It works in ScummVM up to a point. ScummVM works great with the CD/Floppy Windows/DOS versions. It just doesn't work great with the Mac version yet. Going to try it on my old iMac G3 again to see if the issue happens there as well.CharlesS wrote: I hadn't heard of that game, so I googled it. It seems to be a Sierra SCI game, so I wonder if it would work in ScummVM.
If that doesn't work, you could try it in MAME (I posted a patched binary build that can boot 7.5.3 in another thread).
Your idea does sound interesting. Is the maker of Sheepshaver still accepting patches?sentient06 wrote:Risking going slightly off-topic here, and perhaps touching a subject I think was discussed elsewhere: can some QEMU code, as of today, be recycled as to improve SheepShaver? I was thinking MMU, but perhaps there are other components that could be used. It would be nice.kataetheweirdo wrote: Yeah, I considered making a whole topic on the Sheepshaver forum dedicated to dissecting its source code. However, considering how much time it takes and there doesn't seem to be a lot of popularity for it, I was hesitant. There are some notes scattered around, but I'm sure that's not the whole thing either.
It isn't just ROM patches, but RAM patches as well. I could try to rewrite it, but there's little motivation to do so. Given how scarce documentation on Apple's hardware is (like the sound chips), it's not surprising Sheepshaver doesn't have more development. The documentation is out there, but it took a lot of Google searching to find out some of the more obscure bits of the pre-Intel and G5, but post-Mac II Macintoshes.
And I really like the idea of documenting SheepShaver. I remember I read some of the code to guess what kind of settings it is capable of using. I used a template from the Basilisk II docs and changed according to my findings. Still, I suppose there are many other interesting aspects of the program that could be documented.
It would be very cool! Or should I say: it *will* be very cool!gtxaspec wrote:Ultimately, I believe QEMU is a better path of progression, for it is closer to emulating actual Apple PowerPC hardware VS SheepShaver. I do believe though that many people don't understand what the current primary objective of the QEMU project is, an enterprise-grade hypervisor. So we ultimately are at the mercy of the overall project goal in regards to changes and modifications to the way QEMU works and is displayed. We are very grateful that Apple-PPC-Hardware god's like BenH ( Who did lots of early work getting Linux to run on old-world Apple PPC hardware via his Linux Kernel tree ) and Mark Cave-Ayland, and others who contribute to QEMU because IBM ( many of the contributors employer ) sponsors development due to their new Power.org PAPR initiative, have been involved and supportive of making MacOS bootable within QEMU. There has been tremendous work done recently in regards to PPC in QEMU. I think if some other folks experienced in classic MacOS realize that QEMU is booting classic MacOS, some more patches and work will get in. Great progress so far, the QEMU maintainers and everyone who has contributed so far, very much appreciated to everyone's hard work.
Also, wouldn't it be cool to boot m68k MacOS on qemu?
The "official repo" is still here: https://github.com/cebix/macemusentient06 wrote:SheepShaver is more relaxed in a sense; people fork it, experiment with it, change it because there is no "official repo" (afaik) or anything of the sort.
Its possible to point the "Unix folder" to the DVD (image).Changing subjects: have anyone tested the disks from "Mac OS Anthology" in QEMU? If I recall correctly, SheepShaver can't recognise DVDs.
About the wikipage: you mention model type "beigeg3". That should be "g3beige". And the screen shot showing the monitors panel could only have been made using a build from benh's fork. So it is misleading as to what users can expect from a build form the official source.I updated the QEMU PowerPC wiki page here: http://wiki.qemu.org/Documentation/Platforms/PowerPC
Let me know what you think. If something should be added or changed, I will do it.
You are right. Thank you for letting me know.Cat_7 wrote:Yes,
But probably not to run Mac OS. It would need the rom.
About the wikipage: you mention model type "beigeg3". That should be "g3beige". And the screen shot showing the monitors panel could only have been made using a build from benh's fork. So it is misleading as to what users can expect from a build form the official source.I updated the QEMU PowerPC wiki page here: http://wiki.qemu.org/Documentation/Platforms/PowerPC
Let me know what you think. If something should be added or changed, I will do it.
Best,
Cat_7
I found this table of memory addresses and what they are used for. It might be of use to you.alex195812 wrote:Isn't it that?:
A new virtual device "loader" in qemu 2.8.0-rc2.As documrnted at http://git.qemu-project.org/?p=qemu.git ... xt;hb=HEAD it lets loading data and/or images(ELF or raw images) into memory.Images may be loaded via option "-device loader,file=<file name>,addr=<addr>,cpu-num=<cpu-num>".I have successfully loaded Ben's WIP openbios this way,but no luck with Old or New World ROMS.While ELF images need no "addr" parameter,raw images require "addr" assigned.As I don't know where Mac ROMS should be loaded at,I tried 0x0000 and 0x8000 with no luck.Does anybody know where to try?