Hey everybody,
Sorry to make a new post right away, but I've had a seemingly simple question that I just can't seem to get an answer to. I've scoured the internet and even cemetech's old posts, but I can't find anything!!

I want to make a metronome for the TI-83 plus/TI-84. I have (for the most part) the knowledge of asm that I need to do it, but one VERY important thing is missing: I don't have any way to monitor time! I was wondering if there is a memory location or special register where a tick count for the processor is kept. I know I could count out the clock cycles in the main loop as a last ditch effort for timing , but I want something.... easier.

One way you could have a fairly accurate delay is by sticking NOPs in your code, which take up 5 clock cycles each. I think you could also use interrupts for a timer, but I'm not sure. You can't really access the clock directly, though.

Awesome idea with the NOPs!
I still need to read more into interrupts, so I might try that too. I don't know a ton about interrupts yet.
When you say: "You can't really access the clock directly, though," is there some piece of information that confirms this? Like, have you tried it before and it didn't work or is it just totally undocumented?

There isn't any opcode, port (except for port $20, but that just toggles between 6 MHz and 15 MHz mode), or memory location that contains data from the CPU's clock; the clock is only used internally and can't be accessed from anywhere else.

The most compatible way to get a time base would be with the timers, which exist on the 83+SE and 84+/SE.

On the 84+/SE, ports 0x45-0x48 expose the ASIC's RTC as a 32-bit integer. The RTC stands a decent chance of being more stable than the CPU clock, too, since I'd guess the CPU clock is driven by a PLL from a low-frequency (32 kHz) crystal. You could use the RTC as a calibration base for your interrupt frequency.

On the plain 83+, you're out of luck and probably need to kludge it with the interrupt frequency, which is unfortunately not very stable. I'd only consider cycle-counting as a last resort, since it requires a lot of effort to program and doesn't allow the CPU to become idle, thus draining your batteries appreciably faster.

NOP is four cycles, btw (IIRC).

Thanks for the info, Tari. I want it to be usable on the 83 plus, though, so that just sucks for me.
That being said, it doesn't have to be SUPER accurate. Once I've learned interrupts on the z80, I'll just use that.
I mean, when I practice my scales, I don't aim for milliseconds of accuracy (even though I bet my professor would like that )

Edit: sorry I missed your other post, souvik1997. Thanks for the information (I'm guessing this is for the 83+). Why can't they just make things easy for timing?! Everybody knows that a calculator NEEEDS a timer! ()

You can easily do cycle-counting to come up with something that is moderately accurate on the TI-83+. If you want to get slightly more accurate, if you think of things like iFastCopy and your (sound output for the metronome clicks?) other routines as a bit too non-deterministic for cycle-counting, you can also install a little interrupt that simply increments a counter every time it is invoked, and since interrupts are triggered fairly reliably at about 110 (220, 440) Hz, you can make a fairly accurate clock with that.

iFastCopy?
And I'm afraid that even if the interrupt can run at 440Hz, that might not be fast enough. The pitch has to be higher than 440.

Are you making a metronome or something else? (A tuner?) A metronome running at 440Hz would be pretty impressive, let alone the musician who could keep up with it (440Hz works as 26,400 bpm).

Indeed, I'd be impressed with anyone who could keep up with even 110Hz (6,600 bpm).

That said, I would go with an interrupt approach. Inside the interrupt handler (running at 110Hz), subtract your metronome rate (in beats per minute) from a 16-bit counter. When the counter goes negative, set a flag and add 6600 (interrupts per minute) to the counter. This is a basic Numerically-Controlled Oscillator (NCO). The result is that the flag gets set at your desired rate, with a jitter of +/-0.005 second per interval (which the user won't notice).

In the main program loop, check the flag after every interrupt. If the flag is set, clear it and play a short tone/beep/tick. You can use practically any method to generate this sound, as it doesn't affect the metronome timing, as long as the sound is shorter than the metronome interval (don't make the "tick" one second long if you want to support 60bpm or faster).

You misunderstand, the interrupt is for incrementing a timer so you know when to emit clicks. The sound routine itself does not run in the interrupt. If you wanted a very very simple sound routine, for example, you could use:

http://dcs.cemetech.net/index.php?title=PlaySound

If you could keep up with anything above 6 Hz (360 bpm), wow...
my worry with the 440 Hz being too low was that I need a sound above the range of most instruments to be produced for the click. Playing an Ab major scale would be uncomfortable if your met clicked at at pitch of 440 Hz

So, yes, Kerm, that was my misunderstanding. Thank you for clearing that up =)

However, as much as I respect doors CS, I don't want my project to depend on it. I want this program to be accessible to people who are not very serious calc users (people who don't know how to/want to install an os, even if it is easy).

I hear what you're saying. It's a shell, though, just to make that distinction, rather than an OS. MirageOS and CrunchOS are mis-named in that they too are shells, not OSes. At any rate, the routine is a trivial one, about 10 or 20 lines of code, so that's no problem for this particular program. However, you'll also want to do things like copy the graph buffer to the screen fast (especially if you want an animated metronome graphic) and similar tasks, so you may find that there's enough support routines you need to make it worthwhile. If not, it's always there for more complex future projects.