6502.org • View topic - ACIA sense check

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Hardware

All times are UTC

ACIA sense check

Page 1 of 4

[ 52 posts ]

Go to page 1, 2, 3, 4 Next

Previous topic | Next topic

Author

Message

banedon

Post subject: ACIA sense check

Posted: Sun May 01, 2016 9:21 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

Although I built ACIA into the 65C02GPD v1, I never got round to actually checking it. I'm now doing so as I want to include it in the 65C02GPD v2 but want to ensure that I've gotten it right. Also, the 65C02GPD v1 makes all ACIA serial-facing pins available where-as the redesign (v2) will have only the bare essentials required for serial comms as I need to save on space.

Would anyone mind doing a sense check on what I've designed? I'm still a little unsure on this despite having read Garth's primer a number of times. Don't worry about the 6502 bus/selects side, though - just need to check the port-side connections of the ACIA. Cheers!

Here's the circuit:

Attachment:

serial.gif [ 15.97 KiB | Viewed 1472 times ]

ALso, this is some test code for sending out '0123456789' continuosly as a test. This bit I'm also not sure about, but it sure as heck doesn't work on 65C02GPD v1. I'm still looking into it, but would appreciate knowing if the code is good.
Please note: This is an output test hence no IRQ code.

Code:

# ACIA output test

# Constants

vectorNMI = $FFFA
vectorIRQ = $FFFE
vectorRES = $FFFC

startcodeNMI = $E000
startcodeIRQ = $E200
startcodeRES = $EA00

maincode = $F000
delay40 = $C000

ACIA = $8200
ACIA_Transfer = ACIA + 0
ACIA_ResetStatus = ACIA + 1
ACIA_Command = ACIA + 2
ACIA_Control = ACIA + 3



# vector setup

PC = vectorNMI
EQUW startcodeNMI
PC = vectorIRQ
EQUW startcodeIRQ
PC = vectorRES
EQUW startcodeRES


# NMI handler
PC = startcodeNMI
RTI

# IRQ handler
PC = startcodeIRQ
RTI

# RES handler
PC = startcodeRES
LDX #$FF
TXS
SEI
CLD
JMP maincode




# main code
PC=maincode

# Reset the ACIA
LDA #0
STA ACIA_ResetStatus
# Control register
# 1 stop bit, 8 bits word length, Baud rate clock, 9600 baud
LDA #%00011110
STA ACIA_Control
# Command register
# Parity check disabled, Parity mode disabled, Receiver normal mode, TIC disabled, IRD disabled, DTR ready 
LDA #%11001111
STA ACIA_Command

# send 0123456789

.sendstuff

LDA #48
.loop
STA ACIA_Transfer
JSR delay40
INC A
CMP #58
BNE loop

LDA #13
STA ACIA_Transfer
JSR delay40

BRA sendstuff






# my really rubbish software-base delay routine. does the job though.
PC = delay40
# save A, X, Y on to stack
PHA
PHX
PHY

# math
# 1 cycle = 1000ms
# 4.1ms = 4.1ms x 1000 = 4,100 cycles
# the following are in the loop
# LDY#2 = 2 cycles
# INY = 2 cycles
# CPY = 2 cycles
# BNE = 2+1 cycles
# NOP x4 = 4x2=8 cycles
# total: 19 cycles per loop

# 4,100 cycles / 19 cycles = 215.78 loops
# Round up to 240 loops

LDY#0
.loopDELAY40
NOP
NOP
NOP
NOP
INY
CPY#240
BNE loopDELAY40

# restore Y, X, A in that order
PLY
PLX
PLA
RTS

Top

GARTHWILSON

Post subject: Re: ACIA sense check

Posted: Sun May 01, 2016 10:23 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California

banedon wrote:

I'm still a little unsure on this despite having read Garth's primer a number of times.

Make sure you've also read the RS-232 primer. There's also some material on setting up and using the ACIA in the 6502 interrupts primer.

Quote:

Here's the circuit:

You have the transmit and receive turned around. Pin 10 is an output, and you have it going to an output of the MAX232; and pin 12 is an input, and you have it connected to another input but no output.

If you're not going to use the DCD\ input, I would just ground it, instead of connecting it to the DTR\ output.

_________________
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?

Top

BigDumbDinosaur

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 7:36 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

GARTHWILSON wrote:

If you're not going to use the DCD\ input, I would just ground it, instead of connecting it to the DTR\ output.

Clarifying and adding to what Garth has noted:

As recommended by Maxim, Vcc on the MAX232 should be bypassed to ground with a 1µF capacitor, with the capacitor placed as physically close to the the MAX232 as possible. In my designs, I parallel this capacitor with a 100µF, low ESR electrolytic to minimize voltage fluctuations that may occur at times.
The four charge pump capacitors (C15, C16, C17 and C18) should be placed as physically close to the MAX232 as possible. Although the average current flow is low, there are short duration, high current transients to/from these capacitors.

I use tantalums as charge pump capacitors, due to their compact size and low leakage. Other (non-electroytic) types are usable as well.
You have your two data paths (RxD and TxD) incorrectly wired up. They should be connected as follows:

Code:
65C51 MAX232 JP9
—————————————————————————————————————————————————————————————————————
TxD (pin 10) ———> T1IN (pin 2) ---> T1OUT (pin 14) ———> TxD (pin 3)
RxD (pin 12) <——— R1OUT (pin 12) <--- R1IN (pin 13) <——— RxD (pin 2)
—————————————————————————————————————————————————————————————————————

The dashed arrows (---> and <---) represent the internal signal paths in the MAX232.
At your TIA-232 jack (JP9), I recommend that you connect DTR (pin 4) to V+ (pin 2) of the MAX232. Assuming the other device is a DTE (e.g., a terminal or a PC's COM port), DTR at your serial adapter should be hooked up to DSR at the DTE. In some cases, the DTE may not respond if its DSR input is not active.
DCD (pin 1 of JP9) is an input that would only be driven by a modem. It should not be connected to anything, since you don't have the means to drive the DCDB input on the 65C51.
You may run into trouble with using a crystal to generate the 65C51's baud rate clock. My preference has always been a can oscillator for this important function. The oscillator manufacturers have already solved the problems of achieving accuracy and stability in their product. No reason to reinvent the wheel. You'll also have a few less parts to take up space and assembly time.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

banedon

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 10:35 am

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

BigDumbDinosaur wrote:

GARTHWILSON wrote:

If you're not going to use the DCD\ input, I would just ground it, instead of connecting it to the DTR\ output.

Clarifying and adding to what Garth has noted:

As recommended by Maxim, Vcc on the MAX232 should be bypassed to ground with a 1µF capacitor, with the capacitor placed as physically close to the the MAX232 as possible. In my designs, I parallel this capacitor with a 100µF, low ESR electrolytic to minimize voltage fluctuations that may occur at times.
The four charge pump capacitors (C15, C16, C17 and C18) should be placed as physically close to the MAX232 as possible. Although the average current flow is low, there are short duration, high current transients to/from these capacitors.

I use tantalums as charge pump capacitors, due to their compact size and low leakage. Other (non-electroytic) types are usable as well.
You have your two data paths (RxD and TxD) incorrectly wired up. They should be connected as follows:

Code:
65C51 MAX232 JP9
—————————————————————————————————————————————————————————————————————
TxD (pin 10) ———> T1IN (pin 2) ---> T1OUT (pin 14) ———> TxD (pin 3)
RxD (pin 12) <——— R1OUT (pin 12) <--- R1IN (pin 13) <——— RxD (pin 2)
—————————————————————————————————————————————————————————————————————

The dashed arrows (---> and <---) represent the internal signal paths in the MAX232.
At your TIA-232 jack (JP9), I recommend that you connect DTR (pin 4) to V+ (pin 2) of the MAX232. Assuming the other device is a DTE (e.g., a terminal or a PC's COM port), DTR at your serial adapter should be hooked up to DSR at the DTE. In some cases, the DTE may not respond if its DSR input is not active.
DCD (pin 1 of JP9) is an input that would only be driven by a modem. It should not be connected to anything, since you don't have the means to drive the DCDB input on the 65C51.
You may run into trouble with using a crystal to generate the 65C51's baud rate clock. My preference has always been a can oscillator for this important function. The oscillator manufacturers have already solved the problems of achieving accuracy and stability in their product. No reason to reinvent the wheel. You'll also have a few less parts to take up space and assembly time.

Thanks for taking a look and the corrections and suggestions, guys.
I've made the modifications - I hope I've understood your advice (see below).
BTW, I know my symbol for the ACIA has XTL1 and XTL0 and that these should be XTLO and XTLI (doh :roll:

) - I'll correct that later.
With regard to the caps; I normally do use tantalum ones, but have specifically mentioned them now one the circuit diagram. I hadn't spotted the need for a 1uF between the power rail pins on the MAX232 though and had assumed 100nF (0.1uF) - good spot on that. Added the suggested 100uF as well.

Attachments:

serial_updated.gif [ 17.85 KiB | Viewed 1445 times ]

Top

BigDumbDinosaur

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 7:54 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

banedon wrote:

With regard to the caps; I normally do use tantalum ones, but have specifically mentioned them now one the circuit diagram. I hadn't spotted the need for a 1uF between the power rail pins on the MAX232 though and had assumed 100nF (0.1uF) - good spot on that. Added the suggested 100uF as well.

Remove the ground from RING (pin 9 of JP9) and you should be good to go. RING is an output from a modem to indicate that the phone line is ringing. RING is rarely used, and you can't use it with the 65C51 no matter what, so it should be a no-connect.

Incidentally, Maxim illustrates the need for C44 (your designation) on page 17 of the MAX series data sheet.

In a future design, you could consider using the MAX238, which is functionally two MAX232s in one package. That would give you additional channels to fully implement DCD, DSR and DTR, if you wanted to do so.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

banedon

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 8:04 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

BigDumbDinosaur wrote:

banedon wrote:

Cheers BDD

. In fact I've got a '238 in 65C02GPD v1 which does now work now that I've revisited the programming section of the '51 datasheet. It doesn't seem to want to do 19200 baud, but 9600 works ok. Probably poor connectivity somewhere - I'm looking into it.
I'm going to be using a '232 in the v2 design as I don't intend to use any other functionality of the '51 apart from serial comms to/from a PC. From what I can see the other connections (DCD, DSR, DTR) are not needed for this... (let me know if I'm wrong).

Now working on the whole interrupt driven RS232 input thing!

Top

floobydust

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 9:34 pm

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385

I use the '238 in my I/O boards for the 65C51 and fully implemented all lines on the 65C51. I typically run at 19.2K baud, have a double rate clock on one board running 38.4K baud and have even tried 115K which works fine on a 4MHz clocked 65C02. If you're unable to run at higher baud rates, you could have a hardware problem or your interface to the host isn't properly handling RTS/CTS. Back in the 1980's I had a Vic-20 running fully interrupt-driven I/O on a 6551 at 19.2K baud in loop-back mode. I wrote a full duplex interrupt-driven BIOS many years ago (1980's) and updated it recently. The source is floating out here.... you may want to take a look at it for ideas, or just use it. I also found an intermittent bug in every 6551 and 65C51 I've used for transmit, where the transmit interrupt gets disabled by itself. I modified the BIOS to handle that too. But alas, if you're using the recent W65C51 with the xmit bug, you'll need a delay routine... which I also provided that can be easily altered for CPU clock rate. Good luck on coding....

_________________
Regards, KM
https://github.com/floobydust

Top

banedon

Post subject: Re: ACIA sense check

Posted: Mon May 02, 2016 10:14 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

Cheers. I'm currently trying to figure out why IRQB is driven low all the time if interrupts are enabled. This is despite the fact that my IRQ routine reads the status register to clear any conditions. Gonna have an end to end read of the datasheet after posting this.

Top

Dr Jefyll

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 12:51 am

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada

Attachment:

serial_updated excerpt.gif [ 2.78 KiB | Viewed 1401 times ]

The schematic is irregular in a couple of respects. The little diagonal mark that appears on pins 8 and 11 is usually seen only on inputs (to denote that their response is edge-triggered). And you've drawn bypass cap C43 as being in series with the supply. Presumably you've wired it correctly, despite what the drawing shows.

banedon wrote:

I'm currently trying to figure out why IRQB is driven low all the time

You do have a pullup resistor attached to this Open-Drain output, right? Just checking; I know too well how sometimes the obvious can get overlooked!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Top

BigDumbDinosaur

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 5:06 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

banedon wrote:

I'm going to be using a '232 in the v2 design as I don't intend to use any other functionality of the '51 apart from serial comms to/from a PC. From what I can see the other connections (DCD, DSR, DTR) are not needed for this... (let me know if I'm wrong).

DCD is only required if you plan to attach a modem to your rig. DTR might be needed, depending on the term program you are running on the PC.

Quote:

Now working on the whole interrupt driven RS232 input thing!

Be sure to carefully peruse Garth's articles on that. It's not hard if you fully understand what has to happen when the UART interrupts. WDC give some guidance in that regard in the 65C51's data sheet, and Garth's articles flesh it out.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

BigDumbDinosaur

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 5:12 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

banedon wrote:

Aside from the possibility of a missing pull-up on IRQB, as noted by Jeff, I think what you might be seeing is TxD interrupting because there is no data to transmit. This would happen at initial boot before your POST routine has anything to write to the serial channel. Your driver will have to disable TxD or the TxD IRQ when there is no data to transmit, which is something that you take care of within the IRQ handler part of your driver. When the foreground part of your driver gets a datum and writes it into TxD, the TxD IRQ will have to be re-enabled.

If you want, I can post the DUART driver I use in POC V1 to illustrate the process. The hardware is different, but the modus operandi is the same.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Last edited by BigDumbDinosaur on Tue May 03, 2016 5:41 pm, edited 3 times in total.

Top

BigDumbDinosaur

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 5:14 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA

Dr Jefyll wrote:

Good catch. I didn't see that. Of course, with my wicky-wacky left eye, I'm not seeing a whole lot right now. :evil:

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

GARTHWILSON

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 7:25 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California

I mostly use the '51 for receiving (sending source code from the PC to the workbench computer to compile, assemble, or execute); but the times I've transmitted with it, I don't remember ever using the transmitter interrupt. To set up for receive interrupt but not transmit interrupt, I put 00001001 in the command register, for:

no parity
no echo
transmitter on and RTS true, but no transmitter interrupt
receiver interrupt enabled from receive-data-register-full bit
enable receiver and its interrupts, with DTR true

Update: I see I did write 00001011 to the command register for one project, to enable the receiver along with the transmitter but not allow receiver interrupts either. I am also thinking of an additional project where I might have used the transmit interrupt, but I can't think of where to look to find my code for it. That was 30 years ago.

Again, to get around the transmit-register-empty flag bug in WDC's '51, rather than wasting time in a timing loop, you can use one of the timers in a 65c22 VIA in one-shot mode to produce the interrupt, and re-set it each time you write a byte to the ACIA. Then the computer can do something useful in the time that it's waiting, instead of twiddling its thumbs and counting twiddles. When the VIA timer times out, it produces and interrupt, signaling that it's safe to write another byte to the ACIA.

_________________
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?

Top

BigEd

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 8:07 am

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England

GARTHWILSON wrote:

...signaling that it's safe to write another byte to the ACIA.

Hmm - "may be safe" perhaps? I'm not sure if you can tell that the byte you wrote so many ticks ago has necessarily left yet - could flow control affect that?

Top

GARTHWILSON

Post subject: Re: ACIA sense check

Posted: Tue May 03, 2016 8:29 am

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California

On the CMOS '51, if CTS was true so you knew you could start the byte, the byte will finish even if CTS goes false midway through the transmission. I suppose the potential problem would be if you checked, and it was true, then you gave it the byte to send, but CTS went false before that instruction completed. I don't know what the best solution for that would be. If you know the receiving end's response speed is not very good, you might need to leave a small amount of time between bytes to give it the chance to say "I'm full now! Please wait before sending the next byte." That extra time could be added into the VIA timer's value. Since you cannot read the CTS state directly, if you're not using DSR for anything else, you could connect DSR to CTS, because you can read DSR in bit 6 of the status register. DSR's state does not affect either the transmitter or receiver. It can cause an interrupt though.

On the NMOS, a byte would stop in the middle if CTS want false at that time. I think that was either a poor design or a bug. The NMOS didn't have the bug with the transmit-register-empty flag though.

_________________
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?

Top

Page 1 of 4

[ 52 posts ]

Go to page 1, 2, 3, 4 Next

Board index » 6502.org Users Forum » Hardware

All times are UTC

Who is online

Users browsing this forum: Google [Bot] and 53 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum