Todo: Two more menus, one of which is basically re-using an old one with different outputs. And... the rest of the battle system. Gotta get the enemies to input commands into the command queue. Then I've gotta write the code that processes the queue and pretty much does the fighting. Escheron, your days of getting in the way are numbered! Ya hear me! YOU'RE GOING DOWN!
... *ahem*...Maybe early next week. Maybe.
Then the promise of getting focused copies out to select members of the community might actually materialize.
My time at the location I'm presently visiting is running short, so no screenshots of what it looks like. That's gonna go into another topic. For asking opinions about it. And stuff.
...
Yeah. Let's go with that.

The mentioned slowdown should only occur each time the contents of the screen buffer is displayed.

EDIT: Link to post containing something that could be of help provided for your convenience.

With respect to modifying, wouldn't just replacing the call to fastCopy with the romcall to copy the graph buffer work all the same for that purpose?

This is a screenshot of what was going to be my Axe Parser entry for the contest. Couldn't keep it in any longer.


... j/k. Just made a little progress. Mostly graphical. Again. Best viewed in Opera or Firefox. Nevermind the portrait I used for the "DevTeam" special character.

Oh, no. I only seriously used mIRC scripts to compile parts of E:SoR (which is now being compiled with some utilities written in C). Fishy compiles under TASM and uses devpac8x to convert it to a .8xp file.

tasm -t80 -b -i FISH7.asm FISH7.bin
And then use whatever is your favorite .bin to .8xp util.

Also, I tried to use SPASM to build the project, but for some reason, the program (FISH7) just crashes. I really should try to figure out how to get it to compile under SPASM, since doing it that way would make the thing a whole lot easier.

I don't think being able to access the high/low bytes of SP directly is even possible. If you are going to be using SP like some "normal" register, you'd have to keep a few things in mind, some of which was already stated in this thread:
1. You need to save SP somewhere since it's usually important for the stability of the system. Use instructions like "LD (xxxx),SP" (where xxxx is an address) to save SP, and "LD SP,(xxxx)" to recall it again.
2. Interrupts need to be disabled while you're messing with SP. The instruction "DI" is great for that. Interrupts randomly make CALLs. See point # 4 as to why this is bad.
3. There are a few other instructions you can use to mess with SP or deal with it. That's where it starts getting cumbersome. Just let me know if you want to know, either in this thread or via PM.
4. The stack is no longer available (unless you're creating your own miniature stack for some reason). This means that you cannot use PUSH/POP without destroying whatever it is you're working on. Same goes for CALL/RET.

Now... with respect to IXh/IXl ; IYh/IYl. A simple way to remember where you can use them is... wherever using H or L is a valid option, you can use the combination above. Except when the instruction calls for the use of HL or IX/IY as well. As stated in an earlier part of the thread, none of these combinations will work on the Nspire since these uses are "unsupported" instructions. Also, the OS uses IY for its own purposes and expects that register to be the same when the program exits. So be sure to save IY as well. Or if you happen to know what's loaded to IY (it is some constant), load that value instead (saves time).

And as stated (somewhere) above, only use these combinations if you absolutely know what you're doing. Their use is more like a last resort than anything else.

Got item-get conditions fully squared away. Now packrats no longer have to fear about losing important stuff that may make the game unwinnable, like key items.

Now, I've got to throw together enemy sprite display as part of the screen rebuild.

After that, it'll be time to throw together some sort of command queue structure and start coding the meat and potatoes of this battle engine.

I want to see how far you can get with this idea:
;76543210
;SZ-H-VNC

ex de,hl
xor a
sbc hl,de
push af
pop hl
ld a,L
rlca
and 1
ld L,a
It relies on the stack and the fact that the sign bit is the 7th flag bit. Not entirely sure if this does anything, since I'm not too experienced in signed stuffs. I'm assuming you represent these numbers as some form of two's compliment. If you can use the idea, feel free to do so.