More thoughts on Minecraft, compression and encryption

So earlier, I had touched on Minecraft, and lamented on how it doesn’t compress it’s network data very well.  Well it turns out that yes, in the server.properties file, there is an option network-compression-threshold, which by default is set to 256, meaning packets larger than 256bytes are compressed

network-compression-threshold=256

So using this quick stunnel guide, I thought I’d try a quick experiment.  So I loaded up Titan City, and ran some connection experiments:

First, the Minecraft server with a setting of 256000000 which I would imagine effectively turns off compression.  I’m capturing one minutes worth of game play as it tries to render the spawn point.  Then again with the threshold set to 256:

12M 28 Apr 13:44 minecraft-nocompression.cap
1.6M 28 Apr 13:46 minecraft-256compression.cap

So, uncompressed it’s 12MB worth of data!  While with the Minecraft compression on, it’s 1.6 MB worth of data.

And now with stunnel using zlib compression, we get the following results:

2.1M 28 Apr 13:42 stunnel-nocompressioninserver.cap
1.5M 28 Apr 13:48 stunnel-256compression.cap

2.1MB worth of traffic relying on zlib in this case to do all the compression, and 1.5MB with zlib compressing the Minecraft compression.  And for the heck of it, why not compress the data again?
964K 28 Apr 13:46 minecraft-256compression.cap.gz
993K 28 Apr 13:44 minecraft-nocompression.cap.gz
938K 28 Apr 13:48 stunnel-256compression.cap.gz
1.5M 28 Apr 13:42 stunnel-nocompressioninserver.cap.gz

Well, now that is strange, why is the stunnel traffic even compressible, after it’s been encrypted?  Kind of weird to me.  At any rate, here is some more data thanks to the capinfos program:
# capinfos *cap
File name: minecraft-nocompression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 14 k
File size: 12 MB
Data size: 12 MB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:43:30 2015
End time: Tue Apr 28 13:44:29 2015
Data byte rate: 211 kBps
Data bit rate: 1,689 kbps
Average packet size: 844.05 bytes
Average packet rate: 250 packets/sec
SHA1: ffb5542c47da69ddc93da902136e1173d76b56e0
RIPEMD160: bc2102185a924096a8cf145c54375a05ab90e3c6
MD5: ba0e1addfcb36e7db6314764941fa6af
Strict time order: True

File name: minecraft-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 10 k
File size: 1,686 kB
Data size: 1,524 kB
Capture duration: 54 seconds
Start time: Tue Apr 28 13:45:28 2015
End time: Tue Apr 28 13:46:22 2015
Data byte rate: 28 kBps
Data bit rate: 226 kbps
Average packet size: 150.91 bytes
Average packet rate: 187 packets/sec
SHA1: 5b5e51f53f0716fd84a39120afd68eadbfaf9816
RIPEMD160: f2bf3839c084b1d7b31fce0a8a8ce959316643a7
MD5: dc6f56a5a1c10e642548e0eeb979629b
Strict time order: True

And now let’s look at the stunnel captures:

File name: stunnel-nocompressioninserver.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,949
File size: 2,159 kB
Data size: 1,999 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:41:13 2015
End time: Tue Apr 28 13:42:12 2015
Data byte rate: 33 kBps
Data bit rate: 270 kbps
Average packet size: 201.02 bytes
Average packet rate: 168 packets/sec
SHA1: 418cc249c3393d85e6e59a6e02c02060b7b7ce4f
RIPEMD160: bf7f56af412734260e0e96d1a0c7d2f28be3ba95
MD5: 1b96fce1db9d38d8dbbecf9bb2278079
Strict time order: True

File name: stunnel-256compression.cap
File type: Wireshark/tcpdump/… – pcap
File encapsulation: Ethernet
Packet size limit: file hdr: 1520 bytes
Number of packets: 9,585
File size: 1,554 kB
Data size: 1,401 kB
Capture duration: 59 seconds
Start time: Tue Apr 28 13:47:35 2015
End time: Tue Apr 28 13:48:34 2015
Data byte rate: 23 kBps
Data bit rate: 189 kbps
Average packet size: 146.21 bytes
Average packet rate: 162 packets/sec
SHA1: 19b2bbfff8cd9c5c0e460d64ad0f4b966cf3a141
RIPEMD160: e31c226101daea9327a8b13a4a1012a24bea11c1
MD5: a7b4b0d5ecf3e6a472255cff13466b51
Strict time order: True

Well for me this is still interesting.  The stunnel connection sent less packets, and smaller.  I know that this is horrible to ‘measure’ like this, and yes none of the datasets are the same, making this kind of bogus. However, honestly compressing with stunnel does feel faster.

So, want to try?  I guess I can let people try if they want, but you’ll need stunnel.  I’ve read horror stories on griefers and I figure if i raise the bar to connect it’ll be somewhat distractionless.

So here is my stunnel.conf I’m using on the client side.

client = yes
compression = zlib
foreground = yes
debug = 6

[minecraft]
accept = 127.0.0.1:25565
connect = virtuallyfun.com:25566
cert = minecraft.pem

And of course, you need my certificate pair, so here is minecraft.pem:

-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEArvdyw5UGic3wCDowzGM/ZVdaCrnDFeo8SmkP1jJGIhsAzzMV
+56Ctd98raKPnw5nnEtrmV7yImBiF/A32SPbYF6nqBhNKPbrUg4u4dsr9uyo7/F4
00VMcXbcgwc+pDOU5uUCg7hZcmCGolVs+7GxC3R1m8SbPZYvlgcHHJXdnEKL8RG8
z54B2L1Ai76CYlD6Q94QnQxiJricy8DJJP6/ZuqkGg01AcoaCaTOa8mvZMLkBFkj
Ase0aX0nSDRxNkBBe/hgwkRuFWaMI1iGgTCX9J1rogLg2WfZoGIFtuYp8jnwiNQQ
dEM6TTGURm9iqb78pBd6PwWsFBqOa0GLOEzLzwIDAQABAoIBAAz8/373VBnsuLHT
qAW0JGOgfWWobov07G7Vp8BN0Rj9Ci1XbH1WQfvAUGAPXjv/dL+MdbtX6f+VShLe
2TZ8S++2dxmqXCf7VHKt7NsFSxk0bkIJmd+NGGSf3zS21/aWgao2O96NU86CzdvF
Hab9hNgF2CktCh0jRfsMIIIFugK8amQGxpKrseSXuuyWGHNW2a6TIHBJRD1L2DQA
GMVgmpb43aYQHYqeQLmgP40PkJgByazQRV40zqsap1DBxNi2TnDjLUWufKACDM64
RPltM8lZm3H2yqVQEQ2yGbzoEuwVysG5+AlDOCVcbDtQqcj5sV/gzL8X+e6DgV+0
o46pZgkCgYEA5QGN+73cApm1OkjsV1OW7RR22EmGWT9HeFFGReWSBsVoDh/dFjIJ
/KtE7PbafvMcV8JMTzbSxBElc+nPFsRk8J4W+JD3Bluw0MfU1K+AUEmPsj5bX6O6
9Mv8/n8HVhpUusIFvO7K7HutdxxNOis510AtRL8oA6NFkiUBot5KGUMCgYEAw5c1
UVT+N9nciFKopgJlzfcb60SKy60vtWd3eQOuLuRd+1QhF3VpUzTAvwbLARuYdlYM
gIaKcOb7A2+ZNKNCccwP6lTIDEwQuQ3lDyG3KXzHfHocZV4n5uT2SpKLv5NzZlF5
4ealpD5pPwN2c4zpvRDeweWznNahUVngYxma5IUCgYEAvac68eg7g3/OYZWw/WVB
kdgn0FmbxN+uDcupWguUkrz7vu7OhyorsTAZ5fFN5GLr7xX/Yn7xr+TPUp6onZ9K
RSd3uKU9nutilJVaAkXSCyvQsHoJ7DvJgiBJxm5nIfyufPhgDibosU5/yywKHQld
XpFMrClvNwwJes3g/AQB88cCgYEAvOfQ7jG5qrW3Ys765gOQ0gHlrDAyIY+ucXVy
FaYxWEbmYnSZ1W9n/54GvzlPXk2JzllDj+rh0TO1olbp0MYRyZj+kiO6Zu4chK7f
2eKFZgOHJDlILbtnrIDdQ58QbEJ8hYkRv9Yli2FgAyVUBTxHEH03uGwjMsq1Wb4F
k5FKYYUCgYBSe0wqziRUNjxhig/3g5qG6iGt0jnbHN5eTsNiEqe3QxDLKNERGTS4
pjpS0LV52bEdpX7imsIskmt81ed/cPUEKd6nbYyrLT67fUCeLuQ07Zlebc/PI8AD
ZoRiyx8x8k55z143XCIdzIyZTriQ5SkUV33wbzPRF8upD0xaygf2Tw==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIEOTCCAyGgAwIBAgIJAIOpvPCh+v5fMA0GCSqGSIb3DQEBBQUAMIGyMQswCQYD
VQQGEwJVUzERMA8GA1UECAwISWxsaW5vaXMxEDAOBgNVBAcMB0NoaWNhZ28xHDAa
BgNVBAoME1N1cGVyZ2xvYmFsbWVnYWNvcnAxFjAUBgNVBAsMDVZpcnR1YWxseSBG
dW4xGTAXBgNVBAMMEHZpcnR1YWxseWZ1bi5jb20xLTArBgkqhkiG9w0BCQEWHmpz
dGV2ZUBzdXBlcmdsb2JhbG1lZ2Fjb3JwLmNvbTAeFw0xNTA0MjgwMjU1MzJaFw0y
MDEyMDUwMjU1MzJaMIGyMQswCQYDVQQGEwJVUzERMA8GA1UECAwISWxsaW5vaXMx
EDAOBgNVBAcMB0NoaWNhZ28xHDAaBgNVBAoME1N1cGVyZ2xvYmFsbWVnYWNvcnAx
FjAUBgNVBAsMDVZpcnR1YWxseSBGdW4xGTAXBgNVBAMMEHZpcnR1YWxseWZ1bi5j
b20xLTArBgkqhkiG9w0BCQEWHmpzdGV2ZUBzdXBlcmdsb2JhbG1lZ2Fjb3JwLmNv
bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK73csOVBonN8Ag6MMxj
P2VXWgq5wxXqPEppD9YyRiIbAM8zFfuegrXffK2ij58OZ5xLa5le8iJgYhfwN9kj
22Bep6gYTSj261IOLuHbK/bsqO/xeNNFTHF23IMHPqQzlOblAoO4WXJghqJVbPux
sQt0dZvEmz2WL5YHBxyV3ZxCi/ERvM+eAdi9QIu+gmJQ+kPeEJ0MYia4nMvAyST+
v2bqpBoNNQHKGgmkzmvJr2TC5ARZIwLHtGl9J0g0cTZAQXv4YMJEbhVmjCNYhoEw
l/Sda6IC4Nln2aBiBbbmKfI58IjUEHRDOk0xlEZvYqm+/KQXej8FrBQajmtBizhM
y88CAwEAAaNQME4wHQYDVR0OBBYEFJcb/w/SowAjTa/hvtim9oWYSarZMB8GA1Ud
IwQYMBaAFJcb/w/SowAjTa/hvtim9oWYSarZMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQEFBQADggEBAIISqlsBZKh67of21sJhsavDB4T7xrd/qC5zTUeUioScXr+j
n2aziysr+HazliIpVNa5QjicYTniG7urAZdL/zhegSyxEq6r1/BVAks0ooYxJT/f
G5EIhQurv3wQcGKSEXx6IA7+kheqYX++XcM6lAz5jPPIXsRV4NDsE7T68vVuQrr/
RYMHkbCXMqCbUq8x8k65KNN3EPJ66lH83kXuQJRazeurJmcquhmWqApjkORS17kq
+g2xRlnEolvS7umkGz9cbGP7SAWY+ySVIulKSKUKzji8qK8T/hW0dYWUPTZ6+LZx
hHnFJXiaGbnd1sEEB6uVV17XipnE15TGJ8NPT2s=
-----END CERTIFICATE-----

And I run it something like this from the client side…

# stunnel mine.conf
2015.04.28 14:25:23 LOG5[ui]: stunnel 5.16 on x86_64-apple-darwin14.3.0 platform
2015.04.28 14:25:23 LOG5[ui]: Compiled/running with OpenSSL 0.9.8zd 8 Jan 2015
2015.04.28 14:25:23 LOG5[ui]: Threading:PTHREAD Sockets:SELECT,IPv6 TLS:ENGINE,OCSP
2015.04.28 14:25:23 LOG5[ui]: Reading configuration from file mine.conf
2015.04.28 14:25:23 LOG5[ui]: UTF-8 byte order mark not detected
2015.04.28 14:25:23 LOG6[ui]: Compression enabled: 1 method(s)
2015.04.28 14:25:23 LOG6[ui]: Initializing service [minecraft]
2015.04.28 14:25:23 LOG6[ui]: Loading certificate from file: mine.pem
2015.04.28 14:25:23 LOG6[ui]: Loading key from file: mine.pem
2015.04.28 14:25:23 LOG4[ui]: Insecure file permissions on mine.pem
2015.04.28 14:25:23 LOG5[ui]: Configuration successful

Now with stunnel connected, you just have to add a server, but you connect to ‘localhost’. This will have you talking to the stunnel program which then talks to my server, which then redirects to the VM running Minecraft.

aa

Setup a server to ‘localhost’ to access stunnel

bb

Now you can connect to the stunnel server

No promises on how long it’ll be up though.

Titan City!

Titan City!

For normal clients... (shhhh!)

For normal clients… (shhhh!)

Hosting Minecraft as an experiment

So in the latest gamer news, everyone is freaking out about Valve allowing mod developers charge.  It’s amazing how quickly it’s fragmented the community in what was at 2 days before a Valve/GabeN worshiping reddit. (here/here/here/here and a rebuttal)

In the middle of all of this I saw this comment in passing:

Remember how that made me leave Mojang?

Remember how that made me leave Mojang?

So yeah, I never followed the whole Minecraft community thing, but apparently people were hosting servers, then asking users to pay for using mods, and even for using basic items.  And since most people who love Minecraft out there are kids, they were paying with their parents credit cards all over the place for server time, and server mods and whatnot, the parents would find out, and them blame Mojang over the entire thing.  So they banned paying servers (at least from what I understood).

So out of curiosity, since I’ve only really played single player, I thought I’d see how hard it is to run a Minecraft server.

First I’m going to create a Debian 7 VM on my ESXi server.  Nothing too fancy, I have an 8 core box with 8GB of ram, so I was thinking 2 vCPU’s and 384MB of ram, and a 4GB disk.  I mean it’s a simple game, how much can it need, right?

Turns out, it wants a LOT more.

So the install of the OS went pretty smooth, then I have to install Java, which is pretty simple:

apt-get install default-jdk

With that done, the next thing to do is download the server jar file from the download site, or for the purpose of my test, I’m using version 1.8.4.

When I went to run it however, I saw the recommended flags:

java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui

Ouch.  Yes this thing does expect 1GB of ram.  Ok, so I have to RAM and CPU to spare, so I went ahead and gave it 2GB (since I installed the x86 version of Debian..) and 4 vCPUs.

The next thing for me to do was to set it up on the internet, since I’m not in the office.  I have a VM out on the internet, with an OpenVPN back to my ESXi box for my email.  So without trashing my nat I could get xinetd do the dirty work with this simple entry:

 

root@VPS:/etc/xinetd.d# cat minecraft 
service minecraft
{
    disable         = no
    type            = UNLISTED
    socket_type     = stream
    protocol        = tcp
    user            = nobody
    wait            = no
    redirect        = 192.168.1.139 25565
    port            = 25565
}

Then restart xinetd like this:

 /etc/init.d/xinetd restart

Now with Minecraft running on my ESXi server, and my VPS now configured to forward traffic to the ESXi box over the OpenVPN connection I was all set to go!

And I was able to connect, and all was ‘good’.  But then checking the server…

htop on my Minecraft server

htop on my Minecraft server

545Mb of RAM!  And this is with one user!  And look @ the CPU.  Wow no kidding!

And then I noticed something else, the email performance went from OK to horrible.  I spent a lot of time playing with MTU’s receive and send buffers, and other ‘magic’ trying to get something working.  Since my ESXi server doesn’t have a direct internet connection (yuck) I’m in a shared office so it’s not only behind NAT, but I have a DLINK that I use behind their NAT.  And while the UDP protocol ‘works’, changing it to TCP gave me a 5x speed increase.

Very unexpected.

My own world..

My own world..

And not to forget, some helpful stuff for the server:

How do you shut down safely, from the console?

stop

What is the best way to run the server?

Probably behind screen. I started it from /etc/rc.local like this:

/usr/bin/screen -dmS minecraft /usr/local/minecraft/start.sh

start.sh is simply:

#!/bin/sh
cd /usr/local/minecraft/
java -Xmx1024M -Xms1024M -jar minecraft_server.jar nogui

How do I connect to the console?

screen -r minecraft

Remember in this case we gave the screen session a name so it’s easy to find.

How do I disconnect from the console

CONTROL+A+D

Why am I doing this?

I have no idea why. Honestly I find crafting in a game kind of tedious, but setting up a VPN, server and whatnot is more fun to me.

How about network performance?  Since it’s just me, I thought I should look inside the tunnel for a minute and see how big the capture file is:

# tcpdump -s 1520 -w 1.cap -n -i tun0 port 25565 & sleep 60;kill %1

This will run tcpdump for a minute on the default minecraft port, then after 60 seconds end the capture.

# ls -alh *.cap
-rw-r--r-- 1 root root 1.6M Apr 26 16:00 1.cap

Wow that was bigger than I thought. No wonder Minecraft people are always crying about latency! That translates to 213,33 Kbps or 0.21 Mbps.

Can it be compressed?

# gzip 1.cap
# ls -alh *.cap.gz
-rw-r--r-- 1 root root 680K Apr 26 16:00 1.cap.gz

Which then translates into 91,11 Kbps or 0.09 Mbps. Why people don’t compress their network stuff is beyond me, but then again what do I know?

I guess the next step would be to combine this with stunnel, which not only can encrypt the traffic, but compress it as well.

Maybe in time for the Chinese New Year?

KotOR_Cover

The best RPG since FFVII

So yeah I’ve got this extra copy of KOTOR kicking around and I should do some kind of giveaway or contest or something.  As a matter of fact looking at steam I have a few extra bobs and ends…. Any good suggestions?

Also for anyone who keeps up on current events and posts, you have exactly 12 hours left to partake in the humble bundle to get Star Wars KOTOR for ‘name your own price’…

humble bundle starwars

Name your own price…

 

Which means you could score it for as low as say, $1 USD right now.  Personally I wanted Dark Forces as I haven’t played that one in ages.  The rest I already have, so here we are.

While it’s a great game IMHO, it is prone to some weird crashes like the cut scenes trying to change to unsupported resolutions, hardware shadow issues, and the like.  But with it’s recent ports to both iOS, and Android this game will certainly be around for quite some time.

It’s a shame there won’t be a KOTOR3.

Fun with Kerbal Space Program

So right before Christmas there was a new drop of KSP (Kerbal Space Program), and I’ve been playing it on/off again.  One thing that I’ve been amazed about is all of the pluggins.  One that caught my eye was KSPSerialIO, and it’s project page.  It’s mainly focused on using an Arduino based display/control system connected via a serial port.

So I thought I’d make some minor modification so I could talk to it locally.

KSPSerialIO data collection

KSPSerialIO data collection

KSP is a Unity3D program, which is very modular, and using C# you can write pluggin DLLs.  However Unity doesn’t use the native .NET framework on Windows, instead it uses Mono.  So things like named pipes, and message queues are out of the question.  However I was able to find netmq, a zeromq port in C#. Using a special branch (until it’s been mainlined) It will even work with Unity 3D/Mono as they are dependent on being .NET 3.5 compatible (not 2.0 or 4.0!)

So what do I have now?  A server program that the KSP pluggin can communicate with.  Right now it’s just telemetry data being sent to a console.  The next step is to send some commands back (blink the lights or something useful), and then see if I can get it tied into some named pipe so that any program that can open a file can control the craft.

Of course this uses floating point, so I’m going to have to see about how to deal with a binary representation of a float in C# to anything else.

A few minor tips.  First is that KSP takes a long time to load, and when you are crashing out, or constantly having to re-load to insert new versions of your DLL, it’s a real pain to be waiting the 2-3 minutes for it to load.  I found this plugin, ActiveTextureManagement, which compresses the textures.  Now it took me a good 20 minutes for my machine to do this, but once it was done it cut load time to around a minute and a half!

Another great thing to have is a RAM disk (well that, fast CPU/GPU, and plenty of RAM), so I used Softperfect’s RAM Disk. Steam doesn’t mind you copying a game off of disk, and running it off another disk.  I found this combination of a RAM disk + compressing the textures got me to loading in under a minute!

Although once KSP is loaded it’s in memory so most people probably won’t benefit much from it, but if you are constantly loading/unloading it greatly helps! (it feels a bit like experimenting with config.sys/autoexec.bat of the old days, and the difference even smartdrv could make).

JS-DOS

Well ever since Oracle managed to screw up Java into a mass of uselessness, it looks like javascript is going to save the day.

Yes that javascript.

That emscripten compiler now can build DOSBox.  Thats right, you can run DOSBox in your browser.  For more infomation check out EMDOSBox.

It works great with Chrome.

DOOM!

DOOM!

Check out this site, which has many games all configured.

I’ll have to convert out all my old stuff, which is just as well since java is effectively dead.

NetHack 1.3d on the x68000

Ok, I know… why? But it’s more of a why not!

NetHack

NetHack

So I figured since I’ve had major issues trying to get DOOM to run, I’d try something bigger, like NetHack.  I figured its a good fit, it’s all ASCII based anyways, so how complicated can it be?

Actually it turned out to not be that complicated.  Thankfully having both run68’s source and NetHack source I was able to adapt enough of the system stuff to get it running. I decided to use this build of NetHack 1.3d that has been updated to compile with modern compilers, since the cross tools use GCC 4.6.2.  NetHack 1.3d synchronized PC hack, and UNIX based NetHack enough that I could start to build under MS-DOS, and then re-target it, as Human68k and MS-DOS share a lot of features (although Human68k has support for tasks, and shared memory.  It’s more like OS/2 although no memory protection… ).

I’ve gotten it to the point where you can save, load and quit.  Oddly enough the ANSI support in Human68k isn’t as good as ansicon so it actually runs better on run68.

So my next step will be to figure out more of the console controls on Human68k, and remove the ANSI support.

Ideally I’d love to figure out how to talk to the sound drivers on the x68000.  Add some music. Maybe sound effects, and graphics?

So for anyone who cares, my source directory, binaries and a xm6 disk image is all here. I’ve seen in the cvs tree on sourceforge that run68 has some support for BSD.  That’d be another interesting thing to add, common exe’s between windows/linux.  But console access first!

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

Netkeen

I’d never heard about this before, but a group reverse engineered Commander Keen, and re-built it as a network playable game!

Check it out at their site.

To build the source, you’ll need Borland C++ 5.0.2 and TASM 5.  Earlier versions may work but I haven’t tested.  The interesting thing with the networking is that they use the same code out of DOOM.

NetKeen

NetKeen

Advanced Gravis

My experience with the Gravis UltraSound

(guest post from Frank Sapone)

gravlogo

Sometime around 1992, Advanced Gravis teamed up with Forte/E-Tek to design a wavetable synthesis card around the ICS11614 IC. This card offered 32 channels, 14 channels @ 44khz and more channels would start dividing down in sound quality until you got to 32 channels at ~19khz. The mixing was done on-board which saved precious CPU cycles in the days of 286 and 386. The card originally advertised sound blaster support, but reading usenet posts from these days you can tell a lot of people were agitated that it was through a TSR, SBOS, that had hit or miss support and sometimes sounded better or worse than the FM because SBOS mixed it all into stereo.

I found out about these mythical cards a few years ago. A buddy went along with me to the local flea market out in the country-side of York, PA and we found a fellow who was trying to sell some P2-era laptops with USB wifi dongles and Windows XP loaded laptops for $100(!). I started talking with this gentleman and eventually convinced him to let me take a trip to his house and see what other stuff he may have. I took home a healthy share of various SB clones (mostly of the ESS variety, but a few Yamahas were in there as well) and some S3 Virge cards all for free. I built a computer with some of these parts, enough to play Doom and Heretic and started hitting up vogons and was reading some fanboism on the Gravis UltraSound cards. Where did I hear that name before? Oh, yes, in my mid-late 90s days of Doom I remember the setup.exe listed this card as an option and so did Duke3D and some other games I used to play quite frequently.

I did a lot of research on the card. Reading about how it used wavetable synthesis instead of FM. Basically, you can upload real MIDI-like patches to the cards RAM to get exceptional sound quality out of these older games and this also opens the window to creating your own patches if you wanted to tweak the sound of the songs.

Ultrasound Classic

Ultrasound Classic

Fast forward a couple of years later, I finally broke down and bought a GUS Classic v2.4 on ebay for $60. Unfortunately, it didn’t work out of the box. Failing to detect the card every single time, even if I removed everything from the computer and even disabled everything in the BIOS, including the FDC, Serial and Parallel ports. I got a refund, but a few days later I noticed some resistor had a broken leg and I soldered this and it started working! Immediately I loaded up Doom and the music sounded so much better than my SB or any of it’s clones.

Doom

Doom

Enjoying the sound, I started loading up other titles I played a lot back then that I remembered supporting this card: Descent, Heretic, Duke3D, Quake 1. I got a taste of some infamous Gravis issues when it came time to load up any Build engine title (Duke3D, Blood, SW, etc.) and Rise of the Triad. The music sounded great, but the digital voices had some weird clicks and somewhat static-like sound at the end of their samples. More research revealed that the GUS was known for this with those particular titles, and a ìsimpleî workaround is to get an SB card coexisting in the same box.

I amazingly got the SB and GUS living in the same machine after a few hours of fiddling around with some jumpers and tweaking autoexec.bat. Originally, I used one of those stereo to stereo cables. Running line out of the SB to the line in of the GUS, but the GUS’ mixer ìcolouredî the sound of the line in and mic in with entirely way too much bass. I made a cable that ran from line out of the SB16 to the CD-In of the GUS and it sounded excellent. I even found a way to keep my SB working in Win98SE this since it was known that the GUS had shitty support for the Win9x family (more on this later).

There are some shortcomings of the classic cards, the main being the Win9x drivers have no DirectSound support, only software emulation and usenet says that this had unpredictable results. Another annoying thing was no volume mixer(!), they expected you to hook this card up to powered speakers or ideally an amplifier. The v3.7 revision has a volume mixer but had problems with flip flopped stereo (whoops!) and v3.74 (the final GUS classic) fixed this problem. For those curious, for the most part revision versions don’t have bug fixes in their firmware, they just started finding ways to shrink the number of ICs on board. The exception to this was the v3.7 and v3.74 adding the volume mixer. GUS MAX v1.7 apparently had some sort of DMA or IRQ bug (forget these specifics) according to usenet, v1.8 fixed this problem and v2.1 is a v1.8 but lower component count and everything is now soldered on instead of sockets.

Other gotchas include: sound clicking and corruption on High-DMA, sometimes you can resolve this by setting 16-bit delay transactions but not all motherboards have this option and some just won’t work either way. Doubling up on the baseport, i.e. 220 also steals 320. Gravis claims you need to set the GUS and SB Emu IRQ to different values but they can be the same usually and have no problems. Same with the Playback and Recording DMA, unless you want full-duplex. If you’re just gaming it’s irrelevant.

Ultrasound MAX box

Ultrasound MAX box

At some point, I was hungry for more, wanting to try out the later GUS models like the MAX, ACE, and PnP. Particularly the GUS MAX because it included the volume mixer, had a special Crystal CODEC chip for 16-bit recording (was released late in GUS classics life as a daughterboard but it is very rare), the CODEC chip allowed for Windows Sound System, but the port is non-standard (gotcha!) and a special SBOS, MAXSBOS, takes advantage of the CODEC chip as well, and finally some CD-ROM support on board but I was uninterested in that since most of you know how much of a nightmare it is to get that shit working properly. Back to ebay, found a fellow selling a boxed GUS MAX for $100. I didn’t have the total cash on me at the time and it was buy-it-now. Considering the card was fairly hard to find, at least from what I researched at the time, I contacted the guy about paying half now and the other half in a few days. He agreed, and asked that I send it as a gift via paypal. Long story short, he never sent it, stopped replying to my emails and since it was sent as a ìgiftî I had no recourse through ebay or paypal. Learn that lesson when dealing online everyone! Always offer to pay a little extra for the processing fee if they claim this is why they want it set as a gift!

Bummed out, I found another classic, this time a v2.7 and well what do you know, this one doesn’t work either! Tried for 3 days all kinds of things. Cleaning the entire board off with electrical contact cleaner, reseating the contacts on the socketed chips, reflowing solder joints, replacing capacitors, but nothing ever brought it back to life. A year or two later, I found another GUS MAX for sale on ebay, purchased it immediately and it did not work. I tried it in 3 separate PCs and got no results. It always just said baseport UNAVAIALBLE FOR ULTRASOUND for whatever baseport I set it to. However, it wasn’t a total loss. On a whim, I took the GF1 IC from this MAX and placed it in the broken v2.7 classic and it made this card live again.

I setup daily searches for ebay to alert me immediately of any GUS developments appearing. If you’re new to the whole Gravis thing you’ll see theres a guy in Hungary who always has overpriced ones for sale and is unwilling to budge on price. If you check out his feedback you will see that he has been selling GUS cards of all flavours since at least 2010(!) almost monthly. Months and months went by with no MAX showing up and when one finally did it went for way more than I was willing to spend especially with the track record of 2 (almost 3) DOA cards that required soldering and intense cleaning to live again. If you’re planning to experiment with GUS cards be sure the card was tested recently, if you get the typical responses of not having an ISA PC around any more to test it, get the card cheaply and be certain that they will honour the return policy if it does not work.

MAX 2.1 board

MAX 2.1 board

Finally, after a couple of years I did some networking and found some fellow demosceners with GUS MAXes for the price of shipping. I’m waiting on my v2.1, but received two v1.8s. The first one did not work at all, would never detect properly. Tried the usual suspects of cleaning it up, reseating, rocking the caps a little back and forth to make sure everything was making contact, etc. The second one, actually detected the card saying UNAVAIALBLE FOR ULTRASOUND yet again, but this time after I disabled my FDC, Serial and Parallel ports it worked! Excited, I loaded up the usual games and all worked great and the CODEC chip’s mixer program worked properly. Now, I was read to add the SB16 back in but now no matter what base port I would select it always complained it was unavailable, yet again! At some point I got it working sort of but then it wouldn’t let me set any DMA properly in the setup utility. Enough of this nonsense, I thought, I have a few socket 7 towers not being used.

I popped it in to a P1 166MHZ living by itself. Now we can try out that special MAXSBOS!… and unfortunately it doesn’t sound better than SBOS, in fact it sounds worse! And yes, I tried a separate IRQ for SB emulation and low-DMA, high-DMA, making sure the CD-ROM baseport doesn’t conflict with GUS’ baseport and I have 1MB RAM onboard that is 70ns.

At this point I should stop and mention a few other gotchas on these MAX cards. The GUS ìdoublesî up on the baseport. i.e. if you set 220 it will also grab 320. The CD-ROM baseport on these cards will be set, even if you disable the rest of the CD-ROM interface. So make sure you don’t have the CD-ROM set to the same or else it will always complain it’s unavailable for ultrasound in the setup utility. And yes, you just have to remove the IRQ and DMA jumpers on the card and put the jumper on the CD-ROM disable. Panasonic enable jumper appears to make no difference regards to enabling parts of the CD-ROM circuit, unless of course you planned on using the CD-ROM interface. I’m assuming most of you out there won’t be. You also need 70ns rated (or better) 256kx4 chip. The MAX has 512kb RAM on board but you NEED 1MB on any GUS card to get great results or live with missing instruments and all kinds of funnies happening to you. The CODEC also uses some baseport, but this is software selectable so you should have no serious problem there.

Now I go on to try this bad boy out in Win98SE with the special DirectSound enabled drivers. When you install the Gravis GF1 (non PnP) series drivers it will tell you that you have to install the card as a non-PnP device and restart, then manually set the DMA, IRQ, Baseport in the advanced properties for the card. This is fairly trivial if you’re used to DOS, but for newbies just keep it in mind. Another gotcha here is that the drivers will blank out your SET ULTRASND= and SET ULTRA16(for MAX users)= in your autoexec.bat after the reboot so write these values down. I believe this was done on purpose since most people auto loaded SBOS or MEGAEM (the other SB emulator they had) and this conflicts with Windows big time. The drivers do work and the sound quality is fine, but the biggest issue I’ve had is that sndvol32.exe never loads now. You can not adjust the volume or disable the mic-in and line-in and you really should as every card I’ve owned the recording inputs pick up a lot of interference. Moving the mouse and the HDD just all come through your speakers. I haven’t tried Windows 95 yet, maybe the mixer works okay there? At some point I’ll post an update and let internet-land know.

Gravis Ultrasound ACE

Gravis Ultrasound ACE

SoundBuddy 1.0 prototype

SoundBuddy 1.0 prototype

I don’t own these cards, but will mention them for clarity. The GUS ACE (internally referred to as the Sound Buddy) is simply a GUS Classic without the recording capabilities or the gameport. It was meant to be a supplement to a sound blaster or similar clone. You simply run the line out of this card to your line in of your SB16 (or maybe it’s vice-versa? Correct me if need be). You have to update your ultrinit to the last known version because there’s a bug in the official drivers(!) that does not disable the nonexistant gameport and it will steal your other sound cards gameport cause conflicts. For those who need the fix, GUS0047.ZIP. At one point, Gravis struck a deal with AMD to make an enhanced chip, called the InterWave which had GUS support and allows 8MB of samples (16MB apparently if you solder some stuff, but I have yet to see any pictures or even a textfile on this hack). Pouet.net sceners say that it has problems with long loops so some demos may sound wrong. IWSBOS is based from MAXSBOS so I assume it probably sounds just as bad compared to the final revision of SBOS. Usenet posts of users crying that the Win9x drivers are awful too, but again, I don’t own this card so I’m only just passing on what I have heard. Feel free to prove me wrong in the comments.

ViperMAX board

ViperMAX board

Other weirdo cards included the Synergy ViperMAX, which is basically a GUS with an ESS chip for SB compatibility. In theory, this means you should get decent Win9x support through the ESS. These cards are kind of rare now. I have yet to see one appear in the US. But, fellow Pouet.net users have found them across the EU so maybe they are common there. There were some other OEM variants, most similar in design to the ViperMAX. Check out Wikipedia for information on those if you really must know more.

My final thoughts on this long (still not quite yet over) journey is that the GUS Classic is a fun card for breathing some life into the soundtracks of older id and apogee titles with a few silly hang ups on getting it to work initially. The MAX did not live up to its mythical hype with the mixer, special CODEC chip, and Win9x drivers. These cards appear to be very delicate because I have had 3 out of 5 cards DOA and required fooling around to get them to work again. Even though 2 MAX cards still do not work no matter what I’ve tried. Expect to buy more than one to get a working card. The ideal setup would be to get a GUS Classic or ACE and get that to coexist with an SB or compatible clone. I can’t comment on the ViperMAX as I have not located one yet.

Gravis Ultrasound MAX 2.3 prototype

Gravis Ultrasound MAX 2.3 prototype

As much frustration these cards have brought me, they still sound nice when they work! But, it really does make a lot of sense why they are rare today. It is quite aggravating to get one working properly!

All of this would be useless without some samples of what a GUS sounds like, all samples were recorded at 44,100Hz, …

DOOM e1m1


DOOM e2m6


DOOM e2m8


DOOM e3m1


DOOM e3m2