[Featured][Dev] PindurTI (Best Thread 2005)

CoBB · Post by **CoBB** » Fri 01 Apr, 2005 2:47 pm

Currently my implementation doesn't distinguish between normal and interrupt modes. The returned value is always the activity level of the corresponding interrupt line, and writing acknowledges (by a value of 1, not 0!) and masks at the same time. It can't be the mask, since the value read is either 8 or 0 when just polling (depending on the state of the on key, of course). I also tried the upper bits of port 4 if they affect CPU speed, but it wouldn't for me either.

There's also another interesting thing: when I output 1 to port 3, the calc is turned off as if I had pressed 2nd + on, and it's turned on by pressing on in itself. No need for halts after. However, if I just turn the LCD off and disable the timer interrupts, the effect isn't the same, because I have to turn the virtual calc off 'properly' before getting the image back.

Thanks for everything, I'll look into this ASAP.

Jim e · Post by **Jim e** » Fri 01 Apr, 2005 3:10 pm

I tried to see if it the upper bits of port 4 reset the timer they don't seem to.
But a sound recording test may show some type of difference with the second timer, not in frequency but in relation to occurance.

As far as turning off using port 3, i've always needed a halt. But turning off the lcd with port $10 wasn't the same as using port 3. I didn't look much into this though.

Wait.... whats this about lines, masks, and polling. On an 83 polling outside of the interrupt will only return 0 or 8 like you said. But once an interrupt occurs it shows what generated it....But wait.... I'm still lost , can you go into more detail on the first paragraph.

CoBB · Post by **CoBB** » Fri 01 Apr, 2005 3:23 pm

I said it because Tijl wrote something like he'd expect it to return the interrupt mask when no interrupt is in effect.

Kalimero · Post by **Kalimero** » Fri 01 Apr, 2005 6:04 pm

Currently my implementation doesn't distinguish between normal and interrupt modes.

Interesting. Does it work like this on a real calc? Can you enable the timer interrupt and at the same time clear an ON key interrupt for instance? Or to put it in a different way, does out(3),0Bh to clear an on key interrupt also enable timer interrupts?

There's also another interesting thing: when I output 1 to port 3, the calc is turned off as if I had pressed 2nd + on, and it's turned on by pressing on in itself. No need for halts after.

Without the halt, code keeps executing. When you press ON, an interrupt is generated which will turn the screen back on, because bit 3,(iy+9) is still set (onRunning).

However, if I just turn the LCD off and disable the timer interrupts, the effect isn't the same, because I have to turn the virtual calc off 'properly' before getting the image back.

What exactly do you mean? out(10h),2 out(3),9? In that case, pressing ON will generate an interrupt that basically only reenables timer interrupts. You'll have to out(10h),3 to get your display back.

But a sound recording test may show some type of difference with the second timer, not in frequency but in relation to occurance.

Interesting. Is there something similar on the 83+? Because I would expect that to be more or less the same.

Btw, I've updated a couple wikis, including the info you linked to jim_e. Editing a wiki isn't so difficult by the way. The tutorial on http://en.wikipedia.org/wiki/Help:Contents is a good start. And if you want to create a new article you can just copy-paste from an existing page and start from that.

CoBB · Post by **CoBB** » Fri 01 Apr, 2005 6:32 pm

Kalimero wrote:Interesting. Does it work like this on a real calc? Can you enable the timer interrupt and at the same time clear an ON key interrupt for instance? Or to put it in a different way, does out(3),0Bh to clear an on key interrupt also enable timer interrupts?

It acknowledges the same interrupts as it enables, so that would clear the active flag for timer 1 and the on key, and enable their interrupts at the same time.

Without the halt, code keeps executing. When you press ON, an interrupt is generated which will turn the screen back on, because bit 3,(iy+9) is still set (onRunning).

Unfortunately it doesn't seem to happen.

What exactly do you mean? out(10h),2 out(3),9? In that case, pressing ON will generate an interrupt that basically only reenables timer interrupts. You'll have to out(10h),3 to get your display back.

No, I mean the emulator implementation. If the virtual LCD is powered through bit 3 of port 3 (besides the usual command port output) and the other bits mask the appropriate interrupts, the effect is different from the real thing.

Kalimero · Post by **Kalimero** » Fri 01 Apr, 2005 7:12 pm

CoBB wrote:It acknowledges the same interrupts as it enables, so that would clear the active flag for timer 1 and the on key, and enable their interrupts at the same time.

Interesting, makes you wonder why ti writes twice to port 3 at the end of the interrupt handler.

Without the halt, code keeps executing. When you press ON, an interrupt is generated which will turn the screen back on, because bit 3,(iy+9) is still set (onRunning).
Unfortunately it doesn't seem to happen.

eh? what doesn't happen? on the real calc?

No, I mean the emulator implementation. If the virtual LCD is powered through bit 3 of port 3 (besides the usual command port output) and the other bits mask the appropriate interrupts, the effect is different from the real thing.

So out(10h),2 out(3),1 halt? Can you explain what exactly is different?

Kalimero · Post by **Kalimero** » Fri 01 Apr, 2005 8:04 pm

Kalimero wrote:
CoBB wrote:It acknowledges the same interrupts as it enables, so that would clear the active flag for timer 1 and the on key, and enable their interrupts at the same time.
Interesting, makes you wonder why ti writes twice to port 3 at the end of the interrupt handler.

I've taken another look at the code and acking with 1 doesn't seem to be correct. After an ON-key interrupt, the tios always first writes a value with bit 0 cleared (0A, 00, 08) and then sets an appropriate mask. And on a timer interrupt it always writes 09 first. There's one case (0,(iy+16h) reset) where on a timer 2 interrupt it writes 4 first, but then timer 2 gets disabled.

Jim e · Post by **Jim e** » Fri 01 Apr, 2005 11:04 pm

This is all very interesting...erm..well...you know what I mean.

Kalimero wrote:CoBB wrote:
It acknowledges the same interrupts as it enables, so that would clear the active flag for timer 1 and the on key, and enable their interrupts at the same time.

Interesting, makes you wonder why ti writes twice to port 3 at the end of the interrupt handler.

That's odd the 83 hardware acknowledges and enables. No that does sound right.

I find it odd that the 83 code Only clears the interrupt that used it. Where as the the 83+ clears everything.

CoBB · Post by **CoBB** » Sat 02 Apr, 2005 6:11 am

Actually, even the current emulation is rather 'approximate', I'll get back to this stuff after improving it. There are some hardware experiments I need to do first.

Jim e · Post by **Jim e** » Sat 02 Apr, 2005 6:18 am

Do you think TI would answer if you asked about certain ports?
**waits for everyone to stop laughing**
No seriously, I'm suprised shadow phoenix even got response, perhaps a purposely on your part might convince them to give you a clue.

With all else aside, what next for you: taking a break, gui, debugger, more emulation, different project?

CoBB · Post by **CoBB** » Sat 02 Apr, 2005 6:26 am

I don't see much point in starting a new phase while the current one is unfinished. Correct 83 emulation is my first concern, because I'm sure most of it can be reused for 'close' models. A debugger would be nice too, but it takes a bit more time to write, and I can do without it now.

Different project? This one is far enough for completion.

I checked out this paging stuff, and it applies to the 83 as well. So bit 0 of port 4 is finally implemented. However, I'll need to have a closer look at interrupts, because there are two unresolved issues:

- I have to ack with 1, otherwise the cursor will blink really slowly (because the 3 normally consecutive interrupts are placed apart to the distance of the period set)
- I have to reset the counter of the interrupt acked, otherwise GPP programs just can't run

Jim e · Post by **Jim e** » Sat 02 Apr, 2005 8:58 am

Is it possible those those problems have the same cause.

This is what I know about the interrupt timers and port 3:
The timers should never get reset, unless a cycle is complete
They should constantly be counting no matter what.
Once one should occur, then the line is set and the cpu will interrupt if EI was set, if not then it will occur once EI is set.
Reseting bits from port 3 clears the line and prevents that hardware from generating an interrupt.
Setting bits allow that hardware to generate an interrupt.

My thought is if the interrupt timer is reset by setting a bit of port 3, then the ti-os interrupts may not occur as often as they are suppose to be because it has alot of code spacing it out.

But one thing, did you test the recording the ON interrupts, I got some wierd results, I can't really describe it. I was trying to see if on interupts are only occur every so often, but the results were inconclusive.

Kalimero · Post by **Kalimero** » Sat 02 Apr, 2005 12:10 pm

Jim e wrote:Reseting bits from port 3 clears the line and prevents that hardware from generating an interrupt. Setting bits allow that hardware to generate an interrupt.

So writing to port 3 is a logical and operation on the interrupt lines and a store for the interrupt mask at the same time? That would mean clearing a timer interrupt for instance at the same time disables that interrupt. Could be, but I don't think that's the case.

Jim e · Post by **Jim e** » Sat 02 Apr, 2005 12:40 pm

Well thats how it works on the 83+, and I would bet a great that the 83 does the same. I long time ago I wondered what would happen if I only wrote the mask($0b), i got recursing interrupts and my calc crashed.

I believe my statement is true because that would explain why ti-os writes twice to port 3.

The first usually $09 or $0a, $09 clears the timers, $0a clears the on key.

Then it writes $0b(or $0F if set 0,iy$16 ), which enables the used timers and the the on key interrupt.

Otherwise there is no need for that code. You would only need to write $0b.

And just to restate myself becuase I think it's important, the timers keep counting even if they are ignored by port 3. so if an interrupt is generated and not ack the timer will continue counting and generate another when cycle is complete, if possible.

Kalimero · Post by **Kalimero** » Sat 02 Apr, 2005 2:33 pm

Right, but that's not what I was trying to say. Consider the following interrupt routine:

Code: Select all

ex af,af'
ld a,8
out (3),a
ex af,af'
ei
reti

That would clear any interrupt line right? Now the question is, does it also disable all interrupts or does it only clear the interrupt lines and leave the mask intact?

the timers keep counting even if they are ignored by port 3. so if an interrupt is generated and not ack the timer will continue counting and generate another when cycle is complete, if possible.

You mean disabling the timer interrupt (either through port 3 or using di) and then reenabling it, doesn't result in a phase change? Or in other words, the actual timer doesn't stop pulsing, but the pulses are just ignored.