For some reason, the carry flag is NOT set when a number overflows with inc/dec, not even an 8-bit one.

For example:

ld l, 255
inc l

does not affect the carry flag.

That got me good when I first started learning Z80 ASM. For a quick reference, take a look at this thing that every Z80 ASM developer ought to have: http://www.ticalc.org/pub/text/z80/z80instr.txt

I frequently view it when I'm unsure what flags any given instruction will affect. A "." indicates that the flag is not affected and a "*" indicates that the flag will be affected by its definition, whatever that may be (like when you add two numbers together and the result is over 255, the carry flag will be set). It is rather convenient how they set it all up, too.

EDIT: More often than not, I'll view that file just to find out how many bytes that particular instruction will take up. Great for those labelless jumps like "jr $+N"

Thought of how I am going to store all this data in a sane manner in this CaDanITE project. So I figured I'd go with sort of a miniature file system. The details are below in this code box thinger. I just wanna know if it looks like I'm missing anything, or if you can suggest a better or easier way to do it. Coz right now, I'm not entirely liking the fact that I have to have pretty much a file system for a CaDanITE project file, but it's the best thing I can come up with at the moment.
CaDanITE project file structure
Objects not part of the initial table structure gets a preallocated 8 byte name.

;----START OF FILE HEADER
.db $BB,$6D     ;denotes a compiled ASM program
.db $C9         ;If you attempt to run this as an ASM program it exits.
.db "CaDanITE:" ;9 characters that identify this as a CaDanITE level
.db 24chars     ;24 character description header for the project
;----START OF THE DATA FILE TABLE
.org $0000      ;addresses are with respect to this for relocatability
.db NN          ;number of 256-height screens
.dw ScreenDat1  ;address of screen data (specified far below)
.dw ...         ;Every 256 height screen has a boss assigned to it and their
.dw ScreenDatN  ;data pointers will be defined with the screen data
;---
.db NN          ;number of scripts
.dw ScriptDat1  ;address of script data (also defined far below)
.dw ...
.dw ScriptDatN
;---
.db NN          ;number of enemies that can be done
.dw EnemyDat1   ;address of enemy data (defined really far below)
.dw ...
.dw EnemyDatN
;---
.db NN          ;number of path data streams
.dw PathDat1    ;address of path data (uhm...)
.dw ...
.dw PathDatN
;---

;Filetype details:
;ScreenDATA    = 01 ;21 bytes total data size. Contains pointers to other files
;ScreenBITMAP  = 02 ;521 bytes total data size.
;BossAddress   = 03 ;16+1+N(2) bytes where N is # of spellcards. Points to other files
;SplCrdDATA    = 04 ;42 bytes total data size.
;BossGRAPHIC   = 05 ;129 bytes total data size
;BossCharSPR   = 06 ;9 bytes total data size
;BossTEXT      = 07 ;1+2+NN bytes where NN is data stream byte size
;ScriptDATA    = 08 ;1+2+NN bytes where NN is data stream byte size. Pts 2 othr files
;EnemyDATA     = 09 ;8 bytes total data size
;PathDATA      = 0A ;9+1+N bytes, where N is number of step pairs in movement path.

;-----BEGINNING OF CADANITE PROJECT FILE SYSTEM
;ScreenDATA
.db 1 byte      ;FILETYPE
.db 8 bytes     ;name of this data
.dw BossAdr     ;address of boss details ($0000=not set yet)
.dw ScreenBtm   ;address of 64x64 area indicating bottom screen
.dw ScreenBtmLp ;address of 64x64 area indicating bottom loop
.dw ScreenTopLp ;address of 64x64 area indicating bottom loop
.dw ScreenTop   ;address of 64x64 area indicating bottom screen (boss)
.db ScrollDelay ;A value between 1-9. A higher value means slower scroll.
.db LevelLoop   ;A value between 1-128. A higher value means the stage loops more.

;ScreenBITMAP
.db 1 byte      ;FILETYPE
.db 8 bytes     ;name of this 512 byte chunk of data
.db 512 bytes   ;screen data

;BossAddress
.db 1 byte      ;FILETYPE
.db 8 bytes     ;name of this entity
.db BossScript  ;Address to the boss script. lumped together with scripts
.dw BossGraphic ;Address to 32x32 boss graphic
.dw BossCharSpr ;Address to 8x8 boss sprite
.dw BossText    ;Address to boss dialog text
.db NN          ;number of spellcards in the game
.dw SplCrdAdr1  ;Address to the spellcard graphic
.dw ...
.dw SplCrdAdrN

;SplCrdDATA
.db 1 byte      ;FILETYPE
.db 8 bytes     ;8 bytes for spellcard graphic name
.db 1 byte      ;indicates normal bracket or special bracket for spells
.db 4*8 bytes   ;32 bytes for spellcard text underlay (overlay will be autobuilt)

;BossGraphic
.db 1 byte      ;FILETYPE
.db 128 bytes   ;graphic. Tied to name of boss

;BossCharSpr
.db 1 byte      ;FILETYPE
.db 8 bytes     ;graphic. Tied to name of boss

;BossText
.db 1 byte      ;FILETYPE
.dw StreamSize  ;size of text file unknown. Tied to name of boss.
.db "textdata"  ;formatted for whatever. Uh. Details unknown. Won't get to it soon :P

;ScriptDATA
.db 1 byte      ;FILETYPE (boss and stage scripts gets a different filetype)
.dw StreamSize  ;size of the script file
.db N bytes     ;Script contents

;EnemyDATA
.db 1 byte      ;FILETYPE
.db 1 byte      ;enemy type flags
.db 2 bytes     ;Starting (x,y) position
.db 1 byte      ;Initial HP
.db 1 byte      ;Script ID
.dw cyclecount  ;Initialize this enemy at this cycle count (0-65535)

;PathDATA
.db 1 byte      ;FILETYPE
.db 8 bytes     ;Name of this path
.db StreamSize  ;number of bytes that this path can take. Up to 128 (256 steps)
.db N bytes     ;bytes in the path stream


Quote from: Iambian on September 16, 2010, 04:08:25 pm

Slowly progressing. Initial menu now works. Working on an integrated help thing so you can press F1 (Y=) to get details on any menu item your cursor is hovering over. That should be fun.

Very nice

Just make sure that the help isn't too large, though. It would be bad if like 8 KB of the game was just help

Oh no. This level editor isn't going to be part of CaDan. It's going in its own app, which means I can use as much space as I want for it. I plan for the thing to be 2 pages, but that's for all the text that I'm going to be throwing in. Two pages is probably overdoing it but I wanted something more than just a level editor. I wanted to practice a better way of doing things that might later be incorporated into E:SoR or some other project.

It won't be a command-prompt. The project is going to be more menu-based than anything else. At the moment, I'm trying to get cross-page calling down. What I have is essentially a variation on the bcall routine. Just ... trying to get it to work.

yay legendary cherry products! *nom*

Also, the laptop is back together and working (mostly). There's still problems with the screen, but it's working its best in like a year. Very cool stuff. Cemetech's got a topic on photos I shared about the fix.

Thanks for teh bday stuffs ^_^

If you wanted more execution space, it's as BuckeyeDude says. Use an app.

Now, sometimes you just need more contiguous RAM than the OS allows and you don't want to eat up much of the calc's "Free RAM". I've done a little memory juggling in CaDan to allow me access to $8000 and $8EFF by selectively copying stuff to plotsscreen and appbackupscreen. Selective copying, so I can safely eat up all the other saferam areas between the mentioned addresses. Might want to check out it's source if you want to do this.

Sorry for not really answering you question, tho. You might want to do a little study (by looking at the ti83plus.inc's RAM locations) and find out what memory you might want to shuffle away and what memory you can safely overwrite. Also include in your little study areas that can be reliably initialized if you don't want to or need to save that information. What comes to mind is this chunk of RAM at "statVars" and using bcall(_DelRes) to "invalidate statistics" so the OS doesn't crash if you try to do statistics after using that RAM as scratch.

This thread smells of delicious succulent bite-sized sweet crimson orbs ^_^

Having an entire game series is pretty cool.
Git'er done, and I'll be playing this stuff on my calc.