6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 4:29 am

All times are UTC




Post new topic Reply to topic  [ 52 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
 Post subject: ACIA sense check
PostPosted: Sun May 01, 2016 9:21 pm 
Offline
User avatar

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
serial.gif [ 15.97 KiB | Viewed 1476 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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Sun May 01, 2016 10:23 pm 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 7:36 am 
Offline
User avatar

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. :D 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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 10:35 am 
Offline
User avatar

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. :D 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
serial_updated.gif [ 17.85 KiB | Viewed 1449 times ]
Top
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 7:54 pm 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 8:04 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
BigDumbDinosaur wrote:
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.

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 9:34 pm 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Mon May 02, 2016 10:14 pm 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 12:51 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Attachment:
serial_updated excerpt.gif
serial_updated excerpt.gif [ 2.78 KiB | Viewed 1405 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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 5:06 am 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 5:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
banedon wrote:
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.

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 5:14 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
Dr Jefyll wrote:
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.

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 7:25 am 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 8:07 am 
Offline
User avatar

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
 Profile  
Reply with quote  
 Post subject: Re: ACIA sense check
PostPosted: Tue May 03, 2016 8:29 am 
Offline
User avatar

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
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 52 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 51 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

Search for:
Jump to:  
cron