The stack officially gets created with
ld sp, $FFF7
so $FFF7-$FFFF are never touched.

The stack has to end when it runs into something, and that something is the symTable which begins at $FE66.


You could use that ram around $FE66 for variable storage, but the trouble is, you don't actually know how much memory you'll actually have. Maybe in the OS you'll have 100 bytes, but there's a chance that from a certain shell, you'll only have 20 bytes due to some epic stack abuse.


I would recommend you use a different ram area, I put together this giant list. If you can't find enough ram on that page, then you are doing something wrong.

thepenguin77, you made a patch right? Any problems with it?

Nope it just fixes the glitch, and here's a link for all the future googlers.

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.

What language are you writing this in?

About 5 days ago, I was talking on omnomIRC when it froze, I refreshed the page and the framework of omnomIRC loaded, but I don't think it ever connected to anything. It has loaded the same way ever since. (I cleared my cache too)

Here's a picture to better explain.

I think it's due to bad hardware. There's nothing in the boot code that could possibly turn the screen black, so that's caused by an outside source. Also, it doesn't respond to key input, so it's not running the code properly.

Either his boot code is corrupted (next to impossible), his certificate is corrupted in a very specific way (next to impossible), or his calculator has some random hardware issue.

Well, it looks like runer had it right from the start. Carrying 0 coins really is the best option.

I believe the solution is to carry no change.

Whatever the cost of your purchase is and whatever coins you have, you can ensure you leave with the minimum amount of change possible by giving the vendor all of your change. Whatever coins properly contribute to the payment, the vendor will keep; the coins that do not will be returned to you. Since the cents amount of the purchase is an equally-distributed random number, subtracting your constant amount of change from this will result in another equally-distributed random number (mod 100). Whatever amount of change you contribute, the vendor will always have to return to you coins that sum to an equally-distributed random amount of cents from 0-99.

You cannot limit the amount of coins you end with, so the optimal solution is simply to limit the amount of coins you begin with.

And with 2 brute force checks to back this, I'm happy. It looks like I've been doing it right all along. (Nitaku said his results were wrong and I think "someone" solved the wrong problem.