adamantyr

37 here...

Figured I should update a bit here, still working on this! Content generation takes forever... Drawing maps of places that have only been names in a spreadsheet, drawing up monster graphics, writing dialogue and scripting, lots of work! So I could auto-generate PNG's of game maps, I wrote a graphics extractor. Just for fun, here are all the character sets in the game:

Just checking in, any updates to report?

You'll need one of these to play my CRPG on iron! There are currently 187 monsters so far...

Yeah. The only attempt to make an actual linker/compiler system around SAMS that I'm aware of is Art Green's Ragtime AEMS assembler that was provided with the Asgard card back in the early 90's. I've looked at it, the most useful part is in the docs when he defines the new expanded header for loading data directly into pages. The assembler itself, I'm way past using the actual TI for compiling, so it's not so useful... What you're really talking about honestly is memory management. For performance reasons, I decided to implement my own memory structure for my CRPG. I use the lower 8K as data pages, and the upper 24K for a root module and a swapped module for different modes. It's worked pretty well, if I was doing a new design I may break up some of the root functionality into single page function blocks that could be loaded as needed.

Exactly right. Which is why most games are memory images, you want them to load quickly. The truth is, there's almost no reason NOT to convert an E/A 3 program to E/A 5 except it's part of some ongoing project where you may be adding or removing modules frequently. So a living application for a business for example. For a finished product burned to a diskette, it just doesn't make any sense to keep it in that form. Now that's for the standard 32K TI-99/4a system, mind you. SAMS has considerably more memory, and could use a relocatable approach, especially if it was developed on a platform. That said, I wince at the thought at how long it would take to load any programs; the basic DSR routines on the TI are pretty good but their limitation of requiring the VDP memory as a file buffer is a very limiting factor for time. My own CRPG loads 8K segments to get the entire program into memory and takes about a minute on hardware. I love the fact the Miller EEPROMS for the Corcomp disk controller gives you the ability to do directly to CPU memory loads, but unfortunately it's not a common standard available on TI's. So I can't use it. :/ Not even classic99 has it available.

Correct! That being said, if you're using AORG in relocatable code, the question arises "Why not just make it EA5 then?" Relocatable code was the future, of course, with modern computers everything is relocatable anywhere. It's an interesting design that I haven't seen on other 8-bit computers at the time, having both fixed and relocatable code options in assembly. Possibly a reflection of TI's adaptation of mainframe style design? The fact the assembler has support for segments which to my knowledge no one has ever used is a sign of that as well.

EA3 and EA5 are important things to understand. EA3 means "code is relocatable anywhere in memory". It maintains a relative address structure so that you could load it here or there easily. So you sacrifice time to load in return for flexibility. Also, the EA3 loader includes most of the EA utilities like VMBW, DSRLNK, and so forth into the lower 8K RAM automatically so they can be REF'ed at any time. Many of my tools for my CRPG like map editors are written and ran in this mode for quick use. EA5 is non-relocatable code, it has been compiled so that every address is specific. It's like a memory dump, honestly. It splits your files into 8K segments with a six byte header indicating where in memory to load, if any segments are remaining, and how big each segment is. If you used AORG to create a separate lower 8K part, for example, it would create a separate file just to load it. EA5 code loads MUCH faster since it's not trying to determine relative addresses. When I say "use the lower 8K for data" I mean something like buffers. For example, if you were loading a game map from disk into memory, having a buffer in the lower 8K makes sense if most of your code is in the upper 24k. Static data like graphics that's part of the game doesn't necessarily need to be there. Unlike the IBM-PC module design, the TI can do data or code anywhere, it's pretty much on the programmer to decide where he wants it. On another note, storing data like character graphics that are used only once are best offloaded to a disk file and then loaded by your main game program.

The easiest way to give monsters some variety of special attacks would be a byte-index look-up value that indicates a "special" ability. You would need to burn one value as a "none", -1 always works well since 0-based indices are used. However, that won't get you monsters who have multiple special abilities. In that instance, you would want to define all potential specials, count them up, and then use a bit-wise set of bytes to store "has it/doesn't have it" values. For example, a ghoul's ability to paralyze would be one such value. You are correct that adding more monsters doesn't significantly improve gameplay if they have no real discerning elements beyond a name and graphic. It would be better to have less monsters but a more complex monster definition. I'm dealing with that myself. Also, if you are on other projects, I would suggest you take your time with those and come back to this one with a whole heart and don't try to just "dial it in" with monster statistics. It sounds like you hit a bit of a block and put it aside to consider the direction you wanted to go. As much as I want to see the game finished, I want you to feel good about it, and not like "I could have done more with it..."

Yes, most 9900 assemblers can produce a listing when you compile. With E/A Option #5 binaries, your code is always loaded to fixed points in memory. So you can use AORG to locate code into the lower 8K, such as utilities for example. I often find the best thing to do is use the lower 8K as data-space; then you don't need to AORG anything and you can just use EQU labels for your variables in the main program. With SAMS programming, things get more complicated. At some point after my CRPG is complete I'll be sharing the GitHub repository for the source code and publishing some blog posts on how the architecture is both loaded and set up.

Your monster file notes size as one of the byte options, but it's not present on the monsters. I currently have about 170 or so monsters for my CRPG. All the statistics are home-grown, I know I'll be spending a LOT of time balancing them. I'm trying to avoid overt Tolkien ones too, so no orcs, treants, etc. Trolls are fine, they're from norse mythology.

Excellent work! Hey, how could I talk to Mystery Man about the internals of Gauntlet? I've studied that version with the intent of re-creating it on the TI-99/4a. The video stuff was easy since the chip is the same, but Z80 code is beyond me. In particular, I'm keen to know how the monsters were handled.

So you just need a single 8K RAM bank, or two of them? If you need at least two, you'll need the Super Space II module. I have two 8K Supercarts, I'd be willing to sell one. PM me if interested.

yeah same here. MG Eproms. The Extended BASIC 2.7 cartridge also doesn't work quite right without them.

Typically you do a program listing when you compile and check the address to determine space left. With the 32k expansion, programs usually load into the 24k block first. If you are writing without relying on REF and rolling your own utilities, you can either use AORG to relocate part of your code into the lower 8k block. Or use the lower 8k as data and variable storage.

You can do it by hand with a hex editor, if you use TI99Dir to extract the file to a PC file and strip off the 128 byte header at the start.

Awesome! I can't wait to play it on my actual TI. Since everyone else is saying it, PM sent.

What's a SNUG exactly?

Generally it works out because there aren't a lot of programs that are on multiple floppy disks for the TI. And those that DO exist tend to be 90K or 180K disks, so as long as you have 360k drive emulation you can double up. My own CRPG, for instance, has a game disk (always in disk drive 1) and two world disks, both of which are 360K. So 3 drives would be needed to play the game without swapping. The NanoPEB won't work it, though, since it requires a SAMS card and those aren't available in a sidecar form as yet.

That's amazing! I was only ever able to find a Commodore 64 version anywhere online. I started on a conversion of the C64 version at one point, but I never finished. I asked and no one in the TI community had a copy at the time.

In particular, the #3 files are designed to be loadable in any memory. So you pay for that flexibility with a larger file size and a slower load time. #5 files are 100% compiled and static; you can't place them anywhere in memory except where they were compiled to be. They start with a small header that indicates where in memory the code begins. To make maximum use of the RAM memory of the TI and load your program the most efficiently, option #5 files are the best. SAMS loading is a more complex subject. Art Green's SAMS assembler/linker had the option to create relocatable code that could be loaded into any page of memory, but it was pretty complex to understand and I do most of my compiling work on the PC for speed rather than the TI. I ended up writing my own loader for my CRPG, and compiling static binaries that get stored in one large binary file which is loaded and set in fixed pages. To load around 160k takes a little over a minute, so it's pretty fast all things considered.

I use tabs in Textpad and set them up with my assembly files to match the exact necessary boundaries for labels, op-code, arguments and a comment area. It's worked pretty well for me. Adam

Awesome!

Concerning Gauntlet, there are only two attempts that I'm aware of for making it for the TI. The first is Gold Vault, which was a project Quinton Tormanen showed me at the 1990 Portland TI Faire. It was not complete and he never finished it. I emailed him asking about it a few years ago, but he had some real life stuff going on so I don't know if it's going to be finished or not. The second is my own project, which I started about two years ago. It's presently shelved because I want to finish my CRPG before I take on another big project. It will definitely require the SAMS card because I intend to make a better version than either the Spectrum or MSX delivered. I studied the MSX version to see how it was implemented, and I was able to discern most of it through the BlueMSX debugger. (The one thing I couldn't find it how they were doing the monsters. NO Gauntlet implementation actually does the cellular automata design that Dandy did.) Just for kicks, here are some details: The game uses bitmap mode (of course) and the top two tables both share a static pattern set. The game cuts corners in places to make sure all requisite graphics fit in the 256 character set; Lobbers only have one frame for example. The bottom 3rd of the screen dynamically loads patterns for the bottom edge of the map and the player statistics. Animation is achieved by blasting a new frame set across the entire table, or most of it, so all monsters change frame simultaneously. Player graphics are entirely sprites, as are all projectiles. The game performs fairly well but monsters are not numerous compared to the arcade game; I suspect a limit of around 64, possibly 32 per level.

A lot of the TI assembly books have some odd pricing... Several years ago the Compute! guide to Assembly was listed at $400 value with an Amazon seller, due to some eBay auction artificially driving the price up.