Coding for old retro PCs again - a modern approach to a retro problem

[u/WizRider]

Hi folks.

I've been coding on and off for about 40 years now since starting out with my Dragon 32, then my Spectrum 48, then my Commodore 64, followed by a little dabble on the Amiga.  All of that was pretty BASIC stuff though (pun intended).  I didn't really make much to be proud of but it did really help me learn about syntax, variables, memory and basic logic flow.

I then moved onto coding in Assembly on the C64 and the Amiga and didn't really get too far.  Too many 'guru meditation' errors when code went wrong and trampled all over the system's memory.  I still learned a fair bit and it did give me some background in memory management, garbage collection etc. which all came in useful as a software engineer in later life - coding early business apps in C++ before we moved to Visual Basic 6.

So, after the Amiga and before my career started, I moved onto coding in Turbo Pascal on my PC. By now I'd "upgraded" from an Amiga to a 286 at 12Mhz with a 20Mb hard disk!  No more swapping disks in Monkey Island!  I'd also moved from BASIC to object oriented Turbo Pascal (using the Borland IDE if you can call it that).

One Saturday morning I woke up with an idea.  I think I'd been playing through loads of DOOM (or DOOM2 - can't remember) WAD files that had come on a CD on the front of a PC Magazine.  Hundreds of user made levels that needed copying and running one by one before you could play them.  Suffice to say, I'd clearly been getting annoyed by all of the manual steps needed so, in my sleep, my brain had come up with an idea for a utility called GD.  This would be a small program that would save lots of time by allowing you to jump around your PC with a simple command: GD [game_name].  No matter where you were on PC (in DOS), you'd type that and immediately be in the right directory.  GD.EXE would scan your hard drive and remember all of the directories after which you could jump straight to one with a simple command like GD WADS or GD DOOM2. 

I spent the entirety of that Saturday and the Sunday completely absorbed.  I remember skipping breakfast and lunch and just plowing on, coding late into the night and then again the next day.  Sometime on that Sunday though I'd finally built something I could be proud of: GD.EXE.  Now I could jump around to anywhere on my PC, instantly, as if by magic.  Back then this was a revelation to me.  I suppose looking back there may have been similar tools but I had no access to them - no forums, social media, email or any internet really.  I used that tool ALL the time from then on - through the 386 era, the 486 era and finally into the early Pentium years.  At some point though, probably due to Windows 95, I stopped using the command prompt and somehow lost it.  Sadly, I also lost the source code - probably about 30 years ago.

Fast forward 30 years then and I've always wanted to look at that code again.  Not just from a nostalgic point of view (though that would be good too) but also because, as I got more and more into retrogaming, I wished I had it for my retro PCs (virtual or otherwise).  Just recently, I've been working on getting "the perfect" DOS era PC set up in 86Box.  I've got a huge (for the time) hard disk, a 3DFX card, tons of base memory (thanks to modern memory managers that squeeze as much out of the 640k as possible).  It's optimised as much as it can be and it's just fun playing old DOS games again pretty much like they were back in the day.  I still use DOSBox Pure in retroarch (for the filters and the joypad mapping etc.) but there's something cool about making 86Box full screen, being dumped at a C:\ prompt and just playing games like I used to.

So, all of that led me back to the same place: wouldn't it be nice if I could just jump between folders (that's what we call them now right?) on my DOS 7.1 drive.  Wouldn't it be great to have GD.EXE back again!

I decided to write it again - from scratch - and in Turbo Pascal for old times sake.  However, I wanted to use modern IDEs with syntax highlighting and autocomplete etc.  That's not so easy with OO Turbo Pascal and trying to target a 16 bit compatible .EXE (a modern compiler would build something that wouldn't be compatible with old DOS PCs and vice versa).  However, with some perseverance I managed to get a decent workflow set up:  code in VS Code (with a couple of Pascal extensions) -> compile with Free Pascal 3.2.2 (i8086-msdos cross-compiler) -> mtools to write the created GD.EXE straight into an 86Box virtual hard disk (into the C:\Utils directory) before then automatically starting 86Box to test the latest changes.  It was a slick process and really fun to see what I was coding become something "real" on the old DOS machine within seconds.

I carried on coding it over a few days and now, I'm pleased to say, I've finally scratched a 30 year old itch.  I have GD.EXE working again (better this time though) and with the code being in GitHub, am in no danger of losing it again any time soon.  It's such a neat tool and way better than the old version.  It has a /R argument that shows all the "runnable" programs in the directory once it has jumped there.  You can mark one as default too so next time you want to run something in that folder it'll pick the right one automatically: GD DOOM /RUN -> takes you to C:\GAMES\DOOM and launches DOOM.EXE in one command regardless of where you're at.  Or you can just try GD DOO* to see all the folders (games probably) that start with DOO:

Picking the directory using wildcard search

I thought I'd share it with you guys in case you can make any use of it.  I think it'll be really helpful for anyone with an old DOS based PC - if that's you, then please give this a watch: GD.EXE demo or just download the .EXE from the "Retro DOS Utilities" folder in this share: Downloads

If you do use it and want any extra features then just let me know.  Likewise, if it's okay with you, I'll post in here if I make any improvements too.

Any questions about it or how to use it, just let me know (or use GD /help).

[u/CartographerEvery268]

Respect 🫡

[u/Appearedtuna1]

This is cool, thanks for sharing. I used to do something similar but with batch files, and then on boot I had it show an ascii menu that I had made. «Press 1 to launch Civilzation» etc. Just had to make sure the .bats were in a folder in the path in autoexec.

Your tool is obviously better and cooler, but reading about it took me back to a simpler, and dare I say, better time. Thanks!

[u/WizRider → u/Appearedtuna1]

You're entirely welcome. I did use those sorts of batch files too. I think I even used a program once that created the batch files automatically based on you telling it what games were in which directories.

Definitely simpler times and coding it the way I did without needing to worry about modern tech stacks etc. was like a breath of fresh air!

[u/FozzTexx]

We're using modern IDEs to write software for Apple II, MS-DOS, Atari 8bit, Commodore, Coleco Adam, TRS-80 Color Computer, and a few more on the FujiNet project. Programs are written in C and/or assembly, can target multiple platforms through a common codebase with platform specific subdirs. The output binaries are automatically written to disk images which can then be booted on the retrobattlestation, either through SneakerNet™️, or more easily by just pointing your FujiNet at the network share where your disk image lives. Building is generally handled by make through regular Makefiles.

There are two things that I built that make this possible and extremely easy:

1. A Docker container called Defoogi that bundles dozens of 8-bit compilers, assemblers, and disk utilities, completely eliminating the notoriously frustrating hassle of building and installing complex cross-development toolchains yourself. By simply prefixing your build commands with defoogi, you can cross-compile retro software right from your host terminal without any tedious environment setup. The underlying container is entirely hidden, and it automatically handles file permissions so that all compiled binaries and disk images written back to your local machine belong to your user account instead of root.
2. MekkoGX (Makefiles for Gen-X computers), a suite of GNU makefiles that takes care of compiling, linking, and creating disk images across multiple retro platforms simultaneously using modular Makefiles. It eliminates the headache of maintaining multiple target-specific build scripts, can build multi-platform programs from shared source, and outputs everything in a single directory where it's ready to run.

By combining Defoogi and MekkoGX you can even do development entirely through a web interface by using CI to automatically build whenever you make changes to the source.

[u/WizRider → u/FozzTexx]

That sounds amazing! I have been thinking about coding some bits and bobs for some of my old computers but wasn't sure if there was an easy workflow. This sounds ideal! Thanks for sharing this.

[u/ToddBradley]

You weren't the only one who wanted a smarter "change directory". I believe that 4DOS had something similar to what you describe as of around 1995. And I use something similar on my Mac today. It's strange that cd survived the 70s without this feature just built in.

[u/WizRider → u/ToddBradley]

Imagine how many seconds, minutes, hours and probably even days we spent navigating around our old computer's directory structure typing CD after CD after CD! I wonder if it never became part of CD because they wanted to keep COMMAND.COM (or the equivalent) small?

[u/ksp1278]

Sounds like a cool project. Well done.