MaxCoderz

Posted: **Fri 10 Jul, 2009 12:12 pm**

Hi, all.

I've written a small program to test the randomness of the interrupt vector in IM 2. I was inspired by Sigma's interrupt tutorial (archived version if you have problems accessing the original) which, unfortunately, seems to get it wrong. But it is an interesting idea, and I'd like to explore it on hardware.

The program works by writing alternate values to the interrupt table. This restricts us to exploring one bit of the vector at a time, but that is sufficient for this purpose. Say you want to find out what the value of bit 2 (AND mask $04) is. The first 8 bytes of the table will look like this:

Code: Select all

$8a $8a $8a $8a $8b $8b $8b $8b

The remainder of the table is just duplicates of this.

If bit 2 is zero, the interrupt vector will be either $8a8a or $8a8b. The code at $8a8a looks like this:

Code: Select all

8A8Ah       18h             ; JR
8A8Bh       18h             ; JR
8A8Ch       17h

...

8AA4        $C3 XX XX       ; JP XX XX

If the interrupt vector is $8a8a, it gets "JR $18". If it is $8a8b, it gets "JR $17". Either way, it ends up at $8AA4 - which contains a jump to the actual interrupt handler. The same method is applied to $8B8B.

The two handlers just increment a register to count how many times they are called. This process is repeated for all 8 bits - with each interrupt being called 1024 times. In the meantime, junk instructions are executed.

Here is a PTI screen:

For each bit, it reports the number of times it was set and reset when the interrupt occurred. Here's the interesting bit - on actual hardware (84+) I get the following:

Code: Select all

        # RES   # SET
Bit 0:    0       1024
Bit 1:    0       1024
Bit 2:    0       1024
Bit 3:    0       1024
Bit 4:    0       1024
Bit 5:    0       1024
Bit 6:    0       1024
Bit 7:    0       1024

It's more a curiosity than anything - I would still stick with a 257 byte table for safety - but I would like to see what other people get.

You can download the 83+ binary and/or the TASM source.

Thanks!

Posted: **Fri 10 Jul, 2009 5:47 pm**

Cheers for doing the hard work, it will be interesting to see the results!

Here they are for a regular black TI-83+ (serial 2176142867 S-0701A), running the test three times:

Code: Select all

        # RES   # SET
Bit 0:    129     895
Bit 1:    0       1024
Bit 2:    129     895
Bit 3:    131     893
Bit 4:    131     893
Bit 5:    1       1023
Bit 6:    1       1023
Bit 7:    138     886

Code: Select all

        # RES   # SET
Bit 0:    125     899
Bit 1:    0       1024
Bit 2:    135     889
Bit 3:    129     895
Bit 4:    139     885
Bit 5:    1       1023
Bit 6:    1       1023
Bit 7:    88      936

Code: Select all

        # RES   # SET
Bit 0:    130     894
Bit 1:    0       1024
Bit 2:    128     896
Bit 3:    122     902
Bit 4:    127     897
Bit 5:    1       1023
Bit 6:    1       1023
Bit 7:    141     883

Those 1:1023 results are certainly... interesting. I ran the test three more times, and the bit 1, 5 and 6 results were the same as the above.

Posted: **Fri 10 Jul, 2009 9:42 pm**

interesting

should we blame sigma for his resarch?

Posted: **Sat 11 Jul, 2009 1:37 am**

I can't find my USB cable anymore, otherwise I would test it as well. But that would be on a TI-84+ and you already tested that, so I wouldn't have added that much anyway. Unless it differs per model of course.

Posted: **Sat 11 Jul, 2009 12:16 pm**

benryves wrote:Those 1:1023 results are certainly... interesting. I ran the test three more times, and the bit 1, 5 and 6 results were the same as the above.

That is quite weird - especially bits 5 and 6. I wonder if it's some kind of subtlety - perhaps the first interrupt after the EI causes 5 and 6 to reset for the first interrupt? I still have my black 83+ around somewhere. I'll have to dig it out and give it a try.

Thanks for testing it!

darkstone knight wrote:interesting

should we blame sigma for his resarch?

Hehe... But I wouldn't be too hard on him. His docs are probably the best introductory guide there is - it's just a shame about the few very bad errors in there.

King Harold wrote:I can't find my USB cable anymore, otherwise I would test it as well. But that would be on a TI-84+ and you already tested that, so I wouldn't have added that much anyway. Unless it differs per model of course.

It's shame about the cable. It would be interesting to see if my calc is just weird in always setting all the bits.

Posted: **Sat 11 Jul, 2009 11:59 pm**

on a ti-84, i get the same results as you (0/1024)

i suppose it differs per chip, so the 84 / 83SE always jump to I*256+255, or the interrupts are triggered by the R register? you should check that, i'm too lazy

(theory: ti's designers got lazy and neglected to fully copy 83's PCB

)

Posted: **Tue 14 Jul, 2009 8:00 am**

I managed to find my old TI-83+. I tried the program out and got similar results to Ben:

Code: Select all

          # RES     # SET
Bit 0:      239     785
Bit 1:      0       1024
Bit 2:      342     682
Bit 3:      9       1015
Bit 4:      0       1024
Bit 5:      1       1023
Bit 6:      1       1023
Bit 7:      1       1023


          # RES     # SET
Bit 0:      129     895
Bit 1:      0       1024
Bit 2:      127     897
Bit 3:      133     891
Bit 4:      130     894
Bit 5:      1       1023
Bit 6:      1       1023
Bit 7:      131     893

          # RES     # SET
Bit 0:      131     893
Bit 1:      0       0124
Bit 2:      131     893
Bit 3:      132     892
Bit 4:      130     894
Bit 5:      1       1023
Bit 6:      1       1023
Bit 7:      131     893

There's something decidedly non-random about those results. The 130/131/132 results seem pretty weird.

Posted: **Tue 14 Jul, 2009 2:09 pm**

maybe there's a patern in your code??

Posted: **Tue 14 Jul, 2009 3:33 pm**

I suspect it's some value left on the bus that gets messed around with a bit or something like that..

Posted: **Thu 16 Jul, 2009 10:37 am**

Just curious.

Turning this to useful would be awesome.

I don't say any theory because I am not hardware specialist...

But there is some documentation around this...

Posted: **Sun 19 Jul, 2009 5:30 am**

That would be interesting if there was a pattern, but I think it has to do with what's on the databus.

Posted: **Sun 19 Jul, 2009 5:43 pm**

It is, by definition, dependent on what is on the data bus.

MaxCoderz

[TI ASM] IM 2 randomness.

[TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.

Re: [TI ASM] IM 2 randomness.