It’s in the current source, right now, but I figured I’d build it and give it a shot.
The dynamic core consumes MUCH less CPU power. Â The only current downside seems to be a 56kb/sec memory leak (I guess some dynamic code block isn’t being discarded). Â But I have to say it’s REALLY cool to be running DOOM v1.1 on MS-DOS 5.0 and it’s running at 0% CPU utilization on my Xeon.
And as always the ‘normal’ non dynamic version is just fantastic.
I’ve only tested it with DOOM, and it’s worked great. Â Give it a try?
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/loginrc
to
co::respawn:/etc/getty console co_9600
And now you’ll get a “text” login.
Text mode login for A/UX
I guess the real test will be to see if it makes it through the night.
While looking for some stuff on the x68000, I came across this package Lydux, which features GCC setup as a cross compiler from either Windows or Linux to Human68k.
So I downloaded the Windows version, set it up according to this guide, and set on trying to build a simple EXE.  I did install CodeBlocks, but I ran into a problem while trying to build a running executable.  For some reason objcopy doesn’t work correctly unless it is in verbose mode.  I found that by accident, but much to my surprise it does work!
Hello World cross compiled from Windows to the x68000
did the trick, and now it’ll generate working executables.
I’ve found the emulator XM6 TypeG version 3.13 L21 the easiest to deal with as it has English translated menu’s and lets you mount a folder on your PC as a virtual drive. Â This makes loading cross compiled stuff much easier.
Since finding this stuff is getting harder and harder, and that most of the xm6 forked emulators are closed source, I thought I’d at least upload what I’ve been able to find. Â It’s a shame the 68030 stuff is closed off, but there isn’t anything I can do about that. Â Apparently there was some feud between some dev groups. Â I’m not really sure as it seems.
Be sure to set the shared directory under Tools -> Options to be able to map a shared directory.  In the disks sub directory there is a HUMAN302 disk image which contains the needed device driver to map into the directory.  You can run either the 68000 or 68030 model depending on what you like more.  If you have no emulated SCSI or SASI disk, the shared directory will appear as your ‘c’ drive.  And as always the keyboard will be mapped to a Japanese keyboard, so that is why the : * = keys seem in the wrong place.
On the OS X front I went ahead and built a cross compiler. Â I ran into this fun error building GCC on OS X:
Makefile:142: ../.././gcc/libgcc.mvars: No such file or directory
So yeah it turns out you really should configure/compile gcc in a separate directory from the source. Bad old habits die hard. Anyways my tool chain is here. I’m running 10.10 so I’m not sure about older versions of OS X.
If you are like me buying a compiler is something I don’t do terribly often. Â Or I end up doing it for projects or even worse, I end up using old versions I bought over 10 years ago, because Visual C++ 5.0 should be good enough for anyone, right? (I also own Visual Studio 2003, so it’s not THAT bad….)
I haven’t installed it yet, I’m actually still downloading it. Â But it certainly implies that it is far more capable than the older Express Editions.
And of course, for the upcoming 2015 release:
“Built from the ground up with support for iOS, Android and Windows, Visual Studio 2015 Preview makes it easier for developers to build applications and services for any device, on any platform.”
Not to mention they are also apparently going to open up the source to .NET . Â The press release also claims:
expanding .NET to run on the Linux and Mac OS platforms.
I guess that’ll only be a matter of time to tell.
If anything it’ll be a good excuse to crank out some Quake benchmarks.
A few months ago I made a guest-post about my personal experiences with the Gravis UltraSound cards. In this article I mentioned there were a few variants
besides the standard GUS “Classic”, MAX, and PnP series. I was unable to
comment on the other cards since I did not own them. Well, that all changed
a few weeks ago when I contacted someone who wrote some pack-in software that
was included with most GUS cards and surprisingly he still had all his cards.
Even better, he was willing to give them to me!
One of the cards I received was the Synergy ViperMax. I have read some usenet
posts and have talked to other people who were active in the demoscene in the
mid-90s and apparently this card was originally designed by STB and then STB
produced their own card that has an ESS1688 chipset (for SB Pro compatibility
and better Windows drivers) and the GF1 chipset (the IC that makes the GUS
it’s own). How true is this story? I have no clue, as I have never seen an
STB variant of this card, but I have seen STB GUS PnP (the AMD Interwave
version) as Compaq OEM clones for sale occasionally.
In any case, Synergy started producing this card and it’s kind of a rare
number. Again, rumours afloat, that the guy from Synergy was coming to
demoparties and giving these away to groups that won competitions in an
effort to stir up some interest/sales. And before Advanced Gravis all but
gave up on the sound card market they took the Synergy ViperMax cards and
simply placed stickers over the Synergy logo and card name. Gravis also maxed
out the onboard RAM to 1MB (the ViperMax comes with 512kb by default). It is
exactly the same board, which leads me to believe Gravis may have purchased
remaining stock of the Synergy cards and unloaded them. The UltraSound Extreme
may be even more rare than the ViperMax. It’s hard to say as I have personally
never seen either of these cards for sale on ebay.
Keeping the GUS roots, the card is almost completely plug and play. The only
thing you must change is a jumper for CD-ROM Enable/Disable. Like the GUS MAX
there is CD-ROM interface support. Contrary to rumours, this card is NOT GUS
MAX compatible! It does not contain the Crystal CS4231 CODEC chip or emulate
it. This means no MAXSBOS and no special demos that will output 48khz (I only
know of one, The Secret Live of Mr. Black by Orange). I feel this
misinformation was started because of the CD-ROM interface that was also unique
to the GUS MAX. To setup your card you just run viprinit in DOS with your
appropriate SET BLASTER and SET ULTRASND variables and it configures the rest.
However, I noticed viprinit will not properly change your base address for the
ESS chipset (i.e. you want to change it from A220 to something else). No fear,
Synergy included the ESSCFG.EXE utility as well allowing you to change the
base address. Initial configuration is set with VSETUP.EXE from DOS.
Windows 95 installation is basically the same as the earlier cards. You
run the setup.exe and it will install the ESS drivers. It tries to setup
some extra stuff for UltraSound as MIDI device. And it does work just fine
but a gotcha is that the DOS stuff will break. I never had a reason to use
GUS’ MIDI capabilities from within Windows so this wasn’t a deal breaker
for me. After a reboot you will likely have to reconfigure your card
manually from the device manager but after that it’s smooth sailing. And yes,
you can install the updated ESS1688 drivers with no ill-effects. However,
if there are any differences in performance I have yet to notice it. Last known
official ESS drivers for Windows 9x at http://dk.toastednet.org/GUS/drivers/WIN95/VMAX-GUS_Extreme/1688_v1087.zip
The ESS chip is really nice, it sounds very similar to the OPL3 and it has
SB PRO compatibility (take THAT SB16!). Whats the difference? The SB16 only
states that it’s Sound Blaster compatible, not Sound Blaster PRO compatible.
This means some earlier titles like Wolfenstein 3D will only output in mono
on the SB16. With the ViperMax, you can hear stereo sounds again.
Wolfenstein 3-D
Someone asked me if SBOS and MegaEm work. SBOS, no. MegaEm, yes but with no SB emulation. You can probably make MegaEm work with the SB emulation if you
want to play around with running ESSCFG, changing your PnP settings, updating
your BLASTER and ULTRASND variables then running viprinit. But, you’ll need
a lot of free resources and quite frankly I fail to see a point. If anyone
out there has pulled it off drop me a comment.
Since the card has a GF1 IC there is no comparision between the earlier GUS
cards. They will all sound the same. The signal-to-noise ratio is acceptable
though I haven’t measured what it truly is, but for gaming and watching some
demos it’s capable.
All in all, this is a great card. If it was released earlier and through
Advanced Gravis they could have still been in the market. Another nice
side effect of this card is that Windows XP has ESS1688 drivers. Just install
the cards as a non-pnp legacy device, configure manually and enjoy sound!
I made a few more rips comparing the differences between the ESS mode and GUS.
The few module files are played with XTC-Play and two of them (ATBIA3 and
Parallel Universe) are XM modules over 1MB. XTC-Play has a way of quadrupling
the RAM usage by downsampling. However, the modules still sound quite good
and it’s quite a thing to hear the GUS playing large high-quality modules.
VMAX 3D
Before I bring this article to a close, here is some ViperMax/GUS Extreme
Resources:
Enjoy the rips! In a few weeks I’ll have a write up on the Gravis UltraSound
Plug and Play Pro (waiting for my RAM upgrade) and finally some last minute
thoughts and information about a few other OEM cards and the GUS ACE.
so I got it to “work” on OS X….. well 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 no longer 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 (Quake 1 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 primarily 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.
