[TI Hardware] Interrupt Mechanism

[benryves]

Assume I'm talking about a regular 83+ only.

As far as I'm aware, there are four hardware devices that can generate maskable interrupts: On key, timer 1, timer 2, and the link port.

Now, the way I see it, there are two flags associated with each hardware device. One is a flag that indicates that that item has generated an interrupt, and the other is a flag that enables or disables the hardware's interrupt generation (mask).

Thus, as far as I can see:

/INT = !([OnKeyGenerated] || [Timer1Generated] || [Timer2Generated] || [LinkGenerated])

Now, would writing to the mask values will clear the "generated" flag? ie,

Code: Select all

void UpdateOnKeyMask(bool isEnabled) {
    OnKeyMask = isEnabled;
    OnKeyGenerated &= isEnabled;
}

So, if I was to press the On key, I'd check the OnKeyMask flag; if enabled I'd then set OnKeyGenerated to true (which would, in turn, assert /INT?) /INT would only become de-asserted when the mask was cleared in the ISR..?

As a comparison, the SMS only has the VDP (video) attached to /INT; it has two register bits that stipulate whether it can generate line or frame interrupts. When an interrupt condition occurs and the requisite bit is enabled it asserts /INT; /INT is de-asserted when the VDP's control port is read. My implementation works accurately with the notoriously awkward to emulate games, so I'm assuming the fault is in my understanding of the TI's interrupt mechanism and not my implementation of the Z80's interrupts.

[Jim e]

So, if I was to press the On key, I'd check the OnKeyMask flag; if enabled I'd then set OnKeyGenerated to true (which would, in turn, assert /INT?) /INT would only become de-asserted when the mask was cleared in the ISR..?

Thats exactly it.

Port 3 is only a mask.
Port 4's read says what generated the interrupt.
Interrupting hardware only sets port 4's bits, doesn't reset.
The port 4's value is always masked by port 3's value.
If port 4's value is not zero it generates an interrupt and will continue doing so until port 3 masks it out.
That excludes the on button bit, obviously.

On a related note.

On the 83+, interrupt frequency is directly tied to the CPU clock. I've over and under clocked my calc to test this, the tstates between interrupts never change.

For simplicity of explanation, I'll describe how the the 84+'s timer interrupts fire(they are relative to the 83+ I just never documented exact numbers like I did for the 84).

Interrupts on the 84+ are tied to the 32768hz crystal timer. It's based on a count down register, ever tick of the timer the register decrements, if it hits zero it sets the interrupt line and resets its starting value and keeps ticking whether its acknowledged or not.

The starting value the register is set to is based port 04s bits 1 & 2.

64+(80*mode) = starting value

Where mode is a value 0,1,2 or 3. Giving an interrupt frequency of 32768/(64+(80*mode)).

The second timer always fires twice before the first would. In a manner like so:

timer2 fires - 12 tick delay - timer2 fires - 12 tick delay - timer1 fires

The delay between when it fires never changes. It's always before timer1

Those values would just scale up to the 83+ cpu clock instead of the xtal timer.

[benryves]

Thank you for the confirmation/explanation. With your help from the other thread I got OS 1.12 to boot, so thank you there as well.

[Timendus]

Ohoh... Ben is jumping the emulator bandwagon?

[benryves]

Not really, my Z80 implementation isn't accurate enough to be a decent debugging emulator (no undocumented flags, for example).

I put up some pics here anyway, after implementing a timer system according to Jim e's documentation.