Login  •  Register


The time is now: Sun Nov 17, 2019 1:39 pm

Emaculation wiki  •  Delete all board cookies



Post new topic  Reply to topic Page 1 of 2 [ 39 posts ]    Go to page 1, 2  Next
Print view Previous topic  |  Next topic

SheepShaver:
Brilliance 63%  63%  [ 5 ]
The worst thing since Windows/386 38%  38%  [ 3 ]
Total votes : 8
Author Message
PostPosted: Tue Nov 04, 2014 7:16 am 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 3:14 pm 
Offline
Apple Corer

Joined: Sun Feb 01, 2009 4:55 pm
Posts: 269
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).


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 4:07 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 4:53 pm 
Offline
Expert User
User avatar

Joined: Thu Feb 09, 2006 10:24 pm
Posts: 5616
Location: Amsterdam, Netherlands
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: viewtopic.php?p=35746#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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 5:09 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 6:07 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
Oh good news. :cry:


Code:
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:
$ 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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 6:13 pm 
Offline
Forum All-Star
User avatar

Joined: Fri Nov 27, 2009 5:11 am
Posts: 2719
Location: Emaculation.com
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Tue Nov 04, 2014 9:16 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4696
Location: Sittard, The Netherlands
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.

Quote:
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


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 05, 2014 12:51 am 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.

Quote:
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:
# 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:
# 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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 05, 2014 3:18 am 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 05, 2014 1:02 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 05, 2014 2:28 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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:
$ 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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Wed Nov 05, 2014 3:25 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
Thank you!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 06, 2014 10:00 am 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 06, 2014 5:51 pm 
Offline
Apple Corer
User avatar

Joined: Wed Apr 10, 2013 9:32 am
Posts: 272
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!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 06, 2014 6:13 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 06, 2014 7:57 pm 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4696
Location: Sittard, The Netherlands
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


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Thu Nov 06, 2014 11:13 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 6:36 am 
Offline
Expert User
User avatar

Joined: Fri Feb 13, 2004 8:59 am
Posts: 4696
Location: Sittard, The Netherlands
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


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 9:33 am 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 12:58 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
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!


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 1:25 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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:
ether slirp


to something like

Code:
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 1:46 pm 
Offline
Apple Corer

Joined: Sun Aug 25, 2013 3:25 am
Posts: 289
Location: Hong Kong
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 1:50 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
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.


Top
 Profile  
Reply with quote Post a reply  
PostPosted: Fri Nov 07, 2014 3:02 pm 
Offline
Forum All-Star

Joined: Tue Oct 14, 2008 12:12 am
Posts: 1092
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.


Top
 Profile  
Reply with quote Post a reply  
Display posts from previous:  Sort by  
Post new topic  Reply to topic Page 1 of 2 [ 39 posts ]    Go to page 1, 2  Next


Who is online

Users browsing this forum: Google [Bot] and 19 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