So I was playing around with Basilisk II 0.8

[Cat_7]

Some tools are listed at the bottom of this page:
http://www.vintagemacworld.com/mactcpip.html

Best,
Cat_7

[neozeed]

Some tools are listed at the bottom of this page:
http://www.vintagemacworld.com/mactcpip.html

Best,
Cat_7

cool I'll check it out. I added a pcap filter which I think will help things as well.. It turns out my home network is busy with lots of things saying hello to each-other, and I think a default capture pattern that includes all packets (promiscuous mode) may be throwing it off. I'll need to do the same for Shoebill as well.

Something like this:

(((ether dst 09:00:07:ff:ff:ff) or (ether dst ff:ff:ff:ff:ff:ff) or (ether dst fe:fd:00:00:16:48)))

So this way it'll pick up the appletalk broadcast MAC destination, the general broadcast MAC destination and in this example the MAC address that Basilisk is using. It also felt faster too.

I'll push something out tomorrow, probably just source+windows as I promised to look at SLiRP on a PC platform, then back to the grind I guess with CD-ROM and CD-RW support... I hope to emulate RO and maybe (lol) RW. But we all know how picky MAC's are when it comes to this kind of thing.

[adespoton]

There are some really good tools for OpenTransport Macs; I used to use them back in the day. Can't recall anything for pre-OpenTransport.

HOWEVER, you should be able to use WireShark on the host to the same effect; just filter out the junk you don't want to see. It doesn't help you see what the OS thinks is happening, but it does let you see what's actually traversing the "wire".

[neozeed]

There are some really good tools for OpenTransport Macs; I used to use them back in the day. Can't recall anything for pre-OpenTransport.

HOWEVER, you should be able to use WireShark on the host to the same effect; just filter out the junk you don't want to see. It doesn't help you see what the OS thinks is happening, but it does let you see what's actually traversing the "wire".

The problem is that at certain points the network just stops working.. And I don't know if it's an OS 7 or 8 thing, if its still getting passed the packets or what is going on. The lack of logging in MacOS is just insane!

I can download 1-2GB with TCP/IP before the network shuts down.. .upload 25MB. Appletalk is much worse, maybe 100mb either way then it does. It'd be better if it just crashed but the network just drops off. I've noticed when Im using SCSI it drops off quicker so I'm guessing its something interrupt driven.

I'm not sure what is at fault and I know I'll have to tear into the whole thing to fix it. Or these could be things that were addressed post 0.8.. .I haven't even looked at any later builds.

The larger better thing to do is take the new CPU (which I think I got to compile stand alone, I was going to make a simple test machine) and rebuild around that with something like 0MQ, as even a simple queue got slirp along quite well.. and rebuild all the peripherals to queue up, keeping in mind that on OS X the main thread has to be the one that writes to the screen, although I'm not sure about reading devices... But I don't see then why the CPU could then drive the peripherals more like a real CPU bus.... although it's kind of a lot of work for a platform I never really liked

but its been fun

[neozeed]

Good news!

I broke the 100MB AppleTalk barrier!


And even better, I found out about this interrupt patch (it's all the way at the bottom), and network speeds are MUCH faster. And I can do the ultimate AppleTalk torture I can think of, which is copying files from one server to another.



Granted this is on my local LAN, but 426K/sec sure beats the max I ever got out of SLiRP in the 80K/sec range. Speeds are comparable using pcap.

I also changed the buffer code for the SCSI so now you can format disks as large as 2Gig (I haven't tried any bigger) from OS 8. Don't play with silverlining it seems to trash the boot code or something weird, and I wind up with a disk that won't mount on boot. Although I didn't lose any data, I had to boot from a rescue disk and force the disk to spin/mount and all my data was there.

Ill release something later today, but it's shaping up to be a good release!

[uyjulian]

I was working on Basilisk II like 2 years ago, but I didn't really have the knowledge at the time.
Amazing progress! I might play with networking later.

[neozeed]

I was working on Basilisk II like 2 years ago, but I didn't really have the knowledge at the time.
Amazing progress! I might play with networking later.

I'm really amazed at how much more stable the older versions are compared to the later stuff.

I had to go out last night so I didn't get to do any of the things I want to do before I shove out another build. I know there is demand for CD-ROM and MIDI.. I'm pretty sure I can set it to read ISO's and hopefully some kind of raw cd dump that is bit perfect. Although that does mean I'll need to find a way to play audio. CD-R would be neat. Or just passthru although I still need a DDK for that.

The guy wanting MIDI up and disappeared so when I hear back what he's trying to do with what then Id even be able to take a stab at that.

but so far, I'm happy where I've gotten it.

[adespoton]

I'm not sure what that guy wanted with MIDI, but I'd love to be able to hook up to OS X's MIDI I/O system from the emulator, so as to pass it inputs and outputs such as Garage Band, Sibelius, ThumbJam, and a keyboard. On the other end, getting something like DMCS Construction Set to recognize the MIDI internally would be wonderful.

Of course, getting the clock timings to work is still going to be pretty much impossible.

[neozeed]

I kicked out the latest source. I figure the SCSI is as incomplete as the emulated passthru so it's good enough for now.

A casual scan of cdrom.cpp shows that it shims up the TOC, provides some audio playing hooks and can find and mount HFS partitions.

So I assume a more 'assisted' TOC parse is needed than what the real SCSI devices (well passthru emulated) are providing.

It's something to look at anyways.

So yeah, new update on sourceforge, I've built executables for Win32, Linux (i386), OS X 10.8 (i386), and OS X 10.6 (i386/PowerPC).

The PowerPC exe runs on rosetta although libpcap gives some weird error (probably since I'm not on a PowerPC), and exiting gives some freed object error. The native versions don't do that so I'm again inclined to think it's from emulation.

Maybe I should make a new thread?

[mabam]

I could always look at sheepshaver...

I'm somewhat late with my comment on this, but it would be great to have those features implemented in a SheepShaver build for OS X.

[neozeed]

I could always look at sheepshaver...

I'm somewhat late with my comment on this, but it would be great to have those features implemented in a SheepShaver build for OS X.

I did take a small look and saw that a LOT of code is actually common between the two. So it's a real possibility.

In other news I found a DDK, for NT 4.0 of all things but it doesn't matter. I managed to query for SCSI busses, and enumerate devices. but doing an inquiry doesn't work in the manner I'm expecting. Or it could be my emulated peripherals, or a NT DDK on Windows 7.

[Cat_7]

Hi,

Getting decent networking capabilities in SheepShaver would also open up the opportunity to run a full-fledged Mac OS 9 AppleShare IP server with dns, mail, web etc., and clients. Should be appealing

It seems the current tun/tap method for getting SheepShaver to do Appletalk doesn't work anymore in Yosemite. The tuntaposx tool doesn't have signed kexts. Although it seems to install, the devices are not created in /dev/ There are some signed kexts in TunnelBlick, but I have not yet been able to use them.

Best,
Cat_7

[neozeed]

Hi,

Getting decent networking capabilities in SheepShaver would also open up the opportunity to run a full-fledged Mac OS 9 AppleShare IP server with dns, mail, web etc., and clients. Should be appealing

It seems the current tun/tap method for getting SheepShaver to do Appletalk doesn't work anymore in Yosemite. The tuntaposx tool doesn't have signed kexts. Although it seems to install, the devices are not created in /dev/ There are some signed kexts in TunnelBlick, but I have not yet been able to use them.

Best,
Cat_7

I really need to upgrade to Yosemite.

I'm going to keep that snow leopard VM around to at least try half heartedly to keep a PowerPC build, although I have no way of really verifying and I haven't heard back on that one. And the 3 downloads I see could just as well be an error.

But I like the idea that it at least compiles with the old GCC / Cross environment.

Sheepshaver is only slightly more stable than Basilisk II.. I couldn't download anything on Basilisk II and with Sheep I had 50/50 odds.. so maybe ejecting all the features will make it more stable as well. I don't know but I kind of hate undoing so much hard work.

[adespoton]

I've been wondering if it would make sense to just use Tunnelblick to handle the networking for BII and SS -- this might make using the network interface from within the emulators a bit easier. Thoughts?

[neozeed]

I've been wondering if it would make sense to just use Tunnelblick to handle the networking for BII and SS -- this might make using the network interface from within the emulators a bit easier. Thoughts?

I know with BII it doesn't take care of it being so prone to stalling or crashing. Just as the SLiRP code was horribly unstable as well. But a few hours with MSVC & IE 4 seems to have cleared up a bunch of that.

personally I prefer libpcap, I hate tun/tap and I hate making bridges on a machine. I know that's how its done with KVM and other 'big' things, but I still don't like it.

I also want to do something like DOSBox IPX but with AppleTalk. I like that idea of there being an IPX 'cloud' people can connect to, and to reproduce the same thing for AT would be kind of cool. Then we can nettrek or whatever it is people do

[Cat_7]

I'll give the Basilisk PPC version a go later tonight. Firing up my G5 dual gives such fun when my partner is asleep

This is what I get:
Process: BasiliskII_neo [397]
Path: /Users/hsp/Cockatrice/BasiliskII_neo
Identifier: BasiliskII_neo
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: bash [388]

Interval Since Last Report: 343 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2

Date/Time: 2014-10-29 18:42:51.494 +0100
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: ED7B8FD8-6474-4476-9506-D21F22C4A214

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000008fe0105c
Crashed Thread: 0

Dyld Error Message:
Symbol not found: _fopen$UNIX2003
Referenced from: /Users/hsp/Cockatrice/BasiliskII_neo
Expected in: /usr/lib/libSystem.B.dylib


Best,
Cat_7

[neozeed]

I'll give the Basilisk PPC version a go later tonight. Firing up my G5 dual gives such fun when my partner is asleep

This is what I get:
Process: BasiliskII_neo [397]
Path: /Users/hsp/Cockatrice/BasiliskII_neo
Identifier: BasiliskII_neo
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: bash [388]

Interval Since Last Report: 343 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2

Date/Time: 2014-10-29 18:42:51.494 +0100
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: ED7B8FD8-6474-4476-9506-D21F22C4A214

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000008fe0105c
Crashed Thread: 0

Dyld Error Message:
Symbol not found: _fopen$UNIX2003
Referenced from: /Users/hsp/Cockatrice/BasiliskII_neo
Expected in: /usr/lib/libSystem.B.dylib


Best,
Cat_7

well now that is a strange error, from what I can tell that means I'm mixing two SDK's and the PowerPC side is compiling in something too new which is causing the trap.

Since I'm not calling anything exciting I may have to rebuild a 10.2 machine and compile under Qemu, and lipo that in with a 10.6 binary... Or do the sane thing and purge all the SDK components from my 10.6 and try to install a 10.6 Xcode.

http://stackoverflow.com/questions/3207 ... sl-problem

this seemed like a silly "fix" but I wouldn't want to get you into too much trouble with your partner..

[neozeed]

So repeating what I did with Basilisk II, the first phase is to get it to compile and build on Linux.

I somehow managed to do this with GCC 4.7




I also disabled everything that looks like a feature ...

--disable-jit --disable-gtk --enable-sdl-video --enable-sdl-audio --disable-vosf --disable-addressing

Although it still needs to run as root as it does some magical memory mapping in userspace. I haven't even begun to try to understand what on earth it's trying to do, but no doubt this will make things.. interesting.

Also it may be my 8.0 image I loaded up as a Quadra, but it's VERY touchy..

But it compiled on something so now I can try to tear it down and strip it out to see if it'll build elsewhere, basically hardcoded to an i386.. which is fine with me since that is what everyone runs these days.

[Cat_7]

You're referring to ERROR: Cannot map Low Memory Globals: Operation not permitted ?
You can fix that by not running anything like apparmor and by adding vm.mmap_min_addr=0 to /etc/sysctl.conf

Best,
cat_7

[neozeed]

Ok so I'm starting with the SCSI... And it's VERY touchy about that.

From what I've found is that Sheep Shaver really wants to be a 9500. Using a 9500 ROM with a MD5 of dfebb8fdad4124e02608429d98bf349b it can boot from SCSI disks. (tested with 8.6), however bringing up system preferences makes it look like there are no SCSI devices at all.

The formatting tools don't query the bus or anything it just plays dead.

But using silverlining it'll bring up the disk, you can format and install onto it.

I don't know why the CPU type isn't something you can select (like it is in Basilisk II), but the 604 seems to work best with the 9500's old world ROM, and I find the G3 works best with the New World. Also use the New World that matches the OS!!! Don't expect an 8.6 New World image to boot OS 8.1 ... Honestly it seems to me that it's best to stick with the 9500 ROM.

Next should be networking. I tried just replacing the networking with mine but that didn't work. Since I have issues building the latest sheep with my GCC 4.6 or 4.7 in Debian 7, I'm still on the original Sheep 2.2 ... so it's not quite the same as Basilisk II at this point although I suspect I can get what I want done.

[Cat_7]

Some (a long) time ago I tried to graft the Basilisk142 scsi support onto the newer BasiliskII and SheepShaver windows version. While succesfull for Basilisk, it never worked for SheepShaver. The source code said something about a newer version of the scsi manager not being supported.

Best,
Cat_7

[neozeed]

I've tested a bunch of ROM's but the only one that did anything with the SCSI bus was that 9500 rom..

also I ran configure like this:

./configure --disable-jit --disable-gtk --enable-sdl-video --enable-sdlaudio --disable-vosf --enable-addressing=direct

And I can run it as a normal user. I don't like that 0x0 memory map thing. Compiling with GCC 4.7.2 with -O3 seems to be snappy enough for me.

But work is calling.. ugh.

I need to copy over some test programs or something. It seems silly to excersize the 68000 side of things, since there is Basilisk II. And all the PowerPC stuff I know (really ONI) needs 3d acceleration which the only way I know how to do that on a VM is to make a stub library inside the VM that calls out to a native DLL. But I don't know the first thing about programming a Macintosh. One funny thing though, Mac Mint freaks out on a Quadra or any 68040 machine, but runs fine on Sheep Shaver. Kind of unexpected.

Ugh I'd forgotten how unstable all of this is... Then again years ago when I bought a $12 Powermac 5400, it was pretty flaky as well. It did have a TV tuner, and I ended up using it as a TV. Sadly it's gone, dumping it's memory may have been slightly useful.

Oh I nearly forgot, I was downgrading from 8.6 to 8.0, and I used the A/UX 3.0.1 disktool, and that one worked. I was able to initialize, partition and format my virtual SCSI disk... So looking back at the rom patching file it looks like Sheep Shaver really does patch into the legacy 68k side of things... At least regarding SCSI.

[neozeed]

Ugh video on segfault? The need to catch signals isn't so strange but crashing is how sheepshaver actually works..

I'm still not sure if it's brilliant or just horrible design.

I know with Basilisk it's basically how it works with fake opcodes which throw an exception, but it never actually crashes the program and needs to not only catch the crash, but resume...

It's an interesting way of standing on another emulator that is for sure.

Also the configuration /build process is so annoying...

Ugh.

But I'll keep plugging.

[uyjulian]

Yeah, autohell just is very confusing, and it checks stuff that should be outdated 10 years ago!
I like CMake better.

[neozeed]

Yeah, autohell just is very confusing, and it checks stuff that should be outdated 10 years ago!
I like CMake better.

Ugh the only thing worse than cmake is that python thing. I really hate when it builds stuff it hides what it's doing. It's really annoying to deal with.

I prefer make files I can just edit by hand, and a config.h