Wolfenstein 3D for DOS/4GW update

If you remember a while back, I had found the ‘missing link’ of Wolfenstein to Wolfenstein SDL, Wolf4GW.  Well Tobias has cleaned it up somewhat, and now it compiles on the latest builds of OpenWatcom 2.0c!

The first thing you’ll notice if you try to compile it, is that now it’s a single source file, that includes all the other modules.  And it compiles FAST, for me 1 second fast.

From the changes:

  • Compiles with OpenWatcom v2.
  • Keys (for Run, Shot…) are shown.
  • Hang with optimization is fixed.
  • Missing Spear of Destiny SignonScreen added.
  • Inter-procedural optimization (unity build).
  • External assembler routines re-implemented in C.
  • Better interrupt enablement /disablement.
  • Dead Code removed or #ifdefined.

So, if you want to Wolf3d, or SPOD, I’d check out Tobias’s Wolf4GW if you have a 32bit capable machine.  The maps load instantly, and it just feels all around much more smoother than the old 8086 code.

Cross compiling to i386 Linux ELF from OS X

This isn’t terribly useful for 99.9% of the people out there but I needed to do something creative on an F5.  Luckily they run a somewhat sane version of Linux.

Unfortunately I am stuck on Windows 10 right now, so installing a matching Linux distro is out of the question.  So on my OS X box, I thought I’d just build a cross compiler.  Going back to my DJGPP cross compiler, I thought I’d stick with binutils 2.9.1 and gcc 2.95.3, since they worked so well before.

Plus to flesh it out, you’ll want libc, libg++, and the appropriate Linux includes.  I took all of these from Slackware 3.3 since it’s from around that era.

So on the plus side this cross compiler + library set , will crank out static ELF executables, which makes running things on alien platforms all the better.

On the realistic side, I doubt anyone will need it, but here it is.

Clang didn’t want to build anything this old, but luckily that backported GCC-4.2 has no issues.

PCem is getting a dynamic recompiler!

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?

PCem

PCem v9

PCem v9

From the main page:

PCem v9 released. Changes from v8.1 :

  • New machines – IBM PCjr
  • New graphics cards – Diamond Stealth 3D 2000 (S3 ViRGE/325), S3 ViRGE/DX
  • New sound cards – Innovation SSI-2001 (using ReSID-FP)
  • CPU fixes – Windows NT now works, OS/2 2.0+ works better
  • Fixed issue with port 3DA when in blanking, DOS 6.2/V now works
  • Re-written PIT emulation
  • IRQs 8-15 now handled correctly, Civilization no longer hangs
  • Fixed vertical axis on Amstrad mouse
  • Serial fixes – fixes mouse issues on Win 3.x and OS/2
  • New Windows keyboard code – should work better with international keyboards
  • Changes to keyboard emulation – should fix stuck keys
  • Some CD-ROM fixes
  • Joystick emulation
  • Preliminary Linux port

Thanks to HalfMinute, SA1988 and Battler for contributions towards this release.

Very excellent!

OpenWatcom v2

I know what you are thinking, wouldn’t it be great if you could create MS-DOS executables directly from a Win64 desktop with no MS-DOS needed?

Well, I just found out about this unofficial Open Watcom v2 project that targets the usual suspects, allows you to compile from Win64!

Hello World!

Hello World!

Some of the features of this fork include:

  • New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
  • Code generator properly initialize pointers by DLL symbol addresses
  • DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
  • OW is ported to 64-bit hosts (WIN64, Linux X64)
  • Librarian support X64 CPU object modules and libraries
  • RDOS 32-bit C run-time compact memory model libraries are fixed
  • Resource compiler and Resource editors support WIN64 executables
  • OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or configuration
  • Broken C++ compiler pre-compiled header template support is fixed
  • Many C++ compiler crashes are fixed
  • Debugger has no length limit for any used environment variable

Binaries are available on sourceforge.

So how does it fare?  I thought I’d take the old Wolf4GW, and compile it with this toolset.  The first hurdle I hit was this fun feature:

  • The C++ compiler now treats warning W737, implicit conversion of pointers to integral types of same size, as an error.

Which is an integral part of wl_menu.cpp .  So this was somewhat problematic, until I just commented out that block, and while I was expecting no working keyboard, I’m able to play, and load/save games…. Even the boss key works.

Wolf4GW

Wolf4GW

So with the W737 taken care of, I have to say this thing compiles FAST.  Incredibly FAST.  If for some reason you have to build 16bit or 32bit anything, you should look at a 64bit tool chain, well assuming you have a 64bit computer by now.

If anyone want’s to build their own Wolf4GW with the newer OpenWatcom, my source drop is here.

MS-DOS Player updates

Poorly translated from TAKEDA toshiya’s blog..


2014/4/15
I has integrated source of i386 and i286 edition edition. 
In addition, in the i286 version, I added support for int 10h/16h. equivalent to 0.149 MAME, I was replaced with a 0.152 equivalent MAME core i386 i286 core. However, the i386 core, I have omit the TLB around.

Which is very cool, although I wasn’t sure about the MAME source code being open to other projects…?  I tried to contact the i86/i386 author vlinde but he then pulled his contact page.  I wanted to use i386 for something of my own, but the whole “Redistributions may not be sold, nor may they be used in a commercial product or activity.” really puts the damper on it.

I was able to get some simple XMS test program to run, but nothing of any substance.  No DOS4G/W or anything like that.  But if you re-build it specifying MS-DOS version 5.0, some of the MS-DOS utils and even command.com work!

The weird issue I had was running out of conventional RAM, because this program gives you nearly 1MB of conventional RAM… I was surprised, as I wasn’t expecting that much!

Virtual x86

I got passed a link to this new emulator, Virtual x86, a complete PC emulator in javascript.  It is in it’s early phases, but it seems to emulate text mode and a single diskette or ISO ok.  It can boot Linux or OpenBSD, but not any MS-DOS protected mode software I tried.  And graphics don’t work…

But it’s 100% javascript!  And open in that you can download the source (tarball,github) under a BSD style license!  So naturally I made my own mirror

Dungeon on Virtual x86

Dungeon on Virtual x86

I have to say, it’s really cool!

 

PCem v8 released!

New features include:

  • New machines – SiS496/497, 430VX
  • WinChip emulation (including MMX emulation)
  • New graphics cards – S3 Trio64, Trident TGUI9440AGi, ATI VGA Edge-16, ATI VGA Charger, OAK OTI-067, ATI Mach64
  • New sound cards – Adlib Gold, Windows Sound System, SB AWE32
  • Improved GUS emulation
  • MPU-401 emulation (UART mode only) on SB16 and AWE32
  • Fixed DMA bug, floppy drives work properly in Windows 3.x
  • Fixed bug in FXAM – fixes Wolf 3D, Dogz, some other stuff as well
  • Other FPU fixes
  • Fixed serial bugs, mouse no longer disappears in Windows 9x hardware detection
  • Major reorganisation of CPU emulation
  • Direct3D output mode
  • Fullscreen mode
  • Various internal changes

pretty cool!

You can find the source code, binaries, and some ROMs on Tom’s Page.  I’ve got to say I really like PCem, it gives the full (slow and painful, like the real thing) retro PC experience!

AmiDevCpp

Antoni sent me a link to this project, AmiDevCpp. It is a nice little wrapped up IDE for cross compiling applications for the following platforms:

  • AmigaOS (m68k)
  • AmigaOS4 (PPC)
  • MorphOS(PPC)
  • AROS (i386, ppc and x86_64).

Naturally it doesn’t work correctly on Wine.. .Oh well, but for you Windows users out there that haven’t installed Cygwin this is an easy way to cross build stuff for the ancient Amiga platform.

Apparently he was able to rebulid the infamous aclock using this cross compiler…

Everyone mentioned this yesterday…

275,000 transistors of awesomeness!

275,000 transistors of awesomeness!

Kind of interesting is that Linux has finally dropped support for the 80386 microprocessor.

The 386 is perhaps one of the top ten things that has changed our world, along with 4.3BSD .

No, really!

The 386 microprocessor was the first CPU by Intel that was single sourced.  This means that Intel, and only Intel would fabricate the 386 processor.  Before this time, Intel had licensed their processors to other companies (Siemens, AMD, Harris, IBM etc) So that if there was some kind of production issue at Intel other companies could manufacture 8086,80186s and 80286s.  However this all changed with the 386, as Intel stopped renewing these agreements with other companies (IBM had a license that included the 386, although they were slow in making their own), so now Intel was in charge of its destiny.

The 386 brought three major changes onto the then champion processor the 286.  The first being a 32bit processor where it could handle larger data sizes than the 16bit 286 & 8086.  The 386 also included a larger memory model, the so called “flat mode” where it could directly address 4GB of combined code+data, while the 286 could address 1GB it was limited to 64kb segments.  Lastly the 386 introduced hardware virtualization, the “v86” mode where the 386 could emulate multiple 8086 processors, allowing people to have multiple ‘virtual machines’ on the desktop.

At the time the only consumer grade 32bit processor was the hybrid 32/16 68000 from Motorola.  The 68000 could work with 32bit data, but it was restricted to a 16bit data bus, and only could address 24bits of RAM (16 megabytes).  The 68000 however did not include any kind of memory management unit (MMU) making things like porting UNIX improbable (The SUN-1 workstation included a custom MMU).  Because of the open nature of the IBM PC, clone manufacturers were able to leapfrog IBM, and release 386 based machines before IBM got around to releasing the PS/2 model 80.  It was this that effectively brought 32bit computing to the masses with the Compaq Deskpro.

Compaq's 386 Deskpro

Compaq’s 386 Deskpro

The 8086 processor could address 1MB of RAM, with its 20bit address bus.  However to preserve some compatibility with the 8080 processor it was decided that the 8086 (and 8088) CPUs would work with 64kb segments.  This became a massive headache for years as you could not easily contain more than 64kb of data at a time as you would exceed a segment.  Compiler vendors made some workarounds via the large & huge memory models, but porting a program from a 32bit minicomputer (VAX) would prove difficult if it addressed large amounts of memory, and would require a rewrite.  The 286 increased the addressable memory to 16MB, and included a limited MMU, which enabled an address space of 1GB.  However the 286 was flawed in that again the 286 could only work in 64kb segments, and in order to work with large amounts of memory, the processor had to be shifted to protected mode.  However in protected mode, you couldn’t (easily) switch back to real mode.  This needlessly delayed the adoption of protected mode environments, as you would then lose access to the sizable, and growing, library of MS-DOS programs.  Although workarounds were in place for things like OS/2 and DOS Extenders, they were hacks and couldn’t fix the fundamental 64kb issue.  The 386 built upon the 286’s foundation and included a flat memory model where it could address all 4GB of addressable memory in a single segment.  This meant that you could now use massive amounts of data on a consumer grade machine.

For a while the only 32bit environments were Xenix and MS-DOS via DOS Extenders this proved to be a huge liability and effectively stagnated the industry for a long while.  The 286 was a massive determent.  Making things worse was IBMs insistence that the new OS/2 be able to run on the 286, while Microsoft wanted to create OS/2 to run on the 386, and ignore the IBM AT all together. Basically the 286 was created with the assumption that the 8086 wouldn’t be anywhere near as popular as it was.

With the ability to address large amounts of RAM programs only seen on minicomputers and mainframes were finding their way to the microcomputer such as AutoCAD, Oracle, Links 386 Pro, and of course many in house programs where departments now wouldn’t have to pay to run on then ‘big’ minicomputers.  Combined with the 386’s MMU it was also possible to use more memory than was available in the computer, also known as virtual memory.  The 386 made this transparent to the program, only the 32bit environment needed to handle the swapping.

Finally the last big feature of the 386 was v86 mode.  V86 mode in short is a hardware virtualization platform where the 386 can emulate multiple 8086 processors in hardware.  Each virtual machine can get its own isolated memory space, virtual hardware.  Effectively 8086 programs (such as MS-DOS) can run unaltered inside of v86 mode, with the added benefit of being able to run more than one at a time. Windows/386 lead the charge into this new world of virtual machines for the end user.  Before this point, the only wide scale virtual machine environment was the IBM 370 mainframe which could also create virtual mainframes within itself allowing groups to share a single mainframe, but run incompatible software platforms all at the same time.

Thanks to its capabilities the 386 also brought UNIX to the end user.  First with Xenix, then Microport SYSV, and with the removal of AT&T code BSD was able to be released on the 386 via 386 BSD (and later BSDi’s BSD/OS).  During this timeframe the research OS, Minix was extended by Bruce Evans to be able to use some of the 386’s features which then gave rise to Linux.

Thanks to cheap commodity based 32bit computers, and the GNU projects development tools (binutils, gcc, bash) people could then finally realize GNU’s dream of bringing a free and open UNIX like operating system to the masses.

Needless to say, a lot has changed since 1991, and Linux now moving beyond the 386 processor is no surprise.  The rapid adoption of 64bit computing via AMDs extensions, and the new forthcoming 64bit ARM processors do signal the eventuality that one day Linux will even drop support for 32bit processors… Although I wouldn’t expect that for another 20 years.  Even Intel has ceased manufacturing the 386 processor in 2007.

So it is now time to say good bye to the 386 processor.  At the same time thanks to full software emulation, you will never truly be dead. And as always you can check out Linux’s early versions.