Gripe about sheepshaver...!!!!!!

About SheepShaver, a PPC Mac emulator for Windows, MacOS X, and Linux that can run System 7.5.3 to MacOS 9.0.4.

Moderators: Cat_7, Ronald P. Regensburg, ClockWise

SheepShaver:

Brilliance
5
63%
The worst thing since Windows/386
3
38%
 
Total votes: 8
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Gripe about sheepshaver...!!!!!!

Post by neozeed »

SheepShaver is either the most brilliant bit of coding I've ever seen, or the worst thing on the planet.

Video on segfault?! What the heck!

Not to mention that all the shims on Basilisk II were done via a soft 'fault' where they were illegal instructions that were just passed back by a callback function.

SheepShaver? Heck No!!! It not only needs to hook the general protection fault, but it needs retartable fault handlers to continue execution. None of that callback crap, but crashing is how it works.

Basilisk II let's you set the CPU to a 68020/68030/68040 with or without FPU in the config.

SheepShaver? Heck NO! It's hard coded to a G4 of all things, which you know won't be emulated corectly. Not to mention the 9500 that it's hard coded to pretend to be shipped with a 604e/604ev (can anyone clarify this? I'm sticking with a stock 604 for now).

What about Basilisk and it's ability to run from a virtual address space, so that way the executable can be loaded wherever in memory.

SheepShaver? Heck NO! Not only is it lovingly hard coded to a 1:1 relationship, but it wants to map stuff to 0x0 on OS X, and Win32. ugh.

Basilisk II can build without JIT on clang, and Visual C++.

SheepShaver? HeckNO! It uses incomplete templating "features" so that way CLANG or any other somewhat sane C++ will never let it compile.

Ugh.

And boy is it unstable.

So far the 'best' way to run it seems to be to stick with an old 9500 rom since in it's guts, SheepShaver wants to be a 9500. I only have OS 8.0/8.1/8.6 to test, and 8.6 is the best so far.

I substituted in my SLiRP fixes, so hello from Internet Explorer 5!

I've also hacked the SDL Video to not complain about the pool fault (the video thread touches the SDL surface, which is a no-no on OS X, only the main thread can do that). I need to re-work the ethernet code, but it's gone C++ so I can't just blanket copy in my code. But at least my minor SLiRP fixes, and I can launch IE, so that is nice. Oh and Flash 6 actually works on this, so I can play the kitty cat dance video.

Progress has been slow, but the only way to "fix" SheepShaver would be to pick a new CPU emulation package, and rebiuld from the ground up.

Ok enough ranting.

Image

Here it is running on Yosemite.. I can get it to almost compile but the vauge templates throw off CLANG, or by adding in the CPU objects from 10.6 the linker can't apparently link code that wants to access certain memory locations.... I half way expect some later version of OS X to break running PIE 10.6 exe's for good.. :sad:
don't do today what you can put off until tomorrow.
kataetheweirdo
Master Emulator
Posts: 313
Joined: Sun Feb 01, 2009 4:55 pm

Re: Gripe about sheepshaver...!!!!!!

Post by kataetheweirdo »

About the G4 stuff...

Originally, Sheepshaver did emulate a plain old 604, but it was not complete by any stretch of the mind (it didn't even have FPU instructions). When Gwenole worked on it, he recoded the CPU core and expanded it by giving Altivec support, presumably to increase app support and allow the CPU to be recognized as a G4. Gwenole did note there are some instructions from that extension used in Adobe FrameMaker.

Personally, I think he would have been better off emulating the PMMU, as there aren't many Mac OS Classic apps that require a G4 (or anything with Altivec for that matter) and it currently can't even go to 9.1. That may just be me though.

The original core is still in Sheepshaver, but not used for the CPU core. It's under kpx_cpu. As for reprogramming it, definitely possible, but it would take a few months for it to work. The 9500 ID is there for compatibility reasons, since that supports the range of Mac OS versions wanted (and it was the most capable PPC Mac when development began).
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

I just got the JIT to build on OS X.. I guess you can't fight downtown as they say, and I had to stick with GCC 4.2 as it's very much so tied to that era. Oddly enough the JIT (current from the git page) only works on x64, but I don't think that matters.

I started putting in more of my Basilisk II changes, and my SLiRP works, although the pcap crashes in strange and interesting ways.

Of course I'm running this on 10.6.2 inside of VMWare Player on Windows 7, because why not?

My real mac is on 10.10, and there is no way that CLANG is going to build this CPU/Memory model, JIT or otherwise.

I stumbled onto this while looking up a bug...

https://gitorious.org/qemu-m68k

This looks very interesting! Maybe with minimal patching of a Quadra 800's ROM to bypass things like speed/memory tests, and a more acceptable fake video card it may work one day...

I'm very unfamiliar with the Mac Hardware, as I never was that much into the 68000/PowerPC stuff until it was pretty much all OS X. Are the 68030 and 68040's similar to the Mac II? Is there that big a difference between them? And of course, what about the NuBUS PowerPC stuff? It may be more 'sane' to try to pick a single model instead of trying to do every thing at once..

Also I've found the 9500's ROM the best so far, the new world stuff seems to be the worst (IMHO).. I know it's kind of pointless but it is kind of nice booting from SCSI.

Oh and I found a good partial fix to the __NSAutoreleaseNoPool errors in the current builds. Basically in OS X/SDL only the main thread should be touching the screen. So I stubbed out the "video_refresh_window_static" function, and found a good spot inside of the CPU... kpx_cpu/src/cpu/ppc/ppc-cpu.cpp (the goto return_site: seems to be the common path for JIT, and interpreted to finish their blocks) to call the video refresh function, as it's part of the main function. I only get NoPool errors when I'm crashing out for some other reason, but it sure beats billions and billions of events!

I'm surprised, but Quake 1 is quite playable this way.
don't do today what you can put off until tomorrow.
User avatar
Ronald P. Regensburg
Expert User
Posts: 7821
Joined: Thu Feb 09, 2006 10:24 pm
Location: Amsterdam, Netherlands

Re: Gripe about sheepshaver...!!!!!!

Post by Ronald P. Regensburg »

About the __NSAutoreleaseNoPool errors, see also this report by Jean-Pierre Chombier: https://bugzilla.libsdl.org/show_bug.cgi?id=870

It is also mentioned in this old thread that may contain some observations that are still of interest: http://www.emaculation.com/forum/viewto ... 746#p35746

BTW: In my experience (in OSX) SheepShaver works best for MacOS 8.5 through 9.0.4 with the new world rom that can be extracted from the “Mac OS ROM Update 1.0” using TomeViewer. It can also be downloaded from the Redundant Robot site.
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

A while back I was writing something with SDL and going all thread crazy, and it was working fine on Linux and Windows, but when I built an OS X version is when I first saw this pool issue... Basilisk is a surprisingly more sane code base, and in the same way the main thread processes events, while the CPU execution is in a subordinate thread. I suspect the fault/exception model that Sheep needs kind of prevents this, although I suppose it may not be a major retooling to find out.

In the interim, it's much easier to prevent the video thread from actually touching the buffer, and burying the video call inside of the CPU.

So far I'm liking 8.1 / Quadra 800 for Basilisk II, and 8.6 PowerMac 9500 v1 for SheepShaver. I actually had Internet Explorer 5.1 run out of memory. Which is nice, considering it's usually crashing out like crazy.

For new world, I've been trying to match what ROM I can find on the CD, which sees to kind of work OK, but SCSI is more of a miss than a hit that way. Since I know so many people were excited about SCSI. I have it where I'll pass the ID through to a device, but I'm kind of scared as I've already destroyed 2 VM's now with source with me being dumb and off by one. I think I'll have to force a read to look for a MBR or GPT, and bail if it's trying to talk to a PC disk... or anything 'modern' that you shouldn't be feeding a PowerMac/Quadra.

That reminds me, is there a good 'winamp' like thing for the PowerMac's? I want to leave this overnight pulling network traffic...
don't do today what you can put off until tomorrow.
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

Oh good news. :cry:

Code: Select all

2014-11-05 2:01:26.000 AM kernel[0]: Cannot enforce a hard page-zero for SheepShaver
Apple's kernel (xnu) from OS X 10.10 now enforces a 'hard page-zero' where in past this was not the case. Note this requirement is only for 64 bit MachO executables.

The issue would be resolved for your application by ensuring there is a __PAGEZERO segment. Importantly, this __PAGEZERO segment must have a vmaddr of 0x0 (NULL) and a vmsize of at least 0x1000. The specific name '__PAGEZERO' for the segment is not actually required, but most compilers will use it in this manner.


Code: Select all

$ otool -lV SheepShaver
SheepShaver:
Load command 0
      cmd LC_SEGMENT_64
  cmdsize 72
  segname __PAGEZERO
   vmaddr 0x0000000000000000
   vmsize 0x0000000000003000
  fileoff 0
 filesize 0
  maxprot rwx
 initprot rwx
   nsects 0
which is already there. ugh. JIT didn't work for me as a 32bit binary, but as a 64bit, so I guess that's end of the road.
don't do today what you can put off until tomorrow.
User avatar
adespoton
Forum All-Star
Posts: 4227
Joined: Fri Nov 27, 2009 5:11 am
Location: Emaculation.com
Contact:

Re: Gripe about sheepshaver...!!!!!!

Post by adespoton »

I've found these to be the best combos:
7.5.5/IIcx for 24-bit BII
8.1/Q800 for 32-bit BII
8.6/PM9500v1 for old world SS
9.0.4/Update1.0 ROM for new world SS

For an equivalent to WinAmp on BII, you'd want SoundApp -- it could play just about any audio file back in the day -- although it didn't play MP3 or later. Under SS, you could also try SoundJam MP -- which was later bought by Apple and rebranded iTunes.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Gripe about sheepshaver...!!!!!!

Post by Cat_7 »

Some time ago on macemu Github there was a suggestion regarding dyngen generated with a earlier version of the compiler (GCC pre 4.6) and keeping those in the source for various hosts.
check-in generated source files produced with dyngen that was ran on code produced by a working GCC. This way, compilers that are not supported by dyngen would use the pre-generated files instead of generating them themselves. We would need to check-in these files to source control for different architectures and modify the build system to use them appropriately. The nice thing about this approach is it would work with other compilers, such as clang.


https://github.com/cebix/macemu/issues/21

So the 0x0 memory address issue is now the same as in Linux? There was a person asking in this forum (and I checked) whether SheepShaver did not run on Yosemite in 64 bit anymore.
You mention a fix, but I don't understand what you said about it. You mean the fix is already there but doesn't work as intended? Otherwise it should also go into the current source in github.

FWIW: I believe also iTunes 2 can pull radio station data.

Best,
Cat_7
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

Cat_7 wrote:Some time ago on macemu Github there was a suggestion regarding dyngen generated with a earlier version of the compiler (GCC pre 4.6) and keeping those in the source for various hosts.
check-in generated source files produced with dyngen that was ran on code produced by a working GCC. This way, compilers that are not supported by dyngen would use the pre-generated files instead of generating them themselves. We would need to check-in these files to source control for different architectures and modify the build system to use them appropriately. The nice thing about this approach is it would work with other compilers, such as clang.


https://github.com/cebix/macemu/issues/21

So the 0x0 memory address issue is now the same as in Linux? There was a person asking in this forum (and I checked) whether SheepShaver did not run on Yosemite in 64 bit anymore.
You mention a fix, but I don't understand what you said about it. You mean the fix is already there but doesn't work as intended? Otherwise it should also go into the current source in github.

FWIW: I believe also iTunes 2 can pull radio station data.

Best,
Cat_7
From what I can understand there is no fix for 64bit. They have changed the way the OS works.

And we've hit the end of the road for GCC on OS X. I found that gcc-42-5666.3-darwin11.pkg, but it still relies on the system linker, which of course won't link SheepShaver.... whatever you are using to build Sheep for OS X, BACK IT UP NOW...

On this 10.6 VM I have:

GCC 4.0

Code: Select all

# gcc-4.0 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc_40/gcc_40-5493~95/src/configure --disable-checking -enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-arch=apple --with-tune=generic --host=i686-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)
And GCC 4.2

Code: Select all

# gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5646~6/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5646)
Built on 10.6 exe's built with either version of GCC work, for now. Of course, how long will Apple tolerate 32-bit executables? Or even push this fix into the 32bit part of the loader?

On Linux there was a way of setting the memory model so you didn't have to run as root, but since my GCC was too new, I couldn't build with JIT. Something like that would be needed for OS X, but that seems to be way beyond my reach.
don't do today what you can put off until tomorrow.
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

adespoton wrote: For an equivalent to WinAmp on BII, you'd want SoundApp -- it could play just about any audio file back in the day -- although it didn't play MP3 or later. Under SS, you could also try SoundJam MP -- which was later bought by Apple and rebranded iTunes.

I actually found WinAmp for MacOS.. It even plays streams, but shoutcast.com is impossible to browse with IE 5.1 But if you know the IP and port, you can just type it in (say, http://23.95.51.84:9999) and you're in business.

I've started to move the CPU stuff to it's own thread, and instead join MAIN to the SDL event processing, which runs for 2-3 seconds (enough to get a happy mac!) but then SDL is convinced there is no more events, and it's unable to update the video... Very strange.

I don't like having the CPU interrupt itself to paint the screen as there is defiantly lag if you are moving the mouse, or frequent full screen repainting, as I just found that out when my cat moved the mouse while I was just not moving anything like a good user. It seems somewhat worthwhile to prevent all that pool leakage.

I suppose the "next big thing" will be something like WinUAE's new PowerPC emulation where they are using Qemu. Although calling QEMU as a library seems utterly daunting to me, "fixing" the beigeG3 would probably be easier (which is also impossible).
don't do today what you can put off until tomorrow.
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

About that PowerMac 9500 ROM: is that the same as any of the files on Redundant Robot? Is it, for example, the same as the one named Old World 4mb ROM?

Or (without violating forum rules) can anyone suggest a search that might lead to one? Many thanks.
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

emendelson wrote:About that PowerMac 9500 ROM: is that the same as any of the files on Redundant Robot? Is it, for example, the same as the one named Old World 4mb ROM?

Or (without violating forum rules) can anyone suggest a search that might lead to one? Many thanks.
I think I posted the MD5 checksum of that 9500 rom I found I could boot SCSI from.. there are two versions of this ROM that I'm aware of and the 'newer' one doesn't boot.

Code: Select all

$ md5 powermac9500v1.rom 
MD5 (powermac9500v1.rom) = dfebb8fdad4124e02608429d98bf349b
Which I imagine for 99.99% people wouldn't care one way or the other.. And seeing how most of the PowerMac stuff doesn't recognize the SCSI bus it doesn't matter that much.
don't do today what you can put off until tomorrow.
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

Thank you!
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

Image

Ok, so I got it to "work" on OS X..... wel 10.6 in VMWare. I have no idea if this means it will work on your setup.

* If AppleTalk packets get passed early in the boot stage, it will crash.
* If JIT is enabled, it will crash
* Performance is horrible, I'm getting 150k/sec on my LAN, Basilisk II with no JIT blows this thing away.

Honestly I feel kind of hesitant releasing this, but I know it was desired, and I guess it'll help someone somewhere being able to have an easier conversation... So I'm going to upload my source tree, including binaries built with GCC 4.0 & 4.2 with either O2 or Os flags. I'm not sure which is more stable/faster...

So here is my source tree. Sorry you still have to deal with the changing password thing, but cancel it, and it'll tell you the password.

Other lessons learned... SheepShaver's segfault model only works when the CPU thread is the main thread. Even though you "can" stuff the CPU into a subordinate thread, it doesn't play nice once it segfaults, it'll just spin waiting for something that clearly isn't going to happen.

In config.h I added in USEGLOBALvideo as a way for main to call the screen update to end the vast majority of pool leakage. I also added SHEEPSHAVER_CURSOR to enable the hardware cursor. I was having some issues installing OS 8.x when the 'hand' was drumming the fingers waiting for the OS to install it crashed many times, while disabling the hardware cursor made it play nicer. Maybe it's my setup, I'm not sure.

Also in this version I don't read .sheepshaver_prefs but rather sheepshaver_prefs in the current working directory. I didn't want to trash any other prefs. I have to test again but I *think* this should work on 10.10 ... As I found out the hard way x86_64 binaries can nolonger mess with the zero page, so this is a 32bit only build, but I was running it with my SLiRP fixes ok on my macbook air.

This hasn't been extensively tested. I hate to even call it tested, I just copied a few MB of stuff over an NT server running AppleTalk,a nd viewed some flash video with Internet Explorer 5.1 .... I'm sure there are PLENTY of things broken. JIT should work with these binaries (Quake1 is quite playable), but DOOM crashes hard (isn't it a 68k binary?). DOOM runs ok on Basilisk II so does it matter?

If you want speed, JIT + SLiRP is the way to go. Since this is basically the same as the version I was using with BasiliskII I think it's more stable than the generic version as I could at least run all kinds of programs with some of my fixes vs the 'stock' github version.

I should add that I've been primarly testing with that PowerMac 9500 v1 ROM, along with MacOS 8.6. I found 8.0 and 8.1 too unstable, 7.x & 9.0.4 uninteresting.

To get around the early crashing while booting 8.6, I rigged it to drop the first 30 packets. I've successfully booted 10/10 times, so I'm almost OK with that. I'd rather know when the OS is ok, and go with that, but I'm not sure. I thought about a timer, and say ignore the network for the first 30 seconds, and maybe that is the better way to go. When you launch this you'll see some message updating about packets and "wait for 30->" and a number... once it reads "wait for 30->30" , the message will no longer update, and it'll start to forward packets into the machine. You probably will have to disable and re-enable AppleTalk from the chooser to see the network (or I had to). You may have to get creative to generate the needed packets on your network to get it over 30, as those are packets received. Broadcast packets work too, so maybe you can work with that... As long as Sheep Shaver isn't alone something should be looking for other devices.
don't do today what you can put off until tomorrow.
User avatar
mabam
Master Emulator
Posts: 497
Joined: Wed Apr 10, 2013 9:32 am

Re: Gripe about sheepshaver...!!!!!!

Post by mabam »

Wow, that sounds good!

For my purposes performance is not very important.
I am quite busy now but hope to test it next week.

Many thanks for your work!
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

Could you post a binary? This would be very interesting to test, but my 10.6 VM (used for building SS and BII) is on a machine somewhere else.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Gripe about sheepshaver...!!!!!!

Post by Cat_7 »

Hi,

Binaries are in the source download under the Unix folder.
Please note that this version creates a visible sheepshaver_prefs file in the user home folder
Neozeeds website with link to the source is here:
http://virtuallyfun.superglobalmegacorp.com/

Does Ether pcap need to be run as root? I already have full paths to rom and disk, but SheepShaver gives me the familiar unhappy mac when I run as root.
EDIT: I see SheepShaver creates a prefs file in a different location when ran as root. But it still doesn't allow me to use pcap networking.

Best,
Cat_7
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

It's best to run it from a terminal instead of trying to run the program directly.. .I know I should figure out how that launcher thing works, I just never got around to it.

I'm still in the dark as to why it is so sensitive on boot on my network, but I do remember arp broadcasts from my host machine killing BII as well.. There is a whole lot of magic going on with this stuff.

What does the terminal window report when you try the pcap stuff?
don't do today what you can put off until tomorrow.
User avatar
Cat_7
Expert User
Posts: 6145
Joined: Fri Feb 13, 2004 8:59 am
Location: Sittard, The Netherlands

Re: Gripe about sheepshaver...!!!!!!

Post by Cat_7 »

Ok, I see. It is "ether en0" and not "ether pcap". Runs somewhat now ;-)

hsps-iMac:SheepShaver_neo hsp$ sudo ./SheepShaver-gcc42-O2
SheepShaver V2.4 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
EtherInit with [PCAP]
Pcap version [libpcap version 1.5.3 - Apple version 47]
Ethernet address fe fd 00 00 01 96
Building packet filter.........!
Using filter
(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:01:96)))
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
WARNING: RmvTime(1612f876): Descriptor not found 30->0

But DHCP doesn't work, Appletalk doesn't see other Mac, and IE can't resolve names (but also doesn't connect when using an ip address directly).
I set TCP/IP manually, but that did no good.

Could this be a rom issue?

Best,
Cat_7
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

Cat_7 wrote:Ok, I see. It is "ether en0" and not "ether pcap". Runs somewhat now ;-)

hsps-iMac:SheepShaver_neo hsp$ sudo ./SheepShaver-gcc42-O2
SheepShaver V2.4 by Christian Bauer and Mar"c" Hellwig
Reading ROM file...
EtherInit with [PCAP]
Pcap version [libpcap version 1.5.3 - Apple version 47]
Ethernet address fe fd 00 00 01 96
Building packet filter.........!
Using filter
(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:01:96)))
Detected CPU features: MMX SSE SSE2 SSE3 SSSE3
PowerPC CPU emulator by Gwenole Beauchesne
WARNING: Unknown DiskStatus(6)
WARNING: Unknown DiskStatus(6)
WARNING: RmvTime(1612f876): Descriptor not found 30->0

But DHCP doesn't work, Appletalk doesn't see other Mac, and IE can't resolve names (but also doesn't connect when using an ip address directly).
I set TCP/IP manually, but that did no good.

Could this be a rom issue?

Best,
Cat_7
Hmm 30->30 never happens... so it's not seeing or passing up traffic. I removed the 30 count on my test VM, and enabled jit, and it crashes 2/3 times on boot, but the 1 time in three it works great.. network speeds still kind of suck though. It would be a tad bit easier if I could compile this on 10.10 but I guess I can't have everything.
don't do today what you can put off until tomorrow.
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

I'll be glad to try this, but I simply (and ignorantly) don't know how to set pcap started under OS X.

So far, I've plugged the gcc42-02 build (what do the names mean) into my existing solution, and it gives more reliable IP printing "out of the box" than anything I had before. So this work is definitely going somewhere!
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

emendelson wrote:I'll be glad to try this, but I simply (and ignorantly) don't know how to set pcap started under OS X.

So far, I've plugged the gcc42-02 build (what do the names mean) into my existing solution, and it gives more reliable IP printing "out of the box" than anything I had before. So this work is definitely going somewhere!
Well that is a good sign. You are using my SLiRP fixes, which came from my tweaking of Basilisk II so that is a good thing :mrgreen:

Because I have no good way to test, I'm using all the compilers I have on this 10.6 VM, so it's GCC 4.0 & GCC 4.2 Personally I think Os is faster overall but since I'm testing emulators in emulators, real world may be different. So I built each executable twice, once for O2 (maximum safe optimizations) and Os (optimize for smaller executable). Modern CPU's have giant (well compared to the "good old days" L2 & L3 cache's that programs under 1MB can actually fit in. So something like an emulator should (I haven't done enough testing to rule otherwise) benefit more from a smaller size, then some possibly dangerous optimizations. But in case I'm wrong I'm providing both.

To use the pcap, you have to edit the prefrences file, and change the line

Code: Select all

ether slirp
to something like

Code: Select all

ether en0
or whatever your ethernet interface is. I've had far better results running with JIT turned off. But as always YMMV.

I may just build one without the whole skip 30 packet thing, although from Cat_7's output it shows that it only received one packet, and then went silent. That is the part that has me confused as it works on 10.6.2 in VMware, and this is the same pcap code from my BII stuff, so it's strange why it would magically not work here.
don't do today what you can put off until tomorrow.
neozeed
Apple Corer
Posts: 293
Joined: Sun Aug 25, 2013 3:25 am
Location: Hong Kong

Re: Gripe about sheepshaver...!!!!!!

Post by neozeed »

emendelson wrote: it gives more reliable IP printing "out of the box" than anything I had before. So this work is definitely going somewhere!
I should also add that this is a result of being able to run BII under Visual C++. The debugging facilities in VC are awesome. I don't know how anyone deals with GDB. Or worse how I try to use it, and it's such a painful experience. Sadly though the 68k core built with VC isn't as stable as the one GCC produces, but it made troublshooting SLiRP much easier. Which, unfortuantly with SS is out of the question, as it needs an obsolete GCC centric toolchain.

Oh well. I should be trying to figure out more of this pcap thing, but to be honest sheep has kinda burnt me out... lol I've used GCC more this week than I can think of, and built so many "almost" working things, and destroyed so many virtual disks... Thankfully it's quick to restore these days, especially with Time Machine, now that I have a place to do that.
don't do today what you can put off until tomorrow.
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

Sorry to report that in my solution (an Applescript runs Sheepshaver with 8.6) Sheepshaver simply doesn't start with

ether en0

and either

jit false

or

jit true.

This is under OS X 10.9. I'll be running 10.9 for at least another day or two, but will probably upgrade to 10.10 over the weekend.
emendelson
Forum All-Star
Posts: 1706
Joined: Tue Oct 14, 2008 12:12 am

Re: Gripe about sheepshaver...!!!!!!

Post by emendelson »

Sorry to ask another favor: at some point later on, could you let us know which files are modified with your slirp fixes? I'd like to try building your slirp fixes into my own project which has some keyboard changes and a help menu. Thanks again for this.
Post Reply