I made the new source you gave me into a WabbitCode project file but ended up having a couple errors trying to compile, and i just wanted to make sure that i've got it right. Basically, in the statcalc file in p0 there were two undefined addresses (lines 107/120), AddAtoHL and statgetbuf+5. I changed them to AddAtoHL0 and statgetbuf1+5.

You're right, and I'm also kinda embarrassed that I uploaded something without checking to see if it would build at all. Aside from that, I also made another really small revision. You can see that here: http://pastebin.com/FKzmixrX (p0/statcalc.z80)

I would like you to start working on the battle engine, despite the fact that there's nothing in the current code that even remotely alludes to it working. Most specifically, I would like you to work on the part that performs the battle calculations.

Since not everything is put together, just assume that you will have available calls to routines in the form of "call GetStat<insert_stat_type>" in which you replace the stat type with something such as "STR", "WIS", "Evade", "NumberOfPhysicalAttacks", "DEF", "HitRate", etc. I'll be adjusting the names of the routines that fetches the values to whatever you choose to name that call.

Please ignore the file "battengm.txt" since that is an incomplete document. In batteng.txt, please revise line 23 to read:
09.      If have BLIND FIGHTING, %HITRATE = %HITRATE - ( %HITRATE / 4 )
For messing around with the battle system, please refer to this copy of Escheron, complete with source, to see something that might remotely look... decent. It's actually a much more complete version of E:SoR but it was getting to be an absolute pain to work on. To build that software, you'll need to put the extracted contents of that archive in a folder called "LL2" (the project was originally "Lost Legends II" before Zera changed its name) and then put that folder inside the project folder of Dwedit's AppDev kit, then you'll want to replace "asmapp5.bat" with the one I've attached to the bottom of this post. Only then do you go into the LL2 folder and double-click the mLLII.bat file to rebuild the app.

Understand that the source that I linked to you here is completely and radically different from the revision that you are working on (maybe except some of the LCD driver routines. I worked too hard on them to ditch). The difference includes some of the data itself and its structures. In this source file, the entire engine is split between pages 1 and 5 (starting from 1 this time around) with data sitting on page 4.

This version was overall much more complete, and with a few more steps, would've been releasable as the finished product. The problem was with the compilation environment and how everything was arranged together. See, TASM has limits and I was trying to pull together hacks that would overcome *some* of those limits (but not all of them), and I ran into a problem with respect to how the code was arranged. I would not have been able to cram events in there. I had a couple of images that were missing from the source that wouldn't have made it in. Overall, the thing was a complete mess and I felt like I needed to stop that shit and restart the whole thing.

If you think you might be able to cram what needs to be done into the old source and have a pretty complete game, feel free (but I think you'd be wasting your time). So that's why I have a pretty much clean slate that allows me to put together things in a much more sane manner, and allow things to be ... "page-aware". SPASM allows me to do this. Also, SPASM just simply builds faster.

tl;dr: Try to write battle engine calculations. You can test it using the old source if need be, or to use as a reference for the new version should you want to code the whole thing.

Okay. Here's the top level bit of the whole project.

Escheron: Shadow over Ragnoth is a FlashAPP that spans (thus far) five pages (16K each). So far, the following are on each page (starting from page zero)

[page 0] (7KB free) Game startup and shutdown, menu system, font renderer, stats calculator, keyboard reading routine, decompressor.
[page 1] (10KB free) Interrupt routine, events, LCD routines, main loop, tilemapper, sprite rendering routine (incomplete)
[page 2] (2KB free) Tile bitmaps and image data. Whoops, forgot the enemy bitmaps >.<
[page 3] (8KB free) In-game descriptions, text data for menus, equipment stats. And more strings.
[page 4] (7KB free) Data used to place warp info. Tilemap data.

Almost all the game data is compressed, so it will use a spare RAM page (3) that is present on the TI-83+SE/TI-84+(SE) calculators to hold some of that data temporarily. The challenge is to make sure that the data is where it should be when it is needed.

During tilemap runs, the tile bit map is a full 8KB and rests at around the $C000 range. The $E000 and higher range is left open for other uses, but they include things such as sprite data and string data.
I'm not entirely sure what happens during menu runs, where description data (which is also compressed) needs to be loaded, but I do remember that data is juggled around practically everywhere.
During the battle system, the whole tile bitmap data can be discarded in favor of other things, such as decompressing and moving around enemy bitmaps. And perhaps double-buffering the screen if you wanted additional effects.

I probably should've said something about this before, but beyond the game startup and shutdown, there are no romcalls. The TI-OS would crash if you tried to do it due to the way memory is rearranged. In shortl, I shuffled stuff around to give me $8000 to $8EFF, all consecutive "free" RAM. There aren't too many free RAM areas that are left for use. Those that still exist will be defined somewhere. Not sure where, tho.

---
I would want you to work on the battle system, but there just isn't enough information available for that to happen. So in the meantime, you should get familiar with some of the documents that this project revolves around, in addition to how I originally thought the battle system should flow based on what was described.

I suppose I need time to figure out how to explain everything. Here's a little bit of info attached to this post with regards to what I could find. I'm not going to post the entire source quite yet. (gotta make sure the source will actually build)

I could actually use a little help with E:SoR. I haven't thought anyone would've wanted to help out with this project. If you wanna talk about the project, chat with us on IRC, and we'll see what can be done, perhaps exchange a bit of source code.

Just highlight me on IRC (say my name) and wait for a response, since I may be afk at the time.

Since what I'm doing with my calculator will eat too many batteries across what it's doing (it's a secret), I strapped my calculator down to a breadboard and hooked in a spare stripped cellphone charger to supply it with the juice that it needs for the fraction of the price. And so, I leave this with you:



The tape probably wasn't necessary but I wanted it strapped in good. Also, this makes operating the calc a bit more difficult. Whatever works, I guess. The voltage source is probably 5V. Not sure. Most likely. It's a cellphone charger after all. Doesn't really matter to me. Just as long as the calc powers on and doesn't complain to me about low batteries. Which it did when I had a 5V regulator in the circuit (leftover from a previous project). That's what the capacitors were in for, but I guess they might help keep the calc going long enough to reach a place where it can shut down if the power cuts. I haven't tested that one. Should I?

And no, my calc isn't trying to call out for help... yeah. Let's go with that. I was just... um. Too lazy to shoot another photo? Right, right, exactly! That'll be my story. It's believable, right?

EDIT: Quick 15-30 minute project. Most of that time spent was in locating the supplies.

I don't think you need a cursor to go through the letters. If you choose a letter, the cursor automatically jumps one to the right. Like in most name input screen in Gameboy games or like this: http://img.photobucket.com/albums/v626/bublnsqeek/tutorials/nameinput.gif .

I would prefer a cursor in the name, especially since the name input screen will be automatically filled out with the name you used the last time (Or "Nameless" if you're starting fresh with a new install). If something is already in the field, it might take more thought than strictly necessary to figure out where you are.

Also, whoever said it on IRC, I stand corrected. The behavior of the DEL key, at least in Perfect Cherry Blossom, is to move the cursor back and then remove the character at that position. The cursor also didn't wrap, so I might want to go ahead and fix that behavior. Also, maybe I ought to have something like an "End" option like in most games to exit out of the name select screen, because I'm not sure it's evident that the "go back" key (MODE) will allow you to exit and still accept the changes made.

EDIT: *nomnomnomnom*

Does that lowercase "t" have an extra pixel?

Yes. That was intentional and is part of the font.