So since I was looking at the Doom stuff, I thought I’d try to track down the WinG version of Doom, and luckily someone pack ratted away two versions! Needless to say the older one didn’t work for me, but the last one, the April 13th, 1995 build, worked just great!
Even on Windows 7 x86_64, sp1!
So how much of a chore was this to run back in 1995, before Windows 95?
Well to start WinDoom requires a display capable of at least 256 colors. I thought I’d use Qemu for this, but this proved to be… exceptionally difficult to locate a satisfactory display driver. I know lots of people point to the SVGA.EXE update from Microsoft, that uses VESA extensions to drive the video. Oh sure it sounds great but this is what I got:
Ok, so you say, there is this great patch to enable better VESA support right?
Yeah. I also hunted down various cirrus drivers for the specifically emulated chip (I checked the source) and they were all consistently defective. So I tried using a lower chip driver from HP and amazingly the 640x480x16MM colors works! (well, works ‘enough’).
It’s the GD5430 v1.25f, 640x480x16.8M
The next thing is that Doom in both MS-DOS and Windows are full 32bit executables. On the MS-DOS side, it relies on the DOS4G/W extender. For Windows, it relies on the then new Win32 standard, and Windoom was written to conform to the Win32s standard, meaning with an addon it can run on Windows 3.1, Windows 95, And Windows NT. I just fished around the internet, and scored a copy of Win32s 1.25b . I just remember this being a somewhat stable version.
Win32s installs pretty smooth, (as long as you remember the share.exe). Now we just need the WinG runtime to be installed. WinG was Microsoft’s first real attempt at high speed gaming video under Windows. From what I understand it kind of went down because it was ‘too difficult’, and buying DirectX seemed to be a better fit.
Another thing I’ve found is that if you change the midi mapper from the default “Ad Lib” to “Ad Lib general”, you can at least get the midi working in Doom.
Once WinG is installed, then it’ll want to do some blit tests…
And after that, we can even bump it up to glorious 640×400, something the initial MS-DOS version couldn’t do easily as VESA wasn’t a big standard with INSTALLED cards at the time, and it’d require lots of work from the iD team, where the move to Windows pushed all the peripheral development to the Vendors to work around Microsoft. Even to this day, it’s still a big deal with video and audio.
One thing that is cool about Qemu is that at compile time, you can put in adlib & soundblaster cards to give the ‘full’ Windows 3.1 multimedia experience. There is also GUS (Gravis Ultra Sound) support
in Qemu, but I’ve never played with it..
With all of that out of the way, WinDoom will launch.
Then it’ll throw an error, because Windows 3.1 doesn’t have the same video backend as Windows NT 3.5 (and higher), hit ok and then …
Sadly on Windows 3.1 the sound effects do not seem to work, but overall it’s a GREAT little port, mostly because as it comes up on 16 years old, it still works, and with sound. I wish other OS’s could give this kind of support for legacy applications, even ones that had such a brief window of support.
Anyone crazy enough to even think of playing along can download the blob of software I used to get this going here.
I should also add if you want sound effects to work on WinDOOM you really should install the Video for Windows Runtime, and it’ll work… poorly on Qemu/SoundBlaster 16, but it does work!
I never used Desqview back in the day, as I didn’t have a good enough computer. A 286 with 1mb of ram just wasn’t enough to push the thing. And by the time I did get a 386, OS/2 2.1 was all the rage. But in that time between OS/2 2.x and the release of the 80386 CPU there was all kinds of programs to take advantage of the 386’s v86 mode.
Desqview X really is different in that it not only incorporates the desqview multitasking, but it also supports the X11 protocol found in the UNIX world. Sounds cool right? A friend wanted to run it, so he actually dug out a web page, chsoft.com with all the bits.
The first stumbling block is that Desqview requires that you use the memory manager QUEMM, which the majority of emulators we tried couldn’t work with it. Qemu 0.14.0 however proved itself up to the task, as long as you didn’t let it do the aggressive optimization, just let it install, and reboot.
Installing DesqviewX was pretty straightforward, the only catch was the video. VGA doesn’t work but the SVGA modes work fine. I just used the 800x600x256 mode.
With that out of the road, the next thing needed was a good mouse driver. For some reason the majority of the mouse drivers I tried just wouldn’t work with desqview, until I tried ctmouse.
Naturally for the whole X11 experence you need networking. The tcpip package on the desqview webpage uses some old netware thing with a ne2000 driver that is hard coded to 0x300 irq 4. Which won’t work in any machine I know since everyone has at least one com port. So I had to take the lsl & ne2000 parts from my Netware 3.12 client. But doing so revealed that the lsl wouldn’t run because of a lsl buffer pool error. And of course to work with slirp you need to be running ethernet_II instead of 802.3 …
So you’ll need a net.cfg like this:
buffers 4 1504
max stacks 4
link driver ne2000
Naturally you’ll need to change the source to Qemu if you have your own build to use IRQ 3 instead of 9 (it’s in hw/pc.c), or use one of my binaries. It’ll configure via bootp and at the end you should be able to ping 10.0.2.2
On OS X has qemu listen on 6001 for X11 sessions, then redirect them into the VM on it’s X11 port. So I could then easily run xeyes like this:
xeyes -display 127.0.0.1:1
And the output appears inside of Desqview X. Likewise, removing the session security, and allowing remote connections in OS X’s X11 widget, then allowed me to send xeyes from Desqview to my mac like this:
xeyes.exe -display 10.0.2.2:0
And exeyes pops up on OS X as running from the Desqview VM.
I don’t know if it’s terribly useful, but I thought someone may get a kick that Desqview X can run on Qemu 0.14.0 In this day & age though you can get easier versions of X11….
So I was stumbling around the internet, and wondered if there was any good SEGA 32x emulators, as I recently found the Jaguar port of DOOM, and there is some mention of MARS stuff (32x) buried in there.
A split disassembly for Sonic 1 converted to 32x format has been released.
With that, you can edit anything in Sonic 1 to be how you want. It is very possible to recreate Sonic Mars with it, but that would take a lot of time and effort. And there’s no guarantee you’ll be able to play it on your 32x system.
Whoa, that’s pretty amazing! So with a little google-fu I find the mentioned split disassembly, on sonicretro.org
This is pretty amazing stuff, so it also turns out the emulator in question to use is Kega Fusion, which does Genesis, Sega CD and of course 32x.
And the best part is the sonic disassembly includes the tools that you need to gen your own sonic rom! simply extract the source, and run the ‘build.bat’ and it’ll assemble the SH2 code, bind it to a blob, assemble the m68k code, and strap it all into a ROM. Honestly you’d be hard pressed to even tell if there any difference between this, and the original ROM. Other then it won’t run on a standard Genesis (Megadrive).
I know that is confusing, but the 1.0 version of OS X was released in 1999. I should have saved the receipt, but I still have the box.
It does go without saying that OS X changed apple, as it FINALLY integrated the NeXTSTEP OS onto the consumer level machines, and propelled Apple to the #1 spot for the Unix market. Yeah take a step back with me here, and look at the market like this. Apple ships more computers in any given year then HP/SUN(Oracle)/IBM ship that come preloaded with a UNIX. Not to mention Apple also loads their UNIX is the core of the iPhone, iPad, and some of the iPods. Wow imagine that, Apple brought UNIX everywhere. And made it so buried under a UI 99% of the users don’t even know it’s there.
That’s pretty snazzy, isn’t it?
So 10 years ago today, Apple finally shipped 10.0.0 . And let me tell you it was rough around the edges. I had an iMac and at the time I LOVED it. In between the 1.0 & the 10.0 I had bought a G4 and was disappointed that 1.0 wouldn’t run on my beloved G4. I had no intention of running OS 9, but that’s all it could run. So in those fleeting months I managed to run windows 95 on SoftPC (SLOW!) and even got my hands dirty on OpenBSD for the PowerPC.
OS X really made a splash with usable applications that shipped with the OS. I know the nerds hate iTunes, but damn, it’s something a user can use. Same with Mail, and even Microsoft Internet Explorer.
So enough with the reminiscing, I’m sure you want to see it run under some kind of emulation, right?
Well the best (if not only) emulator for running PowerPC Macintosh stuff is PearPC. And version 0.4 is about as good as it gets. Mostly because of Stefan Weyergraf’s untimely death.
Which is sad, however I did find with a little playing around, 10.0.0 can boot single user mode from the CD.
One thing was for sure, at the time, 10.0.0 was so.. rough around the edges Apple did give everyone a free copy of 10.1 . And that version certainly better then 10.0! And it runs on PearPC!
The boot screen, notice the old style mac.
And the progress bar, just like NeXTSTEP. The more things change the more they stay the same..
And welcome to the desktop.
Well since it does run in single user mode, maybe it could be possible to manually place a 10.0 dump on the disk, but that may take a bunch of time… So for now enjoy 10.1!
So for a test I needed an email server, so I thought I’d setup an Exchange server quickly. Exchange 5.5 runs best on NT 4.0 so I’m going to install it on Qemu 0.14.0. Along the way I ran into a few little gotcha’s so I thought I’d update on how to do this.
qemu.exe -L pc-bios -cpu pentium -hda nt4-server.qcow2 -net nic,model=pcnet -net user -cdrom nt4server.iso -boot d
As you can see on NT 4.0 you now have to set the CPU level. This needs to be done going forward with NT 4.0 as again it’s too old to detect newer CPU’s and gets confused. Also I’d recommend selecting the ‘standard pc’ HAL. Oh sure it may look all nice with a MPS/Uniprocessor, but I’ve found it noticeably slower.
The default cirrus logic driver works at 16bit depths at 800×600 well enough (The hardware mouse pointer doesn’t work so you’ll need to turn on a custom pointer). Another thing is my choice of the AMD PCNet NIC, is that it’s the same that VMWare uses, so you can always run these disks under VMWare if need be (as long as VMWare has IDE disk support, and you convert the disk first!!).
Ok that basically covers an IDE install, but let’s get onto SCSI. Qemu now (it’s been in there for a while..) emulates a SCSI controller, the PCI 53c895a adapter. And I’ve found that you can get it to work with Windows NT 4.0! First you’ll need a driver diskette & BIOS both found at LSI’s webpage. The NT driver is nt896.zip if you’ve gotten the correct one.
Now that I’m going to install exchange, the best practice I’ve found for NT is something like this:
OS DISK 4GB
SWAP DISK 256MB
MAIL STORE 8GB
So that’s a bunch of SCSI disks, right? I guess I could build a stripped set but that’d be kind of crazy… so here is how I’m going to do it:
And if it’s done right, you’ll notice that now the SCSI bios will be initializing as seen below with a bunch of disks…
Once your NT CD starts to boot up, you’ll see a blue screen like this. It’s important that you hit both F5 and F6 over and over to tell the setup program that you want a custom HAL, along with an install time SCSI driver.
And as I did above, I’ll first select the ‘standard pc’ HAL.
Then You can tell it to load the LSI / Symbios scsi driver, and install will roll through as normal. Since this is going to be an Exchange server, I’m also going to make it a PDC on it’s own domain, since Exchange requires DC functionality.
And from there it is a somewhat normal NT install. I did leave out the messaging stuff, because it’s that ancient “Microsoft Mail” stuff, and it’s somewhat crippled at that.
For the fun of it, if you load 256 colors, you’ll wind up with this:
And all the icons will be blank squares. Not terribly useful. Maybe for low displays the regular VGA would be best…. But again with 16bit and custom pointers (much like an old MIPS issue) it will work enough. 1024x768x16million colors at 43Hz (interlaced) works pretty good too!
Next I fired up the disktool, (diskman) and slapped down a bunch of partitions… I let the swap formatted FAT as I don’t care about it’s crash to crash integrity, but the rest can be NTFS. Also from a boot limitation the first disk is only 1GB out of it’s 4… I don’t know if that matters.
Then into the system tool to move the swap to the ‘s’ drive.
I don’t know if the actual setup of Exchange is all that … interesting so I’ll just leave it to your imagination.
Years ago Netware sold these 4.1 dev kits on the cheap, and I picked one up in College. Back then the selling point was that along with Watcom you could actually run Netware 4.1 along with OS/2, and do all the dev loading on the same machine!
What a time saver, not to mention you could simulate a LAN on the same PC as each MS-DOS VM could have it’s own virtual NIC and each VM could login independently.
Anyways, I thought I’d go ahead and give this thing a shot, since I haven’t run this in a while, so I installed OS/2 2.11 on Qemu 0.14.0, and … got this.
PNW0162: An internal error has occurred. The program cannot initialize the GDT information.
Which of course is the Global Descriptor Table, and I don’t know why it can’t play with it… Qemu limitation? OS/2?
Anyways afterwards, I get this.
And you thought Windows NT blue screen of death was impossible to read…