I have recently finished the book entitled “8-bit Christmas” by Kevin Jakubowski. It was a very enjoyable read with many similarities to my childhood along with many differences; it was fun to read about another person’s perspective on that period. My brothers and I all wanted a Nintendo after we played one at a relative’s house during the Christmas break. The trouble being, of course, that we would have to wait until next Christmas to get one. Luckily, I had a birthday in July!

Categories: Reflections
No Comments »

The Arcadia (or Starpath) Supercharger is a device which allows you to play beefed up games on your Atari 2600. Games ship on cassettes and are loaded onto the system via an audio cable that connects to a tape player. The other way is to hook up the cable to your computer and pipe a sound file to the device. For 2K and 4K games, you can use a tool called “makewav” which encodes an Atari 2600 binary ROM file into a WAV encoded audio file. I have “ported” the utility so that it can be built on Mac OS X; I use the term loosely since I had to do very little to get it to build. You’ll want to run it like this once it is built:

$ makewav -ts atarigame.bin

Which will produce a WAV file of the same name + a “.wav” extension. You may also want to locate a CD called Stella Gets a New Brain, which is a complete compilation of the games released for the Supercharger. If you decide to rip the audio tracks to an MP3 file, be sure to use a very low compression for maximum fidelity and open the file in a piece of software like Audacity to make sure that the audio is duplicated on both channels; this is because your laptop has stereo output but the Supercharger only accepts mono. You will likely need an interface adapter which converts your stereo signal to a mono signal, but a better way might be to simply find yourself an old stereo audio cable, cut it and the wire going to the Supercharger, and solder one signal line from your stereo cable + ground to the mono cable’s signal line + ground. While attempting to use my Supercharger, I found the noise introduced by the adapter and the oxidized cable from the 30+ year old device was causing a lot of interference, after I cut out the middle man things worked perfectly.

Once that is done, try The Official Frogger by Sega — it’s awesome!

Categories: Atari 2600
No Comments »

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.

Categories: DOS, Game Development, Programming, Retro
No Comments »

It’s hard to believe, but DOOM (or Smashing Pumpkins Into Small Pieces of Putrid Debris as it was known in some circles) was unleashed upon the world as Shareware on this date in 1993. The game was so popular that Microsoft had contemplated purchasing id Software in an effort to promote Windows 95 as a top-notch gaming platform; Bill Gates even featured himself in a video fighting the creatures of DOOM head on. DOOM fever had reached high enough levels inside Microsoft that a special Easter Egg was placed inside of Microsoft Excel 95 with a DOOM-like level called The Hall of Tortured Souls. Over the years, much has been said about this game and the team that created it, so I will not echo that history here, but here are some of the things the DOOM franchise has birthed into this world since its release:

• It has sold over one million copies, but it has been pirated and downloaded many more times than that
• DOOM – The movie starring Dwayne John (The Rock)
• Masters of DOOM Book
• The source code for the game was released in 1997 spawning numerous source ports to other platforms and revamped engines
• The game engine has been licensed numerous times, even for such projects as promoting breakfast cereals like Chex
• For four years after its release, people continued to refer to other 3D games as “DOOM clones”
• DOOM board games and expansions
• DOOM comic books and fantasy novels

Categories: Games, Retro
No Comments »