I was reading this post by Foone on Masto:
Hot take: DOS gaming is not one era. It’s two.
Before and after 32bit extenders.
And I totally agree. DOS games, and DOS software in general, had a first age that was 16-bit, and a later one that was 32-bit and lasted until around 1997.
My first DOS game –or shall I say my first released game for DOS– was Gold Mine Run!, that is a 32-bit game. It requires a 386 or later, VGA and Sound Blaster; which is very different to what we had in the first age of 16-bit DOS.
So when the DOS COM Game Jam was announced, I thought: wouldn’t it be fun to make a game for the early IBM PC?
64K limit is not a big deal if we consider that most of my 8-bit games require less than that –even if you target a machine with
64K of RAM, that includes the video memory as well–. I could potentially port any of my 8-bit games to PC and it should fit in a
COM file, embedding data and all.
I decided that I would target:
- MS/DOS or compatible
- IBM PC (8086)
- PC internal beeper
- All in a COM file (that means
64Kor RAM on disk; I could use more memory if needed), so I can submit it to the Jam!
This is basically what I had available on my first PC, an Olivetti Prodest PC1.
But then, I didn’t want to stress myself again and potentially not submitting the game because I didn’t have enough time. I hadn’t programmed the CGA before, I didn’t know if I could comfortably cross-compile from Linux to DOS and 16-bit. So I went for a simple –yet fun!– game: The Return of Traxtor. I have implemented the game a few times –my favourite is The Return of Traxtor for the CPC–, so it should be fine.
At the end, it wasn’t that bad, even if the CGA is fiddly and closer to what you would do on a ZX Spectrum –encodes 4 pixels in one byte– than what you would do on a VGA.
My strategy is not that different to what I did in “Gold Mine Run!”:
- Using build-ia16 to have a version of GCC that targets Intel 16-bit (8086) and can generate DOS binaries (including
COM) on Linux.
- Embedding the data in the binary using objects and the linker (see for example raw.py).
- The keyboard controller is the same –although I had to rewrite it to use real mode interrupts, fun!–.
The first part was getting to draw on the CGA, following the docs I could find –see: Colour Graphics Adapter: Notes–. It required writing some assembler because of the real mode memory addressing, but I got it working reasonably fast in an evening. Then the interrupt handler for the keyboard was tricky as well, but after that, all it was writing plain old C code.
So far the project is progressing nicely –see my Mastodon account–, and looks like I’m going to finish a good version of the game and on time.