You can't display numbers in hex in any way. Axe doesn't support that, so you'll have to write your own hex-displaying routine.

Also, E reads a hex value to an int, not the other way around. So you can't use E like that, either.

Ah, someone already made the routine. Thanks!

I think they're part of the OS itself (in Flash) ... not sure, though.

Yep, I know they're in the archive (somewhere near the end on the last page, I think). But does anyone know the address in memory? I need to see if certain routine is working and the only way to do that is by giving it a specific area of memory to read. Unfortunately, the only area of memory that I can visually check happens to be those sprites, which I don't know the address of.

What routine is this? Unless your routine is an Axe/asm hybrid with the ability to read from arbitrary places in ROM, you're not going to be able to access this. Why do you want to access the font images anyways?

I also doubt the font data would be at the same address in all OS versions.

True.

You should probably use the routines that you have. If you want to read the bitmap of the character or something, do a Fix 5, then Text( the char you want somewhere on the buffer and read it from there. It works.

Ah, I see.

Well, you could test much more securely by creating an archived variable and toying with that

[supernecrobump]

As calc84maniac pointed out, there's not really a point since it's in different places in different OSes, but since I just spent the last hour digging this up, I figured I might as well post it. For posterity.

OS		Address of n
1.10–1.14		$450D
1.15		$454A
1.16–1.19		$4584
2.30–2.43		$45B4
2.55MP		$4605

(It seems to be on page 07h across all OS versions.)

The font is basically a giant table of 5x7 sprites. Each element has eight bytes. The first byte is the width of the character (which is utterly pointless, since it's always 5), and the next seven bytes are the actual sprite data for that character. The sprite data is aligned to the right, meaning the rightmost column is bit 0 (and since they're all 5 pixels wide, the leftmost column is bit 4). Fore example, here's the sprite data for character 01h, n:


The pointer in each entry holds the location of character 01h (n), so the font table technically starts eight bytes before that. But since 00h never gets displayed anyway, those eight bytes overlap with the end of some random OS routine, so they're essentially garbage.

I couldn't test the 84P OS versions before 2.30 because WabbitEmu froze on them for some reason (WabbitEmu itself didn't freeze, but the calculator it was emulating did).