Resurrected Entertainment

Archive for the 'DOS' category

Networking in DOS

August 16, 2023

Here is a great description / overview of networking in a DOS environment. It’s definitely worth a read if you cannot quite remember all of the details: https://dosdays.co.uk/topics/networking_in_dos.php

Book Review

May 8, 2023

Let’s talk about this book written by Bob Flanders and Michael Holmes in 1993 entitled “C LAB NOTES”.

The title hints that this may be a book about programming in the C language. Spoiler: it is not a book about how to program in C, even though it uses the C language. Instead, it provides you with several interesting, examples about how to tack real world problems (at least, problems that existed in 1993). Here is a run down of the topics being explored:

  1. Setting the system clock via modem and the United State Naval Observatory’s cesium clock.
  2. Collecting program statistics around interrupts used, video modes, disk access.
  3. Running programs on other nodes via Novell NetWare; sending messages is also explored.
  4. Interacting with laser printers.
  5. Phone dialing using a modem.
  6. Synchronizing directory contents.
  7. Automatically retrieving the latest files from multiple directories.
  8. Analyzing disk structure, such as clusters and sectors.
  9. Managing your appointments with a custom calendar.

This was such a fascinating book back in the day. I had limited income to spend on expensive computer programming texts. Many of the programming books that were available in my local bookstore tended to focus on abstract problems that served to introduce foundational concepts. It was so refreshing to see these sorts of problems being explored. Even today, so much literature is written around how a specific technology works, but so few products are written where the author just assumes you know something about the technologies being used. If they used those assumptions constructively, they could dive straight into interesting problems. It would imagine it might be more difficult to find a publisher who would back you on writing a book like this today; they may look at the material and say it would be too hard for most readers to understand, and therefore would not sell particularly well. They would probably be right on both counts.

In any case, I think we can all breathe a collective sigh of relief that advanced books like these are being quickly fazed out and replaced by much more mainstream titles. After all, once a programmer knows how to sort a linked list or draw a simple scene in OpenGL or Unity, there is really nothing else worth exploring.

MS-DOS is Cross Platform

May 2, 2023

Cross platform programming is a labour of love. It’s also requires a large time investment to get it right, so you should only do it if you really need to. There are many technologies available to help you on that journey; if you are building an application, then you’ll probably take a different path than if you are programming a game, and it’s the latter scenario that I would like to dig into a bit.

Let’s suppose you want to program a small game that doesn’t require easy access to 3D hardware, fancy input devices, or the Internet. Okay, I probably lost most of you right there, but for those that are a tiny bit intrigued, let’s continue.

I have a lot of nostalgia around the MS-DOS platform. It was not the first platform on which I began programming, that honour belongs to the Atari 800 XL, but it was still a lot of fun to use and explore. Compared to desktops nowadays, it is obscenely limited, but back in the 80s/90s it felt quite the opposite. MS-DOS is a 16-bit operating system and native access to memory beyond 640 kilobytes was the stuff of fantasy. Luckily, that limitation was relatively short lived, and you could access heaps of memory (get it?) by leveraging DOS extenders, such as DOS/4G, DOS/32, or CWSDPMI. If they packed the right set of low level features, these run-time utilities were all enabled by your friendly 386 CPU, and allowed the adventurous programmer to enter protected mode and access much more memory. It is worth mentioning that 286 CPUs did support protected mode but they lacked important features, so it was never heavily adopted

Once you jumped the hurdle of available memory, there were other lions that would be programmers needed to tame. They also had cope with performance differences between CPUs (with or without co-processors), sound hardware, hard-drive storage (or lack thereof), video hardware, and input device support. Phew. As a result of all this variability, many MS-DOS compatible games were faced with cross-platform challenges on the same, err, platform.

Unfairly, this wasn’t an issue when faced with game console development. The company promoting a console could always choose to add new hardware, such as steering wheel for racing games or new ways of visualizing content, or even additional performance, but it couldn’t do so in a way that would break existing applications. Note that this isn’t necessarily true for consoles built in the last 20 years. For these machines, the hardware remains compatible, but the software involved could change a lot, which would require game developers to retool their application from time to time. That train of thought is inconvenient right now, so we won’t talk about that messy bit of reality for now.

During the 8- and 16-bit era, game consoles provided a stable environment to build games. This stability lead to lower production costs and faster delivery times. In reality, many companies chose to release their games on several different platforms which dirties the delivery waters a bit. We will sweep these software development complexities under the rug as well since the porting strategies used did not impact their code-base in the same way as cross-platform development would affect their projects today. For example, many companies had distinct implementations for each platform, and code reuse was the exception rather than the rule.

Ironically, given the eccentric nature of MS-DOS in its heyday which lead to all sorts of programming headaches, it’s surprising that using a current incarnation of MS-DOS today produces such a stable environment. All you need is the right level of abstraction. Sure, you could always choose to support MS-DOS and all of its gory hardware configurations, or you could target one configuration and enjoy all of that sweet compatibility. What is this magical solution? Well, this paradise of splendour can be had by leveraging emulators like DOSBox. Yes, the solution to the fragmented environment that is an MS-DOS gaming machine is the venerable DOSBox. It is an excellent way to release your game on dozens of platforms without writing a lick of extra code. Want to run your game on Linux? No problem. What about Mac? No problem. Any console with an open development environment and suitable performance characteristics can (and likely does) support DOSBox, or one the excellent downstream projects like DOSBox-X. This means, your game can run on all of those supported platforms too. Go on, grab some MS-DOS development tools and get coding!

Keyboard or Joystick: You Decide!

April 19, 2015

For those who don’t like playing DOS games using their keyboard, there is a nifty little software package called “JoyEmu“. It allows you to map keyboard keys to joystick input (2 or 4 button joysticks), along with the axial directions. It has a great configuration utility to help you set this up, and allows you to save keyboard mappings and joystick assignments as files. These files can be loaded manually alongside a batch file wrapper, if you desire,  so that playing your favourite games is quick and easy. It also allows for mappings to your mouse and a truck load of documentation; you really couldn’t ask for a better utility of this type!

Alone in the Dark for DOS

I have been playing that game recently and researching different aspects of its history; I ran across a thread on the ScummVM message board that said you can enter the text “benjaminyaelfred” at the copy protection screen and it will let you play the game, if you don’t have the code book that came with the game. The last part of the text “yaelfred” is from one of the original artists of the game, Yaël Barroz, and the original engine programmer, Frédérick Raynal.

DOS Software Development Environment

December 12, 2014

I love writing software for Microsoft’s DOS. I didn’t cut my teeth programming on this platform, that was done on an Atari 800 XL machine. However, it was on this platform that I was first exposed to languages like C and Assembly Language, and thus sparked my torrid love affair for programming which lasts to this day. The focus of this post is about DOS software development and remote debugging.

If you have done any development for iOS or Android, then you have already been using remote debugging — unless you are some kind of masochist who still clings to device logging even when it is not necessary. The basic concept is that a programmer can walk through the execution of a program on one machine via the debugger client, and trace the execution of that program through a debug server running on another machine.

The really cool part of this technology is that it’s available for all sorts of platforms, including DOS! Using the right tool chain, we can initiate a remote debugging session from one platform (Windows XP in this case), and debug our program on another machine which is running DOS! The client program can even have a relatively competent UI. For this project, the toolset we are going to use is available through the OpenWatcom v1.9 project, and the tools found inside that wonderful package will allow us to write 16-bit or 32-bit DOS applications and debug them on an actual DOS hardware target! In addition, we can apply similar techniques but this time our server can be hosted within a customized DOSBox emulator, which is also really cool since it allows you to debug your code more easily on the road.

The first scenario is the one I prefer, since it is the faster of the two approaches, but before we get into the details how to set this up, let’s consider some of the broader requirements.

You’ll need two machines for scenario number one. The DOS machine will need to be a network enabled machine, meaning it should have a network interface card and a working packet driver. I would recommend testing your driver out with tools like SSH for DOS, or the PC/TCP networking software originally sold by FTP Software. In order to use the OpenWatcom IDE, you’ll need a Windows machine. I use VirtualBox and a Windows XP Professional installation; my host machine is a Macbook Pro running Max OS X 10.7.5 with 4 GB of RAM.

The second scenario involves using the same virtual machine configuration, but running the DOSBox emulator within that environment. You will need to use this version of the DOSBox emulator, which has built-in network card emulation. They chose to emulate an NE2000 compatible card for maximum compatibility, and also because the original author of the patch was technically familiar with it. After installation, you’ll need to associate a real network card with the emulated one, and then load up the right packet driver (it comes bundled with the archive).

For reference, the network interface card and the associated packet driver I am using on the DOS machines is listed below:

  • D-Link DFE-538TX

These are the steps I have used to initiate a remote debugging session on the DOS machine:

  • Using Microsoft’s LAN Manager, I obtain an IP address. For network resolution speed and simplicity, I have configured my router to assign a static IP address using the MAC address of my network card; below is the config.sys and autoexec.bat configurations for my network
    
    
    
    
    AUTOEXEC.BAT
    @REM ==== LANMAN 2.2a == DO NOT MODIFY BETWEEN THESE LINES == LANMAN 2.2a ====
    SET PATH=C:\LANMAN.DOS\NETPROG;%PATH%
    C:\LANMAN.DOS\DRIVERS\PROTOCOL\TCPIP\UMB.COM
    rem - By Windows 98 Network - NET START WORKSTATION
    LOAD TCPIP
    rem - By Windows 98 Network - NET LOGON michael *
    @REM ==== LANMAN 2.2a == DO NOT MODIFY BETWEEN THESE LINES == LANMAN 2.2a ====
    
    CONFIG.SYS
    DEVICEHIGH=C:\LANMAN.DOS\DRIVERS\PROTMAN\PROTMAN.DOS /i:C:\LANMAN.DOS
    DEVICEHIGH=C:\LANMAN.DOS\DRIVERS\ETHERNET\DLKRTS\DLKRTS.DOS
    DEVICEHIGH=C:\LANMAN.DOS\DRIVERS\PROTOCOL\TCPIP\NEMM.DOS
    DEVICEHIGH=C:\LANMAN.DOS\DRIVERS\PROTOCOL\TCPIP\TCPDRV.DOS
  • Load the D-Link Packet driver
  • I load a TSR program, which I have built from a Turbo Assembly module, which can kill the active DOS process. I do this because the TCP server provided with OpenWatcom v1.9 does not exit cleanly all of the time, and will often lock up your machine. In the end, your packet driver may not be able to recover anyway, and you will need to reboot the machine, unless you can find a way to unload it and reinitialize. Incidentally, the packet driver does have a means to unload it, but when I attempt to do so after the process has been killed, it reports that it cannot be unloaded. The irony of the situation will make you laugh too, I am sure.
  • Navigate to my OpenWatcom project directory, then I start the TCP server which uses the packet driver and your active IP address to start the service. The service will wait for a client connection; in my case, the client is initiated from my Windows XP virtual machine using the OpenWatcom Windows IDE.
    • Ensure that the values for “sockdelay” and “datatimeout” are both “9999”, and make sure the “inactive” value is “0” in your WATTCP.CFG file. Even though the documentation says that a value of “0” for the “datatimeout” field is essentially no timeout, I did not find that to be the case. The symptom of the timeout can be onbserved when you launch the debug session from the OpenWatcom IDE and you see the message “Session started” on your DOS machine, but then the IDE reports a message the the debug session terminated.

These are the steps for the DOSBox emulator running within the Windows XP guest installation:

  • Install the special network enabled build of DOS Box mentioned above;
  • Fire up the NE2000 packet driver  (c:\NE2000 -p 0x60);
  • Start the TCP service
    • Note that I configured a static IP address on my router using the Ethernet address reported by the packet driver. You should not be able to ping that address successfully until the TCP server is running in DOSBox. While the process worked, I found the time it took for the session to be established and the delay between debug commands to be monstrously slow (45-90 seconds to establish the connection, for example) and as a result, made this solution unusable.

While working on a project, it can be really useful to create the assets on a modern machine and then automatically deploy them to the DOS machine without needing to perform a lot of extra steps. It can also be useful to have the freedom to edit or tweak the data on the DOS machine without needing to manually synchronize them. The solution which came immediately to my mind was a Windows network share. This is possible in DOS via the Microsoft LAN Manager software product and has been discussed before in a previous post.

Building Wolfenstein 3D Source Code

June 16, 2014

Way back on Feb 6, 2012, id Software released the source code to Wolfenstein 3D — 20 years after it had already been written. The source code release does not come with any support or assets from the originally released game. In fact, id Software is still selling this title on various Internet stores like Steam. I played around with a DOS port of the DOOM source code quite some time ago, but I had never bothered to try and build its ancestral project. Until now!

As it turns out, it’s actually quite straight-forward with only a minor hiccup here and there. The first thing you’ll need is a compiler, that almighty piece of software that transforms your poorly written slop into a form that the operating system can feed to the machine. For this project, the authors decided to settle on the Borland C++ v3.0, but it is 100% compatible with v3.1. I don’t know if more recent compilers from Borland are compatible with the project files, or the code present in the project produces viable targets, so good luck if you decide to make your own roads.

As per the details in the README file, there are a couple of object files you will want to make sure don’t get deleted when you perform a clean within the IDE:

  • GAMEPAL.OBJ
  • SIGNON.OBJ

You can open up the pre-built project file in the Borland IDE, and after tweaking the locations for the above two files, you should be able to build without any errors. The resulting executable can then be copied into a working test directory where all of the originally released assets are located, I believe my assets were from the 1.2 release.

There are also a few resource files you must have in order for the compiled executable to find all of the right resources. According to legend, the various asset files were pulled from a sprinkling of source formats and assembled into “WL6” resource files. A utility called I-Grab, which is available via the TED5 editor utility, produced header files (.H) and assembler based (.EQU) files from that resource content which allowed the game to refer to them by constant indices once the monolithic WL6 resource files were built. There are annotations in the definition files, using the “.EQU or .H” extension, with a generated comment at the top which confirms part of that legend.

The tricky part in getting the game to run properly revolves around which resource files are being used by the current code base. The code refers to specific WL6 resource files, but locating those resource files using public releases of the game can be very tricky because those generated files have changed an unknown number of times. Luckily, someone has already gone through the trouble of making sure the graphics match up with the indices in the generated files. The files have conveniently been assembled and made available here:

After unpacking, you’ll need to copy those to the test directory holding the registered content for the game. Note that without the right resource files, the game will not look right and will suffer from a variety of visual ailments, such as B.J. Blazkowicz’s head being used as a cursor in the main menu, or failing to see any content when a level is loaded.

Multi-player DOOM on an IPX Network

June 7, 2014

If you want the feel of a light weight and efficient network protocol, then you can start a multi-player game of DOOM via the Ultimate DOOM Setup utility on one machine and the corresponding IPX setup tool on the other machine. The easiest way to do this is to use the Windows 98 protocol stack with the following components installed:

1. Client for Microsoft Networks
2. Appropriate network adapter
3. IPX/SPX-compatible Protocol
4. NetBEUI
5. TCP/IP (you won’t need this for DOOM, but you probably will want it)
6. File and printer sharing for Microsoft Networks

I have read that you may need to enable both file and printer sharing, but personally I haven’t verified that, and I don’t really see how the components are related. If by some chance they are required, the NetBEUI protocol seems to be a requirement for the sharing to work reliably on networks between two Windows 98 machines or a Windows 98 to a Windows XP machine. I was also running this over a wired network on the same router, so if you have one or more wireless routers, make sure that machines can see each other on the network (one reason to get file sharing working between the two machines). A couple of things to keep in mind:

1. Make sure they are on the same Gateway (mine is 192.168.1.1, which is just my router)
2. Make sure they are using the same sub-net mask (I use 255.255.255.0)

A few notes on the IPX configuration:

1. Make sure the frame type is set to “Auto”
2. Make sure the network address is the same on both machines, I use the default address “0”

I have been trying off and on for a few days to get two machines using DOS-compatible IPX protocol stacks to talk to one another, and it has not been easy. I will post about that once I get them working.

2D Scrolling and EGA Support

May 29, 2014

Originally, I was using a Matrox Millennium PCI graphics card in my DOS gaming box, but I found the 2D scrolling performance to be somewhat lacking as games like The Lost Vikings would shear while playing. The card also has virtually no EGA graphics mode support, which was important to me since I wanted to run games like Crystal Caves from Apogee, and I also wanted the development option of writing computer graphics programs written for this video mode.

Enter the S3 ViRGE (Virtual Reality Graphics Engine).

Interestingly, this was S3’s first attempt at a 3D graphics accelerator card. The performance was somewhat lower than expected, however, making the card only slightly faster than the best software renderers at the time, and equal to those renderers when anything other than the simplest 3D techniques were used. Because of the card’s poor performance, it was dubbed the “Worlds First Graphics Decelerator” by critics in the graphics and gaming communities.

I own the “DX” model of this card which is somewhat more performant than its predecessor, but I didn’t buy the card for how well it could render 3D graphics so it matters very little to me. I bought the card for how well it could accelerate 2D graphics and its support for lower end video modes, and it is very impressive thus far.

Day of the Tentacle Quote

June 24, 2013

maniac-mansion-day-of-the-tentacle-small

“You know what they say, if you want to save the world, you need to push a few old ladies down the stairs.”