Important
Controls
- Left/Right - Run
- Up - Jump/Climb up ladder
- Down - Duck/Climb down ladder
- Tap Fire - Stab
- Hold Fire - Use equipped weapon
Weapons (Flame Thrower, Rocket Launcher, Grenades) are obtained by killing enemies that start in a crouched position and don’t have a weapon drawn.
The Project
Green Beret on the Commodore 16 is widely regarded as one of the worst video games ever made, with a number of Youtube videos made on the subject. Everything about it was wrong - terrible blocky graphics with washed out colours, unfair collision detection, enemy bullets that tra…
Important
Controls
- Left/Right - Run
- Up - Jump/Climb up ladder
- Down - Duck/Climb down ladder
- Tap Fire - Stab
- Hold Fire - Use equipped weapon
Weapons (Flame Thrower, Rocket Launcher, Grenades) are obtained by killing enemies that start in a crouched position and don’t have a weapon drawn.
The Project
Green Beret on the Commodore 16 is widely regarded as one of the worst video games ever made, with a number of Youtube videos made on the subject. Everything about it was wrong - terrible blocky graphics with washed out colours, unfair collision detection, enemy bullets that travel at the speed of light, scrolling that stops the entire game for several seconds, no weapons, no music....the list goes on.
I had seen some comments saying that the quality of the conversion was somewhat inevitable on the C16, with just 16kb RAM and no hardware sprites. As I have a bit of a soft spot for the machine I set out to prove that this was not the case and that with a bit of effort and planning a playable version of the arcade game that might have been worth a couple of quid back in 1986 was possible.
The thing I can’t quite understand about ports like this is that it takes just as much technical knowledge and programming ability to make an unplayable game in assembly versus a good one. Drawing the map, getting the sprites on screen, moving them about with animation - the hard work’s already been done! When looking through the original code I found that every level was just a complete copy of the game with the map data changed, and it even turns out level 3 was saved onto the tape version twice meaning level 2 is missing. I don’t think anyone ever noticed....
I can only assume the programmer was given very little time and did not have 2-3 months like I did to think it through properly, nor the advantages of modern tools like CharPad, Sublime Text, KickAssembler and VICE. No wonder they did not put their name to it and we have no idea who they are!
What’s In...
Almost all features from the arcade version are present in this new version....
- All four full-length arcade maps, via multi-load
- Smooth real-time scrolling
- Detailed multi-colour graphics, using more of the machine’s 121 colours
- Soft sprite masking so there aren’t big blue blocks around characters
- Flame thrower, rocket launcher and grenades
- All ground enemies (including kickboxer, dogs, grenadiers, cannons)
- Theme music
What’s Not...
Due to the extremely tight memory restrictions, some features such as airborne enemies, cut scenes, sound effects, custom fonts and proper weapon icons had to be left out.
I’m sure some will ask why not just make it for Plus/4 and take advantage of the full 64Kb? In short the answer is that wouldn’t have been a challenge or anywhere near as much fun, and given the amazing quality of recent Plus/4 ports like Turbo Outrun and Lemmings anything less than a near-perfect copy of the C64 version might be seen as a disappointment, and would also have taken another 3-6 months work.
Technical challenges
Map Data
The arcade levels are between 319 and 519 tiles wide, and at least 12 tiles high. Fortunately they have a number of repeating sections, so I was able to export each unique section uncompressed, and then piece together the level again on the C16 by defining a list of sectors and keeping track of which ones should be visible on screen based on how far the player has travelled. To draw the graphics I imported a .png of the arcade map into CharPad to get the overall structure, and then redrew each character as best I could given the chunky pixels and colour restrictions, often combining several similar characters to get the total down per level from 300-400 to no more than 183.
Level 1’s unique sectors
Scrolling
With just 16kb to play with and no hardware sprites, this project had to be carefully planned to have any hope of fitting all the features I wanted to include. The first hurdle was to achieve smooth scrolling without the ability to ‘un-roll’ copy loops as you might do with more RAM to play with. This was achieved by first reducing the map to 12 rows in height, which fortunately only meant squashing the arcade map in a few places. This both reduced the amount of RAM needed for one level’s map data to under 2Kb and fit neatly at $0200-09FF, and also made it possible to redraw the map in about 3/4 of a frame. The C16 actually has a big advantage over the C64 here as the CPU runs at twice the speed when the raster beam is ‘off-screen’.
Soft Sprites
The second goal was to have proper soft sprites that blended in with the background rather than having ugly square borders around them. This is an expensive operation that involves getting the memory address of the sprite data for the correct frame, the memory address of the character currently on screen where the sprite is to be drawn, combining the background and sprite graphics into one character and copying this into a free slot in the character set, before placing that character and the correct colour in Screen and Colour RAM, and doing that up to six times depending on the size of the sprite for up to ten sprites and six projectiles. Oh, and you also need to remember which background tiles have been replaced and what colour they were so you can put them back again the next frame if the screen did not scroll....phew!
The downside is there is some occasional flickering, especially when the screen scrolls as there just isn’t enough CPU time to draw the background and all the sprites before the end of the frame, but once in the heat of battle it’s not really an issue.
Memory
Eventually with all that working correctly I now had about 7kb of RAM left to actually implement all the gameplay, sound, title screen, game over, disk routines etc. I still couldn’t be certain it would be enough to end up with a complete game but I decided it was probably enough to continue - I mean it couldn’t really be worse than the original!
- 2Kb - Character set. Up to 183 tiles for the background loaded per level, the rest are reserved for dynamic soft sprites
- 2Kb - Screen & Colour RAM
- 2Kb - Map data, loaded from disk per level
- 1.5Kb - Sprite data
- 0.5Kb - Sprite and animation data
With all redefinable characters reserved for background tiles and soft sprites, the HUD is drawn using the built-in ROM character set using a raster split to switch between the ROM and RAM charsets part-way down the screen.
In the end memory got so tight that I was re-using bytes within the tiny BASIC ‘stub’ program that launches the game via a SYS command, re-using as much code as possible between the player and different enemies, combing through code looking for opportunities to save a few bytes.
Disk Loading
Having put all the map data in the 2,048 bytes at $0200-09FF I hit a snag when trying to load map data from disk for levels 2-4. The kernel disk routines use a number of memory addresses in that region and there’s even a small bit of code at $07D9, so I stepped one instruction at a time through the disk routine until it crashed due to an overwritten value, worked out what should be there and manually restored the value(s) before calling the disk routine and repeated this until it no longer crashed!
It cost perhaps 100 bytes but was well worth it to have the map data safely tucked away in an area of memory that is not normally used.
The C16 version of CharPad was invaluable, here is the character set and part of the map for Level 1.
Soft sprite characters in CharPad. I initially budget another 20 characters for the airborne enemies, but in the end I needed that space for more code and there wasn’t room to implement their behaviour anyway....
I like to split my code up into small modules so things are easy to find. Here’s some code that finds a valid ‘floor’ near the player for the enemies spawning at the sides of the screen. The code editor is Sublime Text 4.