RS232 value of first character is doubled

[toby405]

I have this program that opens the RS-232C device and waits for characters. I have a terminal set for 1200 baud connected to COM4 and I have the same settings in the VICE Userport RS232 section.

The program displays the hex value of any character typed on the terminal keyboard.

On program restart, the value of the first character received from the terminal is 2x what it should be. Every subsequent character has the correct value.

Example:

Start program.
Type "A" on the terminal. Program displays "82".
Type "A" on the terminal. Program displays "41".
Type "A" on the terminal. Program displays "41".

Anyone know why this is happening? It's driving me crazy.

Code: Select all

            processor 6502
            org $1001               ; Unexpanded VIC

            ; BASIC stub (unexpanded vic)   
            dc.w $100b              ; Pointer to next BASIC line
            dc.w 1981               ; BASIC Line#
            dc.b $9e                ; BASIC SYS token
            dc.b $34,$31,$30,$39    ; 4109 (ML start)
            dc.b 0                  ; End of BASIC line
            dc.w 0                  ; End of BASIC program

            lda #$93                ; clear screen
            jsr $ffd2

            lda #<TEXT
            ldy #>TEXT
            jsr $cb1e               ; print string

            lda #1
            ldx #<RS232FN
            ldy #>RS232FN
            jsr $ffbd               ; SETNAM
            lda #2                  ; logical file number
            ldx #2                  ; device address (RS-232C device)
            ldy #$ff                ; no secondary address needed
            jsr $ffba               ; SETLFS
            jsr $ffc0               ; OPEN

MAIN        ldx #2                  ; logical file number
            jsr $ffc6               ; CHKIN
            jsr $ffe4               ; GETIN, Z=1 if no char
            cmp #$0                 ; subtract 0 from A (why?)
            beq MAIN                ; branch on Z=1
            pha
            jsr PRTHEX
            lda #$0d                ; carriage return
            jsr $ffd2
            pla
            cmp #$1b                ; exit on esc pressed
            bne MAIN
            ldx #2                  ; logical file number
            jsr $ffc3               ; CLOSE
            rts

PRTHEX      SUBROUTINE              ; print hex of char in A
            pha
            jsr $ffcc               ; CLRCHN
            pla
            pha
            lsr
            lsr
            lsr
            lsr
            jsr .1
            pla
.1          and #$0f
            cmp #$0a
            bcc .2
            adc #$06
.2          adc #$30
            jsr $ffd2
            rts

TEXT        BYTE "RS232 TEST",$0d
            BYTE "SEND CHAR FROM TERM",$0d
            BYTE $00

RS232FN     dc.b 8

[furroy]

probably off by a bit? make sure both sides are using same parity & stop bits settings i imagine

[toby405]

Very interesting comments about RS232 in this post:

https://sleepingelephant.com/ipw-web/bu ... 06#p119706

RINONE ($A9), the flag used to record when a start bit is received is not initialized when an input channel is set up. As a result a framing error occurs when the first byte is received.

If this caused the bits of the first byte to be shifted one to the left (like what an ASL would do for example) it would result in the byte value being multiplied by two.

Seems like a stretch that this explains my problem though because it would have showed up immediately with any kind of testing.

[srowe]

If this caused the bits of the first byte to be shifted one to the left (like what an ASL would do for example) it would result in the byte value being multiplied by two.

Check the contents of RSSTAT ($0297) after receiving the first character, I bet you have $02 indicating a framing error. You should also be able to fix this by setting RINONE to a non-zero value before opening the channel for input.

Seems like a stretch that this explains my problem though because it would have showed up immediately with any kind of testing.

Given the number of bugs I would assert there was very little testing of this code, probably just focused on testing output (e.g. printers). Because the RINONE location is shared with the cassette routines I also believe you won't see the issue if you first load a program from tape.

[toby405]

Framing error is confirmed.

To fix, I just stored $01 to NINONE ($A9) right after the call to OPEN ($FFC0) and all is well!