Happy 2015 everyone!
Yeesh… I’ve been working on this project for 10 years now… I seriously need to just get it done!
I’ve been pretty busy since late December moving into the new home, and getting things organized and put away. You accumulate a lot of stuff when you stay in one place awhile… and the fact I’m a bit of a pack rat doesn’t help matters. I found to my surprise that I had seven, SEVEN, TI-99/4a consoles in my garage. I’m not sure how that happened! I don’t need that many, really two is enough, so I’ll be looking to find new homes for some vintage hardware.
On the CRPG side of things, digging back into my code base meant figuring out where I had left off… as part of that, I also started to wonder how much more space I had for the game and when I’d need to start moving code into different areas.
A little hardware background first…
The TI-99/4a has a 16-bit addressing space, so it can address 64k of memory maximum. Most of this isn’t RAM; a lot of the address space is consumed by ROM’s, cartridge drivers, and other system peripherals. The console itself actually only has 256 bytes (!) of actual CPU RAM.
The only other RAM in the system is the 16K used by the video display processor. This RAM is not included in the addressing; there’s a memory-mapped ports in that very small CPU space (nicknamed “the scratchpad”) to read and write bytes to and from VDP memory. Yes, it is an eclectic computer indeed…
A fully upgraded TI-99/4a includes a memory expansion card, which adds 32k to the system. It adds 8k in one spot of memory (called “low memory”) and 24k in another (called “high memory”). When you wrote assembly language programs with the Editor/Assembler, you typically only have the 24k available, because the loaders used to load your program occupy the low memory, along with some other utilities. There IS space there, around 6k worth, but it’s tricky to get into.
Most assembly programmers on the TI write their programs to load as “memory image files”, which are just raw assembly code loaded as 8k segments directly into memory, chained together with a common file name structure. In order to convert your assembled program INTO memory image files, you used a a utility that occupied the low RAM. Which meant you still couldn’t quite use that whole space.
My solution to this problem is to reserve the entire low memory section as pure RAM for the program. I’m actually using that much RAM (or more) for the game; the maps alone consume half of it. After the program finishes loading, the entire space of memory is mine to use as I see fit, and I don’t have to worry about loaders.
But… my program is going to exceed 24k in size. I’ve known this for awhile, so I planned for it by obtaining a handy cartridge called the Super Cart. It’s basically an Editor/Assembler cartridge, but with 8K of RAM at the cartridge port address. This extra space will be enough to finish the game easily, and for those users who want to run on an actual TI, the cartridges aren’t hard to come by.
Figuring out how to create the memory image files for this proved to be a challenge, though. There are compiler directives to redirect code into different addresses, which I used, but I found out that I was unable to use any utility, in the emulator or on the TI itself, to actually create the files!
My final solution is a bit of a hack… literally. I do a memory dump out of the emulator after fully loading the assembled file into memory. I then hand-create the memory image files and copy and paste the data from the dump into files using a hex editor. It’s a bit slower than the old method, but it works, and now I have freed up plenty of space in high memory to finish the job!
On the CRPG code itself, I’m working to get at least ONE spell, fireball, working. The effect on screen should be spectacular, a ball of flame streaking towards a location and exploding, sending clouds of fire and dust in a slow spiral outwards. Implementing this has proven to be trickier than expected though…
Aside from writing the code to achieve the effect, I’ve discovered that my code to determine attack results with melee and ranged weapons got somewhat mixed into my actual effects code. I need to unravel it and clearly separate the effects on screen from the actual logic to determine WHAT effects to show and when… This also means I’ll have to do regression testing of melee and ranged combat when I’m finished…
My latest code effort was rather amusing… instead of a fireball streaking out to the targeted location, a fireball flew towards another party member and struck them causing damage! Not QUITE what I was going for…
Low-level programming on the TI sounds headache-inducing! Coming from the Amiga I’ve been spoilt: all video, audio, and other DMA, accept pointers anywhere into the built-in memory, and you’re free to place things anywhere they fit. But I think the Amiga was made a few years after the TI, 1985, when this kind of flexible logic was more doable and affordable.
Yes, the Amiga WAS a few years later, when architecture opened up and design got a lot better. The design of the TI-99/8, which was never released, was a much better approach that would have been a far better system to program on. It had built-in paged memory which was expandable to 1024k (an impressive feat in 1983!).