The Legacy Of The Floppy Still Looms Over Windows

We no longer use floppy disks on the vast majority of computers, but a recent Old New Thing blog post from Microsoft sheds light on one of their possible unexpected legacies. It seems Windows disk cache items expire after two seconds, and as the post explains this has its origin in the development of MS-DOS 2.0.

Disks, especially floppy disks, are slow compared to computer memory. A disk cache is a piece of memory into which the operating system puts frequently loaded items to speed up access and avoid its having to repeatedly access the disk. They have an expiry time to ensure that the cache doesn’t become clogged with data that hasn’t been needed for a while.

IBM PC floppy drives didn’t implement any form of notification for a disk eject, so it became quite possible for a disk to be ejected while the operating system still believed cached data from it to be valid. Thus a pair of Microsoft engineers tried their hardest to swap floppy discs as fast as they could, and it was discovered to be an impossible task in under two seconds. This became the cache expiry time for a Microsoft OS, and thus we’re told the floppy’s legacy lives on as more than just the ‘save’ icon.

As this is being written the Internet is abuzz with a viral Tweet about railroad gauges having an origin in the width of a Roman horse, that rail historians are debunking with a reference to the coal tramways of [George Stephenson’s] Northern England. It’s thus sometimes dangerous to take simple soundbite origin stories at face value, but since in this case our source is Microsoft themselves we think we can take it as being close to the horse’s mouth. Even if it isn’t a Roman horse.

IBM floppy drive image: Michael Holley [Public domain].

Hail To The King, Baby: Reverse Engineering Duke

If you’re a fan of DOS games from the 1990s, you’ve almost certainly used DOSBox to replay them on a modern computer. It allows you to run software in a virtual environment that replicates an era-appropriate computer. That’s great for historical accuracy, but doesn’t do you much good if you’re trying to leverage modern computing power to breathe some new life into those classic titles. For that, you need to dig in a little deeper.

For the last two and a half years, [Nikolai Wuttke] has been doing exactly that for 1993’s Duke Nukem II. The end result is RigelEngine, an open source drop-in replacement for the original game binary that not only runs on a modern Windows, Linux, or Mac OS machine, but manages to improve on the original in a number of ways. An accomplishment made even more impressive once you learn that the original source code for the game has been lost to time, and that he had to do everything blind.

In a blog post chronicling his progress so far, [Nikolai] explains the arduous process he used to make sure his re-implementation was as accurate as possible to the original game. He spent untold hours studying the original game’s disassembled code in Ida Pro, handwriting out pages of notes and pseudocode as he tried to understand what was happening behind the scenes. Once a particular enemy or element of the game was implemented in RigelEngine, he’d record the gameplay from his version and compare it to the original frame by frame so he could fine tune the experience.

So what’s the end result of more than two years of work and over 25K lines of code? Thanks to the incredible advancements in computing power since the game’s release nearly 30 years ago, [Nikolai] has managed to remove the need for loading screens. His engine is also capable of displaying an unlimited number of particle effects on the screen at once, and multiple sound effects can now be played simultaneously. In the future he’s looking to implement smooth character movement (in the original game, movement was in 8 pixel increments) and adaptive volume for sound effects based on their distance from Duke. Ultimately, RigelEngine should be able to replace the original graphics with new high resolution textures once some issues with the rendering buffer gets sorted out.

It’s hard to overstate how important some of these classic games are to those who grew up playing them. With John Romero still releasing DLC for the original DOOM and hackers disassembling nearly 40 year old games to fix bugs, it doesn’t seem like they’re in any danger of being forgotten.

Continue reading “Hail To The King, Baby: Reverse Engineering Duke”

35C3: A Deep Dive Into DOS Viruses And Pranks

Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.

So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.

We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.

Continue reading “35C3: A Deep Dive Into DOS Viruses And Pranks”

DooM Retrospective: 25 Years Of Metal

Metal is many things. A material hard and coarse in nature that by forging it in fire becomes sharp enough to cut through anything in its path. The music that bares its namesake is equally cutting and exudes an unyielding attitude that seeks to separate the posers from the true acolytes. Metal is the sentiment of not blindly following the rules, a path less taken to the darker side of the street. In videogame form, there is nothing more metal than Doom.

The creators of Doom, id Software, were always hellbent on changing the perception of PC gaming in the 1990s. Games of the time were rigid and slow in comparison to their console counterparts. The graphical fidelity was technically superior on PC, but no other developer could nail movement in a game like id. The team had made a name for themselves with their Commander Keen series (which came about after a failed Super Mario Bros. 3 PC demo) along with the genre defining Wolfenstein 3D, but nothing topped Doom. In an era that was already soaking with “tude”, Doom established an identity all its own. The moody lighting, the grotesque monster designs, the signature push forward combat, and all the MIDI guitars a Soundblaster could handle; Doom looked and felt a cut above everything else in 1993.

In December of that year, Senators Joe Lieberman and Herb Kohl held a hearing to publicly condemn the inclusion of violence in videogames sold in America. The bulk of the arguments sought to portray the videogame industry and its developers as deviants seeking to corrupt the nation’s youth. Id Software responded as if to raise the largest middle finger imaginable, by releasing Doom to the world the very next day. A quarter of a century later people are still talking about it.

Continue reading “DooM Retrospective: 25 Years Of Metal”

Tiny Ray Tracer Fits In 64 Bytes

Throughout human history, people try to make the biggest, the fastest, and — sometimes — the smallest. [Hellmood] falls into the latter category and proves it with a 64 byte interactive 3D raycasting application for MSDOS.

Why MSDOS? We suppose why not? The .COM file format is lean, and you can take over everything without a lot of work. If the program were huge, it wouldn’t be very impressive. There are 64 shades of gray which is odd looking these days, however there are versions that use various color palettes and each one fits in 64 bytes or less. There’s even mouse control and you can see the results in the video below.

Continue reading “Tiny Ray Tracer Fits In 64 Bytes”

A Parallel Port Synthesiser For Your DOS PC

It is a great shame that back in the days when a typical home computer had easy low-level hardware access that is absent from today’s machines, the cost of taking advantage of it was so high. Professional PCBs were way out of reach of a home constructor, and many of the integrated circuits that might have been used were expensive and difficult to source in small quantities.

Here in the 21st century we have both cheap PCBs and easy access to a wealth of semiconductors, so enthusiasts for older hardware can set to work on projects that would have been impossible back in the day. Such an offering is [Serdef]’s Tiny Parallel Port General MIDI Synthesizer for DOS PCs, a very professionally produced synth that you might have paid a lot of money to own three decades ago.

At its heart is a SAM2695 synthesiser chip, and the board uses the parallel port as an 8-bit I/O port. The software side is handled by a TSR (a Terminate and Stay Resident driver loaded at startup, for those of you who are not DOS aficionados), and there are demonstrations of it running with a few classic games.

If the chip used here interests you, you might like to look at a similar project for an Arduino. The Kickstarter we covered is now long over, but you can also find it on GitHub.

MSDOS Development With GCC

It might seem odd to think about programming in MSDOS in 2018. But if you are vintage computer enthusiast or have to support some old piece of equipment with an MSDOS single board computer, it could be just the thing. The problem is, where do you get a working compiler that doesn’t have to run on the ancient DOS machine? Turns out, gcc can do the trick. [RenéRebe] offers a video demo based on a blog post by [Chris Wellons]. You can see the video, below.

The technique generates COM files, not EXE files, so there are some limitations, such as a 64K file size. The compiler also won’t generate code for any CPU lower than a 80386, so if you have a real 8086, 80186, or 80286 CPU, you are out of luck. The resulting code will run in a real DOS environment on a ‘386 or higher or in a simulator like DOSBox.

You might be thinking why not use the DJGPP port of gcc to DOS. That sounds good, but it actually doesn’t produce true DOS code. It produces code for a DOS extender. In addition, [Chris] had trouble getting it to work with a modern setup.

The only real trick here is using the right combination of gcc flags to create a standalone image with the right codes. A COM file is just a dump of memory, so you don’t need a fancy header or anything. You also, of course, won’t have any library support, so you’ll have to write everything including functions to, say, print on the screen. Of course, you can borrow [Chris’] if you like.

The last pieces of the puzzle include adding a small stub to set up and call main and getting the linker to output a minimal file. Once you have that, you are ready to program like it is 1993. Don’t miss part 2, which covers interrupts.

If you pine away for QuickBasic instead of C, go download this. If you just want to run some old DOS games, that’s as close as your browser.

Continue reading “MSDOS Development With GCC”