RS232 and CRU bits

[+9640News]

Was going through some RS232 code and I do not understand something. If someone can explain it to me, much apprecaiated.

 

The code is:

 

LI R12,>1360

TB 0

 

 

I know this is testing for interrupts, but I am lost why >1360 is being used rather than something like >1300 or >1340.

 

Beery

 

[+Lee Stewart]

Was going through some RS232 code and I do not understand something. If someone can explain it to me, much apprecaiated.

 

The code is:

 

LI R12,>1360

TB 0

 

I know this is testing for interrupts, but I am lost why >1360 is being used rather than something like >1300 or >1340.

 

Beery

 

Not sure why you would test >1300 or >1340 if you want to know if there was a receive interrupt. You are probably aware of Thierry’s page related to this.

 

...lee

[+InsaneMultitasker]

Perhaps what is confusing is that the programmer chose a less common convention for CRU addressing and bit testing, which relies upon R12 being set to the specific base+offset. However, loading R12 with the CRU base + offset is not the same as loading R12 with the base address and then testing the bit offset. Subtle and easy to get into trouble. From your code example, these two routines perform the same test:

 

LI R12,>1360

TB 0

 

Is equivalent to

 

LI R12,>1340

TB >10

 

Note the bit tested in TB (and SBO/SBZ) is half the value of the offset added to the base >1340 in the previous statements.

Edited March 14, 2018 by InsaneMultitasker

[+9640News]

Perhaps what is confusing is that the programmer chose a less common convention for CRU addressing and bit testing, which relies upon R12 being set to the specific base+offset. However, loading R12 with the CRU base + offset is not the same as loading R12 with the base address and then testing the bit offset. Subtle and easy to get into trouble. From your code example, these two routines perform the same test:

 

LI R12,>1360

TB 0

 

Is equivalent to

 

LI R12,>1340

TB >10

 

Note the bit tested in TB (and SBO/SBZ) is half the value of the offset added to the base >1340 in the previous statements.

 

 

I had read Thierry's page and was trying to relate it to the 9902 Datasheet as I could not make the jump. Tim's notes helps clear that up. I did not realize you took half the offset as I spent considerable time trying to figure out where this imaginary bit 32 was coming from when the range was from 0 to 31.

 

Thanks. That helps quite a bit with my understanding.

 

Tim, still trying to get your interrupt code to work. I'm going to have to move some files back to MAME and do some debugging as I can not for the life of me figure out why I am not capturing/displaying anything from the WiModem232. I do a power cycle, so I know it should be receiving characters. I just do not know if the issue is in the capture of the characters in the interrupt routine or post issue with the display.

Beery

[apersson850]

The offset is counted in CRU bits. Since the TMS 9900 can only physically address 32768 words, but is logically byte addressable, it uses only hardware adresses for all even bytes. The odd bytes are handled internally. As a consequence, it can't create addresses to CRU bits in any other way than by two. Since the least significant bit doesn't exist electrically, incrementing the CRU hardware bit address requires the logical address to be incremented by two.

 

That's why LI R12,>1300 TB 1 and LI R12,>1302 TB 0 are the same thing.

 

This leaves 15 bits to the address. Since the three most significant address bits on the TMS 9900 are used to decode external instructions, we get twelve bits left. That's why the TMS 9900 can't handle more than 4096 CRU bits.

Edited March 14, 2018 by apersson850

[+mizapf]

Correct. You can easily see this by the pin definition of the TMS9900. I suppose only Chuck Norris finds the A15 on the TMS9900.