Ok, my Rockwell ACIA was a dud. Got it off ebay, and I get bus contention on the D7 data bus line. unhook the ACIA from that line, computer works. I noticed that that pin is floating all over the place at power up. I think it got zapped.

So, until I get suitable replacements, its back to the WDC parts I have.

Ok,I have a running program that just counts from 0 to 255 and starts over, and displays the result in binary on some LED's using the VIA. Works just fine.

I thought a good first test of the ACIA would be to just transmit the same byte to it that I am sending to the VIA.

I'm getting nothing out of the TXD line (watching for activity with scope)

Scope confirms that address decoding is correct (CS0 HIGH, CS1 LOW, R/W LOW at the same time as 00 on the RS lines).

PH2 and Baud rate clock both present and clean.

DSR DCD and CTS are tied low
RxD DTR RTS and XTL0 N.C.
1.8432 oscillator can on XTL1

I have no activity on the TxD line at all. I feel there is enough delay in my code to make the WDC65c51 bug not an issue.

here is my code. Comments MAY be wrong. I've been trying things so long I'm not sure I've been faithfull at updating them.

How are the register-select (RS) lines connected? I see addresses $5001 and $5011, which is easy to do, but it seems unlikely that that's what you wanted. If you have A0 going to RS0 and A1 going to RS1 and the base address is $5000, the control register will be at $5003, not $5011. The "11" for register selects in the data sheet is in binary, not hex. The same kind of thing applies to the command register, at address $5002, not $5010.

Also, make sure the chip selects are not qualified by Φ2. They have to be valid and stable before Φ2 rises, or the thing won't work.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

A few other notes, all minor:

• You already have $FF in X (for the TXS), so if you want to store that value elsewhere, just do an STX, rather than LDA #$FF, STA.
  
  
• LDA #0, STA can be replaced with the single instruction STZ (STore Zero). (I think you have a CMOS 6502, ie, 65C02, right?)
  
  
• There's no need to do a CLC before the INC. It's not the same as ADC #1. INC, DEC, INY, DEY, INX, and DEX do not use the C flag as an input or affect it as an output. (Also, they are always hex, not decimal, regardless of the D flag, which doesn't change anything this time but there will be future uses where you'll want to keep it in mind.)
  
  
• If you wanted to do it without variables, you could use Y in place of address $200, and have the delay routine do a PHY...PLY so it can count with Y without losing it.
  
  
• Again with the CMOS 6502, you can shorten the JMP counter with BRA (Branch Relative Always) counter and save a byte.
  
  
• The DELAY routine is not finished. (Ok, maybe that one's not so minor.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I'm not on the lab right now, but I'm pretty sure you nailed it with the addressing. The binary/hex mashup is obvious now!

On the other stuff, the delay works (I got it from you!) that's a cut and paste error.

My use of memory as my counter is because this program was originally a way to test SRAM.

My use of CLC is a remnant from trying to get some stuff to work right earlier. I later solved said problem in hardware. I was curious if the incrementing instructions used it though, and you cleared that up.

I do have a CMOS part. I only just got around to discovering the added instructions. All my books except the one you recommended seem to predate that part.

Also, your optimization tips will be handy. I've been "sticking to what I know" because all this is still just to test the hardware, but I'm gonna need to know these things eventually!

Thanks!

The addressing screwup was it. I'm getting data out now.

RS232 decoder on scope shows its the correct output.

Now just need the new batch of Rockwell parts to get here.

Sounds good. It's good to hear it's working now.


The JSR/RTS tests the RAM too, since the return address is saved on the stack in page 1. PHY...PLY will also use the stack.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Makes sense.

How much delay does one need to get around the WDC65c51's bug? do you just figure your baud rate times how many bits (10 in my current case) as the absolute minimum time between transmissions, and add some arbitrary extra time just to be safe? I'm still working my way through the forum thread on the matter, and my Rockwell parts won't be here for a week.

I think the only time you might need to add is to have at least one full additional Φ2 cycle. The very first byte doesn't need any delay before you send the 2nd byte, because the transmit register is transferred to the shift register, and the 2nd byte can be loaded into the transmit register right away to wait there and be ready for when the first byte is done being shifted out. After the 2nd one of course you'll need to do the delay because there's nowhere else for the '51 to store data that's waiting in line. From the data sheet, it looks like if you're running at 1MHz and doing 9600,8,N,1, you would need 1043 cycles from one store to the next store to the ACIA's data register. Adding a few more to make you feel good would have a negligible effect on the amount of time needed to transfer a file or message. Again, if you don't want the computer to have to twiddle its thumbs in a delay loop while waiting, you can set up a timer interrupt on a VIA.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yeah, I had just discovered the timer interrupt trick a few minutes ago reading the relevant forum thread. seems like the way to go.

Just so I'm understanding how that works, do you basically have the timer send an interrupt at intervals the same length as the delay we talked about, and have the program look for that instead of the stuck bit? I.E., is it still a delay, but just one that runs in the background?

It would probably be best to set it up in one-shot mode, so it generates one interrupt per write to the counter high byte. When the counter rolls over, it generates the interrupt and keeps counting, but the counter interrupt will be disabled after that until you write to the counter high byte again, which you'll do immediately after storing the new byte in the ACIA's data register, so the delay always ends at the right time.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?