WDC 65C51 Woes

[GARTHWILSON]

Quote:

so i have made an assumption that reading from the 65c51 will be pulled from the RDR, while a write will be put into the TDR.

That is correct. The data sheet's register-select table shows that you cannot read the transmit data register or write to the receive data register. Bit 3 of the status register is indeed the valid way to know if a byte has come in though; and when you read the receive data register, bit 3 of the status register is cleared.

What does your routine to set up the '51 look like? When you figure out the problem, it'll probably be a forehead slapper. We all have those episodes where we fight for a week with something that turned out to be caused by a really silly error. (I have never had any problem with the '51 itself though.)

In your first post where you say it "get's [sic] it stuck in a never ending loop waiting for data, as the receive bit is never set," I'm left wondering if the false-start detection (possibly from the baud rate not being agreed on) or anything else is keeping it from responding to a byte.

[8BIT]

Remove the loop back and run the test again. The read data should not match.

Daryl

[chrisabird]

GARTHWILSON wrote:

What does your routine to set up the '51 look like?

Here is the full code for the test program.

Code: Select all

 .segment "OS"
 
 ACIADATA = $5000
 ACIACONTROL = $5003
 ACIACOMMAND = $5002
 ACIASTATUS = $5001
 VIACONTROLA = $6002
 VIACONTROLB = $6003
 VIADATAA = $6000
 VIADATAB = $6001
 
 NMI_VEC
 IRQ_VEC
 START
   LDX #$FF
   TXS
   LDA #$00
   STA ACIASTATUS
   LDA #$1F              
   STA ACIACONTROL
   LDA #$0B              
   STA ACIACOMMAND
   LDA #$FF
   STA VIACONTROLA
   STA VIACONTROLB
   LDA #$AA
   STA VIADATAA
   STA VIADATAB
 
 LOOP
   LDA #$2A              
   STA ACIADATA
   JSR WAIT_6551
   LDA ACIASTATUS
   STA VIADATAB
 ; AND #$08
 ; BEQ LOOP
   LDA ACIADATA
   STA VIADATAA
   JMP LOOP
 
 WAIT_6551
   PHY      ;Save Y Reg
   PHX      ;Save X Reg
 
 DELAY_LOOP
   LDY   #2    ;Get delay value (clock rate in MHz 2 clock cycles)
 
 MINIDLY
   LDX   #$68      ;Seed X reg
 
 DELAY_1
   DEX         ;Decrement low index
   BNE   DELAY_1   ;Loop back until done
   DEY         ;Decrease by one
   BNE   MINIDLY   ;Loop until done
   PLX         ;Restore X Reg
   PLY         ;Restore Y Reg
 
 DELAY_DONE
   RTS         ;Delay done, return
 
 .segment "VECTORS"
 .word   NMI_VEC
 .word   START
 .word   IRQ_VEC

GARTHWILSON wrote:

We all have those episodes where we fight for a week with something that turned out to be caused by a really silly error.

I couldn't agree more, i can only thank you all for persevering with me!

GARTHWILSON wrote:

I'm left wondering if the false-start detection (possibly from the baud rate not being agreed on) or anything else is keeping it from responding to a byte.

I'm struggling a little on how to check for fasle-start or baud rate issues. Inspecting the block diagram i can see RxC is fed into the dividers for both Tx and Rx. So in the loop back test they should be at least be sync'd. Scoping the Tx and RxC at the same time shows signals that appear to line up, but RxC is fast as it's yet to go through the divider. But RxC at 308Khz / 16 ~= 1/19200 baud which is what i have set. Am i mis-understanding the point you're making?

8BIT wrote:

Remove the loop back and run the test again. The read data should not match.

Strange behavior continues, disconnecting the loop back (and checking for any wiring mishap with the scope) is still showing my test value on the VIA output. This could seemingly invalidate the above discussion, as a read and transmit register should not be shared.

[GARTHWILSON]

I haven't looked at the code in detail yet, but one thing that pops out at me is that you have the VIA port addresses backwards. It should be:

Code: Select all

VIACONTROLA = $6003
VIACONTROLB = $6002
VIADATAA    = $6001
VIADATAB    = $6000

It will be the same thing later when you work with the timers. This is nice especially with the '816 so you can store 16 bits in a single instruction and the low byte of data goes to the low address, and the high byte at the high address, in normal low-byte-first 65xx order.

I would encourage using different names above, as "control" could be confused with the ACR (auxiliary control register), PCR (peripheral control register), or IER (interrupt-enable register). The other "data" register is the shift register's data. I use VIAPB and VIAPA for "Port A" and "Port B," VIADDRB and VIADDRA for data-direction register B and A, and then there's register $0F which is like PA but intentionally leaving out any enabled handshaking, thus something like VIAPANOHS (although I've never used that one myself).

Edit: I don't see any other problems with the program.

[chrisabird]

As predicted the problem was so simple, I must hang my head in shame. OE on the SRAM was left floating, which created very subtle data bus contention, making it look like things were working but actually were not.

In happier news there seems to be a wealth of the R65C51 floating about on eBay at the moment, so the dreaded WDC65C51 has been evicted.

Thank you all for all the advice!