The F-1 (aka "I Was Too Excited to Draft the UART Circuit")

[Individual_Solid]

Hello folks! Given the unprecedented "heat bubble" upon the Pacific Northwest United States, I have a little bit extra time to write up my project.

The other evening, after being truly amazed at watching FreeRouting do in minutes what I failed at for hours, I was so excited I just rushed to export Gerbers and throw some money at JLCPCB. For Rev B, I do suspect I'll do a mixture of manual and automatic. Thankfully, they rejected my order for not containing a board outline. I still wanted to get things progressing, so the very next evening I finished up the board and got it submitted and its nearing the completion of fabrication. The process of designing and ordering a PCB is brand new to me (including schematic capture) but as someone who made some money on the side as a professional draftsman many years ago, I felt sure I could figure it out. With the little extra time I had to work on the board, I did decide to toss on another 65c22 VIA with a very simple header pinout.

The board itself is not very different from Garth's 6502 Primer design. Anything not strictly from his all encompassing schematic is pretty much cribbed from somewhere else in the Primer (i.e. the reset circuit, address decoding the second VIA). The main exercise here was learning schematic capture so I can get a little more funky on Rev B. There's also a "control port" with Sync/RWB/VP (oh...shoot...I forgot VPB and MLB didn't I... add it to the list!) to allow easier logic probing/possibly experiment with wait states and things of that nature.

png sch

pdfs also attached with higher res

I'm posting for three or so reasons:

1) pride, and a sense of accomplishment

2) if anyone spots a reason this board might be DOA - something wrong in the schematic, the layout, or something I can't even think of - I'd be ever appreciative of your keen eyes!

3) there's one decision for this little computer I haven't made, which is how I might talk to it from a modern-day-computer. and, as the title of this post may betray, though I threw that second VIA onto the board, I sure didn't take the time to put a UART on. I have a SY6551 as well as two WDC65c51s in my parts bin, but that won't help me with my busses not broken off the board. now, I don't need serial communication - I'd be plenty excited to build a demo where the VIAs talk to an LCD as well as some digital potentiometers that control the RGB backlight. But in my parts bin I do have:

• a veritable pile of Raspberry Pi Picos, and assorted ESP, STM, AVRs (and tons of logic level shifters)
• another pile of ESP8266/"ESP-01" wifi modules (which admittedly do speak serial...)
• so many assorted USB-UART cables and breakouts, including at least one Adafruit FT232H breakout which includes a shift register mode and an 8-bit so called databus mode
• yet another pile of assorted bluetooth and wifi chips that speak SPI, including at least one "Airlift" which is an ESP32 with a preflashed firmware to speak SPI.

It seems like, even with one VIA dedicated to an LCD screen and a few buttons, the second VIA should be able to bit bang SPI or ... something else ? to talk to something in my parts bin.

I'm currently leaning toward bitbanging SPI (though I need to look closely at speeds) as that would probably turn out useful anyway, or doing a naive/dumb/slow/bespoke 8-bit serial-ish I-don't-even-know-what-you'd-call-it with the VIA Port 1 handshaking and a Pi Pico.

The FT232H certainly provides the most flexibility but also requires a lot more custom software on the "high side". The closer to a gritty terminal experience I can screen into from a Raspberry Pi (full size), the better.

Any thoughts on my line of thinking?

Your collective wisdom is much appreciated.

[drogon]

Here is an idea based on my own system:

The VIA can talk to an AVR using the VIAs 8-bit handshake mode. So you get an 8-bit bus that will run as fast as you like with handshaking. All you then need is some sort of protocol to enable bi-directional communications.

I'd suggest driving it from the 6502 side, so the AVR just sits, waiting...

You send one of 3 simple command bytes:

(1) I have a byte for you to output
Then you send the byte

(2) Do you have anything for me?
Then you switch to input mode and read a byte which is 'yes' or 'no'

(3) Send me the data
Then you switch to input mode and read the data byte, or... it stalls waiting for that data byte.

The AVR then sends/gets data via it's serial port in the usual way. You need 10 bits on the AVR side which is easy, but on an ATmega 328 (ie. 'Arduino' tricky to get a whole port, so you need to do some bit shuffling. No matter as you'll still saturate a 115200bps serial line to your terminal, even though you need to send 2 bytes from the 6502 just to print one.

And the terminal - in my case it's my desktop Linux box which runs either a dumb terminal (minicom/putty) or a smart terminal which interprets Acorn MOS/BBC Micro VDU commands to draw now just text, but graphics, colour, etc.

My Ruby system doesn't work like this, but it could, if required, and I took it one step further in that the code in the AVR detects the terminal type and if not the RubyTerm, assumes ANSI and translates the Acorn MOS VDU commands on the fly...

The AVR could be a Pi running Linux too - although you'll need level shifters. That Pi can then do the smart graphics directly.

This:

https://youtu.be/rPGCT0lah4Q

is a C program running on my 6502 outputting Acorn MOS VDU commands to the 'smart' terminal which interprets them and although it's not the 8-bit parallel interface between the 6502 and AVR it's a very similar style interface.

This:

https://youtu.be/Bg-DcjrJ8g0

is my Ruby system talking to a real terminal (a Wyse-60) and the AVR is doing the code translation, so screen editors, etc. can "just work".

Looks good so-far - and starting with the LCD is good! It'll be nice to see your progress on it.

-Gordon

[BigEd]

A very good idea to ask for a review of your work before shipping to production!

[GARTHWILSON]

Welcome.

Quote:

It seems like, even with one VIA dedicated to an LCD screen and a few buttons, the second VIA should be able to bit bang SPI or ... something else ? to talk to something in my parts bin.

Note that you can put a whole lot more than that on a single VIA. From section 10 of the 6502 primer:

• You might be surprised how much I/O and other features you can do with few parts if you plan it all right. One of the 6522 VIAs on my workbench computer is used for: (this list is repeated in the "I/O ICs" section, with the connection diagram)
  
  • LCD
  • 5-key keypad
  • beeper
  • printer port
  • T1 interrupts for software real-time clock, calendar, and alarms with 1/100th-second (10ms) resolution
  • I²C port
  • triggering the A/D convertor (which puts the data on another VIA)
  • "Abort" button (like Reset but less drastic)
  • and a synchronous serial port for things like my analog oscilloscope raster-graphics display
  That's all through a single 6522, simultaneously, and the only conflicts are that you can't press more than one key at a time while the LCD or printer are getting fed data or you'll mess it up, and you can't press a key during I²C operations.

[BigDumbDinosaur]

Individual_Solid wrote:

...Your collective wisdom is much appreciated.

Are you aware that the W65C22S has a totem-pole IRQ output?

Also, you have one of your 65C22s connected to NMI. I wouldn't do that, mainly because NMI is edge-sensitive and it's all-too-easy to get into deadlock if your NMI handler isn't correctly written. Better to have both 65C22s driving IRQ through an AND gate with triple inputs—the third input can be used by that UART that should have been in the circuit.

A good use of NMI is to attach another DS1813 to it, along with a push button. If a program gets stuck in a loop you can break it with a push of the button—the DS1813 will debounce the push button for you. Your firmware can then decide how to handle it. I have this feature in my POC units and have used it many times during software debugging.

Lastly, I know Garth's schematic in his 6502 primer shows it, but using Ø2 to qualify chip selects is not the best way to do it. At a minimum, what should be qualified by Ø2 is the RAM's /WE. The idea is for the RAM to be selected as soon as the MPU places a valid address on the bus. Almost all hardware using separate /OE and /WE control inputs will perform better in 6502 circuits if the chip select occurs before the rise of the clock.

In your design, it's not a biggy at 1 MHz. However, if you ever decide you want to take the clock into double digits (the WDC 65C02's FMAX vs. VCC curve extrapolates to ~24 MHz on 5 volts) you will need to minimize chip select delays as much as possible.

Things get a little more interesting with the 65C816, which we can discuss if you decided to build a system with that MPU.

[GARTHWILSON]

BigDumbDinosaur wrote:

you have one of your 65C22s connected to NMI. I wouldn't do that, mainly because NMI is edge-sensitive and it's all-too-easy to get into deadlock if your NMI handler isn't correctly written. Better to have both 65C22s driving IRQ through an AND gate with triple inputs—the third input can be used by that UART that should have been in the circuit.

I do have my VIA1 (not any of the other I/O ICs) on NMI\; but the only interrupt I normally have it do is the 10ms T1 timer interrupt, for the realtime clock, so there's no polling necessary. I have the hardware there for the ABORT button, but have never actually used it. But yes, generally if you have multiple interrupt sources on NMI\, you'll have to be super careful because of what BDD says. If all doesn't go perfectly, your NMI interrupts will effectively stop.

I have all five of my other I/O ICs on IRQ\. I don't know why I didn't think of it when I built my main workbench computer, but now I would add jumper options for the interrupt connections for all or most I/O ICs (although in so many years of using this computer I can't say it has ever been a problem).

Quote:

Lastly, I know Garth's schematic in his 6502 primer shows it, but using Ø2 to qualify chip selects is not the best way to do it. At a minimum, what should be qualified by Ø2 is the RAM's /WE. The idea is for the RAM to be selected as soon as the MPU places a valid address on the bus. Almost all hardware using separate /OE and /WE control inputs will perform better in 6502 circuits if the chip select occurs before the rise of the clock.

In your design, it's not a biggy at 1 MHz. However, if you ever decide you want to take the clock into double digits (the WDC 65C02's FMAX vs. VCC curve extrapolates to ~24 MHz on 5 volts) you will need to minimize chip select delays as much as possible.

If you have slow RAM, you'll need to do what BDD says. Fortunately, the slowest SRAM speeds you'll probably find available today are almost four times as fast as what there was in the 6502's early days (120ns versus 450ns). I don't mind qualifying the chip selects with Φ2 up to at least 10MHz since SRAM is commonly available and inexpensive down to 10ns access time, and you can even faster if you look hard. For the W65C02, tDSR and tMDS are a couple of the key spec.s to look at, along with the timing spec.s of your SRAM. At 1MHz though, you can get away with murder. [Edit: I must clarify that that refers to timings. If you have fast parts, you still have to keep your nose clean regarding build technique, as poor build technique can bite you even at very low clock rates.] If you ever want to try for 25+ MHz, then yes, you'll need to select the RAM sooner and use a Φ2-qualified RD\ and WR\ (and really fast logic). Since forum member "windfall" has a 65816 running at 24MHz @ 3.3V, three times the speed the data sheet says you can get at that voltage, it makes me wonder what it could do at 5V!

[Individual_Solid]

BigDumbDinosaur wrote:

Are you aware that the W65C22S has a totem-pole IRQ output?

Aha! I just went to my (very warm) office and this is just a mistake on the schematic. I have in my parts box W65C22Ns, NOT the S. I'm still getting used to grabbing and labelling the exactly correct IC in KiCAD.

BigDumbDinosaur wrote:

Also, you have one of your 65C22s connected to NMI. I wouldn't do that, mainly because NMI is edge-sensitive and it's all-too-easy to get into deadlock if your NMI handler isn't correctly written. Better to have both 65C22s driving IRQ through an AND gate with triple inputs—the third input can be used by that UART that should have been in the circuit.

GARTHWILSON wrote:

I do have my VIA1 (not any of the other I/O ICs) on NMI\; but the only interrupt I normally have it do is the 10ms T1 timer interrupt, for the realtime clock, so there's no polling necessary. I have the hardware there for the ABORT button, but have never actually used it. But yes, generally if you have multiple interrupt sources on NMI\, you'll have to be super careful because of what BDD says. If all doesn't go perfectly, your NMI interrupts will effectively stop.

I did intend to connect NMI to a tight "realtime" timer (and not use that VIA for [m]any other interrupts). I actually have a handful of MAX1232 power supervisors that include a watchdog timer that I was considering integrating but haven't thought it through yet. Obviously this offers less control than a direct panic routine, but may be fun>

BigDumbDinosaur wrote:

A good use of NMI is to attach another DS1813 to it, along with a push button. If a program gets stuck in a loop you can break it with a push of the button—the DS1813 will debounce the push button for you. Your firmware can then decide how to handle it. I have this feature in my POC units and have used it many times during software debugging.

Interesting idea. Is there any potential race between the Power-On-Reset signal and NMI? e.g. is it likely that my computer would "boot up" direct into the NMI routine? I suppose that could be useful...

BigDumbDinosaur wrote:

Lastly, I know Garth's schematic in his 6502 primer shows it, but using Ø2 to qualify chip selects is not the best way to do it. At a minimum, what should be qualified by Ø2 is the RAM's /WE. The idea is for the RAM to be selected as soon as the MPU places a valid address on the bus. Almost all hardware using separate /OE and /WE control inputs will perform better in 6502 circuits if the chip select occurs before the rise of the clock.

GARTHWILSON wrote:

If you have slow RAM, you'll need to do what BDD says. Fortunately, the slowest SRAM speeds you'll probably find available today are almost four times as fast as what there was in the 6502's early days (120ns versus 450ns). I don't mind qualifying the chip selects with Φ2 up to at least 10MHz since SRAM is commonly available and inexpensive down to 10ns access time, and you can even faster if you look hard. For the W65C02, tDSR and tMDS are a couple of the key spec.s to look at, along with the timing spec.s of your SRAM. At 1MHz though, you can get away with murder. If you ever want to try for 25+ MHz, then yes, you'll need to select the RAM sooner and use a Φ2-qualified RD\ and WR\ (and really fast logic). Since forum member "windfall" has a 65816 running at 24MHz @ 3.3V, three times the speed the data sheet says you can get at that voltage, it makes me wonder what it could do at 5V!

I appreciate the idea of qualifying /WE instead of /CS. The concept makes sense. I will have to think that through more carefully. My RAM chips have a 35ns access time, and I was able to successfully run this circuit on a breadboard at 8MHz. The fastest can oscillator I have in my kit today is 12MHz but speed is not (yet) a goal for what I'm trying to build.

drogon wrote:

The VIA can talk to an AVR using the VIAs 8-bit handshake mode. So you get an 8-bit bus that will run as fast as you like with handshaking. All you then need is some sort of protocol to enable bi-directional communications.

Yep, something like this is exactly what I'm thinking today. Though the 6502side programming is a little more complicated than just-a-UART, and there's still AVR-side programming, I really like how it still ends up with a plain tty session on the modern-side.

[BigDumbDinosaur]

Individual_Solid wrote:

BigDumbDinosaur wrote:

A good use of NMI is to attach another DS1813 to it, along with a push button. If a program gets stuck in a loop you can break it with a push of the button—the DS1813 will debounce the push button for you. Your firmware can then decide how to handle it. I have this feature in my POC units and have used it many times during software debugging.

...Is there any potential race between the Power-On-Reset signal and NMI?...

It's not a problem.

Let's say /NMI is still low after the MPU comes out of reset, possible due to slight differences in the two DS1813s. Since /NMI is an edge-sensitive input and would be low when the MPU started executing instructions, the latter wouldn't "notice" /NMI—the high-to-low transition would have occurred before the MPU got going. Once /NMI goes high then your "panic button" will be enabled. I have my own POC units in which this behavior has been confirmed.

In my POC units, the NMI code is as follows:

Code: Select all

;inmi: NON-MASKABLE INTERRUPT SERVICE ROUTINE
;
inmi     longr                 ;16-bit registers
         phb                   ;save state
         phd
         pha
         phx
         phy
;
;———————————————————————————————
;NMI REGISTER STACK FRAME
;
nmi_yrx  =1                    ;.Y
nmi_xrx  =nmi_yrx+s_word       ;.X
nmi_arx  =nmi_xrx+s_word       ;.C
nmi_dpx  =nmi_arx+s_word       ;DP (direct page)
nmi_dbx  =nmi_dpx+s_mpudpx     ;DB (data bank)
nmi_srx  =nmi_dbx+s_mpudbx     ;SR (status register)
nmi_pcx  =nmi_srx+s_mpusrx     ;PC (program counter)
nmi_pbx  =nmi_pcx+s_mpupcx     ;PB (program bank)
;———————————————————————————————
;
         jmp (ivnmi)           ;take NMI indirect vector
;
inmia    longa                 ;16-bit accummulator
         lda !#kerneldp
         tcd                   ;set kernel direct page
         shortr                ;8-bit registers
         lda #kerneldb
         pha
         plb                   ;set kernal data bank
         lda nmi_pbx,s         ;anywhere in bank $00?
         bne .0000010          ;no
;
         longa                 ;yes
         lda nmi_pcx,s         ;interrupted address
         cmp !#mm_rom          ;anywhere in ROM?
         bcs crti              ;yes, ignore NMI
;
.0000010 jmp monbrk            ;goto M/L monitor

The above is for the 65C816, so some minor changes would have to be made to accommodate the 65C02.

[Michael]

Individual_Solid wrote:

BigDumbDinosaur wrote:

Lastly, I know Garth's schematic in his 6502 primer shows it, but using Ø2 to qualify chip selects is not the best way to do it. At a minimum, what should be qualified by Ø2 is the RAM's /WE. The idea is for the RAM to be selected as soon as the MPU places a valid address on the bus. Almost all hardware using separate /OE and /WE control inputs will perform better in 6502 circuits if the chip select occurs before the rise of the clock.

I appreciate the idea of qualifying /WE instead of /CS. The concept makes sense.

FYI: There's another 'simple single chip decoder' method (not in "the Primer") that favors RAM rather than ROM in the address space and also provides PHI2 qualified read and write signals.

Stay safe. Cheerful regards, Mike, K8LH

[GARTHWILSON]

Michael wrote:

FYI: There's another 'simple single chip decoder' method (not in "the Primer") that favors RAM rather than ROM in the address space and also provides PHI2 qualified read and write signals.

Not the same one; but the second diagram in the 6502 primer's address-decoding page does give the same memory map. It doesn't qualify as a single-chip decoder, but unused sections of the two ICs used can be used for the reset circuit and other things. The '139 is cool in that it does the address decoding in a single chip, and gives the RD\ and WR\ signals. The 74HC139 is pretty slow (38ns max); but if it's a problem, it can be remedied by using the 74AC version. I would shy away from the HD68B50 though, as it lacks an onboard baud-rate generator and oscillator, and tops out at 2MHz. It also lacks some of the functions needed for a modem, but who uses modems anymore. Sometimes I think it'd be fun, but I don't have any need for one myself. It would sure be simpler than implementing the internet protocol.

[Individual_Solid]

The board(s) arrived today! I haven't had time to socket the chips and test it out, but I did at least throw on all the sockets and passives this evening.

A few things I've already noticed:

• Looking at it in real life, I could definitely place the decoupling caps better (and use a more appropriate footprint for ceramic multilayer caps)
• J4 - the header to nowhere. I accidentally selected 2.00mm pitch instead of 2.54mm. whoops. I don't have a part that will fit these holes. That's probably okay, as it should rotate 90d anyway. And probably be a female header.
• I only had a 40-pin ZIF socket in the wide size. I trimmed off some legs, but I need to source the right one.
• Not sure what I was thinking with the screw terminals for power in. When I do revision B and run my 5V and GND lines manually, I will be sure to switch to a DC barrel.

Honestly, not much to report til I actually try the board out, but I am just amazed how fast the turn around was!

[BigDumbDinosaur]

Individual_Solid wrote:

The board(s) arrived today...A few things I've already noticed:

• Looking at it in real life, I could definitely place the decoupling caps better (and use a more appropriate footprint for ceramic multilayer caps)

Yep! Long leads tend to reduce the effectiveness of the caps. BTW, not all MLCCs are created equal when it comes to bypassing. These are what I use.

Quote:

• I only had a 40-pin ZIF socket in the wide size. I trimmed off some legs, but I need to source the right one.

What goes into that socket? If it's a 28-pin ROM there's a more compact ZIF socket available. It's only slightly larger than the footprint of a standard socket.

Quote:

• Not sure what I was thinking with the screw terminals for power in. When I do revision B and run my 5V and GND lines manually, I will be sure to switch to a DC barrel.

That particular style of terminal block is not very reliable due to the manner in which it grips the wire. I used to use them in the automatic block signal modules that my company was building for large-scale model railroads. In the field, it was discovered that they wouldn't maintain a tight connection and it was necessary to periodically go around and tight connections. I ended up using a different type made by Tyco, which uses a "guillotine" to make contact with the wire, instead of the pincer of the unit you have.

What I use on my POC units for input power is a Berg connector as used in 3-1/2 inch floppy disk drives. That allows me to power the computer from a standard PC power supply. Or, I could easily adapt a wall wart, although those are not always a good choice—some have pretty horrible regulation.

[Dr Jefyll]

I agree about barrel plugs being unsatisfactory. The Berg connector is certainly an improvement. But here's a little spring-loaded terminal block which I recently used for the first time, and it features the guillotine style clamp BDD mentioned. It's a Phoenix Contact product, 1713017, and it mounts on a .1" grid. Costs less than half a buck.

I do tend to use wall warts (although it's true there are some iffy ones). Wall warts tend to have a variety of different plugs on the end, so I just chop 'em off... which renders them all the same!

For polarity "protection," I just include a suitably beefy Schottky diode on the board, wired in parallel with the supply so the wall wart sees a short if I accidentally reverse the connections.

-- Jeff

[GARTHWILSON]

DC-10 jacks and plugs (called "barrel plugs" above) can indeed be quite satisfactory; but you have to get ones that have plenty of spring tension so you don't lose contact as the plug gets moved. The Kobiconn 163-179PH-EX is one of them. We've used the Switchcraft one it apparently copied from. The problem for hobbyists is that they don't fit into a .100" grid on perfboard.

[Michael]

GARTHWILSON wrote:

Michael wrote:

FYI: There's another 'simple single chip decoder' method (not in "the Primer") that favors RAM rather than ROM in the address space and also provides PHI2 qualified read and write signals.

Not the same one; but the second diagram in the 6502 primer's address-decoding page does give the same memory map. It doesn't qualify as a single-chip decoder, but unused sections of the two ICs used can be used for the reset circuit and other things.

I think you can duplicate that memory map (16K ROM, 16K I/O, and 32K RAM) with your 74HC132 IC by replacing the 32K RAM chip with a 64K or 128K RAM chip and taking advantage of the extra active high chip enable line on the 64K RAM chip to qualify the RAM chip select with PHI2. The left-over 74HC132 NAND gate to be used for the reset circuit.

A 64K or 128K RAM might also be used with the 74HC139 single-chip decoder for a number of different memory maps.

Cheerful regards, Mike, K8LH