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

Jim e · Post by **Jim e** » Sat 02 Apr, 2005 2:49 pm

Well my info coming form the 83+, but the way interrupts are handled should be similar. Some of the things cobb wrote where identical(or atleast relative) to what I found.

Right, but that's not what I was trying to say. Consider the following interrupt routine:
Code:
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?

That would clear the lines and disable all hardware interrupts, though I don't know about this normal mode and interrupt mode for port 3. I don't know how a difference can be distiguished.

The only way I can see to test the modes would be to DI and wait for an interrupt to generate.

Quote:
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.

Yup. If you only DI though the lines will set and it will generate upon EI.
I wish it didn't though, we could of had flawless grey by now.

CoBB · Post by **CoBB** » Sat 02 Apr, 2005 3:23 pm

PindurTI also separates the z80's iff states from the three calculator specific interrupt lines. While the interrupts are disabled the timers keep counting and activate their corresponding lines at each overflow. As soon as interrupts are enabled and at least one line is active, the interrupt occurs.

The on key interrupts aren't simulated really, I just set the on line active when the mouse button is pressed. Even if the interrupts are disabled at the moment, this will be preserved as long as it isn't explicitly cleared.

CoBB · Post by **CoBB** » Sat 02 Apr, 2005 5:48 pm

I played around a bit with my calculator and found another useful piece of information: bit 4 of port 4 also regulates interrupt frequency. When the bit is reset, the frequency is 90% compared to when it's set. This applies to the whole interrupt pattern, it's effectively scaled in time, even the relative positions of the two timers.

Basically I wrote a little program in which I polled port 3 with the interrupts disabled. I set the frequency, enabled the timer of interest, waited for it to fire, then acked it and started a counter like this: loop: inc hl \ in a,(3) \ and n \ jr z,loop.

I got the following results (final value of the counter):

Timer frequency (same for both, doesn't matter how they are enabled), value on port 4 being 00-02-04-06-10-12-14-16:
291, 679, 1068, 1456, 261, 611, 961

These values aren't invariant. The frequency increases at a significant speed, then it's corrected, so the counter value for the slowest frequency has a 'jitter' of around 6-7, I think. Others should also do some measurements.

Time between the two consecutive firings of timer 2: 48 and 43 (depending on port 4 bit 4, first for 0, second for 1)
Time between first firing of timer 2 and firing of timer 1 (except for the hiccups): 83 and 75

To translate these values to clock cycles, multiply by 38 and add 55 because of the code to initialise HL and port 3 before the loop. (It's not as accurate anyway, so the addition is quite pointless.) The values you'll get will be practically the same as if you divided 6 million by the frequencies given by me in the previous post (where port 4 bit 4 was set), e. g. 120Hz to 600Hz for the base frequency.

Oh yes, acking is indeed with zeroing the corresponding bit, I'm convinced.

However, I'm also sure there is no 'interrupt' and 'normal' mode, the two writes are needed simply because of the dual function of the bits.

The upper 3 bits of port 4 don't seem to affect the timers, neither the frequency, nor their relative position.

Jim e · Post by **Jim e** » Sat 02 Apr, 2005 11:00 pm

d00d, Nice.

So bit bit 4 affects the 83, I don't think I ever tested that for the 83+, I should. What about bit 3, no affect?

I never did hear of these modes till today, no matter.

CoBB · Post by **CoBB** » Sun 03 Apr, 2005 6:40 am

I updated the on-line version. Now the timers are implemented as described in my previous post. The timer counter is never reset except for its normal period, acking is with zero bit, timing is as described, and GPP works perfectly.

Even better, finally the cursor blinks at (almost) the same pace as on the real thing. Also, outputs to port 3 seem to work as intended at last.

Jim e · Post by **Jim e** » Sun 03 Apr, 2005 6:57 am

I bow to thee, CoBB.

And what shall you do on the seventh day.

Post by **tr1p1ea** » Sun 03 Apr, 2005 7:37 am

CoBB is incapable of resting!

I am lost reading half of this stuff, but i know that it is some great work

.

CoBB · Post by **CoBB** » Sun 03 Apr, 2005 8:01 am

This IS resting for me.

Jim e · Post by **Jim e** » Sun 03 Apr, 2005 8:15 am

Darn, I was hoping to get a match with that B4:P4 but I didn't see any change. I'm still testing though to see if there is any more that I missed.

One thing, i tried to get a few people to help with my port help thread in prgming help. You should try it to to see if there is any difference with the older or newer versions of 83. I was surprised that the SE and BE were different. But one thing, I was unsatisfied with the program I wrote, If you do do(hehe...dodo) that you should make an all in one tester. The one I made I slaped together in ten minutes.

Man CoBB, I can't say it enough, great work!

**Hopes there will be an 83+ version**

CoBB · Post by **CoBB** » Sun 03 Apr, 2005 8:56 am

I think I'm finding something interesting again. You know, port 15h seems to return a constant of 254. I suspect that this is actually the data on the bus, because this address isn't connected to any kind of circuitry (I guess). It would be a great help if we had a direct means of reading this data, since it determines how big a jump table we actually need. I wonder what it returns on your calc (83 of course, I don't know if there's an undefined input port on the pluses which doesn't mirror an existing port).

pacHa · Post by **pacHa** » Sun 03 Apr, 2005 9:20 am

You mean we wouldn't need anymore a 257-byte table to point to the interrupt ?
Wow, that could be nice :)

CoBB · Post by **CoBB** » Sun 03 Apr, 2005 9:24 am

Of course that's only possible if this value applies to the conditions when the interrupt is generated. Otherwise we'll need to use a tricky jump table to determine what the low byte was. I proposed this experiment earlier and sigma did it as far as I remember.

The assumption of the low byte of the address being $fe unfortunately doesn't hold.

Jim e · Post by **Jim e** » Sun 03 Apr, 2005 9:57 am

I tested bits 1 - 7 by counting each interrupt for 3 seconds. I also tested every combination of bits and useing different hardware. It took like an hour, and I got nothin. so theres another difference in the interrupt hardware of the 83 and the 83+(the hiccups is the other).

As far as port 15 goes, I have now Idea what it does, I suppose debugging the OS for an occrance of it's use is in order. I'll try later.

Kalimero · Post by **Kalimero** » Sun 03 Apr, 2005 1:23 pm

port 15h isn't used anywhere

Jim e · Post by **Jim e** » Sun 03 Apr, 2005 1:34 pm

Yeah, doesn't look like it. But that doesn't mean it doesn't do something. IT's just ALOT harder to figure out now. though probably not worth it seeing nobody seems to be using it.