The big change is the new 68881 maths FPU emulation. It’s completely new code in this version. As the author, Pruten mentions:
it should be the “most accurate” 68881 emulator (with regard to chip behavior) ever written, as far as I can tell. I can’t find another open source emulator that even attempts to emulate FPU exceptions, probably because Motorora’s documentation is terrible. Rife with typos and errors, and lacking descriptions for lots of edge cases. It’s also a superset of IEEE 754, so it’s tricky to get softfloat, a strict IEEE 754 implementation, to implement all the weird extra behaviors in the 68881.
On the flipside however:
It will also be much slower than the old version, since the new FPU uses integer-based softfloat. The transcendental instructions will be emulated by running whatever the best natively available function is, and then blindly copying the result to the dest FPU register. Since the FPU is the last big piece of shoebill that requires x86, this should allow it to compile on other architectures, like maybe PPC
I’ve only recently rebuilt the emulator with only the addition of the SLiRP code that I’ve been able to debug from Cockatrice III (who said that I was wasting my time? At a minimum I ‘fixed’ up SLiRP to make it more stable), and kicked out a Win32 build (source/binary).
I’ve just had it running doing a simple shell script after disabling the UI. So far it’s 15 hours of uptime…
8:43am up 15:02, 3 users, load average: 0.00 0.01 0.01
Which is nice.
I should add, to disable the UI in A/UX it’s best to edit the inittab and change
co::respawn:/etc/getty console co_9600
And now you’ll get a “text” login.
I guess the real test will be to see if it makes it through the night.
Great news! The excellent A/UX capable emulator Shoebill, now has working Ethernet support! The sad news is that it only supports the TUN/TAP interface. So Windows users are kind of left out in the fun.
Except, I’ve been here before with SIMH ages ago. So I dusted off my source code, and injected it into Shoebill. The first issue I had was that SLiRP was rejecting all the inputted frames, because of invalid frame length. Even more weird is that ARP worked, and I could see the 10.0.2.2 and 10.0.2.3 virtual IP’s but TCP and UDP outbound wouldn’t work at all.
It took me longer than it should have but although this code worked great with GCC 2.7 and 3.0, 4.x breaks it. And it’s the same reason why Shoebill originally didn’t work on Win32, the blasted packed structures! So adding the ‘-mno-ms-bitfields’ flag to GCC is all it took, and now I could ping 10.0.2.2 for about 5-7 pings until SLiRP would crash. I tried all kinds of stuff trying to see if there was an issue with SLiRP, but I should have payed closer attention to the debugger, with all those threads flying around. It turns out Shoebill was trying to read & write a the same time, which caused SLiRP to crash as it is not re-entrant. I tried to place mutex’s on every SLiRP call but that ended up having SLiRP not process any packets. Very strange. I then reduced it to where I read the frame out of SLiRP and pass it to Shoebill, and where Shoebill write’s a frame out the SLiRP. And much to my amazement I can run ‘worms’ just fine!
So after a minute of worming and pinging I called it ‘good enough’ and rebuilt a production binary, and packaged up my source code.
Good news, as mentioned here, the Shoebill emulator was recently given some much needed SDL love, and ported to Linux.
Well that’s great and all, but the vast majority of people who run anything these days do it with Windows. So I decided to try to get it to compile with MinGW to see how far I could get.
And the short version is that I got it working!
The long version is that in the first pass there is some SIGUSR2 stuff that is undefined. And for a good reason, since it won’t work. So I just commented them out. The next minor problem was the lack of bzero. Honestly I don’t know why bzero is missing from MinGW, but who knows why.
Shoebill also processes some internal macros with a perl script that for some reason was dropping in binary values into the source, making GCC mad. I just commented out a line that was adding in more comments into the header. This let me compile with a simple pass.
There was some issues reading the ROM file, since the 68000 is a BIG ENDIAN processor, and the 8086 is LITTLE ENDIAN, Shoebill makes extensive use of hotns and hotnl, ntohl, and ntohll. These can be found in the winsock library, and even better they dont need any winsock initialization, they work right away. I just have to make sure I include winsock2.h, and link against the winsock library.
However when trying to boot, the checksum was 0x00000000, not the expected value! Luckily there was an assert to catch that and crash. This led me to notice that in Linux files are opened in binary mode by default, while on Windows, they are opened in ASCII mode. A quick change of all the fopen calls, and I was reading the ROM, but now crashing on the disk.
As it turns out newer versions of GCC go all crazy when it comes to structs, and try to automatically align to boundaries for quick access. Which sound nice, until you try to read in some binary data, and expect things to be in certain locations and find out that your structure is larger than expected, and data is read in the wrong place.
The solution is to force the compiler to leave it alone with
HOWEVER as luck would have it, Microsoft apparently packs structures a different way, and you have to either make a macro to do a bunch of work to force it to make the structure 1:1 of what you expect, or use the CFLAG option of
And now MinGW’s GCC will build something along the lines of what it’d build on Linux.