This is a 60 second page to showcase my version of
Gauntlet for the Vic-20.
The magic of programming within the confines of 4k is that even with 4k there is a near infinite amount of ways it can be used.
- Steve Baldwin


03.25.13: Yeah, ahhh, it's been a while...

I tell you, I really have a lot of things going on in life, but sometimes I get a hankering. This remains something, though, that I still want to finish. It's something I want to be able to check off my list and say, yup, that was not another idea or project that didn't get completed. That being said, I have yet to have a real deadline in mind, so every few years between the world travels, being an extra in movies, making my clients happy, and recording music, I wander back to this from time to time.

This weekend, I tore apart the BASIC version which I posted below. I literally copied it line for line in to a text document where it was extremely easy to read and I was free to comment on the various areas and define what subroutines did. By doing so, I removed some bloat and got it running a bit faster.

That version, though, is not intended for a release, but it makes for a nice testing ground. I can put my ideas in to action before coding them in ML. My plan is to simply replace the BASIC code section by section, subroutine by subroutine until the whole thing is in ML. I've also done some necessary work in converting the graphics to a file, rather than having them as DATA in the loader file.

I also reworked the graphics some and finalized the layout of the game screen, which you can see here. This is a real screenshot of the actual graphics I'm now using, although the game itself is not playable yet.

Next steps (time permitting) is to work my scrolling ML in to this as well as convert a real map to map file. I also have to decide if I want to create more graphics. I'd really like if the bone pile was visually different for health rather than using colors.

Okay, now I can say what this is. I had considered making the Vic version use 4 characters per tile, which gives more visually. The issue is that the 4k version would not be able to handle the graphics. If I were to do an 32k expanded version, it would most likely look like this. This is doable, and would be a hell of a lot more impressive!

I digress, I insist on first making a 4k version. As mentioned, I would be able to use the same data from the maps between all versions.

A new discovery: the Vic can go FULL SCREEN! Yup, with the right pokes, you increase the screen resolution, so there is now more space for a closer match. The example above uses 21 x 30 to better match the real game resolution. Yes, the vic is normally 22 x 23, but 21 x 30 works too. I will need to see what it looks like on a TV as opposed to a monitor, though.

Another discovery: the original version uses maps that are seemingly 33 x 33 blocks. The trick is that if the map is not a borderless one, they only place the outside wall once, so effectively getting 33 x 33 with a 32 x 32 map. The benefit of this is that the map can have a true center. I will need to do some recoding to make this work.
01.26.09+02: The original version I was making as a kid exists again!

After finding my files, I see that I did some updates to the old 1986 version later in 2001/2002. I didn't correct my misspelling of 'tresure', but you can see all the characters of the game now.

What I do have is a VICE image of the BASIC version (downloaded 1748 times) I was testing with prior to doing the ML version. Feel free to download it, but I warn you, it is slow and something goes crazy with the graphics when you open a door.
01.26.09+01: Woah, seven years have passed!

I've been looking at the code and trying to find the disks with the source that I've already made as of late. There are some bugs in the program now, but this VICE freeze (downloaded 1591 times) shows an example of what a map would look like. Use your joystick to scroll about, but realize there are no boundries set yet, so if you exceed the 32 x 32 block map, it will get weird.

The routine in place that interprets 256 bytes and draws the map from it (1024 blocks) may need a new condition added. I checked the original Gauntlet and the sizes seem to match, but the original may have a variable that sets a bordered/borderless map making the border outside of 32 x 32 zone making it 34 x 34 blocks with border. I'll have to examine the original closer. Also, I am only using 4 bits (a nibble) of the map data, so I'm wondering what the other nibble could/should be used for. If nothing, I probably could put 8 blocks in to a single byte rather than the 4 blocks per byte I already have. This would make the display edge a bit more complicated to handle. Another thought was each bit could represent something like the type of wall, 0 = normal, 1 = breakable.

The great thing is that reviewing the arcade version, their screen resolution was quite low. The playable area they use is 16 x 16 blocks, while my layout does 15 x 15 blocks. This gives 4 equal rows to the player info.

I've found the source code from the 2002 version disks, so perhaps I won't have to disassemble and re-enter everything again!

03.21.02: Everything is coming along wonderfully! I've now got a sample (downloaded 1624 times) of what to expect in a Vice Vic-20 emulator snapshot file and a PDF (downloaded 2446 times) that explains everything in detail available. This shows the layout of the game. There also is a bit of interaction added for testing purposes. Using the arrow keys you can scroll around a test map.

  This is one half of the screen update code. I've suceeded at reducing the 1024 bytes of the map to only 256 bytes. All the memory saved will help in the end! This is the part that draws the floor and walls. The next part will interpret the Monster Queue and place and animate the entities. Once that ML is done, the game will be near completion with the exception of the graphics. The maps are to the actual dimensions of the real game, but there will be no smooth scrolling. Everything runs on it's own timer though, so the game play will hopefully be good enough!

   Every effort is being made to create the most compact and efficient version of Gauntlet on an Unexpanded Vic-20. This is in the neighborhood of 5k to work with. I'll even be using the screen areas that are blank to store variables to limit memory usage.

03.18.02: Will put up a proposal and details in PDF form for any to read.

   The PDF contains code, flow charts, graphics and procedures. I hope to generate any helpful means of achieving this goal of making breaking the Vic's RAM in to these parts:

  • 512 bytes using 2 to 3 bytes per Monster in the Monster Queue
  • 384 bytes for the map with each byte representing a 2x3 character space tile
  • 256 bytes for the custom characters
  • 2048 bytes for the actual ML

       The premise is that the Monster Queue will contain all entities that are not the Heroes. This includes Ghosts, Grunts, Demons, Wizards, Lobbers, Death, Teleports, Weak Walls, Keys, Potions, Treasure, Food and lastly shots. Each cycle calls the Monster Queue and it checks which entity it is and then parses the bytes in to X position, Y position, Health and Speed. This is a gray area as I'm still uncertain the level of accuracy to the original game this conversion will have.

       Every effort is being made to create the most compact and efficient version of Gauntlet on an Unexpanded Vic-20. This is in the neighborhood of 5k to work with. I'll even be using the screen areas that are blank to store variables to limit memory usage.

    03.17.02: Started coding a character editor for the Vic-20 in Assembly.

       This has come along quite fast. So far, I've got the interface started complete with cursor movement, text string drawing, hidden characters that user can't edit but don't use any of the 128 user editable characters.

  • If you have any comments or suggestions,
    email me at 99cent@howdymedia.com.