My experience with the Gravis UltraSound Part 2: Synergy ViperMax / Gravis UltraSound Extreme

(guest post from Frank Sapone)

ViperMAX_PCB

Synergy ViperMax / Gravis UltraSound Extreme

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

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

VMAX 3D

Before I bring this article to a close, here is some ViperMax/GUS Extreme
Resources:

* Gravis UltraSound Extreme Manual: http://dk.toastednet.org/GUS/docs/EXTMAN.ZIP
* Gravis UltraSound Extreme CD ISO: http://dk.toastednet.org/GUS/ISO/GUS_EXTREME_CD.ZIP
* Synergy ViperMax CD ISO: http://dk.toastednet.org/GUS/ISO/VMAX_V10.zip

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.

For comparison here is DOOM II Map 06


Gravis


Sound Blaster

SheepShaver with pcap support

It "works", just incredibly slowly

It “works”, just incredibly slowly

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.

Phase one on a SheepShaver rebuild complete

SheepShaver on Linux

SheepShaver on Linux

Only because people were asking for it.  The first thing I did for Basilisk II was to get it building on Linux, so here we are.  I only tweaked the config process to let me build it with GCC 4.7.2 .

So this will be in the same effort of removing features, and trying to place in my SDL drivers, network and SCSI stuff.

Im starting with SheepShaver v2.2, which is pretty old.  But 700kb compressed is a good starting point.  As you can see it boots MacOS 8.0 which is also good enough for me.

The other questions will be, can this build under Windows with MinGW configured like this, and can it build with OS X.  It looks like all the stuff is there so this may be kind of easy. I hope.

Also SheepShaver does something funky with it’s memory space, it does some direct mapping to the user area.  I’ll have to see if I can disable that, performance be damned (well I turned off JIT as it won’t compile with 4.7 either) so this won’t be fast, but I’m just patching stuff up, not re-implementing the wheel here.

AltaVista Personal Indexer

caption

Probably not a good idea..

I never got into the whole ‘desktop search’ thing as I used to know where my stuff was.  But now we live in the future where not only can you just go out and buy terrabytes worth of storage but downloading 10 years worth of usenet is something you can accomplish in a few minutes (on a good connection) but storing it as flat files only takes 20 minutes to decompress some 2,070,332 worth of files is a trivial manner.  It’s really cool to live in the future.

Total Files Listed: 2070332 File(s) 5,429,376,673 bytes 
                    168164 Dir(s) 1,119,884,468,224 bytes free

Now what about finding something in those files?

I should be embarrassed as I was using grep.

Yes in my hunt for obscure information grep was my tool of choice.

So after Frank had mentioned it in passing, if I’d ever used AltaVista Personal Search 97 before I thought I’d give it a bit of a test.  First I unpacked some BSD source code, and had it index that.  The results were incredibly FAST.  So the next thing to do was to try the UTZOO archives.  I should have expanded my NT 4.0 VM’s disk first, but I got this far until I was down to 200MB of free disk space

Screen Shot 2014-10-29 at 9.04.27 PM

 

I should add that I’m sharing the UTZOO archvie over the network.  Not the fastest way at all.  And I only made it about 40% the way through the archive.  Even at this point the search database is only 1.2GB

So how does it run?  Well it’s a localized web service that resides on your desktop.  Of course it only works when you request from 127.0.0.1 as they sold a network searchable version of AltaVista, the Workgroup Edition.  Even this was a retail product at one point retailing for $29 to $35

Screen Shot 2014-10-29 at 9.46.46 PM

Show me the Xenix!

So you hit the web page, type in your search, and you answers like immediately.  It really is scary how fast this thing is.  Although the results can need a lot of tweaking but we are talking 800,000 files.

But needless to say there was the disastrous Compaq buyout of DEC, and the entrance of Google, and it was over.  From what I understand people are still selling the workgroup/enterprise search.  I can see why even though the 97 is rough it still has promise.

What a bargain!

What a bargain!

For anyone who cares, it’s geared to Windows 95, or Windows NT 4.0.. 2000 and beyond is at your own risk.  It uses a Win16 setup program, so Windows 7 x64 was out of the question, but you can download it here.

While hunting for Hack 1.0 in usenet

I came across this PDP-11 version.  I saved it to the side while I was looking for my main target.

Now I’ve tried to compile it on contemporary UNIX of the time, namely Unix v7, 2.9 BSD and 2.10 BSD and they fail at the same point:

hack.monst.c:99: Too many initializers: mon
*** Error code 1

Stop.

What is more weird is I didn’t see anyone having any reports of it working, just requests for the code.  Although I have been able to compile and run it on 4.2BSD/VAX.  So it must be a cc/pcc thing, or some other C compiler they are using on the PDP-11 in Amsterdam circa 1985.  And then I found this interesting bit:

Date-Received: Mon, 22-Apr-85 06:57:56 EST
References: <[email protected]>
Reply-To: [email protected] (Andries Brouwer)
Distribution: net
Organization: CWI, Amsterdam
Lines: 11

In article <[email protected]> [email protected] (Chuck McManis) writes:
>… about the PDP-11 version of hack …
>All in all it doesn’t seem to do 90% of the things that make it different
>from rogue.

The PDP-11 version of hack is a slightly improved (by people at the VU,
Amsterdam) version of some code that was stolen from my directory
some three years ago; it was being worked on, and certainly not in a
shape fit for distribution. Thus, as you noted, it doesnt have half
of the features present in hack, and, what is worse, it is very buggy.
I am sorry it was distributed.

Which to me is kind of interesting as this recently happened on September 21st:

The NetHack Development Team feels it is necessary to publicly address an issue that has surfaced in the last week.

Recently a NetHack source distribution has appeared, claiming to be NetHack 3.5 or 3.5.0 or 3.4.4.

This claim is partially correct. This is our code. However it was not released by us or with our authorization. This code is not ready for release: it is unfinished, unpolished, and almost certainly very buggy. It has not been play-tested for balance or functionality. It is best considered a partial and unfinished rough draft. We will not be supporting this code, nor will we be releasing binaries or bugfixes for it. It will not be available through our website.

Due to this incident and to prevent confusion, we will not now nor in the future release anything with a version number of 3.4.4, 3.5, or 3.5.0.

We thank those of you who play and develop both NetHack and its many variants for your support and encouragement at this time and over the many years NetHack and its progeny have and continue to evolve.

So yeah it seems there is a long history of hacking hack, why even the Fortran port of Zork was born that way:

Zork (was) only as encrypted files that were runnable in an MDL environment but were not readable (and modifiable) as source code. They even went so far as to patch their famously insecure ITS development system, adding security to just the directory that stored the source. Hackers, however, won’t be denied, and soon one from DEC itself had penetrated the veil. From Infocom’s own official “History of Zork“:

[The security] was finally beaten by a system hacker from Digital: using some archaic ITS documentation (there’s never been any other kind), he was able to figure out how to modify the running operating system. Being clever, he was also able to figure out how our patch to protect the source directory worked. Then it was just a matter of decrypting the sources, but that was soon reduced to figuring out the key we’d used. Ted had no trouble getting machine time; he just found a new TOPS-20 machine that was undergoing final testing, and started a program that tried every key until it got something that looked like text. After less than a day of crunching, he had a readable copy of the source. We had to concede that anyone who’d go to that much trouble deserved it. This led to some other things later on.

Indeed,hackers won’t be denied.

Hack 1.0 preliminary version

The source code to Hack was posted onto usenet back in December of 1984:

From: [email protected] (funhouse)
Newsgroups: net.games,net.sources
Subject: Hack sources posted
Message-ID: <[email protected]>
Date: Mon, 17-Dec-84 09:11:48 EST
Article-I.D.: mcvax.6238
Posted: Mon Dec 17 09:11:48 1984
Date-Received: Tue, 18-Dec-84 07:04:44 EST
Organization: CWI, Amsterdam
Lines: 20
Xref: watmath net.games:1303 net.sources:2185

I will post the sources for Hack to net.sources.
They come in 10 parts; the total source is slightly over 400kbyte.

Hack is a game resembling rogue (but much richer than the versions
of rogue I have had access to).

The game runs on all machines with sufficient address space:
$ ls -l /usr/games/HACK
-rws--x--x  1 play       159744 Nov 10 19:09 /usr/games/HACK
$ size /usr/games/HACK
text	data	bss	dec	hex
106496	34816	29264	170576	29a50
but if you are unfortunate enough to have a backward C compiler
(without structure assignments or bitfields or functions returning
structures or with only 6 significant chars to an identifier)
then you'll have to work to get this running.

I am happy with mail, but will be abroad the next four weeks.

Good Luck & Happy Hacking !

Oddly enough the full source code to Hack had been lost.  Even the Nethack Wiki didn’t have the full source code, although thanks to the UTZOO archives by Henry Spencer, I was able to look through enough of the tapes since I had the date and subject in hand, and I was able to pull out the entire thing.

hack 1.0 preliminary version

hack 1.0 preliminary version

I’ve added a package tape for SIMH, as it builds and runs on 4.2 BSD out of the box.

It’s really cool to have saved this from the digital dumpster, although it was there all along.  And thanks to others for at least pointing out that part of it was missing or I’d never even look.

Impuse Tracker open sourced

I’ve never been musically inclined, but for those who loved the whole tracker scene of 20 years ago, Jeffrey Lim has released the source code to Impulse Tracker!  It features an impressive sound card support list:

  • Sound Blaster
  • Sound Blaster Pro
  • Sound Blaster 16
  • Sound Blaster AWE 32
  • Terratec EWS64
  • Hoontech Soundtrack 97 PCI
  • Gravis UltraSound, PnP, Max
  • Pro Audio Spectrum
  • Pro Audio Spectrum 16
  • Interwave
  • PC Speaker
  • DAC on LPT

It’s all in assembly and can be built with Turbo Assembler 4.1

You can find the source code on bitbucket here. Github mirror!