Public Commander Keen Forum

Have you always thought there are too much graphics on screen and the music is too detailed while playing Commander Keen 4?
Then try the new Commander Keen 4 Tandy version.

Other improvements include:

• Faster loading times, thanks to replacing Huffman compression by ZX0 compression.
• Disable the score box by pressing Backspace to make the game faster, just like in Bio Menace.

Watch some gameplay footage or listen to the Tandy 3 Voice soundtrack on YouTube.
And download the game and source code from GitHub.
You need to provide your own copy of GAMEMAPS.CK4 from Commander Keen 4 v1.4 to play this game.

BTW, I've only tested this in DOSBox with machine set to tandy and in PCem, not on a real Tandy 1000 computer.

Ah I remember seeing this on your channel a few months ago. Neat idea!

ah, nice to see that someone else came up with the same idea to toggle the score box on/off mid game. FitF will also be equipped with such a feature. We even picked the same action key to make the score box sprite disappear from screen. sweet

It's the first time I did something useful with Ghidra: disassemble Bio Menace and copy-paste the score box code.

Hey there, I suppose that you're also identified as Frenkel in these forums: Duke4.net, RGB, old 3DR forums?

Either way, that's an interesting mod! While the graphics - as expected - should match the EGA ones, the new Tandy music surely feels quite different. Rather than interpreting the original IMF Files, it looks like you created data in a separate, custom format; Just like how are PC Speaker and AdLib sound effects are separate, and also are CGA and EGA graphics.

It does look like there's a problem with corruption of graphics upon transitioning between levels. One guess of mine is a buffer overflow. It's probably not noticeable outside of level transitions due to the lack of caching in the middle of a level.

I'm wondering how many people thought about Tandy ports of Keen games, even if only as an idea. I think that I also thought about the concept in the past.
What was demonstrated in a video from 2016 (if not earlier) and later uploaded in 2019, was an adaptation of VileR's CGA composite graphics Keen 4 mod for the Tandy:
https://www.youtube.com/watch?v=GDm538gpBW8
https://github.com/kubilus1/keen4t

I've recreated the music in TNDY-Tracker and then I played it in DOSBox-VGM to create VGM files. Those files were converted to an IMF like format: 2 bytes to send to the Tandy 3-voice sound chip followed by a UINT16LE for the delay.

I also get the corrupted graphics when I play it in PCem emulating a Tandy 1000 with 640 kB or less. To fix it, I run ADJMEM -16 before the game.

I forgot to mention the following about the music and sound effects.

If anybody around here gives the combination of Tandy music and AdLib sound effects a try, without starting AdLIb music first, you might find out that a few sound effects differ from the way they sound in the original, unmodified games. That is, unless AdLib music was never turned on in any of these games.

On the other hand, this is the way they may sound in multiple Keen mods, even with AdLib music being in use.

From what I learnt, the reason for this is that the original IMF tracks share a sequence of OPL commands which seem to impact the outputs of sound effects. Custom IMF tracks used by most mods tend to lack these commands, and they're obviously not relevant for Tandy music.

For more details, there's the following post (with video URL) and thread in which it's present: viewtopic.php?p=99507#p99507

Frenkel wrote: ↑Mon Jan 17, 2022 8:44 I've recreated the music in TNDY-Tracker and then I played it in DOSBox-VGM to create VGM files. Those files were converted to an IMF like format: 2 bytes to send to the Tandy 3-voice sound chip followed by a UINT16LE for the delay.

Looks like it did take some unknown time to recreate the music, then. I had a brief look at the port's sound code, and it did look like the Tandy music format was very similar to IMF. I obviously didn't expect such modifications of the routines to be 100% compatible with IMF for Tandy.

I also get the corrupted graphics when I play it in PCem emulating a Tandy 1000 with 640 kB or less. To fix it, I run ADJMEM -16 before the game.

Thanks for informing me and others about this. ADJMEM can be tried by me later.

It took a couple of weeks to recreate the music. I had to learn using the music tracker and research what good Tandy music sounds like. Leisure Suit Larry doesn't use the noise channel in its music while Kings of the Beach does.

BTW, there was a request at the Vintage Computer Federation Forums for an EGA version with Tandy music, so I've created CGA, EGA and MCGA (16 colors only) versions with Tandy music and put them on GitHub. The CGA version should run a tiny bit faster than the official id Software version, because I've removed the transparent pixels on both sides of the sprites, so there's less to draw. I've also unrolled some extra sprite drawing routines so the Dopefish is drawn faster in the EGA and CGA version. The loading times were faster thanks to ZX0 compression, but then I improved the memory usage of the memory manager by not using pointers and then the loading times went up.

I'm working on adding fade in/out to the Tandy version, but right now it's really slow in PCem.
The MCGA version is just a hack of the Tandy version. It's compatible with VGA and fading in/out looks really nice in 256 colors.

Using ADJMEM as described by you seems to solve the memory usage problems, thanks!

The addition of MCGA hardware support, even if mostly for its lack of support for EGA mode 0xD, is an interesting case. So is the ability to take advantage of smoother fading; I think the latter should also be possible with the VGA while using EGA mode 0xD.

Since ModID supports Wolf3D's VGAGRAPH files in addition to CGAGRAPH and EGAGRAPH, there was a point in which someone known as furan was experimenting with upgraded VGA graphics, using "cksrcmod" as a base. The work was not finished, but here's a K:M thread: https://www.keenmodding.org/viewtopic.php?t=1940

One bit of thought I've had, is if a Tandy adaptation can be made - at least for the song "Too Hot To Handle" - when it comes to Catacomb 3-D. I don't even know if it's possible to get a port of it to work with acceptable frame rate on the Tandy 1000. BSzili used Reflection Keen (ReflectionHLE) as a base for Amiga ports of Keen Dreams and the 3D Catacomb games. He also ported Keen Dreams and Catacomb 3-D to the Amiga CD32.

Ignoring the frame rate, I expect porting Catacomb 3-D to be at least as challenging as porting Keen 4-6's Star Wars styled scrolling texts.

I'll finish with a few more comments specific to the TANDY and MCGA builds:
- One interesting side-effect of the port is that like the CGA builds, the Tandy and MCGA builds seem to ignore the sprite's shifts field. This leads to smoother horizontal movement of the Dopefish, compared to the original EGA versions.
- It looks like there's a problem with setting the viewport camera position around the bottom edge of a map, or alternatively the bottom of an area bounded by a scroll bar. The camera will briefly pan when you enter, e.g., level 6 or 18. Same holds when entering the first house in level 15. This is further reproduced by pausing or showing level stats and then returning to the game.
- There are multiple rows of pixels around the bottom of the screen which aren't drawn at all in Tandy and MCGA modes. They're left black-colored. The menu, help screens and ending sequence look ok.

Duke Nukem II and Prehistorik 2 are two games that run in EGA mode 0xD but use VGA colors. So I also think it should be possible to have smooth fading in Commander Keen when it's run on a VGA card.

I've been thinking about making a Tandy version Catacomb 3-D, because I've already got the music and the music player code.
I didn't know about those Amiga ports. Neat.

It's nice to hear the Tandy version has at least one advantage over the EGA version. I've never noticed that the Dopefish moves smoother in the CGA version than in the EGA version. Now I can't unsee it.

The camera panning bug has been partially fixed. It still pans on the High Scores screen. I had to replace the hardcoded literal 13 by the constant SCREENTILESHIGH. For CGA and EGA SCREENTILESHIGH is equal to 13, but for Tandy it's only 11. Here's a video of how the CGA version uses 64 kB of memory that wraps round for the gameplay. There isn't enough room for two full Tandy screens, so I had to make the screen a bit smaller. The menu etc. don't use the second screen, so those can be drawn full screen.

Come to think of it, the last version of cksrcmod has a compile-time option for enabling runtime shifting of EGA sprites, while not using separate cached shifted copies. I don't know what impact will this have on performance while using vintage hardware, but with newer hardware (including the use of emulators), this is a good way of saving memory.

Thus, the only advantage I can think of that at least the MCGA build still has, is smooth fading. As written earlier, this can be extended to the EGA build if some form of VGA-compatible hardware detection can technically be added. Alternatively, separate EXEs can be built with a compile-time switch.

I did forget to mention another advantage the EGA build currently has over the rest (including CGA), at least in theory and for original hardware. It syncs to vblank for each frame, via the following chain of function calls: RF_Refresh -> VW_SetScreen -> WaitVBL. The difference might not necessarily be noticeable even on vintage hardware, and the setup might have more of an impact.

From what I remember, there's one major difference between the CGA and EGA implementations. With the EGA, a great deal of manipulations is done while using video memory. With the CGA, almost all work is done in system memory, while the updates to video memory are only done via VW_CGAFullUpdate, from VW_UpdateScreen or RF_Refresh.

With the Tandy/MCGA, you currently seem to use an approach similar to VW_CGAFullUpdate, albeit the hardware is using a subset of the system RAM as video RAM in Tandy's case. I assume that it might technically be possible to use two screens for the Tandy if there's enough memory, but I'm not sufficiently familiar with the technical details. Regarding the MCGA, the situation is maybe more complicated.

NY00123 wrote: ↑Fri Feb 04, 2022 15:19 Thus, the only advantage I can think of that at least the MCGA build still has, is smooth fading. As written earlier, this can be extended to the EGA build if some form of VGA-compatible hardware detection can technically be added. Alternatively, separate EXEs can be built with a compile-time switch.

Doesn't Keen already have VGA and MCGA detection? I'm not sure if it works, but the game does have some code that takes VGA into account.

NY00123 wrote: ↑Fri Feb 04, 2022 15:19 With the Tandy/MCGA, you currently seem to use an approach similar to VW_CGAFullUpdate, albeit the hardware is using a subset of the system RAM as video RAM in Tandy's case. I assume that it might technically be possible to use two screens for the Tandy if there's enough memory, but I'm not sufficiently familiar with the technical details. Regarding the MCGA, the situation is maybe more complicated.

Right now when I play the Tandy version in PCem emulating a Tandy 1000 SL/2 with 640 KB of memory, when I go to level 15 in hard mode with Tandy music, I only have about 3K of free memory left. That's not enough for a second screen.
When you create a new scrolling platformer for the Tandy, you should probably use two screens.

Frenkel wrote: ↑Sat Feb 05, 2022 8:51 Doesn't Keen already have VGA and MCGA detection? I'm not sure if it works, but the game does have some code that takes VGA into account.

You're right, maybe the existing detection code is sufficient.

Right now when I play the Tandy version in PCem emulating a Tandy 1000 SL/2 with 640 KB of memory, when I go to level 15 in hard mode with Tandy music, I only have about 3K of free memory left. That's not enough for a second screen.
When you create a new scrolling platformer for the Tandy, you should probably use two screens.

Sounds like you do hit severe memory constraints when you try to combine the limitations of the Tandy 1000 with the amount of data required for a single 320x200x16-color screen (the latter being the same as the EGA across all 4 planes).

I guess this leaves a few options, Tandy-wise:
- Use an upgraded Tandy. The Tandy 1000 TX reportedly includes 640KB, expandable to 768KB, with memory beyond 640KB being reserved for video-related uses. The additional 128KB should cover four 320x200x16-color screens.
- Draw less to visible area, as currently done.
- What will probably require a significant rewrite, which is to make this work with less memory. While probably not as relevant for Keen 4-6, if I'm not wrong, Keen 1-3's EGA code uses an approach which depends less on double buffering for the purpose of reducing redraws. Basically, from what I remember, a tile at a given on-screen area isn't redrawn if not changed or covered by a sprite. The EGA's Horizontal Panning register can help making redraws unnecessary for a horizontal scroll of up to 16 pixels at a time. Basically, imagine that Keen 1-3 need to redraw all tiles per frame, except for cases where it's known there's no need. The latter works well with repeatable background tiles (e.g., the common Keen 1 Mars background), as well as having just a few on-screen sprites.

Here's a video of the latest version running on real hardware; I recently bought a Tandy 1000 TL.

And here's some footage of the smooth palette fading.

What are the hardware spex of your recently bought a Tandy 1000 TL?