AUTOBAUD DETECTION FOR 9902

[+TheBF]

I found this code in an old book from TI circa 1981.

 

I thought the gang here might find it interesting. Apologies. I have not assembled it and the tabs are all wrong but it's a neat idea.

It appears to work by measuring the time between mark and space in the signal and then looking up the rate interval for that measurement in the table.

Smart people at TI in 1981.

 

Minor edits per Stuart's comments

* autobaud for 9902
* Software Development, Texas Instruments 1981

           LI      R12,BASE
           SBO     31
           LI      R1,6200
           LDCR    R1,8
           SBZ     13
           CLR     R3

* wait for start bit
SBAUD      TB      15
           JEQ     SBAUD

* wait until rin goes back to space condition
SBAUD1     INC     R3
           TB      15
           JNE     SBAUD1

* FIND THE BAUD RATE
           LI      R4,BAUDTB-2
SBAUD2     INCT    R4
           C       R3 *R4+
           JH      SBAUD2

* baud rate found - set recieve and transmit data interval
* read a char and throw it away

           LDCR *R4,12
SBAUD3     TB   21
           JNE SBAUD3
           SBZ 18

BAUDTB     DATA >0007,>001A     * 19200
           DATA >000E,>0034     *  9600
           DATA >001D,>0068     *  4800
           DATA >003B,>00D0     *  2400
           DATA >0075,>01A0     *  1200
           DATA >00EA,>0340     *   600
           DATA >0246,>04D0     *   300
           DATA >7FFF,>0638     *   110

Edited December 15, 2018 by TheBF

[+TheBF]

I just discovered that you don't have to turn on the RS232 CARD to access the 9902 chips!

 

The CRU address can be set to >1340 and you can read and write the 9902 bits and send and receive data just fine.

 

Does anyone know of a downside if you are not using the DSR code?

[+InsaneMultitasker]

The nanoPEB devices require you to turn on the card, causing incompatibility with any programs that used the "feature" you describe.

 

The creator did not want to fix this difference which, in my opinion, is a mistake and has created a few headaches.

 

No downside so long as you roll your own code.

[Stuart]

 

I found this code in an old book from TI circa 1981.

 

I thought the gang here might find it interesting. Apologies. I have not assembled it and the tabs are all wrong but it's a neat idea.

It appears to work by measuring the time between mark and space in the signal and then looking up the rate interval for that measurement in the table.

Smart people at TI in 1981.

 

 

Tiny little typo in the listing:

 

LI R4,BAUDTB=2 should be LI R4,BAUDTB-2 (minus 2, not equals 2)

 

Note that the values in the Baud rate table are for no-wait state memory. The values in the first column will need recalculating if the code is run from memory with wait states. The Baud rates, from the top to the bottom of the table, are 19200, 9600, 4800, 2400, 1200, 600, 300, 110 Baud.

[+TheBF]

Thanks Stuart,

 

Any thoughts on the multiple that we should use for those times in column 1?

I suppose I could just load the code and hit it with a known BPS rate and look at R3.

 

I need to write this up in RPN assembler and try it.

[Stuart]

Values best established by experimentation I think. Probably best to make sure interrupts are off as well, just in case.

[apersson850]

This was a common feature back then. I remember first learning about it in school, 1982 or something. Not with the same UART, but using a similar principle. It was common to send the character 'A', due to its bit pattern.

[Swim]

I seem to recall baud rate parsing is done in the console ROMs? Parsing wait state and clock speed? Correct? I think user atrax27407, Hummingbird EPROMs, has ROMs with wait state and clock speed options available.

[atrax27407]

Here are the baud rate calculations:

Scan.pdf

[+FarmerPotato]

Recently I read the TI Software Development Handbook for the first time.  RKN's scan of the TI RX "Real-time Executive" was a big deal as well. 

 

So Dave Pitts (sim990) has some MPP disks, Microprocessor Pascal, which targets the TM990/101.  On disk 7 is some source to RX, because it is the base of MPX, the Microprocessor Pascal Executive. 

 

In the source, I noticed an (older?) version of the auto baud code posted earlier.  

 

debug.src

 

* REVISION: 03/28/80          ORIGINAL: 01/20/80
* ABSTRACT:
**************************************************************************
*                                                                  
*     STAND-ALONE DEBUGGER PACKAGE FOR Rx.                         
*                                                                  
**************************************************************************

 

 

INIT02 BYTE >62          CHARACTER USED TO INITIALLIZE 9902

 

Lines 110-168

 

****************************************************************
*      SET THE BAUD RATE OF A PORT.                            *                
*           THIS ROUTINE SETS THE BAUD RATE OF ONE OF THE      *                
*      9902'S OF THE 990/101M BOARD.  THE PROPER BAUD RATE     *
*      IS CALCULATED BY WAITING FOR AN 'A' OR 'CR' INPUT       *
*      AND THEN LOOKING UP THE PROPER REGISTER VALUE.          *
*                                                              *
*      CALLING SEQUENCE:      BL   @SETBD1 (OR SETBD2)         *
*                                                              *
*      PARAMETERS:    NONE                                     *
*                                                              *
*      REGISTER USAGE:                                         *
*           R3 - SCRATCH.  POINTS TO THE BAUD RATE FLAG FOR    *
*                        9902 IN USE.                          *
*           R7 - SCRATCH.  POINTER TO BAUD RATE TABLE.         *
*           R8 - SCRATCH.  USED AS TIME COUNTER.               *
*           R11 - RETURN VECTOR.                               *
*           R12 - SET TO CRU BASE FOR THE 9902 USED.           *
*                                                              *
*      SUBROUTINES USED:      NONE                             *
*                                                              *
****************************************************************
*
SETBD1 LI   R12,>80      SET THE BAUD RATE FOR THE FIRST PORT
       LI   R3,CTTY      LOAD ADDRESS OF THE BAUD RATE FLAG
       JMP  SETRT        JUMP TO THE SET RATE
SETBD2 LI   R12,>180     SET THE BAUD RATE ON THE SECOND PORT
       LI   R3,CTTY+2    LOAD ADDRESS OF BAUD RATE FLAG
*
SETRT  SBO  31           RESET THE 9902
       LDCR @INIT02,8    INITIALLIZE THE 9902
       SBZ  13           SKIP THE INTERNAL TIMER
       CLR  R8           RESET LOOP COUNT
TSTSP  TB   15           SPACE?
       JEQ  TSTSP        NO, TEST AGAIN
SPLOOP INC  R8           TIME START BIT
       TB   15           FALL OUT ON MARK
       JNE  SPLOOP       CONTINUE IF NOT
*
*      TABLE LOOK-UP FOR BAUD RATE
*
       LI   R7,TABLE     SET POINTER TO TABLE
BDLOOP C    R8,*R7+      SEE IF MATCH
       JLE  MATCH        YES, SET BAUD RATE
       INCT R7           NO, UPDATE POINTER
       JMP  BDLOOP       LOOK AGAIN
MATCH  LDCR *R7,12       SET THE BAUD RATE
       MOV  *R7,*R3
       RT
TABLE  DATA 7,>1A        BAUD = 19200
       DATA 14,>34       BAUD = 9600
       DATA 29,>68       BAUD = 4800
       DATA 59,>D0       BAUD = 2400
       DATA 117          BAUD = 1200
BD1200 DATA >1A0
       DATA 117          BAUD = 1200
BD1200 DATA >1A0
       DATA 234,>340     BAUD = 600
       DATA 582,>4D0     BAUD = 300
       DATA 32767,>638   BAUD = 110
       PAGE

 

These baud rate tables would be for the TMS9900 using static RAMs on a TM990/100 single-board computer.  Lo, they are the same as above. 

 

Tragically, the Pascal mpp7.fpy is part 2 of the RX source code. Part 1 is lost. (I found that half the REFS have no DEFS)  mpp6.fpy does have the object code. 

 

[+TheBF]

Cool.

 

I looked at this and the first thing I saw was a misleading comment IMHO.

 

SETBD1 LI   R12,>80      SET THE BAUD RATE FOR THE FIRST PORT

This sets the CRU address of the 1st port. 

[apersson850]

No, the comments are correct. They describe the purpose of the instruction, or rather the whole block of instructions following. This is not a tutorial of how to write instructions for the TMS 9900, it's about how to get something done. The target audience is assumed (and rightly so) to know that you load the CRU base address to R12, so they will see that the purpose of this code is to set the baudrate for port one (and right below port two) and can see that different CRU addresses are loaded for that. The audience is also supposed to be knowledgeable enough to understand the meaning of this.

 

So, on the contrary, it's a comment very much on the mark. Unlike some you see, like this one:
INC R1 * Increment R1 by 1

Completely unnecessary for anyone except when learning the instructions themselves. This is a better comment:
INC R1 * Count the entered characters

The only objection I have to the comment is that I would probably have formatted it like this:

* Set the baud rate for the first port

SETBD1 LI    R12,>80

to more clearly indicate that this comment is a headline for a code segment, not a comment about a single instruction.

 

There is an error in the code, though, and that's that label BD1200 is defined twice and the data for 1200 bits/s is given twice.

Edited July 27, 2023 by apersson850

[+TheBF]

1 hour ago, apersson850 said:

No, the comments are correct. They describe the purpose of the instruction, or rather the whole block of instructions following. This is not a tutorial of how to write instructions for the TMS 9900, it's about how to get something done. The target audience is assumed (and rightly so) to know that you load the CRU base address to R12, so they will see that the purpose of this code is to set the baudrate for port one (and right below port two) and can see that different CRU addresses are loaded for that. The audience is also supposed to be knowledgeable enough to understand the meaning of this.

 

So, on the contrary, it's a comment very much on the mark. Unlike some you see, like this one:
INC R1 * Increment R1 by 1

Completely unnecessary for anyone except when learning the instructions themselves. This is a better comment:
INC R1 * Count the entered characters

The only objection I have to the comment is that I would probably have formatted it like this:

* Set the baud rate for the first port

SETBD1 LI    R12,>80

to more clearly indicate that this comment is a headline for a code segment, not a comment about a single instruction.

 

There is an error in the code, though, and that's that label BD1200 is defined twice and the data for 1200 bits/s is given twice.

I am of the same opinion.  A comment to the right of an instruction should pertain to the instruction. 

Comments for a block of code should be on the line preceding the code. 

 

Good catch on the duplicate label and data.  Better minds than mine...

[+FarmerPotato]

Uh, duplicate lines were my copy-pasting screenful at a time.