Help with MacBook-->ACIA via FT232R

[schlachet]

I've been spinning my wheels on this for too long and thought I'd ask for help here. I am probably missing something simple. First, I'm a Mac user. I have a MacBook with a USB-TTL adapter based on FT232R. I have it in 5V mode.

Adapter is this: DSD TECGH SH-U09C5 USB to TTL UART Converter
ACIA is a Rockwell 6551 (R6551AP)

USB adapter connections:
GND --> breadboard ground (same ground as ACIA)
TX --> RxD on ACIA
RX --> TxD on ACIA
RTS --> CTSB on ACIA
CTS --> RTSB on ACIA

The ACIA is connected using Garth's decode logic, so it's at $4400 DCDB and DSRB are tied to ground.

This is what I'm a little fuzzy on. I have the IRQB lines from two VIAs plus the R6551 going to a CD74HC21E. My thought here was that this would go low if any of the irq lines went low. The unused input is tied to high, and the line from the R661 is tied high with around 3.2k ohm (3 x 1k, and a 220 ohm, this is what I had on hand).

From my Mac, I'm using pico com. Here is my command line:

Code: Select all

picocom --baud 19200 --flow h --parity n --databits 8 --stopbits 1 /dev/cu.usbserial-AB0KNYFS

So here's what works and what doesn't work.

When I send output from the 6502, I see it on my PC. When I type a letter on my PC (sent to the 6502), I see the 6551's irq line go low, and on my scope I can decode the serial line and see the key pressed. The scope shows the data on RxD, CTSB stays low and IRQB goes low. But IRQB stays low, so I don't think I'm handling the receive interrupt properly. The ACIA repeatedly sends a character back ("D") in a loop. I don't know where it's getting that.

Here is what I have for setup:

Code: Select all

  ; initialize acia
  lda #$00
  sta ACIA_STATUS
  lda #%00001001        ; $09 - No parity, no echo, interrupt enabled
  sta ACIA_COMMAND
  lda #%00011111        ; $1f - 1 stop bit, 8 data bits, 19200 baud
  sta ACIA_CONTROL

  cli                   ; clear interrupt (enable)
  jsr loop

Here's what I have for interrupt handling:

Code: Select all

irq:
  pha
  lda ACIA_DATA
  ; debugging; this sends a char to the LCD.
  ; this sends the same char indefinitely.
  ; lda #$41 ; "A" 
  ; jsr print_char
  bit ACIA_STATUS ; reset interrupt of ACIA
irq_end:
  pla
  rti

I've found a few examples and can't get this working yet. I hope it's something small/silly I'm missing here. Any help is appreciated. I don't care about processing the input yet, I just want to get it out of the ACIA so the IRQ resets. I think I can handle the rest if I can overcome this hurdle.

Here's the scope.
1: CTS
2: TxD
3: RxD
4: IRQB

[BigEd]

Quite a lot is working, so that's good.

I'd wonder if the IRQ handler is getting called. Have you an LED to light or any other IO? Instead of your
jsr print_char
as a debug, I'd suggest just doing a STA ACIA_OUT. It should send back the character it received.

It might be good to share your assembler listing: often, the mistake will be using the wrong addressing mode or the wrong address for something. Seeing the hex will help.

[schlachet]

It does feel like I'm at the 90% mark on this milestone.

Here's a hex dump of the binary (I'm always amused after spending so much time on something only to see a few kilobytes of data)

Code: Select all

00000000  a2 ff 9a 20 71 80 20 4e  80 a9 24 20 cb 80 a9 00  |... q. N..$ ....|
00000010  8d 01 44 a9 09 8d 02 44  a9 1f 8d 03 44 20 24 80  |..D....D....D $.|
00000020  58 20 4b 80 48 a2 00 bd  df 80 f0 0a 8d 00 44 20  |X K.H.........D |
00000030  38 80 e8 4c 27 80 68 60  5a da a0 01 a2 68 ca d0  |8..L'.h`Z....h..|
00000040  fd 88 d0 f8 fa 7a 60 9c  01 44 60 4c 4b 80 48 a2  |.....z`..D`LK.H.|
00000050  00 a9 ff 81 04 a9 e0 a2  00 81 06 a9 38 20 b7 80  |............8 ..|
00000060  a9 0e 20 b7 80 a9 06 20  b7 80 a9 01 20 b7 80 68  |.. .... .... ..h|
00000070  60 48 a9 00 85 00 a9 50  85 01 a9 01 85 02 a9 50  |`H.....P.......P|
00000080  85 03 a9 02 85 04 a9 50  85 05 a9 03 85 06 a9 50  |.......P.......P|
00000090  85 07 68 60 48 da a9 00  81 04 a9 40 a2 00 81 02  |..h`H......@....|
000000a0  a9 c0 81 02 a1 00 29 80  d0 f0 a9 40 a2 00 81 02  |......)....@....|
000000b0  a9 ff 81 04 fa 68 60 20  94 80 a2 00 81 00 a9 00  |.....h` ........|
000000c0  81 02 a9 80 81 02 a9 00  81 02 60 20 94 80 a2 00  |..........` ....|
000000d0  81 00 a9 20 81 02 a9 a0  81 02 a9 20 81 02 60 53  |... ....... ..`S|
000000e0  74 61 72 74 69 6e 67 20  75 70 2e 0d 0a 00 40 48  |tarting up....@H|
000000f0  ad 00 44 8d 00 44 2c 01  44 68 40 00 00 00 00 00  |..D..D,.Dh@.....|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00007ff0  00 00 00 00 00 00 00 00  00 00 ee 80 00 80 ef 80  |................|
00008000

I've attached a txt file containing my code at the moment.

dualvia-serial.txt

(3.21 KiB) Downloaded 97 times

[schlachet]

I did change the handler to immediately do a "sta ACIA_DATA" and it looks like it does do this from the scope, it's just not being decoded correctly? Looks like its slightly delayed.

[BigEd]

That's good - your IRQ is called, you can send back what you saw.

Next mystery perhaps - and I haven't look at your hex yet, but thanks for that - is why the machine starts sending. And it only sends when it has received. And it keeps on sending. That's actually three puzzles.

[schlachet]

That TxD line may be a red herring. I tried my test again, hitting '1' instead of 'Q'. The scope shows I sent '1' but received the same shape of pulses. So I was maybe just seeing things there.

[schlachet]

As a debugging step, I setup port B on the VIA as a debugging output and connected LEDs. I also setup port a pin 0 as an output. In my interrupt handler, I first pulse port a pin 0, and then load ACIA_DATA and output it on port b.

When I power up, and hit '1' on my terminal window, what I'm seeing is the interrupt running repeatedly (constant pulses on port a pin 0), and 'D' on port b repeatedly.

I'm at a loss here. I had another R6551 (labelled R6551P / R6551-27) and it exhibits the same behavior. I've pared my test program down to nearly nothing. Maybe this is a circuit issue? I may tear it down and built it back up again.

Code: Select all

;
VIA1 = $5000

VIA1_PORTB = VIA1
VIA1_PORTA = VIA1+1
VIA1_DDRB  = VIA1+2
VIA1_DDRA  = VIA1+3

ACIA_DATA    = $4400
ACIA_STATUS  = $4401
ACIA_COMMAND = $4402
ACIA_CONTROL = $4403

  .code

reset:
  ldx #$ff
  txs

  ; initial via 1 port a pin 0
  lda #$01
  sta VIA1_DDRA
  stz VIA1_PORTA
  ; initialize via1 port b all pins for output (debug)
  lda #$ff
  sta VIA1_DDRB
  stz VIA1_PORTB
  ; initialize acia
  stz ACIA_STATUS       ; soft reset acia
  lda #$09              ; $09 - No parity, no echo, interrupt enabled
  sta ACIA_COMMAND
  lda #$1f              ; $1f - 1 stop bit, 8 data bits, 19200 baud
  sta ACIA_CONTROL

  cli
loop:
  jmp loop


nmi:
irq:
  ; ; pulse our debug pin to indicate we're in irq
  lda #$01
  sta VIA1_PORTA
  stz VIA1_PORTA

irq_read_acia:
  lda ACIA_DATA
  sta VIA1_PORTB

  bit ACIA_STATUS       ; reset interrupt of ACIA
  rti

  .segment "VECTORS"
  .word nmi
  .word reset
  .word irq

scope:
1: via 1 port a pin 0
2: r6551 txd
3: r6551 rxd
4: irq at 6502

[schlachet]

ok, well perhaps I should have tried this earlier. I just ripped the circuit out, and built it again. and of course, IT WORKS. I thought I was going nuts, trying to get a dead simple program working, when it was the wiring that was at fault. In any case, thanks for taking a look.

[GARTHWILSON]

That would explain why we were drawing a blank. What was the mistake though? Or did you just rip it out and re-do it without finding out what the mistake was?

[schlachet]

I just ripped it out. I was scratching my head about increasingly rudimentary code, off and on for weeks. That should have been my first clue. I had it rebuilt from scratch in about 20 minutes and the test worked right away. Lesson learned!

[BigEd]

It's a good result! (It's more difficult if you've designed and built a PCB, of course...)