Here's what I originally planned, in that respect:

 - Enemy would blink when attacked, or when it executes an attack

 - Either the entire window would blink when a character (or the entire party) was attacked, or the screen would shake

 - Spell animations would consist of screen-flashing and shaking effects

I'm not sure what Iambian is going to do, though. I guess it depends on how taxing the effects are, and what's really most feasible.

It wouldn't be difficult to create a few animation assets. Off the top of my head, we would need:

 - Single bitmap of a fire animation, flipped back and forth to give the illusion of a burning effect

 - Single bitmap of a snowflake / icicle, blinking on top of targets to indicate ice-based spells

 - A bolt of lightning, flipped back and forth to give the illusion of a lightning-strike

Each of these may need to be masked. They could possibly be handled in a similar fashion as character sprites, which use 3-level grayscale. The fourth gray is sort of reserved as a mask, or a value that the system reads as transparent. I'm not quite sure how Iambian handled that.

Either way - I'm not sure if we even have the memory. This is entirely up to Iambian, since he knows more about this than I do. I don't want to propose any additions that are going to make the process much more complicated.

I think the biggest complications would result from compression. Trying to insert any new data, as far as I know, is really difficult.

Or, it would just sit there uncompressed so it can be recalled whenever I need. Or if compressed, in a completely different "file" of the game.

Hehe. Confession time.

I'm not worried about space in the application at all. What I'm worried about is being able to access whatever I want on the same page and not have to deal with page flipping just to get to the data that I want. Or having to shuffle data around the application to make something else that has a higher priority on some page fit there.

I'm sure a few battle animations outside of what was originally planned could be worked in. Why, then it would make use of those reserved command codes that I kept just for such an occasion...

lol, you reserved command codes for them already? Planning for any other contingencies I don't know about yet?

The crickets are chirping in this thread

No. I've been spending some time learning some C so I can write utilities that would help automate the rebuild process for the assets in the game. So far, I can perform the following with a double-click:

(1) Rebuild all the tilemaps directly from their .gsm (calcgs tilemap) format
(2) Rebuild all the item/magic descriptions from their uncompressed source

At some point, I'm going to want to build a utility to do something similar to image assets so I can have all that mess be automatically included into the project. Might have to allocate yet another page file for that mess so I don't accidentally run out of space or something (since things are more automated now). That would bring the project up to 6 pages long (98304 bytes). I think that's still below the threshold for complaints, as I recall DJ Omnimaga stating that Ti-Connect (serial) has problems with filesizes over... uh. I think it was 130KB?

So... in short. I learned a lesson.

If you want to code a massive RPG in ASM, it would do you well to know C so you can build some utilities that will help assemble your assets.

EDIT: I also still have to do item-get thing. And then the rest of the battle system. After all this time, I still haven't forgotten.

Cool bananas!

It is very handy to be able to whip up utilities when you need them, saves a hell of a lot of time and headaches.