Omnimaga

Calculator Community => TI Calculators => Axe => Topic started by: AngelFish on October 04, 2010, 03:47:21 pm

Title: RAM addresses
Post by: AngelFish on October 04, 2010, 03:47:21 pm
Hey, does anyone know how to display Hex RAM addresses in Axe? I tried

:{8000}-->A
:Text E°A

But it gave me a random character, not 8000h as I need.
Title: Re: RAM addresses
Post by: Deep Toaster on October 04, 2010, 03:53:15 pm
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.
Title: Re: RAM addresses
Post by: Runer112 on October 04, 2010, 09:45:43 pm
Here (http://ourl.ca/4129/124589) you go :) You'd want to use Disp sub(W2H,A)
Title: Re: RAM addresses
Post by: Deep Toaster on October 04, 2010, 10:37:43 pm
Ah, someone already made the routine. Thanks!
Title: Re: RAM addresses
Post by: AngelFish on October 05, 2010, 07:32:37 pm
Thanks for the link.

By the way, does anyone happen to know what beginning address the text sprites used by TI-OS are stored at?
Title: Re: RAM addresses
Post by: Deep Toaster on October 05, 2010, 07:36:17 pm
I think they're part of the OS itself (in Flash) ... not sure, though.
Title: Re: RAM addresses
Post by: AngelFish on October 05, 2010, 07:41:43 pm
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.
Title: Re: RAM addresses
Post by: Runer112 on October 05, 2010, 07:49:22 pm
Quote from: Qwerty.55 on October 05, 2010, 07:41:43 pm
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?
Title: Re: RAM addresses
Post by: calc84maniac on October 05, 2010, 07:50:05 pm
I also doubt the font data would be at the same address in all OS versions.
Title: Re: RAM addresses
Post by: Deep Toaster on October 05, 2010, 07:52:35 pm
Quote from: calc84maniac on October 05, 2010, 07:50:05 pm
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.
Title: Re: RAM addresses
Post by: AngelFish on October 05, 2010, 08:03:29 pm
Quote from: Runer112 on October 05, 2010, 07:49:22 pm
Quote from: Qwerty.55 on October 05, 2010, 07:41:43 pm
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?

It's a routine I'm using for TI-Explorer. I know it can access the area because the routine is precisely how I found out that the sprites are even stored in memory as is. The only reason I care to access them if because the routine has to locate an arbitrary address and read it correctly. Since the rest of Flash is difficult for my human eyes to efficiently read, the text sprites are the best area to debug with.
Title: Re: RAM addresses
Post by: Deep Toaster on October 05, 2010, 08:06:56 pm
Ah, I see.

Well, you could test much more securely by creating an archived variable and toying with that ;)
Title: Re: RAM addresses
Post by: AngelFish on October 05, 2010, 08:08:07 pm
Oh... :P

That would probably be a good idea. Just store something to a safe area of memory and read it.
Title: Re: RAM addresses
Post by: Deep Toaster on July 02, 2012, 07:25:20 pm
[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:

████████    00h
████████    00h
████████    16h
████████    09h
████████    09h
████████    12h
████████    12h

The pointer in each entry holds the location of character 01h (http://tibasicdev.wikidot.com/83lgfont#01) (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).
Title: Re: RAM addresses
Post by: kindermoumoute on July 02, 2012, 08:19:03 pm
Then... zStart could change font on 83+BE ? :P
Title: Re: RAM addresses
Post by: blue_bear_94 on July 02, 2012, 08:48:26 pm
The way most programs/apps  that do that use a font hook instead of modifying a Flash location. Overwriting the font data would be a pain (backup parts of the page that should not be overwritten, then erasing the page containing the data, restoring the backup content, and writing to the proper parts).
Title: Re: RAM addresses
Post by: Deep Toaster on July 02, 2012, 09:43:08 pm
Right, and if you want an app to change your TI-83 Plus's font, Omnicalc (http://detachedsolutions.com/omnicalc/) can do that :)

Wonder why zStart doesn't support fonts on the TI-83 Plus, though.
Title: Re: RAM addresses
Post by: thepenguin77 on July 03, 2012, 12:48:55 am
Hey, so I was writing this post when I realized that I can make fonts work on the 83+BE.

First of all, we need to remember that the font hook needs to be lightning fast. Basically, it has to be so fast that people don't even realize it's running. Here's why: the font hook is called for every single character that is displayed to the screen. For simple tasks like typing, only 1-5 characters are displayed at at time, but when you press clear, open a menu, or scroll a menu, up to 128 characters have to be rendered. At 100 characters per render, each .001 second that my font hook takes corresponds to 1 extra second to scroll 10 names in the program menu. (Which is enough to make you turn the hook off)

Next, we need to look at the memory setup I have to deal with. zStart is an app, which means that it is going to be executing from a flash page. We'll assume the standard situation where the font is archived so it is also on a flash page. Lastly, the location where I need to copy the font data is in the $845A region. Also, to make things worse, we're running in a really common hook, which means we can't touch any memory besides $845A which is what we're supposed to change.

So, in order to get the job done, we need to have zStart executing code, the archived font, and $845A all exposed at the same time. We have three memory blocks, $4000, $8000, and $C000. On the 84+, $4000 can have either flash or ram, $8000 can have either flash or ram, and $C000 can have any of the ram pages. Here's the setup I use to do the copying:
$4000 - zStart
$8000 - flash page of font
$C000 - ram page 1 (this allows me to virtually move $845A to $C45A)
In this position, the copying is rather easy, just stream from $8000 to $C000.

There is another way I could have done this to avoid the memory mess, and that is:
$4000 - flash page of font
$8000 - regular with zStart code copied here
$C000 - flash page 0 (this won't be used)
This works, but there are two key flaws with it: 1) This is a very common hook, so if I destroy like 200 bytes several times a second, I'm going to break a lot of stuff 2) Copying 200 bytes every character would severely slow the calculator down


So that's the reason I didn't think I could do it before. But I just figured out how I can do it. Instead of copying the font data to $845A immediately, I'll copy it into a part of the stack that I allocated, and then I can copy that back to $845A.

Next time I work on zStart, this is going to happen.
Title: Re: Re: RAM addresses
Post by: Deep Toaster on July 14, 2012, 01:21:54 am
Not sure what you said about the stack, but glad to hear ;D