The next page is simply the next page. Literally. So if you run off of 08, the next page is 09. You never have to worry about it crossing a sector (i.e. 0B -> 0C or 0F -> 10) because TI's file structure doesn't allow it.

One problem I immediately see with your code is that it assumes that the name of the program is going to be exactly 4 letters long, if that's true, then cool, but otherwise you'll have to add some code to fix that.

Here is a relevant wikiTI article on the flash variable format, what you're interested in starts at "After the status byte for that sector..."


Anyways, the best way to check if you went over $7FFF is to check bit 7 of h. If bit 7 is set, then increase the page number by one, reset bit 7, and set bit 6.

Here is how I've been doing this whole process for the past 3 years: (this is from zStart)

ld hl, name
rst 20h
bcall(_chkFindSym)
call findStartInRom

...

;##################################
;Move to start of data in Rom
;Input: Output of _ChkFindSym
;Output: HL = start
; B = rom page
;Destroys: C DE


FindStartInRom:
ex de, hl

LD de, 9

add hl, de

call fast_bhl

bcall(_LoadCIndPaged)     ; number of letters in variable name

inc c
ld e, c

add hl, de
;$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
;fall through
;########################################
;faster bhl
;only checks for going over

fast_bhl:
ld a, h
res 7, h
set 6, h      ; this is a little hacky to save space, but it does what I said it does
cp h
ret z
inc b
ret


Also, if speed isn't an issue, there's always bcall(_flashToRam) (it's not actually all that slow).

Awesome, thanks! And when you say "crossing a sector", i don't understand the difference between a "page" and a "sector". Is a page swapped into a sector? And the filename will always be the same since there's only going to be one file. The program is getting too large to fit the level packs in so i wanted to try making them external. Speed's not an issue and i would've used _FlashToRam, but the thing is the levels are RLE compressed and i wanted to unpack them directly into my buffer (rather than look for ANOTHER 2k+ space in RAM to store the compressed levels into).

Another option might be to calculate how many bytes are left until i reach the next page and load it into bc or something and switch to the next page when the counter runs down (or just exit if i reach the end of data before the page ends), that way i don't have to test after every byte read. I like that "fast_bhl" routine, it's pretty clever

EDIT: Alright, it's finally working like a charm My 83+ arrived today and the first thing i did was toss my program on there and much to my dismay many of the levels were crashing. I added these few lines in (which i think is slightly shorter/faster than the code above? If it is, to you or anyone else: "help yourself!"):
ld a,%10000000
and h
jr z,continueRLE
rra
ld h,a
in a,(6) ;charger la prochaine page de FLASH
inc a
out (6),a
continueRLE:
...and now it's working great. Thanks a lot

EDIT2: Not faster than calc84maniac's code I just saw your post, thanks

EDIT3: Errr... maybe not. It works fine now on the emulator but oncalc it's buggy

EDIT4: (sorry) And i just ran it again and now it's working perfectly. It's so weird. I can't remember if i garbage collected or not, i think so, which might be why it's working now

EDIT5 (and final!): I finally figured out what was causing it, my routine works fine once you have the address and are advancing one by one, but to get the initial offset you need to use one of the other routines since they don't depend on you changing hl one byte at a time. Now everything's working great on both the emulator and hardware

This isn't very on-topic, but if besides reading data from archive you also plan to write to it, be very careful to not mess up and writing to the wrong Flash sector (OS certificate). This can permanently damage your calc. Not sure if reading the archive directly from the wrong sector can cause damage, though.