Excellent news, I look forward to seeing this! 
I've been away for a while. Any news on the TED extended system card? How did that work out?
On a coding note: For some strange reason I decided to do stack manipulation for the BRAM routines (they are written from scratch, instead of using the syscard ones). I'd normally use macros, but I decide to use JSRs instead, but needed an escape level that was above the original call. So I just increment the stack, and hard jump to a return address on an upper level (for returning errors). Works quite nice. Not sure why I never did this before; saves more memory than macros and still keeps code listing nicely compact and clean.
Not only that, but the logic for my loops is now different because of this setup. After years (a decade now) of coding in assembly, it's nice to see something different in logic/code approach. Doesn't mean so much to the user that can't see it, but it's kinda neat:
ldx #$12
.LoopInner
jsr __GetBRAMByte
jsr __CMP_ID
dex
bne .LoopInner
;match found!
;return DIR offset in A:X, status in Y
;Y=0, OK
cly
lda __DIRoffset+1
ldx __DIRoffset
rts
__GetBRAMByte and
__CMP_ID have their own error handling code, and fixes the stack to negate the call so it can hard jump to the error output routines. Or in the case of
__CMP_ID, increment to the next DIR block, and re-enter the loop while
__GetBRAMByte handles all out of bounds checks (both bram size and bram used range).
Hmm. Maybe I could even go a step further with
__GetBRAMByte, and have the return jump be from a table. And the index (into the jump table) would be the register in which the function that called it, would set the return address. That way I could reuse that code for other functions. I doubt that would be considered an "object" or some such, but something along those lines.. (reuseable code for a different function and slightly different code path). Or maybe not..
Also, spring semester is over and two week coding frenzy has begun!
