Single 6522 for a few applications

[floobydust]

Hmmm, the Vic-20 comes to mind. Commodore used the NMI driven by the second 6522 timer for timing. A fair amount of source code and not a very fast baud rate. I'd skip it and use a real UART. Just my $0.02.

[sburrow]

Dr Jefyll wrote:

That means the CPU will be unable to do anything else during the time it's transmitting a character, or listening to see if there's a character to receive.

By the way, yes, that does sound like a good tradeoff to me. So, "cannot do anything while listening" is interesting. An idea I was thinking is that I could set up some type of an interrupt on the start bit. How would I then NOT trigger an interrupt every 'low' bit I do not yet know, but just thinking here. Still, if I put the computer into a 'listen for some serial data' loop, hit 'enter' on my computer, then it should not have any problems.

Thank you for that reply!

[sburrow]

floobydust wrote:

Commodore used the NMI driven by the second 6522 timer for timing.

Now THAT is an interesting idea. Hm, will be thinking about that, thank you.

I accept your $0.02. I'm not ignoring it, just thinking through all the possibilities and limitations at once. Mostly, I'm learning.

[ I know we are all probably similar in how we think, that's who we are, and why you find folks like us on 6502.org at all. I'm one to think of every single possibility, every single instance. Map it all out in the mind. Have an answer for every question, whether it actually gets asked or not. I am a math professor, I get paid to do this sort of thing. Turn probabilities into possibilities. ]

Thank you!

[Dr Jefyll]

sburrow wrote:

An idea I was thinking is that I could set up some type of an interrupt on the start bit.

That approach is workable if you're not concerned about being able to receive and transmit simultaneously (ie, Full Duplex). Maybe that capability isn't required.

But if Full Duplex is the goal -- and assuming you only have one timer and interrupt line available (not one of each for transmit and one of each for receive) -- I'd suggest having a periodic interrupt that runs continuously whenever either or both task(s) is active. (For the sake of simpler code, it may even be reasonable to let the periodic interrupts continue even when neither the transmit task nor the receive task is active.)

You'll probably want the interrupts to occur at triple ( 3x ) the bit rate, because doing so allows you to start receiving a character at any time (meaning, on any given interrupt). Remember, you don't get to choose when an incoming character will arrive. You could be in the midst of transmitting a character, then suddenly need to also start receiving a character. And of course it's unlikely that the bit-clock of the incoming character will be time-aligned with that of the outgoing character. But having interrupts at a 3x rate means the receive and transmit tasks can be phase shifted by zero, by 1/3, or by 2/3 of a bit-time relative to one another.


So! With the scheme I propose, if there's a character in the process of being transmitted then the Interrupt Service Routine will, on every third interrupt, shift out a bit onto the TxD output. And, if there's a character in the process of being received then the ISR will, on every third interrupt, shift in a bit from the RxD input.

To minimize the performance impact, the ISR needs to do the absolute minimum then exit as soon as possible. (After all, there'll be a foreground task that can manage the big picture.) One way to keep the ISR fast is to have it begin with an indirect jump (or, use self-modifying code) that gets updated according to what's going on. This'll be faster than having the ISR read various activity status bits then do conditional branches.

-- Jeff

Edits: improved explanation, and this PS. Further edit: fix diagram

Here's a diagram to explain the choice of a 3x interrupt rate, as opposed to 2x or 4x or any other number.

3x timing for asynch.png (3.38 KiB) Viewed 7386 times

The vertical red lines indicate interrupts, and sooner or later the incoming character will be detected. This entails a degree of variability, and the upper and lower depictions of the incoming character illustrate the boundaries of that variability.

At "B," the Start Bit is detected. Then at "C" a repetitive pattern begins. There'll be an interrupt that samples RxD, one that does nothing, another that does nothing, then the pattern repeats until all bits have been received. You'll notice that the "sample RxD" interrupts remain well centered within the bit-time (between 33% and 66%), as desired.

[John West]

Another option is to skip the UART altogether and use something like the FT240 or FT245. I haven't used one myself, but it looks like it pretends to be a serial port on the PC side, and gives you a simple parallel interface on the other end.

[BigDumbDinosaur]

floobydust wrote:

Hmmm, the Vic-20 comes to mind. Commodore used the NMI driven by the second 6522 timer for timing. A fair amount of source code and not a very fast baud rate. I'd skip it and use a real UART. Just my $0.02.

The same was done in the C-64 and C-128, using the second 6526 and NMIs. There are a lot of problems with getting bit-banged TIA-232 to run at any significant speed and without errors—the C-64 and C-128 renditions are also hobbled by a hardware bug found in many 6526s.

Given that UARTs are a dime a dozen these days and lots of working code exists to use one, I fail to see any incentive to bit-bang TIA-232. Once again, I must caution about becoming overly complex on a first-ever design. This is exactly the sort of thing I would be avoiding.

[sburrow]

John West wrote:

Another option is to skip the UART altogether and use something like the FT240 or FT245.

Well! That is a good idea! I don't know much about it, but I'll have to research it. Thank you for that option!

[sburrow]

BigDumbDinosaur wrote:

Once again, I must caution about becoming overly complex on a first-ever design. This is exactly the sort of thing I would be avoiding.

Indeed. Thank you BDD.

I bought one of those adapters just now on Amazon for $6. I'm going to test it out on a Raspberry Pi, using delays and whatnot to emulate the oscillator as best as I can. If I'm not happy, "turn around don't drown". Before I even get a PCB I'm going to put the whole thing together on a couple of breadboards. Or at least large sections of it.

Thank you, yes, I will be cautious, and your concern is something I am not brushing off.

[BigEd]

sburrow wrote:

This is an excerpt from Garth's RS-232 Primer page:

"...(There is a forum topic here on bit-banging 57,600bps on a 1MHz 6502.) ... "

http://wilsonminesco.com/RS-232/RS-232primer.html

Just to help a bit, I've linkified it:

Quote:

"...(There is a forum topic here on bit-banging 57,600bps on a 1MHz 6502.) ... "

This feat of ingenuity is a similar effective rate to the UPURS project for Acorn's BBC Micro, where the 6502 runs mostly at 2MHz but slows to 1MHz for I/O access. This project achieves 115,200 bps. There's a megathread in which it was developed.

[Michael]

Dr Jefyll wrote:

sburrow wrote:

... You'll probably want the interrupts to occur at triple ( 3x ) the bit rate, because doing so allows you to start receiving a character at any time (meaning, on any given interrupt)

I used a similar method several years ago for a PIC demo (posted on PICLIST) and it worked quite well. The PIC was running at 2 MIPS which is quite a bit faster than a 2 or 4 MHz 65C02...

Code: Select all

;******************************************************************
;                                                                 *
;   Filename: 12F683 Full-Duplex 9600 Demo.asm                    *
;     Author: Mike McLaren, K8LH                                  *
;       Date: 02-Jun-05  (last revision 04-Dec-05)                *
;                                                                 *
;    Full Duplex Bit-Banged 9600 Baud Serial I/O Demo             *
;                                                                 *
;   ·Uses 12F683 INTOSC running at 8-MHz                          *
;   ·Bit rate error 0.6% plus or minus 1.0% for INTOSC            *
;   ·Bit-banged 9600 baud serial I/O                              *
;     ·Full Duplex (TX and RX simultaneously)                     *
;     ·Interrupts at approximately 3X bit rate every              *
;      34.5 usecs (every 69 instruction cycles)                   *
;     ·Circular 16-byte RX character buffer                       *
;     ·Circular 16-byte TX character buffer                       *
;     ·Inverted TX and RX signals (MAX232A or similar             *
;      inverting RS-232 interface required)                       *
;   ·ISR and support routines Init232, Put232, and Get232         *
;    fit comfortably in the first 189 words of code space         *
;    occupying memory from 0x04 through 0xBC (185 words)          *
;                                                                 *
;      MPLab: 7.21    (tabs=8)                                    *
;      MPAsm: 4.02                                                *
;                                                                 *
;******************************************************************

Code: Select all

;******************************************************************
;                                                                 *
;     Interrupt Service Routine for a Full Duplex Bit-Banged      *
;     9600 Baud Serial I/O with 16 byte circular receive and      *
;     transmit buffers...                                         *
;                                                                 *
;     Interrupts are generated at approximately 3 times the       *
;     bit rate for 9600 baud at 34.5-usec intervals or every      *
;     69 instruction cycles.                                      *
;                                                                 *
;     The transmit and receive processes are executed in the      *
;     correct sequence each interrupt cycle by using a state      *
;     machine variable and jump table for both RX and TX.         *
;                                                                 *
;     After detecting a start bit, the receive bit stream is      *
;     sampled every third interrupt cycle in the approximate      *
;     middle third of each bit (between 33% and 66%).             *
;                                                                 *
;     The 16 byte circular TXBUFF is located at B0..BF in RAM     *
;     and will buffer 15 bytes.  The "unload buffer" process      *
;     is performed in the ISR after sending a character and       *
;     the "load buffer" process is performed outside the ISR      *
;     in the Put232 subroutine.                                   *
;                                                                 *
;     The 16 byte circular RXBUFF is located at A0..AF in RAM     *
;     and will buffer 15 bytes.  The "load buffer" process is     *
;     performed in the ISR after receiving a character and        *
;     the "unload buffer" process is performed outside of the     *
;     ISR in the Get232 subroutine.                               *
;                                                                 *
;     Of the 69 instruction cycles between interrupts the ISR     *
;     uses between 34 and 35 cycles average each interrupt or     *
;     approximately 49.3% to 50.7% of the overall processing      *
;     time available.                                             *
;                                                                 *
;       34.0 cycles avg (49.3% mcu overhead) RX idle              *
;       35.0 cycles avg (50.7% mcu overhead) RX in progress       *
;                                                                 *
;******************************************************************

[sburrow]

Michael, thank you, that clarifies a lot. I was PM'ing Dr. Jefyll about the 3x, and he clarified it as well. The part I was missing was that it's 3x the baud rate, not 3x Phi2 or something. And why 3x in particular? 2x is not enough, and 4x is too much and annoying. At least that's how I'm seeing it. If I'm wrong, let me know.

Thank you!

[sburrow]

floobydust wrote:

Having found the Xmit bug in the recently released W65C51 ACIA, I wouldn't recommend using one. You can likely find some older Rockwell R65C51 parts if you shop around, if you're really set on using one. I'd suggest one of the newer NXP parts, like the SC28L92 or if you prefer a DIP component, look for the older SCC2691. These are fairly easy to get working, plus there's code around that takes full advantage of them already. No need to reinvent the wheel

So... I've been trying to find these SCC2691 dip chips on the internet. And I can't find any reliable place that sells them! I mean, I think I can get it in a PLCC package, maybe.

Do y'all have some super secret warehouse where you get these neat-o IC's? I've used Jameco, and am familiar with Mouser and Digikey. [ Remember, I'm new! ]

Thanks guys.

EDIT:

I just bought a SCC2691 on eBay for $5. We'll see what happens!

[floobydust]

sburrow wrote:

floobydust wrote:

Having found the Xmit bug in the recently released W65C51 ACIA, I wouldn't recommend using one. You can likely find some older Rockwell R65C51 parts if you shop around, if you're really set on using one. I'd suggest one of the newer NXP parts, like the SC28L92 or if you prefer a DIP component, look for the older SCC2691. These are fairly easy to get working, plus there's code around that takes full advantage of them already. No need to reinvent the wheel

So... I've been trying to find these SCC2691 dip chips on the internet. And I can't find any reliable place that sells them! I mean, I think I can get it in a PLCC package, maybe.

Do y'all have some super secret warehouse where you get these neat-o IC's? I've used Jameco, and am familiar with Mouser and Digikey. [ Remember, I'm new! ]

Thanks guys.

EDIT:

I just bought a SCC2691 on eBay for $5. We'll see what happens!

Yup... some other lesser known sources.. some eBay sellers in the US. Also UTsource in Asia. Take a look at my C02BIOS code (Github page) to get it running, complete with a 10ms jiffy-clock timer. Note that these are fine with CPU clock rates to 6Mhz and possibly a bit more depending on the chip. I have that runs fine at 8MHz.

[sburrow]

Attached is a newer schematic. I was talking to BDD and he suggested starting with UART only first, and then work my way up.

I was using his schematic for his DUART alongside the datasheets and other things.

My memory map changed a tiny bit, it's now full 32K RAM, I moved the I/O addresses to overlap the ROM a bit now. The '688 makes it easy to do this though.

No 6522 VIA if you can see. Not that I do not plan on including it. This is just supposed to do ONE thing: terminal with Linux. From here, I will add on.

Thoughts?

Thank you all for your time and help on this!

Chad

[GARTHWILSON]

For debugging, I would be in favor of having at least something that can feed a beeper and/or LED as discussed in the debugging page of the 6502 primer at http://wilsonminesco.com/6502primer/debug.html . Otherwise, if you have trouble getting the UART communicating, how can you debug it? If there's the possibility of turning UART outputs on and off, that might serve the purpose, but they may have to be on for communication, like RTS\ and DTR\ outputs. On my workbench computer, I have three 65c51 ACIAs (UARTs), and since two of them are seldom used, I do actually use their RTS\ and DTR\ outputs to feed four LEDs on the front for status for applications that don't use those ACIAs. Then in Forth, I can put, somewhere in the program where I want to monitor progress, things like

Code: Select all

    TURN ON #4 LED

or

Code: Select all

    TURN OFF #1 LED

VIA1PB7 feeds a beeper, so I can have simple beep routines that tell of the progress in different frequencies and durations.