I have a variety of goals with this project. Some are technical in nature, others are concerned with genre and gameplay.
I'll start with the technical goals:
And now, some technical options that some may feel I should be exploring, and my reasons for not doing so.
One of the strong selling points of the TI was its speech support, a rarity in the early 80's. Thanks to their LPC (Linear Preditive Coding) technique, they could produce human speech that sounded about equal to digitalization quality at the time, and in a lot less memory.
I've seen some pretty neat stuff done with the synthesizer. The classic "Bert and Ernie" short was amazing, and it's still a wonder how it was done. (Although I suspect that some non-TI tools were used...) A Frogger-game in Extended BASIC used it to create a "ribbit" sound and a swishing sound effect when the frog was run over by a car...
However, I'm not tempted to include speech. The main reason is that I'm uncertain where it would really fit in the game; I don't want to include things "just because it's there". Another is that I'm unfamiliar with how to code speech; I could spend a considerable amount of time on it with little practical return.
And finally, while the MESS emulator does a fantastic job reproducing the TI-rendered speech, it doesn't do so well with user-created speech; I hear frequent "blings!" and other random noise. This is probably caused by MESS using a later-model speech core.
The TI has more than just a disk system. It also has a cartridge port, which can have 8k of RAM or ROM, with paging possible, and up to five 6k GROM banks. A cartridge could be used for a loader, like what Tunnels of Doom uses, or even to store static data.
The problem is that I don't want my game to be dependent upon a cartridge to load. It also would make it necessary, in order to test on a real TI, that I have a cartridge simulation device like a Gram Kracker, or actually create a cartridge from scratch. Finally, working with GROM means invoking GPL, something I really want to avoid.
I'm not completely dismissing the idea, just shelving it.
The Advanced Memory System card was developed by Asgard before they shut their doors, and a number of user groups built their own based on the specifications. It gives the TI a true CPU RAM expansion by using an un-utilized memory paging system. Minimum size was 128k, but cards of even greater size exist, in the multi-megabyte range.
The primary issue with the AMS is that there aren't that many tangible cards in existence. (Less than 200, by last estimation.) It isn't likely that more will be made, as the chips that it uses are becoming increasingly rare. Many of the TI emulators can simulate the AMS card's operation, but this would tie the game inexplicably to extremely high-end users, or those running on emulation.
Another problem is that more memory isn't necessarily a good thing. The processes that comprise the game engine should be able to fit in the existing TI framework, or at worst, spill over only a little. Most of the AMS memory would only be used to store resident data, which can just as easily be stored in disk files.
Also, AMS programming means programming in a paged environment, which I am unfamiliar with. I have a copy of the AMS compiler/editor, but I have not had time to look into it on how it works.
It's possible that if the game is completed with the proscribed TI hardware, an AMS version could be written to remove a lot of the common file dependency. But I'll cross that bridge when I come to it.
Although TI never made a successor video chip to the TMS9918A, another company, Yamaha, did so for their MSX2 line of computers. The V9938 (and later V9958) offered an 80-column RGB display, a far larger amount of video memory (64-192k), and a palette of 512+ colors. Sprites were also improved; you could have a single color per horizontal line, and up to eight sprites per horizontal line.
Several 80-column cards using these video chips exist, giving the TI-99/4a an 80-column display. The Geneve also used the V9938 as its native video chip. It is probably the most popular high-end modification for the TI, as it relieves you from the pain of NTSC, and gives you a much wider display for text processing.
There's no doubt that a game would greatly benefit from the improved graphics a V9938 would offer. Looking at MSX2 screenshots is proof of that! However, there are problems with this.
One issue is that the 9938, other than backwards-compatability with the 9918A, takes a fundamentally different approach to hi-res graphics. The added modes are linear memory-mapped bitmap images, with 16/256 colors per pixel possible. Since it is not a cell-based display, you would have to blit the images to the screen. The V9938 has hardware functions for graphics copying, but a lot of this work will be done by the CPU, through the same narrow 8-bit bridge that the TI-99/4a has.
Another problem is the added memory that such advanced graphics would need for storage. Where a bitmap character on the 9918A takes up 16 bytes for an 8x8 block, on the V9938 it would take 32 bytes for a 16-color block, and 64 bytes for a 256-color block. The MSX2 systems have multi-megabyte cartridge ports to store graphic data; the TI does not have this advantage. You can always store graphic data directly in video memory, but even doing this, you're still working with much larger and more complicated graphics, which means more CPU cycles to process them.
In the end, it comes down to this: the V9938 is simply 'too much' video chip for the TMS9900 processor to handle optimally. It's only viable if you're only doing 80-column text or bitmap operations that require minimal CPU involvement. For games, the architecture just isn't there.
The MSX computer systems, such as the Colecovision, have a surprising number of similarities to the TI. (The MSX-1, in particular.) They share the same video chip and a nearly identical sound chip, so many MSX games look like they could be running on a TI. You can see some screenshots of MSX and MSX2 games here.
The principle difference is the MSX uses a Z80 8-bit processor, running at 3.58mhz. Their memory architecture was also different, expandable to up to 64k RAM. Although it had been created with a home computer focus in mind, the MSX was mostly used as a game machine. A disk drive system could be hooked up, but most software was on cassette or cartridge.
It's a nice thought that I could write the game for two platforms and have them be cosmetically the same, but the idea of re-writing all the code into Z80 assembly is not that attractive. And while the MSX is inspirational in how they overcame many of the video limitations, it's not my TI.
The Geneve is, in my opinion, very close to what the TI-99/8 would have been, had it seen release. With 128k of RAM (upgradable to 512k), a V9938 chip, a TMS9995 10.7mhz processor, hard drive support and MDOS, the Geneve stands as not an extension to the TI but a successor in its own right.
Which leads to the main reason why I am not coding for the Geneve; it really ISN'T a TI. It would be interesting to program on one, and write a CRPG on it; the Geneve does seem to have a lack of games. But that's a task for another year. Another reason is that there aren't that many Geneve machines or users, making it a subniche of a niche market.
Of course, any game is more than it's technical requirements. I also have a number of goals in how I want the game to play, and what contributions it makes to its genre and platform:
So what kind of tools go into making a CRPG?
Well, not surprisingly, a lot of the work happens offline, on paper. In my teenage years, working in TI-BASIC and Extended BASIC, I would spend hours drawing graphics and maps using colored pencils and graph paper. In many ways, the process was more fun than the finished product!
For this project, though, I've gone digital. I make extensive use of Microsoft Excel for tables and calculations. Excel has an optional scientific pack that installs hexidecimal/decimal functions that can save a lot of time with number conversion. I can also use Excel to test game formulas and keep track of game data, like names and statistics for items, monsters, and so forth.
I will be doing most of the development work through emulation. I know some purists may consider this a weakness, but I feel it's necessary for two reasons.
One, it's a lot faster and user-friendly. Unlike a normal TI, I can turn off speed-throttling and compile at much faster speeds. A great number of the tools I'll need will have to be written from scratch; it is essential that turn-around time is minimized. Also, code can be written in PC text editors and pasted into the TI through the emulator, which is much more convenient. And code can be outputted to the printer port into a PC text file, making source control much easier.
Two, working with my original hardware isn't easy. The firehose cable is so sensitive that even a nudge can cause the computer to lock up, potentially losing hours of work. The keyboard isn't as comfortable to type on for long periods. The NTSC display is a real eye-strain. And finally, the constant compiling could eventually cause my disk drives or even my power supply to burn out.
My emulator of choice is the MESS emulator. It does an excellent job of simulating the actual TI's performance, and it runs well in Windows XP. On the down side, there's a curious problem involving files and disks that leads to sectors being overwritten. This particular problem, which I reported more than two years ago to the MESS technical group, is still in the current build. The best way to counteract it is to not have more than one 'active' file on a disk at a time.
I also have a copy of PC99, which I would gladly use except that it was designed to run in full-screen DOS mode, and has no natural speed throttle like MESS does. The UI for disk/cartridge selection is also less flexible than MESS. However, I will be periodically converting disks to ensure they operate in both environments. I'd like the game to run on Classic99 and Win994a, so when I have a working prototype I'll be happy to share the source with the developers of each.
I will also be testing prototypes and beta releases on my authentic TI, another good reason to avoid the high-end hardware I don't own. However, I will have to obtain an IBM-PC 360k disk drive before I can do this; The 1.2mb drive I have cannot write TI-readable disks. I may enlist the aid of some other 99'ers for beta testing with high-end hardware, but that's a long ways off.
So, having listed my goals, we'll have to see if I can actually meet them. Next installment, I will cover the anatomy of the TI disk file system, and how it will be utilized for the game.