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!
There are always quirks and minor differences between the emulator and the real hardware. It is always a good idea to periodically test the game on the actual machine at least once in a while.
I used to be frustrated whenever I came across a setback or issue that delayed my progress and thought I had lost countless hours and even days that I could have been used in working on the game but I now view this philosophically–overcoming bugs and issues like these are par for the course and are part of the entire process. At the end of the day, you still save a lot of dev time using a cross development environment than actually programmig the entire game on a stock machine.
For my own game, I’ve thought about adding support for memory expansion that went beyond the 32KB that was the maximum available back in the 1980s but I’ve decided that the game runs actually very fast with an SD card reader with fast loading enabled. So in my case, I will stick with defacto virtual memory based on external storage (for content to be loaded on a on-needed basis and swap space).
I don’t think there is anything wrong by designating a specific disk drive to access specific game resources as long as is is documented. I know a lot of the retro dev community is pushing for a convention where all of our code should be “drive number agnostic” — but this was barely followed at all back in the day.
Yeah, the only reason I was really panicking was I wasn’t sure if there was an issue with my disk controller card (which was NOT a TI controller) or the memory card.
My Corcomp Controller is actually slightly better than a TI controller and all the documentation I found said it was 100% compatible, but I thought I was having disk file issues so I had to confirm that the card wasn’t the problem. It’s not AS fast as I’d like though, it takes about a minute for it to load 128K of program data.
The AMS card has actually been around since the early 90’s in design, although the original cards had some slight differences in mapping that would have to be accounted for. It’s also fully emulated in several emulators, so I feel pretty comfortable using it.
Back in the day, what most TI users used was RAMdisks, a particular one called Horizon. The OS for it was fully compatible with the TI disk system, letting you just use different drive numbers and even emulating your floppy drive system. I’m kind of bummed I didn’t have one… But my present setup would fully support one if one wanted to.
I was going to store a lot of my data on file as well, and stick with stock memory, but I had already over-written the original confines and was forced to use an 8K cartridge. Plus, there is so little TI software that takes advantage of this wonderful piece of hardware, I felt it needed it. It’s definitely made programming a lot more fun, no more concerns about running out of memory!