Here is where to post about the latest Commander Keen fangame or modification you've finished, a new website you've made, or another Keen-related creation.
It's not quite Christmas time yet, but since these are the days of Keen's 35th anniversary, I thought it was a good opportunity to finally release this to the public:
This package contains full source code for all versions of Keen 1-3 that I know, from the November 1990 beta version of Keen 1 to the relatively obscure Precision Software Applications release (version 1.34). Compiling the source code with the correct compiler and assembler versions and compressing the resulting executables with LZEXE or PKLITE (if necessary) generates executables that are 100% identical to the original files.
You will need Turbo C++ 1.00 (not 1.01!) and Turbo Assembler (2.0 or above) to compile exact copies of most versions of Keen 1-3 (versions 1.31 and earlier). The later special releases (the "pre-registered" Gravis version 1.32 and the PSA release version 1.34) require Borland C++ 2.0 for a fully identical copy.
---
If you have read the timeline.txt file I released along with my Reconstructed BioMenace Source Code last year, you might have noticed an entry that said "got side-tracked revisiting another old project". This is that project.
Most of the Keen 1-3 code reconstruction was done back in early 2021, before I started preparing my reconstructed Keen 4-6 source code for release. The big problem that prevented me from getting my Keen 1-3 code to compile and compress into 100% identical copies of the original executables was the fact that I didn't have access to the right compiler back then. I only had Turbo C++ 1.01, which generates slightly different code than Turbo C++ 1.00. It was impossible to get Turbo C++ 1.01 to produce the code that I needed.
Another contributing factor is that the order of the uninitialized variables in the so-called BSS segment depends on the names of the variables when using Turbo C++ 1.x to compile the code. And since some of these variables need to be accessed from within the assembly code, I couldn't simply group the variables into a struct like I did elsewhere. I had to find names that would allow the variables to appear in the correct order. So after some trial and error, I wrote a small throw-away program that generated a bunch of variables with random names and ran that list of variables through the Turbo C++ compiler. Disassembling the generated .OBJ file showed me which order these variable names would produce, so all I had left to do was to let the compiler (and the assembler) rename the variables internally. This is done in the BSSCHEAT.H and BSSCHEAT.EQU files.
A word of advice for those attempting to use a similar trick to modify the order of the variables in the BSS segment: If two names produce the same hash value for whatever hash function the compiler uses, the order of the variable declarations can have an effect on the order of the variables in the generated code. This includes "extern" declarations as well, not just the actual declaration of the variable. One way to detect hash collisions in a list of randomly generated variable names would be to reverse the order of the variables and compile the file again. If the order of certain names changes after that, those names have the same hash values and you are probably better off using only one of those names to avoid having to move (extern) declarations around to get the result you want.
---
If you check out IDLIB.C and IDLIB.ASM, you will see that I based the code in these files on The Catacomb and Hovertank. This is the code that got the team in trouble. They used the same routines they wrote for their day jobs at Softdisk in the Keen code. No matter what those old letters posted by Scott Miller said, the boys were in serious trouble.
Most of the IDLIB.C code must have come directly from the PC version of Dangerous Dave. I don't think the Dave source code has been released to the public, so you'll just have to take my word for it. But there is some extremely strong evidence showing that the id founders used Softdisk's code in their own game. Sure, it's not the code responsible for the smooth scrolling, but it is code they probably didn't have the rights to use.
---
That's all for now. Have fun messing with the code.
Very cool: I just built a copy of Keen 1 (albeit with Borland C++ 3.0, which was what I had lying around), and despite the issues you mentioned, managed to play it through to completion.
It's really neat to see the differences between versions, particularly with the beta version. Having the Makefiles is also really convenient for me.
Definitely looking forward to playing with it some more, maybe trying some proper source modding or something…
Multimania wrote: Tue Dec 16, 2025 9:07
Very cool: I just built a copy of Keen 1 (albeit with Borland C++ 3.0, which was what I had lying around), and despite the issues you mentioned, managed to play it through to completion.
Presumably the differences would only matter if you were to attempt patching the executable
A strange spirit has taken residence within the Temple of Jaral.
Nospike wrote: Tue Dec 16, 2025 13:57
Presumably the differences would only matter if you were to attempt patching the executable
No. The code has bugs that can cause serious problems if the variables are stored in a different order. Borland C++ 3.0 stores the variables in a different order than the older versions.
Haven't gotten to building any executable, but as usual, that is an important milestone.
I've been in contact with K1n9_Duk3 recently, mostly with relation to BioMenace Remastered testing. I've also been aware of the plan to update the reconstructed BioMenace sources, with my feedbacks having their impacts. That said, I haven't seen a hint of the work on Keen 1-3.
I had figured out beforehand that Hovertank technically resides in-between Keen 1-3 and Keen Dreams. In particular, I recall Fleexy finding out that Hovertank uses (a variation of) Keen Dreams' EGAGRAPH format, while the levels are rather still formatted as in Keen 1-3. I had probably seen a hint or two in an interrupt handler related to timing and/or PC Speaker sound playback.
It makes sense at least a subset of Dangerous Dave (1990) code was reused. What I do remember is Catacomb II (i.e., The Catacomb) having a control panel looking like Dave's, more-or-less. This code seems to be under Catacomb II's PCRLIB_C.C. One clear difference from Dave is that Catacomb II lacks separate VGA graphics.
Hovertank 3D had a derived IDLIBC.C file. My hunch is that the reconstructed sources' Keen 1-3 reside in-between these two files.
There's also assembly code, Catacomb II's PCRLIB_A.ASM and Hovertank 3D's IDASM.ASM. Keen 1-3's IDASM.ASM seems to reside in-between. It's probably closer to Hovertank 3D's, albeit Hovertank had a lot of code removed from that file.
On a related note, if anyone was wondering about Wolfenstein 3D's main menu function from WL_MENU.C being named US_ControlPanel:
- It should be clear when such a function is found in the Catacomb 3-D sources' ID_US_2.C.
- The name "Control Panel" probably makes more sense in the context of Keen Dreams, as what it has does look more like a control panel. Keen Dreams has a function of the same name in ID_US.C, preceding the replacement with the separate ID_US_1.C and ID_US_2.C files.
- We may see here, though, that usage of the terms "Control Panel" seems to date back to early Catacomb and Dangerous Dave games.
K1n9_Duk3 wrote: Mon Dec 15, 2025 6:48
It's not quite Christmas time yet, but since these are the days of Keen's 35th anniversary, I thought it was a good opportunity to finally release this to the public:
This package contains full source code for all versions of Keen 1-3 that I know, from the November 1990 beta version of Keen 1 to the relatively obscure Precision Software Applications release (version 1.34). Compiling the source code with the correct compiler and assembler versions and compressing the resulting executables with LZEXE or PKLITE (if necessary) generates executables that are 100% identical to the original files.
You will need Turbo C++ 1.00 (not 1.01!) and Turbo Assembler (2.0 or above) to compile exact copies of most versions of Keen 1-3 (versions 1.31 and earlier). The later special releases (the "pre-registered" Gravis version 1.32 and the PSA release version 1.34) require Borland C++ 2.0 for a fully identical copy.
---
If you have read the timeline.txt file I released along with my Reconstructed BioMenace Source Code last year, you might have noticed an entry that said "got side-tracked revisiting another old project". This is that project.
Most of the Keen 1-3 code reconstruction was done back in early 2021, before I started preparing my reconstructed Keen 4-6 source code for release. The big problem that prevented me from getting my Keen 1-3 code to compile and compress into 100% identical copies of the original executables was the fact that I didn't have access to the right compiler back then. I only had Turbo C++ 1.01, which generates slightly different code than Turbo C++ 1.00. It was impossible to get Turbo C++ 1.01 to produce the code that I needed.
Another contributing factor is that the order of the uninitialized variables in the so-called BSS segment depends on the names of the variables when using Turbo C++ 1.x to compile the code. And since some of these variables need to be accessed from within the assembly code, I couldn't simply group the variables into a struct like I did elsewhere. I had to find names that would allow the variables to appear in the correct order. So after some trial and error, I wrote a small throw-away program that generated a bunch of variables with random names and ran that list of variables through the Turbo C++ compiler. Disassembling the generated .OBJ file showed me which order these variable names would produce, so all I had left to do was to let the compiler (and the assembler) rename the variables internally. This is done in the BSSCHEAT.H and BSSCHEAT.EQU files.
A word of advice for those attempting to use a similar trick to modify the order of the variables in the BSS segment: If two names produce the same hash value for whatever hash function the compiler uses, the order of the variable declarations can have an effect on the order of the variables in the generated code. This includes "extern" declarations as well, not just the actual declaration of the variable. One way to detect hash collisions in a list of randomly generated variable names would be to reverse the order of the variables and compile the file again. If the order of certain names changes after that, those names have the same hash values and you are probably better off using only one of those names to avoid having to move (extern) declarations around to get the result you want.
---
If you check out IDLIB.C and IDLIB.ASM, you will see that I based the code in these files on The Catacomb and Hovertank. This is the code that got the team in trouble. They used the same routines they wrote for their day jobs at Softdisk in the Keen code. No matter what those old letters posted by Scott Miller said, the boys were in serious trouble.
Most of the IDLIB.C code must have come directly from the PC version of Dangerous Dave. I don't think the Dave source code has been released to the public, so you'll just have to take my word for it. But there is some extremely strong evidence showing that the id founders used Softdisk's code in their own game. Sure, it's not the code responsible for the smooth scrolling, but it is code they probably didn't have the rights to use.
---
That's all for now. Have fun messing with the code.
Oh wow, so now a source code for all keen games is known. This is a major milestone. Sadly, I don't enough of C to do much with this. Though I feel like the keenxAct.c files would the main target for "patching". Does this actually eliminate the limits on keen vorticon mods, or is that due to limits in DOS?
I know is off-topic, but please pardon me, I have no other places to ask this better than here.
as you may, or may not know it, the source code for Street Fighter 2 (DOS) (aka SFIBM) have been found recently. https://github.com/raytomely/Street-Fig ... rce/sf2src
so please K1n9_Duk3, could you reconstructs the other versions based on the original source code ?
or just the popular versions (SFLIU and SFRANMA (aka SFIBM 198 or SFLIM) )
as I said it is a game that defined an era, and it does need to be preserved.
and thank you for your efforts on reverse engineering and decompiling of Commander Keen and BioMenace.
and having a read through their sources codeis real thrill.
thank you again.
This sounds very promising. I also wonder what this means in terms of overcoming current modding limitation.
For example would it be conceivable to have vorticon elites together with yorps and gargs in one level? And generally more types of enemies at once? Are even bigger levels a possibility? Are the memory limitations overcome now or expanded?
I assume if all these things are possible it would also require some work from a skilled modder or patcher. Or what we previously called patching.
I don't have a github account, and I don't intend to create one in the foreseeable future, so I won't be uploading it to github myself. The code is released under the terms of the GPL, so I can't prevent anyone from uploading it elsewhere. But since some names may change (sound names, for example; see below), it would be better to wait for an update before uploading the source elsewhere, just to make sure we're all working with the same naming scheme in the future.
@Calvero:
You're right. The Catacomb (1 and 2) and Hovertank source code also uses the naming convention of having the ...SND at the end of the name instead of using a SND_... prefix like I did here. But I did the same thing in my Keen 4-6 source code and I figured it would be easier for modders to switch between the two code bases if I used the same naming scheme.
I am open to changing this (for Keen 1-3 and for Keen 4-6) if you prefer to use the original names. It might also help in transitioning from my reconstructed source to the original source code (should id Software ever decide to release it).
There are other things that might get renamed as well. I wasn't quite happy with the names I picked for the tile attribute arrays (tile_numframes, tile_behavior, tile_blockDown, etc.) and it was brought to my attention that they were most likely called "nexttile", "intile", "northwall", etc. in the original source code, which also matches the names used in Keen 4-6 (INTILE, NORTHWALL, etc.).
@shikadi:
Which files you would need to edit depends on what you want to achieve. Yes, enemy behavior is mostly found in the KEEN?ACT.C files and Keen's code and some shared actor code is in KEENACTS.C. Other aspects may be defined in other files. For example, the starting ammo and equipment (pogo or no pogo) for a new game are defined at the beginning of the MenuLoop function in KEENDEMO.C.
Compiling this code will still create a real-mode DOS program that is limited to operating withing the 640k of conventional memory. That won't change unless you port the code and turn it into a 32-bit protected-mode executable for DOS or you port it to another operating system entirely. Code and data are (mostly) loaded into the same memory region when working with real-mode DOS programs. The more code you add, the less memory will be available for loading data like sprite images, sounds, etc. You can add more enemy types and more playable levels, more kinds of keys, new score items (like a 20000 points item that would act as an immediate extra Keen), etc. But if you add too much, you will eventually run out of memory.
What doesn't change much is the tileset size limitation. The code requires an EGA/VGA card with at least 256k of video memory. The first 112k of the video memory are reserved for the two display "pages" used by the game, the remaining 144k are used to store the image data from the EGALATCH.CK? files. That means the 8x8 pixel font, the tile images, and all the unmasked images (from the title image to the Id Software logo). The EGALATCH.CK1 file from Keen 1 is already using over 116k of those 144k, so there are "only" about 28k left. That means you could add up to 217 extra tiles for a total of 828 tiles if you keep all the unmasked images and don't change their size.
But adding new tiles means you will also need new tile attributes. In the original implementation, each tile requires 12 bytes of tile attributes. The tile attributes are stored in the main data segment, which is limited to 64k. And if you have more than 700 tiles in your tileset, you will also need to adjust the arrays for the tile animation frames, which means once you have 700 tiles in your tileset, each additional tile will require 20 extra bytes in the data segment instead of just 12. To allow up to 828 tiles, you would be adding 3628 bytes to the data segment in Keen 1 v1.31. That shouldn't be a problem, since Keen 1 v1.31 still leaves enough space for up to 17338 extra bytes.
Another aspect to keep in mind is that Keen 1-3 use the SMALL memory model, which means you can't have more than 64k of compiled machine code in total. It is possible to add more code, and all versions after Keen 1 v1.0 are actually using more than 64k of machine code (for the unwound DrawPage routines), but that extra code comes from the assembly files, not from the C code. Just to give you some specific numbers, the Keen 1 v1.31 code base could support up to 6478 bytes of additional machine code. The code in KEEN1ACT.C (without the extra code from the shared KEENACTS.C file) is only 4434 bytes of machine code, so there is still a decent amount of space left for additional code. And you can make room for more code by disabling other code that you don't really need. For example, most Keen 1 mods don't compress their graphics, so you could compile a version of Keen 1 that omits the LZW decompression code if you don't need it anyway (comment out or delete the "#define USE_LZW" line in GRAPHCK1.H) and that alone would remove over 500 bytes of machine code from your executable.
@Vortlike:
Levels still need to fit into the big buffer (64k by default), but you can increase the size of that buffer if you want. You will also need to adjust the code that reads and decompresses the level data and make sure the compressed data gets loaded to the ed of that buffer. I will make the big buffer size a #define in the next update to make that easier.
As I said above, new enemies shouldn't be a big problem. What might be a problem is that all sprites are kept in memory all the time, so combining bigger level buffers and more enemy types means you will require a lot more memory and it will soon become impossible to play the game if you add too many sprites.
Edit:
As it turns out, allowing bigger levels will require more than just changing the size of the big buffer. Some parts of the ReadLevel function will need to be modified as well. At the moment, any level file larger than 32767 bytes (compressed) will cause problems because the file size is treated as a signed 16-bit value, meaning a size of 32768 or above will be treated as a negative number and mess up the calculation. And if you want bigger levels, you will also need to use huge pointers instead of far pointers in that function.
You won't be able to use insanely huge levels, though. The planesize value in the level headers is stored as an unsigned 16-bit integer, so the plane size cannot be larger than 65535 bytes. Since each tile is stored as a 16-bit value (2 bytes), that means your levels cannot have more than 32767 tiles, i.e., width * height of the level must not be larger than 32767. For example, the largest perfectly square level would be 181 x 181 (= 32761 tiles), the tallest possible level would be 24 x 1365 tiles and the widest possible level would be 1927 x 17 tiles. This is basically the same limitation as in Keen Dreams and Keen 4-6, except the Vorticons code can handle levels that are more than 256 tiles wide or more than 256 tiles tall.
It would theoretically be possible to allow even larger levels, but you would need to modify the level header format and turn the planesize value into a 32-bit integer for that, which means you will also need to use a customized level editor program that can write levels in this new format. And you will also need to make the game use huge pointers all the time when accessing the level data, which will lead to significantly worse performance overall. And you will also need to rewrite the assembly code to make it use huge pointers as well. That means manually adding extra code to normalize the pointer addresses, which will add a lot of extra code in the unwound DrawPage routines. You should use the loop-based DrawPage code instead of the unwound routines to keep the code short, but that would also make the performance slightly worse. Long story short, allowing levels with a plane size of more than 65535 bytes is not really feasible for a real-mode DOS version. But a source port for a modern system could do it, as long as it provides its own (built-in?) level editor.
@keenguest:
Sorry, I am not familiar with the non-IBM system architectures. Can't help you with that.
---
After reading Multimania's post about compiling the code with Borland C++ 3.0, I re-evaluated what I wrote about the corruption caused by accessing the entrances array with an index of 254. As it turns out, my calculations were flawed. The array elements are 6 bytes each and the array is 16 entries long, so accessing entry number 254 will access the 6 bytes located 1428 bytes after the end of the entrances array. It is true that the line_offsets array follows immediately after the entrances array in the original executables, but that array is only 800 bytes long. The corruption actually affects the memory region beyond the end of the variables in the data segment. That is where the near heap and the stack are.
The stack should never grow big enough to reach that area, especially not in the ScanWorldMap function. The only thing that uses memory from the near heap is the stream buffer for the stdin and stdout streams. These buffers are allocated by the library code directly at startup (512 bytes each) and they are generally unused mid-game, so the memory corruption should have no effect. Still, it's unsafe to just let the memory corruption happen and hope for the best. It's easy to fix and you should fix it.
I remember this memory corruption being a big problem in my early builds. I was using Borland C++ 3.1 initially and the variables might have been declared in a different order (in Borland C++ 3.0 and 3.1, the order of the uninitialized variables depends on the order of their declarations, not on their names) and I may or may not have used COMDEFs, which can also change the order of the uninitialized variables.
BTW, I think NUMSOUNDS is off-by-one, because the soundnames start at 1 instead of 0. It's not really a problem because NUMSOUNDS isn't used anywhere anyway.
And I'm not sure if it should be "Keencicle" or "Keensicle".
I just uploaded updated versions of my reconstructed Commander Keen source code and my guide to the Keen 4-6 source. The files have replaced the old downloads, so the old download links should still work. If you're too lazy to scroll or open the old threads, use these download links:
A side effect of replacing the old files is that you might still get the old files if some server still has the old file in the cache and decides to give you the old file instead of the new one. If that happens, try again in a day or so.
Changes:
- Added support for Keen 1 version 1.3
- The sounds have been renamed from SND_... into ...SND (Keen 1-3 and 4-6 and in the Guide)
- The pics and sprites have been renamed in similar fashion (Keen 1-3)
- Modified some code to recreate the original machine code without using pseudo register variables (Keen 1-3 and 4-6)
- Added optional code in ID_MM.C that allows proper stack overflow checking (Keen 4-6)
- Added many new BUG: comments in various files (Keen 4-6)
- Added a few new constants and macros to make the code easier to read and modify (Keen 4-6).
- Modified the project files to remove the debugging information and instead initialize the segments (Keen 4-6). All this means is that I could now compile the projects and compress the new executables without having LZEXE ask for confirmation every single time.
