All the cool kids are doing it! Actually, I just think I'm going to have a lot of questions, and I thought "all the cool kids" had a good idea. So, let's start with the questions!

How do I make a timer that runs a subroutine, say, every two seconds?

The only way I can think of is to have a huge multi-byte integer and increase it at the start of each cycle of my program loop, and then check for the highest byte to be 255 or something and, if so, execute the routine...

Is there a better way? If not, how many bytes would I need in order to have a long enough delay? (I'm thinking it'd be a lot...)

Thanks in advance for all the help!
-Zippy (Taw)

If your main loop runs in a fairly consistent amount of time, the best thing to do is have a variable that you decrement once per cycle, then reset to a starting value and run your periodic code if it reaches zero, more or less what you said. If your main loop is doing a decent amount of stuff, a two-byte counter will probably give you a second or two (or more). You more or less have it.

Another way is to use an interrupt handler to increment your counter, and then check the value of the counter in the main loop. Or, depending on what the subroutine does, you might be able to run the subroutine directly from the interrupt handler so you don't have to check the counter in the main loop. Using an interrupt is a more accurate, or at least more consistent, method than counting cycles through the main loop, especially if the main loop cycle varies considerably.

I'm pretty sure there's at least a ~120Hz interrupt on all models of 83(+)/84+ calcs, and some models have other clock sources as well (but I don't know if those other ones even trigger interrupts).

That's probably WAAAAAY over my head at this point. I think I'll try using just a 2 byte counter and see how that does

Sure, I understand. Interrupts can be tricky when you're still trying to learn everything else about ASM. A counter in the main loop will probably work just fine.

Actually you might be able to exploit the 120Hz interrupt without having to write an interrupt handler at all:

Code:

The "halt" instruction waits until the next interrupt occurs, so if your "main loop stuff" runs in less than 1/120th of a second, the loop will run 120 times per second. As a result, the counter decrements 120 times per second, and the subroutine is called every 2 seconds (every 240 times through the loop). Just make sure that interrupts are enabled before calling "halt", otherwise the calc will completely freeze. If you don't do anything with interrupts, they will be enabled by default.

As you can see, there are quite a few ways to do things in a low-level language like ASM (and ASM is as low as you can practically get (ignoring micro-code inside some CPU's), since it's a human-readable form of machine code).

To continue making a long story longer, if you're operating on the TI-84+ and TI-84+SE line of calculators, there are three crystal timers accessible via ports $30 through $38 that can be set to run and occasionally checked to see if they have expired yet; one or two of them is used by the OS for things like direct USB, but I believe at least one remains free for userland use.

Okay, so right now I'm trying to write a routine to write a custom 5x7 font character to the buffer. The character sprites are stored using 3 bytes where each nibble is one row of the sprite.

The routine I have come up with doesn't seem to be working, though I don't see why not. Maybe I did something wrong with the masking?

Code:

I based my code off of the masked xor sprite routine found in ASM in 28 days.

Before I start critiquing code, you do a lot of very cool and very smart things there, so many kudos! Anyway, I spotted what I think is a glitch in checking if the coordinates are aligned:


Code:
Shouldn't that ld a,e in the fifth-to-last line not be there, since you saved the unshifted e to a previously?

Ooh, good catch! That was definitely an issue, but that still didn't fix it It's displaying nothing...

Well...technically it's not nothing. It's just displaying the graph screen with the axes and "DONE" that's it.

I assume that you iFastCopy'd after running that routine, just to rule out silly omissions?

Indeed I wrote a program that just does basically

Code:

Okay, so I'm obviously failing hard here, but I'm trying to write to the homescreen from inside an app. Why won't it work?


Code:


Really I'm trying to get that 4x6 sprite routine to work, but I'm now realizing that part of the problem may have been that NOTHING seems to be working.

EDIT: Also, is there any place that documents the actual source for the different bcalls? That would probably be pretty useful...

_putc should work fine. Did you make sure that textWrite, (iy+sgrFlags) is reset so that text will go to the LCD rather than the graph buffer?

Ah, that did it...So now I can write to the LCD, but how about writing to the actual homescreen buffer? How would I do that?

You can just store the bytes representing the characters into the 128-byte buffer; it's stored in 8 rows of 16 columns each, of course.

Well, writing to the text shadow doesn't seem to be working...or am I writing to the wrong place?

But now that I've gotten it to at least display some stuff with _PutC, I was able to partially fix my font routine It still has a few bugs, but at least I can do some forms of output to trace the issues.

Also, why does this code freeze my calc?

Code:


Edit: I think I figured it out.....It's because I'm in an app, so I can't write to that address, I can only read from it, correct? Does that mean I have to write ALL data that I ever want to modify to some free area of RAM? How do I go about doing that (and still keeping track of where everything is)?

Edit again: I have concluded that that is indeed the reason...Right now I'm just looking at the RAM areas and trying to find ones that are large enough and also presumably safe....Is there a better way to get usable RAM?

No, you are allowed to rampage all over RAM addresses if you so choose. The reason that PutS and VPutS are special is that those routines reside in ROM, so your App's page gets swapped out while those routines are running, hence any constants (like strings) inside your code aren't physically available while those two routines are running. The solution is to either copy your strings to RAM and call them, or make your own PutS and VPutS inside your app that just call PutC and VPutMap respectively in a loop.

I know that...but as far as I can tell it's impossible to modify values within the app itself. That's my understanding of why that ClearPlotSScreen routine wasn't working, because as soon as I used iMathPtr5 for my save_sp, it worked perfectly. If there is in fact a way to modify values within the app itself, then PLEASE let me know how to do that.

Also, I am using entirely customized text-display routines along with a custom font, so I won't be using PutS, vPutS, PutC, or vPutMap very much if at all. I almost have my PutC routine entirely working with masked sprites and clipping, but I'm still getting a few bugs...The mask is always $F8 though, unless it's clipped.

Nope, your app is in Flash ROM (read-only memory), so you can't use the non-App program trick of using parts of yourself as scratch space.

Okay, so my question still is: Is there any good way to get scratch space, or do I just have to use safe areas of RAM?


Also, completely unrelated, I randomly thought of the idea that it would be possible to change the name of programs/appvars/lists by modifying their VAT entries. Would that work? Honestly I don't know why I thought of this at all...