Yearly Archives: 2014

The complete archive for DOOM for the 3DO is on GitHub!

Posted on by
Reply

Link to the archive is here.

It’s a sizable download, 287MB, the majority being the ‘movies’ and ‘music’ directory.

 

The complete archive for DOOM for the 3DO
Yes, this is the infamous port of DOOM for the 3DO. Firstly, this was the product of ten intense weeks of work due to the fact that I was misled about the state of the port when I was offered the project. I was told that there was a version in existance with new levels, weapons and features and it only needed “polishing” and optimization to hit the market. After numerous requests for this version, I found out that there was no such thing and that Art Data Interactive was under the false impression that all anyone needed to do to port a game from one platform to another was just to compile the code and adding weapons was as simple as dropping in the art.

Uh… No…

My friends at 3DO were begging for DOOM to be on their platform and with christmas 1995 coming soon (I took this job in August of 1995, with a mid October golden master date), I literally lived in my office, only taking breaks to take a nap and got this port completed.

Shortcuts made…
I had no time to port the music driver, so I had a band that Art Data hired to redo the music so all I needed to do is call a streaming audio function to play the music. This turned out to be an excellent call because while the graphics were lackluster, the music got rave reviews.

3DO’s operating system was designed around running an app and purging, there was numerous bugs caused by memory leaks. So when I wanted to load the Logicware and id software logos on startup, the 3DO leaked the memory so to solve that, I created two apps, one to draw the 3do logo and the other to show the logicware logo. After they executed, they were purged from memory and the main game could run without loss of memory.

There was a Electronic Arts logo movie in the data, because there was a time that EA was going to be distributing the game, however the deal fell through.

The verticle walls were drawn with strips using the cell engine. However, the cell engine can’t handle 3D perspective so the floors and ceilings were drawn with software rendering. I simply ran out of time to translate the code to use the cell engine because the implementation I had caused texture tearing.

I had to write my own string.h ANSI C library because the one 3DO supplied with their compiler had bugs! string.h??? How can you screw that up!?!?! They did! I spent a day writing all of the functions I needed in ARM 6 assembly.

This game used Burgerlib 2. My first “C” version of Burgerlib because Burgerlib was originally written in 65816 for the SNES and the Apple IIgs. If you check out Burgerlib 5 (The current version, also on github), you’d notice that some code is still in use.

I hope that everyone who looks at this code, learns something from it, and I’d be happy to answer questions about the hell I went through to make this game. I only wished I had more time to actually polish this back in 1995 so instead of being the worst port of DOOM, it would have been the best one.

And one more thing…
The intellectual property of DOOM is the exclusive property of ZeniMax. No transfer of the intellectual property of DOOM or any transfer of the ownership of the sounds, art or other game assets are given nor implied. If anyone wishes to release a version of DOOM 3DO commercially, contact ZeniMax for a license.

The source code… Go for it.

Rebecca Ann Heineman

Olde Skuul

Seattle, WA

Run68 Human-68k emulator

Posted on by
Reply

I found this one by accident, but it’s more like DOSBox in that it runs 68000 executables with an emulated processor and emulated OS.  No SHARP ROMs or HumanOS diskettes needed.  It’s strictly text mode, but it’s enough to run executables produced by GCC.

Hello!

Hello!

The project is over on sourceforge, and unlike any other x68000 project this one is GPL’d.  The source code is remarkably tiny so I’d say for anyone looking for a way to sneak some C into something this may be an interesting ‘door’..

PCem is getting a dynamic recompiler!

Posted on by
20

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?

New build of Shoebill available.

Posted on by
5

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

Text mode login for A/UX

I guess the real test will be to see if it makes it through the night.

(edit)

And yes it did!

5:40pm up 1 day, 2 users, load average: 0.00 0.00 0.00

I’ll let it run a little longer but this is like a new record.  Although at the same time, I’m not hammering the poor thing.

# netstat -ni
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
ae0 1500 10.0.2 10.0.2.15 4232 0 3551 0 0
lo0 1536 127 127.0.0.1 157 0 157 0 0

Cross compiling to the Sharp x68000

Posted on by
4

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

Hello World cross compiled from Windows to the x68000

In the script for CodeBlocks, changing

oc_x = _T(“human68k-objcopy -O xfile $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).X”);

to

oc_x = _T(“human68k-objcopy -v -O xfile $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_FILE).X”);

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.

All my work on this is here.

WindrvXM settings

WindrvXM settings

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.

Visual Studio Community 2013 with Update 4

Posted on by
4
Visual Studio Community 2013 update 4

Free stuff!

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….)

So it was interesting that Microsoft released Visual Studio Community & Express as part of their Connect (); event.  It’s a whopper of a download though, a 6GB iso file.

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.

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

Posted on by
Reply

(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

Posted on by
4
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.