Hardware Hassles

Been a busy holiday weekend… My company, while in software, is also in retail so they wanted coverage during the entire five-day holiday shopping period to make sure nothing went wrong. I ended up doing a couple of very early morning shifts on site and a few virtual ones. I also managed to catch a cold, bleh…

As far as CRPG work goes, I’ve been wrestling with some concerning issues with the game itself. I decided to port my code over to the hardware to test out, and it failed to work. First the loader just failed to load any of the game data, then later it was loading but mysteriously omitting part of the data. (The title screen, in particular.)

I was reading schematics, writing test programs, and analyzing everything (disk controller, memory card) to try and determine where the failure was for the last several days. Upgrading my laptop with a new hard drive and memory, where I do most of the PC side work, complicated matters as well.

I FINALLY sussed it out today… The disk image used by the Lotharek drive was flawed. How it got messed up I’ve no idea, but on hardware it failed to load files correctly. Mysteriously, disk catalog systems showed all the files correctly, and they appeared to be correct in hex code. Initially it seemed like any new disk image I created wasn’t working, but a complete restart of the directory program cleaned everything up.

Part of me is furious at wasting several days trying to figure out the issue… The other part is relieved there is no issue with my code or the other hardware! I was being careful to make sure that any hardware requirements were met.

Re-writing the game to make use of the expanded memory has been good for making better code and making better use of what’s available on the system. I figured out how to use the “read/write files by sectors” disk operation which is used for both loading the program data into memory pages (128k worth) and to copy and overwrite saved game files to prepare a new game. A lot of my old infrastructure code for file management is getting removed and re-written since I’ve cut down file usage considerably. I also ended up removing the idea of “disk paths”, the native TI disk system uses a number or letter designation for a drive, which the best 3rd party extensions (like the Horizon RAMDisk) just extended rather than replacing. I’ve decided to make the game just expect the game disk to always be in the first drive (DSK1) rather than have it be clever and identify it’s origin disk on load. If I get a LOT of push-back I may add that back in.

I’ve also decided I’d better start sharing a progress list. It always feels good to check things off a list! I’m working on one module at a time, and adding common functionality to the root module as I go along. For example, base file management is in root, but each module would have individual file controls for specific data types.

You can find my progress list on the tabs for the main page!

Posted in Coding, CRPG, Design, TI-99/4a | 2 Comments

Picture Perfect

The work continues… I absolutely intend for this game to be finished and complete in 2018. It’s amazing how many different pieces and parts need to be completed though to make that happen.

Right now, I’m working on something I’ve been doing off and on since the start of the project, the opening title screen (with music) and the interface for creating new games. The code has never been written so it’s a new fresh thing to do, and it’s helping me sort out which functions need to be in the “root” module.

The title screen however, I’ve had a prototype of that for awhile. First some background…

The TI-99/4a’s video chip is the TMS9918A, released in 1979. The “4A” part of the computer’s name comes from the fact it has the appended version of the original chip, which added “bitmap mode” to the TI. After studying it and working with it for some time, I have to say it was probably one of the best chips on the market until the Commodore VIC-II came out. And even then, it was still competitive; if the TI had possessed the same level of 3rd party software development as the Commodore you’d have seen some pretty impressive games on it.

MSX Game using TMS9918A

This same chip was also used in the MSX computer systems that were in widespread use outside the US in the early and mid 1980’s. MSX games actually look a lot like classic Nintendo games; I suspect that many of the same developers went on to write NES games and used similar software techniques to maximize the hardware.

The MSX2 platform had a successor chip, developed by Yamaha based on TI’s original schematics, called the 9938 (and later 9958), which offered 80-column resolution and much greater sprite and color support. Adding a 9938 or 58 to the TI was a good way to get an 80-column mode.

So bitmap mode on the 9918A was meant to give the TI the ability to do “turtle graphics” like most of the other platforms of the day, which could freely draw all over the screen. And so it does… but with some critical differences in implementation.

Most other computers approached high-resolution video as follows:

  • Determine a color depth in bits. (Usually 1 to 2 bits, for 2 or 4 colors)
  • Create a video buffer in CPU memory of the requisite size. (A 256×192 screen would require 6K. Double that for 4 colors.)
  • Render the screen by processing left to right, up to down all the pixel data in the buffer synchronously

Six colors! Worship the Woz!

Most 8-bit computers didn’t have enough CPU cycles to render the screen with a lot of colors, so some would double the pixel width to gain more colors, creating an odd hybrid look. This was typically referred to as “artifact” colors, this effect can be seen on the Atari 8-bit home computers, Tandy Color Computer and Apple II. (Wozniak, being a brilliant engineer, also figured out a way to get six artifact colors not just four, among other optimizations.)

TI took a different approach. They extended the existing “graphics mode” which used an extended 256-character ASCII table by adding two more tables so you could fill up the entire screen with 768 patterns. Then they expanded the color table to match it in size, so you could define a foreground and background color for every row of 8 pixels. Some mathematics are required to calculate pixel location, since it wasn’t a continuous buffer, but this allowed you to have complete control of the screen to the pixel.

This approach has some advantages. Unlike every other computer, the TI can have ALL colors on the screen at all times. And with a cell-based architecture, things like scrolling are a lot easier to do, albeit at the cell level, not the pixel level.

Blue and red only intersect well in some cases…

Of course, there are trade-offs. Only having two colors for every eight pixels requires some artistic planning to prevent “jagged” effects. This is somewhat mitigated by the fact the TI doesn’t render color differential all that well in NTSC. An example: If you place two single pixels of two different colors next to each other, unless they are VERY different in brightness and tint, you won’t be able to discern them. Two pixels of the same color next to each other, though, stand out much better.

A far worse problem is that the 9918A has it’s own memory separate from the CPU. Changes to it are done through a memory mapped port, which means the CPU has to spend cycles moving data back and forth. On paper, using 16-bit memory for registers and ONLY registers for the move, you could theoretically pass data fast enough to update the 6K pattern table at a 30/second frame rate, but in practice it doesn’t work. Games such as the Red Baron Flight simulator get around this by only doing partial updates.

Also, the VDP chip only had 16K of RAM, and you’re using nearly 80% of it just to render the screen. Add in a sprite pattern table (another 2K) and you’re pretty much out of memory with no room for buffer space. This can be problematic if you want to use disk file systems; they require at least a kilobyte at the top of RAM to operate.

Finally, by separating color from pattern, it makes color and pattern changes difficult to do at the same time. Other computers had to create sprites in software by storing pixel patterns and finding ways to “blit”, or “bit block transfer” graphics over top each other to create a seamless sense of movement. The TI can do this, but not very well as you have to move stuff at least 8 pixels at a time horizontally to prevent color corruption, and two writes to two different areas of memory may lead to a “jumpy” look with color lagging behind the pattern change.

For the CRPG, I’m using bitmap mode, but a hybrid form of it. You can configure the VDP registers to mask out the extra color and pattern tables and get an “enhanced graphics mode” that gives you the color depth of bitmap mode but only in a single table. There is a small trade-off with sprites; they are dependent upon the pattern table register for some calculations and the bitmask throws them off so you only can really use 8 instead of 32, but it’s an acceptable limit.

Moran, Thomas (1837-1926) The Grand Canyon of the Yellowstone, 1872

For the title screen though, I’m using full bitmap to make a beautiful scene, based on a painting by Thomas Moran. The only problem I had was, how to draw it?

Most of the graphics programs on the TI have the same fundamental problem, they’re trying to apply a pattern that doesn’t fit the TI’s architecture. Drawing lines and circles is not the way to make a good looking title screen. Most of them fail to expose the true nature of bitmap mode as well, neither telling you about the color limitation or giving direct control of foreground and background color. (Paint N’Print is probably the most usable in this regard, but it alternates foreground/background with no indication of which you’ve changed.)

There’s a couple of modern tools you could use for this work.

Magellan is designed to let you edit character sets and draw maps, but it doesn’t have bitmap-friendly tools. (extend to three tables, plot all characters automatically to make a drawing grid, etc.)

Convert9918 is a well-designed tool to convert any existing image to 9918A format. It has a wide variety of different algorithms to color match and render images. In practice, though, I haven’t found settings to get the effect and appearance I want. In particular, details get lost and you get some weird color choices at times.

The work so far…

So how am I doing it? I wrote my own bitmap editing tool. Since I’m only really working at a pixel level, it doesn’t need to BE in bitmap mode all the time, just have a memory buffer of data I can edit on screen and then occasionally view to make sure it looks good. Using a paint program I drew a lattice of grid lines on the image I want so I can approximate things and decide which objects I want to stand out and which ones I want to mask.

So that’s what I’m doing… it’s slow-going, but very satisfying because as an artist I have control over how it looks. And I think I can make something very cool. 🙂

Posted in CRPG, Design, Graphics, Screenshots, TI-99/4a | 3 Comments

Legends of Yesterday

Quick post about this, the CRPG Addict has played, won, and reviewed Legends on the TI!



His final rating is to my judgment very fair… I’m glad he found it was fun enough to finish!

I’m also really jazzed he was able to contact the author, Donn Granros, and get some interesting information about him and the game’s design.

Posted in CRPG, Review, TI-99/4a | 1 Comment

Data Dump

Been quiet for a couple weeks… I’ve been heads-down on writing up all the transactions for the first disk.

Here is a breakdown on the first disk’s contents:

  • Dialogue is in game text, stored in four sizes. (16, 32, 64, and 128 bytes with compression)
  • Monster data is statistics, graphic data is self-explanatory. 🙂
  • Map data is uncompressed maps, map headers are metadata, elevation data is for specific maps
  • Mobs are special objects on the maps
  • Transactions are scripted commands and actions for a given mob

The width indicates the record’s size in bytes. Estimate is how many records exist. Sectors is how many disk sectors (which on the TI are 256 bytes) it will take up. This includes a single sector used for tracking. And finally the size in kilobytes. The total size, 176k!

One thing to note here is that the mob file WILL change as the game progresses, so it will be both read from and written to. The other files are all read-only. I always had it on the table to move the mob files to the game disk just in case I ran out of room, but it looks like I should be able to get all the content I want for a rough 25% of the game into a single 180k disk.

The script encoder has been working out well… it occurred to me a few days ago that it’s nearly good enough to be a shareware CRPG script engine! 🙂

The process of scripting has been interesting. I’ve been adding, revising, and changing the actual script language as I go along. For example, I originally had commands to do various byte/word manipulations so that you could spell out all the game logic if needed. In practice, though, this leads to a lot of repetition of the same kind of activities over and over again. While I could apply an effect and give feedback if a player doesn’t have enough money to pay for healing, it’s cheaper and more economical to encompass this into a !HEAL script command that just gives the internal engine the values it needs. (Cost, power, etc.)

I also ended up revising text, a lot. I now have a text encoder that encodes the entire disk’s contents and assigns record values for all of them, outputting the contents to a text file. I can then copy and paste those values into my text spreadsheet, which allows me to easily assign them contextually in scripting. I found I was gradually shifting text more into the larger dialogue files (64 and 128 byte size) over time, but in the end this worked out pretty well for disk space. The only downside to text revisions was it meant I sometimes had to backtrack and update references…

I also wrote a new tool, a text formatter, which formatted all the text lines to fit a 30-column screen. I found that I was often much too “wordy” in places, and that I had to both cut down the amount of text and make it fit better on the screen.

Ideally, writing a complete tool that stores all the text, mobs, and transactions would be the best thing to do. Then if you changed text it would just dynamically re-assign it for you. I’m not really sure I want to take the time to write up such a complex tool though, it feels a bit too removed.

Eventually, I’ll need to write a “transaction player” running on the actual TI. This would let me pick and choose a transaction to “play” so I can view what it would look like in the game, with tools to set particular flags on or off. This will make testing MUCH easier.

I’m nearly done populating data, what I have left to do is populate the monster data with treasure items (item revisions and changes has been ongoing) and then figure out the mob system for graphics. My new design will allow for up to 256 unique patterns, so I need to define those at least for the first disk…

After that, it will be time to work on engine code!

Posted in CRPG, Design, TI-99/4a | 5 Comments

Moving On Up

If the site looks a little different to you, there’s a reason… I’ve relocated the blog!

My WordPress blog on Yahoo has been stuck on a prior version for several months now. When I contacted their customer support, they pretty much said they weren’t compatible with the latest and that they would have it working “eventually”. During which time none of my posts propagated to the main site unless I explicitly attempted (and failed) an update. I also ceased getting emails telling me that a comment was awaiting my approval.

I’ve been unhappy with Yahoo as a host for quite awhile now… Aside from the fact the company always seems to be on the verge of Chapter 11 these days, they split off their business web hosting side into a new company called Aabaco, part of some larger futile effort to avoid taxes or leverage more money out of it. The result is poor lackluster service.

We’ve been using AWS (Amazon Web Services) at work for the last few years, and I’m impressed with their work. In particular, storage space is very affordable, and running a WordPress blog should be pretty cheap! (After the first free year of course.) So I’ve relocated there and been very happy to do so!

Fair warning, I eventually want to put up some pages for my CRPG, so I may stop re-directing the main domain to my blog eventually. You’ll always be able to find it at adamantyr.com/blog!

Posted in Blog, CRPG, Personal | 4 Comments

More Ingredients

First of all, congratulations to Sinphaltimus for being the first player to win Wizard’s Doom! Along the way to a 93 rating, he also discovered several bugs I had to fix with the final encounter… Well done!

As I’m working on the CRPG, I want to make sure that the game has enough depth in play that it remains interesting all the way to the end. Some things I’m adding and changing in design:

  • Weapons, armor and spells now use a damage type system, with slashing, piercing, blunt, fire, cold, etc. This allows for nuances like a skeleton being tougher to kill with a sword than a club.
  • Weapons now have a throwing quality, so you can throw them in combat. Most are one-time use in this manner and it leaves you without a melee weapon for the rest of the combat. Some magical weapons return to you, allowing unlimited use in this manner.
  • As part of moving item names and attributes into CPU memory, I can also have a “readied” weapon approach much like Tunnels of Doom did. So switching from a melee to a ranged weapon to a spellbook takes an action point.
  • I may expand the party size from 4 to 6, but only allow you to create up to 4 maximum to start with.
    • On that note, I may need to add a “hostel” system of some kind so you can remove characters but retrieve them later.
  • I’m considering adding an “item storage” system so you can bank extra items for retrieval later.
  • After thinking about it awhile, I think I will add in attributes and also expand out the skill sets. Because I can keep more active data in memory more easily, the calculations aren’t as crunched as they used to be. My chief concern is to avoid having any classes become automatically “better” than another.

I’ve actually completed all the regular sized monster graphics for the first quarter of the game, which was a lot of fun to do. My “monster editor” proved to be an easy and fast tool to do the work with!

The “boss monsters” are taking more time, mainly because I’m trying to get them to look just right.

I’ve also been re-working monster statistics to match my new approaches. For certain damage types, reduction applies, for others it doesn’t. That means monsters may end up with a lot more health than the players typically have, since they may have no damage reduction at all against a particular common attack.

I still need to get the transactions done for content, and I may need to create some more tools to convert text listings into binary code so I can easily update item lists, monster statistics and so forth. After that’s all done I hope I can start working on the common and travel modules and getting the game engine back on it’s feet!

Posted in CRPG, Design, Screenshots, TI-99/4a | Leave a comment

Putting it Together

Hello everyone… Or like, both of you. Or one of you. Maybe. 🙂

I’ve actually been hard at work on the CRPG for several months now… After the TI faire I got myself an AMS card, which gives the TI a megabyte of CPU memory to play with. I decided that I wanted to upgrade the CRPG to use it, so that I could do a bunch of things I wasn’t able to do before.

The biggest pain point with this is the architecture change. Most TI software wasn’t designed with segment/module coding in mind, and as a result, there’s almost no way to write them. A gentleman named Art Green did write an AMS linker way back in 1993, but it’s a bit heavier than I’d like, and it would require me to do all my compiling in emulation rather than with an external tool.

So in order to make it work right, I will have to write three different sets of source code, one for each major module in the game coupled with a common module. Then I can compile each module to fit in the original 32K confines, take the compiled code and create the necessary binaries that will be loaded into paged memory. I’ll also have to write my own custom loader as well…

This approach will let me do some things I really wanted to do but due to memory constraints couldn’t. For example:

  • Double-sized monsters, occupying 4×4 characters. Perfect for large creatures like giants and dragons
  • Multiple monsters, such as a group of bandits accompanied by a bandit captain and a rogue sorcerer
  • NPC’s who can join a party that is under 4 characters in size along your travels
  • Graphics sets, items, spells and sound effects are all stored in CPU memory for much quicker load times! (I’ve been spoiled in emulation with extremely fast speeds)

Right now, I’m working on content. I realized I needed to have some actual game content to complete, test, and refine the game engine. So I have divided the game into rough quarters, and am working on the first disk, or 25% of the game.

What have I got done?

Well, the first thing I did was rework the graphics. Now that my TI is setup and running, I was able to re-evaluate them on an actual NTSC screen. I also decided to change my approach and use more colors to make them “pop” better… something MSX games did to very good effect. I’ve been very pleased with the results! This is definitely a TI game that makes FULL use of bitmap graphics capacity.

I then completed all the maps for the first disk. This was time-consuming, as some hadn’t really been even drawn on graph paper, and only existed in concept. I also didn’t want to waste a lot of map space on a map that had only one purpose, so I was removing and adding entries all the while. I also made elevation use an option, so not ALL maps have elevation. This saves some disk space and is more efficient, since most maps don’t need it.

A big change was I’ve dropped the idea of storing battle maps on disk. As I increased the terrain types, I realized the battle map file was consuming a ridiculous amount of memory. I was aiming to keep each quarter of the game to fit on a single 180K disk, and the battle maps easily pushed it over. So my plan now is to create battle maps dynamically based on the terrain around the player. I’m still thinking about that algorithm, but with the added memory it should be doable…

I also completed all the mobs (mobile objects) for the maps, although many have empty data values for monster tiles and dialogue/transactions. My goal here was to determine how many mobs I would need, and it worked out about where I thought it would, just over a thousand for 64k of maps. As part of this, I wrote a new tool in C# to create the mob binary coding from text files. This lets me make changes quickly and easily, then just paste the entire block into a binary file.

I’ve written out all the dialogue for the first disk, although I’m constantly adding and removing entries… My compression algorithm wasn’t quite as effective as I’d hoped; it averages about 18%. But for now it works pretty well. I’d have to write some tools to find common words in my actual text blocks if I wanted to try and write a better one. A job for another day…

I’ve also decided to make monsters game disk-specific as well… It just makes sense, monsters are geographically located and if you end up repeating a few it’s not a big deal. My initial write-up ended with around 84 monsters, but that could go up or down. This is ongoing work because I decided to give monsters a full bitmap color block, which means I have to redesign the graphics to take advantage. I realized that there weren’t really any good tools to do monsters easily, so I wrote my own! Hopefully I can have some fun with it while I draw them up…

The next stage will be writing up all the transactions. I have a few done, but it will take awhile to write ALL of them… and there will be considerable cross-referencing done with the mobs and dialogue on the way, which makes it very time-consuming. I figured I’d end up with at least 2k (2048) transactions before I’m done, but it could be easily double that. Fortunately they take up very little space on disk.

Once I have all the game data done, it’s on to the engine! My plan is to get the Travel module done first, followed by Management (Inventory & transactions) and finally Combat.

Posted in Blog, CRPG, Design, Screenshots, TI-99/4a | 5 Comments

Running the Gauntlet

Hi all!

So I went to Fest West 2017 this year, down in Woodland, WA. It was a 3+ hour drive for me to get there, but well worth it. I met a lot of great guys and saw some pretty awesome stuff. I was even able to acquire a new NanoPEB that DID work with Wizard’s Doom (Apparently my CF card reader is, in fact, busted in some weird way) and an Extended Basic 2.7 Suite cartridge. Going to a convention for your vintage computer hobby is a lot of fun and it really helps inspire you to do more with it.

So what’s my next TI project? Well, I’m taking a short break (hopefully) from the CRPG to do something a bit different, an arcade/action game. I’m also returning to assembly language, because I want to really push some limits on the TI.

Specifically, I want to write Gauntlet for the TI. 🙂

Why? Well, it was far and away one of my favorite arcade games back in the day. Even as a kid I was fuming that it was available on the Commodore 64, Atari 8-bit, and Apple systems but not the TI. And then recently I discovered the ZX Spectrum and the MSX platform had it too! 🙁 Knowing a MSX version existed though made me realize it SHOULD be possible.

The first thing I realized was I could not use the baseline TI’s memory. Every single port of Gauntlet for the home computer system market had at least 64K of RAM, and it’s needed! In particular, storing graphics and animation frames consumes a LOT of space. So I am using the SAMS card to make sure there’s plenty of RAM available. This solves some other problems as well; I can use memory-over-time solutions in several places.

The biggest hurdle is going to be updating graphics in real-time. The MSX version (which I studied in a debugger) essentially keeps the character sets static in the upper 2/3 of the screen, only changing them dynamically in the lower 1/3 for the 3 rows of graphics. They also only change patterns and not colors for animation. I want the TI version to do better than this. 🙂

I’m not going to call the game Gauntlet for a myriad of reasons, mainly because there are aspects of the game I don’t like that I want to make changes to/improvements on, and I also want to port some of the fun things from Gauntlet II into it.

Currently I’m working on a prototype scrolling map display to see how it performs. The basic algorithm is as follows:

  • Store the entire dungeon map as a literal set of tiles, each tile is 8×8 pixels in size. There are a potential of 608 unique patterns, so a full word (16-bit is needed.)
    • This will consume 8192 bytes, or 8k.
    • The map has NO mobs (movable objects such as monsters)
  • Extract the viewable area from the map into a buffer space, which is slightly bigger than the screen. Wrapping occurs if it goes beyond boundaries.
    • This is refreshed anytime the map is scrolled or mob movement is done
  • Iterate through a mob array, checking if a mob is present in the viewable area. If so, copy their tile patterns to the buffer in the appropriate location.
    • Also store the mob you just placed into a “visible mob array” which stores their local coordinates. That way you can quickly decide actions for mobs that can actually move.
  • Using a “character pattern index” for the section of the bitmap video display, create a “view buffer” that uses actual character pattern values (0-255).
    • If a given tile isn’t in VDP yet, get it there, either immediately or store it into a larger buffer that’s written all in one write.
    • If you run out of patterns, reset to zero and restart.
  • Write the character pattern changes to VDP.
    • I may utilize a hybrid bitmap mode so that the upper 2/3 of the screen use the same character pattern set for better speed.
  • Write the view buffer out to the screen. This may also include updates to the bottom statistic area such as health count and score.
  • On given interrupt intervals, change the animation patterns used and update accordingly.
    • This is where it could get messy; I may need to have a separate stack array that stores the current “mob” patterns that need updating in a given block.
    • For simplicity it may be best to just do a complete linear write of patterns and colors rather than trying to do them individually.
  • Animated static tiles (like treasure chests) are only animated in color, not pattern

The big question is, will it be performant enough for an arcade game?

I don’t need the view to scroll particularly fast; if you play the arcade version of Gauntlet, which I have in emulation quite a bit, the map actually scrolls at a steady speed. Even if you are playing an Elf who moves very fast, the map speed doesn’t change. But I don’t want to see distortion or glitches while it updates either.

The question is if the animation will slow it down too much. I had a thought of having the animation patterns just be brand new characters introduced and replaced, but this will DEFINITELY overload the pattern buffers, forcing me to either clean up unused ones or redo the entire buffer from scratch more periodically.

But you don’t know until you try it all…

Posted in Coding, Design, Gaming, Screenshots, TI-99/4a | Leave a comment

12 years (and counting…)

So what I have been up to, what am I working on, when is the CRPG going to be done? What’s going right or wrong? Time for some answers…

Real Life

In real life, work is actually going pretty well! But, if you spend all day doing software design, you’re kind of burnt out by the end of it. You’d rather read, watch TV, play video games, anything else to recharge the batteries. I also have other chores to deal with such as home care, laundry, dishes, taking care of my cat… As a result, my time to work on hobby software projects is not as much as I’d like. I need to step up efforts to win the lottery. 🙂

Hardware Woes

Recently, I’ve been getting very frustrated with running TI software on the actual console. I have one of the CF card reader systems (now called a NanoPEB) but it’s been getting hard to work with. It doesn’t work with memory image files that are larger than a certain size. For example, bitmap drawing programs fail to save or load files. When I tried loading my recent Extended BASIC game it fails to load the low-memory assembly routines, giving a cryptic IO error. Argh!

The problem with vintage hardware is you’re either all in or out… you have to spend a considerable amount of time and money if you want to get a hardware setup that works correctly with modern computer systems for transferring software. I’m not sure I want to do that, because I’m just NOT a hardware guy. If something goes wrong, I can’t grab a soldering iron and fix something.

Other Projects

I got a bug in my brain to do another software project on the TI, which has been consuming more of my attention. I don’t want to say much about it yet because I’m not sure I can get it done to a satisfactory level, but it is an arcade game…

I’ve been using the TI’s advanced memory system (which I don’t have but is emulated well in Classic99) and it’s been a refreshing change of pace from the tight memory constrictions I’ve had with the CRPG. I’m even considering saying “Screw it” and just using it for that project as well! It won’t speed up work on the CRPG (content generation isn’t something more memory will fix) but it at least makes the engine work less of a trial.


Things are basically about the same here.. I’m generating content. I think the big fear I have here is, am I writing good content or not? Is it lame and stupid? Reading the CRPG Addict’s experiences with various games and how some have great story lines and others are terrible has me feeling a bit under pressure to deliver something much better than old tired tropes. (“There’s an evil wizard… in a castle. Uh, slay him. Yeah.”)

Yahoo Concerns

So as we all know, Yahoo is NOT doing well… and they are my current web provider.

Sometime last year, they split their web service into a separate business called Aabaco. Unfortunately, this hasn’t improved service all that much, and I am concerned that I may be asked at some point in the near future “Hey, where did your website go?” I’d better do some local FTP copies of all my content soon…

It isn’t the first time I’ve had to relocate my blog, but I’d like to try and preserve the WordPress version of it if I can. (Not a fan of Blogspot) And I’d like to take my domain with me if I had to leave Yahoo, not sure if that is doable. If I had a choice of new webspace, I’d probably go with either AWS or Azure.

An Apology

Finally, I am sorry that I don’t update often enough. I know the CRPG work has been going on a ludicrously long time now… I really should just sit down and finish something, even if I’m not happy with the design.

I was reminded of the importance of communication recently when I saw a video on YouTube called “Whatever happened to…” concerning a video blogger I like and followed. In the last couple years their content generation of funny movie/video game reviews dropped to nothing, their Patreon account dropped from 5k/month to under 1k/month, etc. And worst of all, they have been utterly silent in social media, confining themselves to Twitter and banning anyone who asks why there hasn’t been any new content.

I don’t ask for money to do any of my hobby work, but I realized I didn’t want to be THAT kind of person. I want to make sure everyone knows where I’m at and where I want to go with things.

Posted in Blog, CRPG, Personal | 3 Comments

Dungeon Crawling

So… In the last post I mentioned working on some TI-99/4a side projects. Well, I have finished one! 🙂

It is a 3D dungeon game called “Wizard’s Doom”, a spiritual sequel to the “Wizard’s Lair” and “Wizard’s Revenge” games developed by Rainbow software in the mid 1980’s.


“Wizard’s Lair” was the first TI game I personally bought with my own money, ordering it from the Triton catalog. It was one of those things I would anxiously check the mail for every single day. I let out a literal whoop of excitement the day it arrived. 🙂

And what about the game itself? For a game designed to run in TI Extended BASIC with no disk system or memory expansion, which means it had about 13k at most to work with, it’s pretty good. The game runs at a decent speed and has greater depth and nuance than most games produced for the TI-99/4a at the time. It was definitely worth money! The sequel is essentially the same game but with better graphics and some new twists.

The manual is very professional; the cover artwork is amazing and as far as I can tell, original. I can’t read the signature in the corner to determine the artist, but I’ve never seen it reproduced elsewhere. The manual was also not a cheap photocopy job; you can tell this because the cover has ink all the way to the edge, which is only possible if you printed it on a printer at 9×12 size and cut it down. And the cassettes and diskettes for the game had a shiny embossed label in two colors.

The games are a derivation of “Dungeons of Daggorath”; they share the same plot and basic game play. However, in comparison to that classic game, they are laughably simple… Granted, Dungeons of Daggorath is written in 100% assembly, so it has an advantage.

After 30 years, I thought “Why not write a sequel to Wizard’s Lair and Revenge? One that actually plays more like Dungeons of Daggorath in terms of depth and challenge? And uses a disk system and 32k RAM for maximum play-ability?”

And that’s how the project started…

Initial Design and Prototyping

The first step was to write my own maze generation algorithm. I’ve done some of this previously with experimenting doing a Rogue-style game, and in a Java project I did back in college over a decade ago.

The basic algorithm is: Create a 2-dimensional grid of empty squares. Pick a square, random or determined, mark that square “open”. Try and move in a random direction, and if you can, open the new square and make a connection between it and the prior square. You can either always look for empties, and back-track if you can’t find any, or just go through occupied squares. You can stop either when it runs out of chambers or have it track how many it’s created and stop arbitrarily. You can generate a lot of different styles of mazes with just a few simple changes to the algorithm in places, and it’s easy to seed with a fixed random value to generate the same maze time after time.

Studying Wizard’s Lair, I was amazed at how slow the algorithm was. It takes it several minutes to generate a maze, more than ten at some points, and other times it’s oddly fast. Part of the reason is the code infrastructure is sloppy with a lot of GOSUB and GOTO’s involved, rather than a clean linear approach. The other issue is that it doesn’t handle dead-ends well; if the maze is plotted without running into any other chambers it goes pretty quick, but once it has to deal with dead-ends it slows way down.

I wanted a fast generator, because I wanted each level to get progressively larger as you descended. I also wanted to use bit-wise operations to store directions in each chamber, which is much more efficient. (So the 1 bit becomes “north”, the 2 bit is “east”, and so forth.) I also added tracking for all open chambers by putting their row and column values into two strings. That gave me a record of chamber locations for backtracking, as well as placement of random monsters and items.

For dead-ends, I had to figure out how to handle them in a quick and efficient way. I wanted to keep the mazes from becoming too “single path” oriented, where one way just leads to a dead-end, I wanted 4-way crossings to be more common. So I put in a random check to determine if it backtracked to a prior chamber to look for new empties (using the chamber location strings) or if it just forged through an already open chamber. It also only tries once to backtrack; if it fails to find empties a second time it automatically plots through an open chamber. Playing with the randomness, I narrowed it down to a value that seemed to work and generate decent mazes that had the aesthetic I wanted.

After creating the maze, I wrote up the code to generate the 3D view. I wanted it to be faster than the original games were (which were okay but not great), but I quickly ran into problems…

The truth is, TI Extended BASIC is not very fast with video operations. At all. Drawing characters on the screen with HCHAR and VCHAR is decent in a single statement, but the overhead of calling multiple statements is much slower, creating visible drawing artifacts. I tested using static DATA statements to store positions for drawing, but it was no faster. In fact, the probable fastest method is to do direct stacked lists of call commands that use no variables, only static values.

I had some more complications as well… While doing some graphics design, I decided I wanted to use brick patterns for the dungeon walls. For the far off and middle-range bricks, I only needed two repeatable patterns. But for the close-up view, I wanted to do 2×1 size bricks, which meant I had to alternate the pattern every other row. I tested using DISPLAY AT for this and it worked, but was so slow… Taking tens of seconds to draw your view was just not acceptable.

So this got my mind going another direction… why not use assembly language for the drawing routines? And maybe more…

Assembly and BASIC

Let me give you a bit of background on this subject…

TI Extended BASIC has always had the ability to support assembly language routines. 25% of your memory expansion is actually inaccessible to Extended BASIC except via assembly routines; the 8K lower RAM area. A command was supplied (LOAD, which also doubled as the POKE command) to load assembly files directly into the 8K RAM, where you could then call them using the LINK command, passing values back and forth to assembly language routines.

However, the documentation on setting up assembly language subroutines for BASIC and Extended BASIC is, well, absolutely awful. All the information is actually in the Editor/Assembler manual but it’s so hidden that you’d never find it unless you knew what you were looking for. Also, TI Extended BASIC and TI BASIC are two separate environments (three, if you included TI Extended BASIC with and without memory expansion), and the documentation is hazy at times about the differences.

The first big issue is figuring out how to pass data into an assembly routine. This is where things get messy because you have to be familiar with how Extended BASIC stores data on the stack and how to determine if the value is a static, numeric, or string. The original documentation recommends using a library package TI provided for all your access needs. But it’s an enormous waste of generic code designed to handle every potential combination, eating up a good chunk of that 8k. Plus, TI didn’t provide source code, only binaries.

The second issue is dealing with the character set bias. TI BASIC and Extended BASIC relocate the ASCII table upwards by 96 characters because they had to make room for other things in video memory in the lower character values. As a result, any characters you want drawn you have to add 96 to in assembly.

It took a lot of reading of documentation, and even experimenting in the emulator with the debugger screen to look at memory addresses during execution, but I finally figured out how to write my own routines to extract static and variable values from a passed LINK call. It helped that I only needed numbers and not strings. I then wrote up my own video plotting routines to draw the maze sections, using a passed numeral value to indicate which section and if it was a wall or corridor, so it could branch to the appropriate routines. And it worked beautifully!

My first design used an internal buffer approach. It would draw in the buffer and not on the screen, and then output the buffer to the screen after it was completed. To my surprise, this didn’t work well. While navigating the maze, you’d push a direction button and after a notable pause, the view changed without any warning. I realized that the lack of a “feeling” of movement was the problem.

So I altered the design so that the BASIC code just calls LINKS for each section, essentially replicating what the original games did, just replacing the HCHAR and VCHAR calls with a single LINK. Testing showed that the movement issue was solved; you saw the corridor being drawn but it was acceptably fast and you had a definite sense of responsiveness.

The last issue with assembly routines in BASIC is loading them. The manuals advise you to use the LOAD command, which does work… but it’s incredibly slow. I only have around 2-3k of assembly code and it took several minutes to load in this fashion. It only needs to be done once at the game start, but having to wait 4-5 minutes for the game to finish loading isn’t cool…

Fortunately, another 99’er solved this issue years ago. Barry Boone wrote the Systex loader, which lets you take your assembly routine and merge it into an Extended BASIC program. The typical approach with Systex is to write a “loader” program which just runs your main program. You embed your assembly routines in that loader, and you’re good to go! It also has the advantage of obscuring your assembly binaries from casual viewing.


The other advantage of going to assembly routines was I could do something else I truly wanted… monsters bigger than the original single sprite that was in the first two games.

Wizard’s Lair and Revenge used a single 16×16 size sprite for monsters; the first game even used the same monster graphic (an impish creature) for every monster in the game. This works all right, but the monsters appear very small against the larger large 3D dungeon window (which takes up more than 2/3 of the screen.)

I had already been considering using more sprites for monsters, but moving to assembly was necessary to make it a viable option.

Why? Well, TI Extended BASIC can handle sprites, but typically only when you’re just doing one at a time. The manual specifies you can control multiple sprites in a single command. But in implementation they are NOT in sync with each other. For example, telling two sprites to move at once, you can see that the second starts moving after the first one starts.

The problem is that the subroutines provided actually process sprites one at a time, doing a full video read and/or write, then looping for the next one. This makes multi-sprite operations where you either want them to be alongside each other or over-lapping very difficult to manage. In assembly, things can be done quickly and in blocks, which makes sprites move instantly, change color instantly as a group, and so forth.

I had one other issue to solve though… TI Extended BASIC has a very limited character set, and that limit still applied even in assembly. I decided to do pattern swapping when a monster was on screen so I could have the best number of 16×16 patterns (eight) available. This meant that items and other sprites that appear in dungeon corridors wouldn’t be available when a monster was present. I decided it was worth it for the better graphics. I also used the same technique when drawing the map of the dungeon; swapping out character sets so I could show a more better detailed map than the original games.

The monster graphics themselves turned out to be a bigger job than I’d imagined! I didn’t want to copy any existing game’s graphics, so I decided to draw them myself.

I started with the wizard on the cover of the manual. I drew some boxes on him and tried to approximate the pixel locations. Funny enough, as I worked, either my natural artistic ability came out or I just got lucky but he slowly changed to be slightly angled in profile.

The end result was very nice, so I decided to extend it to every other monster; find a picture online (thank you Google images!) and draw boxes on it and plot them out. Nearly every monster ended up looking radically different from their original artwork. So I didn’t feel like I was “stealing” anyone’s work, more that I was inspired by it.

Abandoned Ideas

With any project, you occasionally have an idea that doesn’t make it in… mine in the case of this project was the Speech Synthesizer.

I wanted the wizard to give an evil laugh when the player reached level 6, just to freak them out. When you actually found the Evil Wizard, he would say “Die fool!” when either you or he initiated combat. Possibly a scream of “Noo!” when you defeat him. And finally, anytime the player died you would hear the wizard say “And yet another does not return…” My own little homage to Dungeons of Daggorath. 🙂

Unfortunately, creating speech on the TI-99/4a is incredibly difficult.

The first obstacle is finding software that will record audio in mono. (The TI’s sound chip is not stereo…) The second obstacle is to find software that will convert the audio file into LPC encoding that the synthesizer understands.

Fortunately, the engineers at TI who worked on the synthesizer went on to found their own company years later. And they wrote software in DOS to create the speech encoding for a variety of chipsets. The only hitch is it was packaged with a blueprint for a slightly later model of the speech core. This creates some slight misalignment but it’s surprisingly close. It also only available as 16-bit binaries, which means can’t be run on a 64-bit PC. (32-bit will go back to 16-bit, though.)

I did get test speech working, both in emulation and on the actual hardware. But a host of issues cropped up with it…

The first problem was it was very quiet on the actual hardware, as opposed to the emulator. After puzzling for awhile, I realized I’d recorded my voice using a crappy laptop microphone in an open room. So I had to re-record, keeping my mouth close to the mike. This worked, but the software I had to convert it to a mono audio file kept messing up from the volume of the recording, creating a static sound. It took a lot of tries to get a clean audio file.

The second problem was the LPC encoding. It generated a text file containing all the bytes, but it was HUGE. An evil laugh took over 600 bytes alone. My intend was to embed the code into the 8K RAM rather than load on the fly, but I was concerned at running out of memory to even store the four phrases I wanted.

Final problem… I hated how my voice sounded. I don’t have a naturally deep voice, so it was very difficult to get something that sounded like an evil wizard, and was scary. Part of that may be my bias against my voice, but still… it just sounded lame.

After all of that, I decided I would just forgo speech in the game.

Original Game Mechanics

When designing game-play, my first step was to investigate the original games and how they worked. Both Wizard’s Lair and Revenge have nearly identical design.

Wizard’s Lair has a fixed number of chambers per level, the maximum on level 4 is 45. The actual mazes can be up to 8×8 in size. Wizard’s Revenge, possibly to save memory, only has mazes that go up to a maximum of 6×6 in size. That also means there are less monsters and items in the second game.

There’s no hit mechanic in either game; you just deal damage when attacking and take it in return from monsters. Your attributes also take damage with every attack, but at a much smaller scale. (Which is why the manual notes that you may observe your attributes drop in value against “stronger” monsters…)

Monsters only have two attributes of note, their name and their power level, which is both their health and their amount of damage. The Evil Wizard has the highest power level, plus any spell that would kill a monster outright doesn’t work on him.

Items and monsters are populated off of static data lists. Each item or monster has a specified count and a minimum and maximum dungeon level they are on. Because the games were written for a 13k cassette environment, they don’t try and optimize by loading the data into arrays; instead they just read the data statements as needed. This creates the interesting effect that when moving into a new chamber, it takes notably longer for certain items to appear on the screen than others. (As it has to read/search all the data until it finds the one it wants.) Traps on items have a small percentage change of being generated.

In both games, treasure is used solely to increase “treasure points” which is used to calculate your final rating. You can essentially skip every treasure chest in Wizard’s Lair if all you care about is defeating the Wizard. In Wizard’s Revenge, chests also store food on the last few levels, which restores health. Experience points have no effect on your character at all in either game, they’re only used for ratings calculations.

Wizard’s Lair doesn’t have exits to the next level. Instead, you move on to the next level anytime you want with a command or you automatically descend after a certain amount of time has expired. If you are on the last level when this happens, you lose the game. Wizard’s Revenge got rid of the time factor and added exit chambers, a change I agree with.

Both games have some interesting fun things…

Wizard’s Lair has three separate spells that get rid of monsters immediately; VANISH, DEATH, and GRAVITY. The latter actually levitates the monster off the screen! None of them work on the Evil Wizard.

Wizard’s Revenge has very interesting traps beyond just impacting your attributes and health. One creates leeches in your backpack, filling every available space, forcing you to waste time dropping them. Another teleports you to a random position in the dungeon. And one creates walls blocking you in your current chamber; you have to attack the walls and break them down to escape!

Wizard’s Revenge also has a new instant death spell, MEDUSA, which literally turns the monster to stone. You can even leave and return to the chamber and find their statue there. (Obviously, that one doesn’t work on the Evil Wizard.) There is also a CARPET which will whisk you to the next level immediately when used. (If used on the last level you lose the game though.)

I’ve played and won both Wizard’s Lair and Wizard’s Revenge of course. A typical game takes an hour or two. The games are pretty challenging due to the randomness. The first game in particular has a pretty steep curve of power for monsters; you’re feeling cocky finishing level 1 with a club and leather shield and suddenly on level 2 you’re facing an ogre or mummy and getting pounded into oblivion. The Evil Wizard himself IS a challenge but not overly so; I found that so long as you had a magic shield (using a spell) you could beat him fairly easily.

So now on to what I want to do…

Game Goals

Early on, I wrote up a list of things I wanted in my game:

  • Character classes, so you could play the game in different ways
  • Six levels, each one progressively larger than the prior one
  • A much more useful map that shows the exact layout of the dungeon
  • A hit mechanic to go with the damage mechanic, to make combat more complex and nuanced
  • A separate spell system by which you can use magic points to cast spells. Spells now become scrolls that can be written into your spellbook or used to cast the spell
  • A greater variety of items and individual items to use
  • A greater variety of monsters, with unique abilities and graphics
  • State tracking for spell and trap effects, both positive and negative
  • A truly powerful Evil Wizard, who can actually cast spells and has a few tricks up his sleeve…

I’m happy to say I was able to implement everything I wanted and I still ended up with around 3K of memory left in Extended BASIC! 🙂 The only additional feature I added was a save/load game option. This came about due to feedback from a good friend play-testing the game, who noted it was taking several hours to complete and that a save game feature would be handy.


This was probably the most challenging part of the design. After the game was finished, I had to fine-tune the mechanics and make sure the game was winnable.

I was impacted by an earlier game of mine, which I discovered LONG after the fact was not winnable. The final level was relying on some game physics I’d changed without realizing it would impact it. I promised myself in my future games that I would make certain they could be won before releasing them.

It took a great deal of time to get the game to a playable state. I discovered early on that it was pretty easy to make the game TOO difficult. Part of the problem was that as the designer, I am fully aware of the mechanics and of how things work, how to use items, and so forth. As a result, what seems a challenge to me is flat out impossible to anyone else! I had to scale the game back to the point that I felt slightly bored with it to get it just right.


Since I was writing a spiritual sequel, I also wanted to create a manual for the game, modeled to look exactly like the first two game’s manuals. I intended to have a PDF copy of the manual AND to print a few copies, one for myself at least. 🙂

First, I scanned the original Wizard artwork as well as the graphics for the logos and other things. I then constructed the layout in Microsoft Publisher, and wrote up the text. Since my game was considerably more complex, I ended up with several more pages.

The main font used for the text was easy to discern; Helvetica, although I had to download it for Windows from a 3rd party site. Figuring out the font used for the title was harder; I eventually hunted it down as Parsons. Publisher has an option to publish documents at PDF files, which I took advantage of to create the final templates for printing.

Because the outer cover has ink all the way to the edge, I had to find a local print shop to print the covers. Fortunately I found a decent place right in town, the only tricky bit was getting my proofs and finished materials before they closed. (No weekend hours and closes at 5, usually when I’m on the bus home…) I considered the process to be a nice trial run for when I get manuals created for my CRPG.

I had 20 copies of the cover printed. In retrospect, I was probably optimistic on the count; I offered anyone who wanted a manual one for the cost of postage, and ended up selling maybe half-a-dozen. Oh well, I still have some if anyone wants one…

Final Thoughts

I quite enjoyed the experience of writing the game. It really came together exactly as I pictured it would! And expanding my knowledge of the TI’s capabilities with assembly routines and BASIC was very awesome as well.

I’m waiting now to hear if someone else has won the game. Regrettably, I’ve gotten little feedback, positive or negative… I suppose when you write a vintage game you should be happy for what you can get though.

I also discovered recently that another game already had the title I’d chosen… Wizard’s Doom is also the name of a Commodore 64 action/strategy title game. There was a lot of overlap in game titles back in the 80’s, so I’m not too worried about someone surfacing and filing a lawsuit over the name. 🙂

And my final challenge to anyone who has read this to the end…

Dare ye enter… and deliver unto the Evil Wizard his final doom?

Download: TI Game Shelf

Link: AtariAge thread on Wizard’s Doom

Link: CRPG Addict’s Review of Wizard’s Lair/Revenge/Doom

Posted in Coding, CRPG, Design, Screenshots, TI-99/4a | 7 Comments