Is it necessary to enable LCD interrupts to correctly time writes to VRAM? Also, is there an exact fps for the ti 84?

I'm beginning to doubt, since many programs I've examined don't seem to use its interrupts.

I'm asking this question since I'm in the starting stages of an interrupts library for the C SDk, and I want to know if it's worth it.

It is not necessary to use LCD interrupts to correctly write to vram, but it is useful to know when to swap buffers using interrupts. Keep in mind some C library functions disable interrupts; and the OS really interferes a lot with interrupts, but creating your own vector table and interrupt handlers would totally be doable, as library functions can be easily changed to not disable interrupts at crucial moments. If you would like; I would totally be willing to help out with this and perhaps add it to the C library structure, if at all possible

Thanks
Here is a quick idea of what I'm planning

*isr setup*
void im_setisr(int32_t **vector, void (*isr)())

void cleanup()

*for use in isr*
void inableint(int16_t mask)
void im_aqint(int16_t mask)
int16_t im_readmaskedstatus()

*LCD related*
void im_setlcdintmask(int8_t)
void im_aqlcdint(int8_t mask)
int8_t im_readlcdmaskedstatus()

Ah, I see. The way the interrupt controller works is by specifying a particular bit for all of the interrupts that are generated for each piece of hardware. The steps involved include configuring the controller to use the IVT location, build the IVT (usually by just loading the same address), and then use a single ISR routine that handles the source of all the interrupts. This is probably the best solution by using interrupt mode 2, which means it will be nice and modular for all interrupt sources. There really is no easy way to set up a IVT for entries, mainly because there is no FIQ signal. Of course, since you are changing the OS interrupt vectors, you would need to restore the vector entries. Here's some sample code to reset: (Courtesy of DrDnar)

tl;dr: The IVT would just all contain the same address. There is one ISR which handles the source of interrupts, which then branches to the actual routine handler, which can be set by the user; otherwise it can be ignored.


Code:


Here's basically what happens to the CPU when in interrupt mode 2:

The interrupting device places the lower 8 bits of the interrupt vector on the data bus. Bit 0 of the byte must be 0. The middle byte is set by the CPU's Interrupt Vector Register, I.

Applications running in mixed-memory or ADL mode use {I[15:0], D[7:0]} as the full interrupt vector address. A 24-bit word is fetched and loaded into the Program Counter, PC[23:0].

At the risk of sounding like a broken record... For best forward compatibility, I think that ISR and system hook handling should be considered "core" functionality of the third-party execution environment under development, and performed by a common, shared block of code, wherever it is (shell-independent library with special handling by libload, libload itself ? You TI-eZ80 people have more insight into that than I do).
TI can still screw us up any time to some extent, but having some common code can't hurt the fixing process: not more (and certainly fewer, in practice) places to fix.

I prototyped the im_setisr function, and I came here to find out if it is acceptable

Code: