Hi all! I've been lurking for a while, but I think it's time to get involved.

This is my first step in to the homebrew computing world, and having devoured Garth Wilson's legendary site pretty much in its entirety and appreciated a fair few of Jeff Laughton's articles as well, I've arrived at the following fairly modest goals for my first build:

- WDC 65C02 (well d'uh, I'd be in the wrong place otherwise!) @ 2MHz
- 8k ROM
- 48k SRAM
- Rockwell 65C52 DUART, driving pin headers which allow me to plug in FTDI dev board clones (https://www.sparkfun.com/products/retired/8772)

And that's about it. Not even any GPIO.

I've attached a PDF of my proposed schematic, and I'd really appreciate it if any of the helpful folk who frequent here could cast an eye over it and comment on whether it makes sense.
I've got it more or less running on some breadboards (with several deviations from what I propose here - address decode, reset and clock are all different!), but I haven't exactly pushed it (it writes "Hello World" in response to each character sent to the serial port), but a PCB of this size will be a somewhat larger investment than I've made to this point. While I know that mistakes are almost inevitable, I'd like to do everything I can to get it right!

Once I've demonstrated to myself that I can get this rather simple system up, I have a whole host of aims for future revisions. I've been playing with an FPGA which could be used to implement a graphic card, for example (even with some modest success!). And I might also move on to implementing something with a more challenging processor (probably the m68k of my childhood best friend, the A500+).

Then there are the crazy ideas. I recently came in to possession of a 90s vintage PSTN gateway, for example, and harvested from it no less than 9 (count em!) 80186 processors. Anyone fancy exploring bus arbitration logic in a multi-processor system with me somewhere down the line?

As this is my first post, it also seems like a good moment to thank the people here for the level of insight I've already gleaned from their personal sites and the archives, even without ever asking a question. This place has been a fantastic primer in digital logic and related subjects since I made it a hobby a few months ago, and the willingness of people here to help those new to the subject without judgement or condensation is really quite inspiring!

Mike

A little backstory on the excessive looking protoboards...

The address decoding was done with a three deep combination of 74HC00 and 32 (nand and or), which I propose to replace with a 74138 and a single 7400. I don't think it will improve the prop delay (in fact, it's probably marginally worse), but it feel cleaner. I thought I'd eliminated some chips, but actually, since I scaled back my ambitions to a single IO chip, this appears no longer to be the case.

The top left board houses a reset conditioning circuit, which is over-engineered to produce a short pulse, but I've removed that because my 65C02 won't overheat. And clean pulse is fine, regardless of length.

It also has the clock generation circuit with a toggle switch to select between the crystal and a single cycle button, using some tri-state buffers to gate the final clock signal. However, I've discovered that I can't use the switch while the machine is running without adding some flip-flops in to the mix to prevent the machine crashing when the crystal output is cut mid-cycle and the minimum cycle time is violated. So I've pared that back for my first iteration as well.

I'll print out the schematic (in monochrome; it's best to not use color in schematics around here ) and as soon as I have some time I'll look at it.

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

Thank you.

Predictably enough, I've noticed my first error already. Both nand gates featured should, in fact, be nor. How embarrassing!

You seem to have something very odd going on with your RAM and ROM qualifying signals. I think the ROM will work as you expect it to, though using PHI1 is not generally a good idea as all the timing signals are specified against PHI2 and the delay between PHI1 and 2 is no longer guarenteed. On the RAM however, I am certain you will get spurious writes to bogus addresses during PHI2 low. (CS_RAM and R/W will go low early in PHI2 low, when PHI1 is high - the result being /CE1 and /WE active whilst /OE is inactive which is precisely the command for "write"). You need to gate the /WE signal with PHI2 so it is only active when PHI2 is high, at minimum. It'd probably be good to do the same with /RE too, on both your chips for consistency. You can easily create the necessary /WE and /RE signals from R/W and PHI2 using a single 2-to-4 multiplexer or three NAND gates. You could also simply feed PHI2 into the E3 input of the '138, meaning that no memory device can be selected during PHI2 low, though that's not best practice due to the delays that incurs on the address decoding time - probably not an issue at 2MHz but it would be if you wanted to speed up in future.

You've mispelt the /DTR1 label on the serial chip pin 27, as /DRT1.

RDY doesn't have a pull-up on it. You need to have a pull-up resistor (recommended 3.3k or 4.7k) or it'll float. Ditto with NMI. You might also need pull-ups on the Serial Chip's IRQ lines, though I'm not familiar with this particular serial chip so they may be totem poles in which case its fine.

I'm puzzled why you've decided to break out DTR on your serial headers instead of RTS? Its not wrong, just unusual. Normally serial interfaces use RTS/CTS and DSR/DTR as pairs - having both of one pair or neither rather than mixing and matching. Particularly as many UARTs can handle hardware flow control on RTS/CTS but have no such provision on DTR/DSR - though I'm not familiar with the R65C52 chip's capabilities in that area.

also, I think your memory map is going to be (correct me if wrong):

You need to have at absolute minimum 6 bytes of ROM at the very top of your address space (FFFA to FFFF) for the reset and interrupt vectors, which your current map doesn't allow. It also seems a bit odd to split the RAM up like that - it'd make your life easier when programming it to keep the RAM area contiguous if you can.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I looked over your schematic and have the following comments.

1. As Alarm Siren indirectly noted, MPU inputs cannot be allowed to float. Inputs that are not positively driven by another device should be pulled up to Vcc, preferably through 3.3K resistors.
   
   Do not directly connect RDY to Vcc. If RDY is directly connected to Vcc and a WAI instruction is accidentally or intentionally executed, the 65C02 will attempt to pull RDY low, which would effectively result in the MPU trying to short out your power source.
   
   
2. Per WDC's recommendations, the PHI1OUT and PHI2OUT outputs should not be used and should be left unconnected. All system timing should be derived directly from the Ø2 clock generator circuit. As Alarm Siren pointed out, WDC does not test PHI1OUT and PHI2OUT, and does not specify how much those signals lag the Ø2 clock generator.
   
   
3. In the future, I recommend you use a "can" oscillator to generate your Ø2 clock. A half-can oscillator takes up little space on the board (much less space than a crystal and the components that go with it), costs little more than a "bare" crystal, has better fan-out, and will generally be more stable. The can oscillator's manufacturer has done the work for you in achieving stability and reliable operation over the operating temperature range. A home-grown oscillator circuit may not always perform as expected.
   
   In my designs, I pass the oscillator's output through a flip-flop to strengthen the waveform and make it perfectly symmetric. The WDC 65C02 is somewhat fussy about clock quality and at higher speeds, asymmetry can result in timing violations. If you do that, you will be using an oscillator whose frequency is twice that of the desired Ø2 frequency. The following illustration is a typical circuit.
   
   
   Attachment:
   File comment: Clock Generator Circuit
   
   clock_gen_2phase.GIF [ 16.88 KiB | Viewed 2184 times ]
   
   
   At the relatively low speed at which your circuit will operate you can ignore the use of the flop and directly connect the oscillator's output to the MPU, as well as to other hardware that needs the clock.
   
   Similarly, I recommend the use of an oscillator to produce the bit rate generator clock for your UART. In the case of the 65C52, you would drive XTAL1 and leave XTAL0 unconnected.
   
   
4. Chip selects of non-65xx devices should not be qualified with Ø2. Such chip selects should be asserted as soon as the MPU has placed an address on the bus, which is about midway through Ø2 low. Qualifying them with the clock substantially narrows the window of time in which the selected device can be accessed.
   
   The exception in your circuit is the 65C52, which is somewhat idiosyncratic compared to most 65xx peripherals. As the 65C52 does not have a Ø2 clock input like its more commonly used sibling (65C51), you must gate its CS input with Ø2 so the UART is selected only when Ø2 is high. R/W on the 65C52 should be directly connected to RWB on the 65C02.
   
   
5. The 65C52 is a relatively slow device, limiting your system to a maximum of 3 MHz. Also, its inputs and outputs are TTL level, despite being a CMOS device. This makes sense when you consider it was meant to replace the 6551 that was widely used in NMOS systems. The 65C52 doesn't have internal FIFOs, which makes it vulnerable to receiver overruns. An overrun occurs when a new datum arrives before the previous one has been read by the MPU, resulting in data stream corruption. Succinct interrupt processing is generally necessary to minimize the overrun risk.
   
   
6. Reads and writes of non-65xx devices must be qualified by Ø2 so the access doesn't occur while the clock is low. This is especially important on write cycles, as the data bus will be in a state of flux during Ø2 low and may trip up the device being accessed. The below illustration is of a R/W qualifying circuit that works with any asynchronous device with separate /OE and /WE control inputs.
   
   
   Attachment:
   File comment: Read/Write Qualification
   
   read_write_qualify.gif [ 32.21 KiB | Viewed 2184 times ]
   
   
   In the above circuit, the inverter can be replaced with one of the 74AC00's unused gates, unless all of them are needed.
   
   
7. In future designs, take a look at the Maxim DS1813 reset generator instead of a roll-your-own reset circuit. It's in a TO-92 package (also SMD if you can work with dinky parts). The 1813 is also handy for debouncing push buttons, such a push button attached to NMI on the MPU.
   
   
8. As Alarm Siren noted, CTS and RTS are more useful in most serial interfaces than DTR/DSR. I would attach RTS to the headers so you can rig up bi-directional hardware flow control. Note that XON/XOFF flow control is generally unreliable beyond 9600 bps.
   
   
9. The IRQ outputs of the UART are open-drain, which means they must be pulled up to Vcc with a resistor (3.3K recommended). Also, they should be wired directly to IRQ on the 65C02. Splitting the IRQ outputs is only useful if you have priority interrupt encoding in your system, along with hardware to modify the MPU's IRQ vector on the fly.
   
   
10. RxC and TxC on the UART are inputs and must be tied to ground or Vcc, unless you plan to use them.
    
    
11. The RxD inputs on the UART must not be allowed to float. Pull them up to Vcc with 3.3K resistors, which will hold them in the "mark" condition if there is nothing external connected (pulling them down would put them in a continuous "space" condition, which the UART will likely misinterpret as a programmed break, causing it to generate spurious interrupts).
    
    
12. You device selection circuitry is awkward and severely limits future expansion. It's late and I'm tired, so I didn't work out the full memory map. However, as Alarm Siren noted, it seems there is no ROM at the MPU hardware vectors, which means that right now you have an unbootable system.

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

Welcome, Mike! It's nice to hear that!

Sorry if my post came across as a bit gruff, it was very late when I posted it! Welcome to the forum, and the very best of luck


OT:


Yes, I remember seeing you use a DS1813 for NMI debounce on one of your POC designs and thinking "wow, that's really clever". A tad expensive perhaps, given it costs ~£5 per chip, but very clever. I was tempted to use that in my current design, but I had a left over schmitt inverter anyway so I rolled with a Low Pass filter instead.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Wow, there was a lot more wrong with that than I was expecting! A few are face-palm worthy it-was-late-and-I-shouldn't-have-been-making-modifications-to-my-design-at-that-time (address decoding, for example, for which I already had a working and bread-board tested design). A lot of the others are rather more subtle.

Thank you all for the pointers. I'm pretty heavily engaged this week, so I'll be back to address several of them later, but I have a few follow on questions which I'll squeeze in now.


I did test the timing (of one chip) using a scope, and found it to be damn close to 180 degrees, but I guess that's not really a good idea.


As I read it (and I am quite likely to be mistaken), the SRAM latches the address on the falling edge of /OE during on a write cycle, which (timing non-guarantees aside) would make PHI1 -> /OE a very convenient gate. The /OE to "ready to latch data" delay is advertised to be considerably shorter than the same delay from /CS so it seemed like a good idea, even if at the speeds I'm talking either would do...
I need to go back to the datasheet on that one, it was a long time ago I made that choice, and my reading of timing diagrams has improved somewhat in the interim.


Oh, this is good news. I didn't find clarification in the datasheet (although the copy I have is a poor scan of a paper copy, and not being able to search the text is... less than convenient.


Damn, I overlooked that. Can anyone recommend a CMOS level alternative? Including converters would be a little... messy, esp from a routing PoV.

(edit): My datasheet says "Full TTL or CMOS input/output compatibility". That sounds... hopeful.


I labelled the headers to match the FTDI breakout board I referenced in the original post. It comes from the Arduino world, where I believe a DTR signal is used to reset the microcontroller, making the bootloader available for sending a new program image. Thinking about it, this is probably not the standard usage. Perhaps I should just make the FTDI chips part of the main board and provide USB ports rather the relying on a pluggable breakout which might not be designed for exactly my purposes...


If you do have the time/energy, I'd be interested to hear your thoughts on how it might be improved (or just a pointer to some existing writings your aware of on "good address decoding practice").

The schematic as presented was also flat out wrong (I was holding an old memory map in my head and confusing the two when I wired it). My desired memory map is

$FFFF
8k ROM
8k IO
48k RAM
$0000

I had been considering a backplaned design so that I could iterate on different modules independently, and the idea was that the CPU board would provide that basic decoding, and then each IO board would perform a further address decoding of A10-12, gated by the IO_CS signal from the CPU board. That would give me 8 different IO "slots", with allocation probably hard-wired in to the IO boards.
I didn't expect the hard-wiring to be particularly limiting - I can't imagine 8 different classes of IO I'd attach to this particular model.

However, I scrapped that plan, mostly because the cost of PCB space for the connectors to the backplane on each board quickly eroded the expected savings from not having to re-print the whole computer if I want a new revision! But also because I've read enough here to know that it is not recommended(TM) in spite of being very tempting.
Even at $5 per square inch for three copies (oshpark), PCBs are cheaper than ever, and well within my reach, but also cost more than all the other components combined! And three copies of a buggy board aren't much use...

So, the address decoding I presented (if corrected) was only ever intended to handle the one IO device and I was expecting to re-do it for any future revision which had more requirements. I'd be interested to hear how it might become more flexible, and how that flexibility might be exercised.

Thank you all for your thorough input. I'm especially glad that I decided to post, rather than re-check, order PCBs and hope!

Hmm. Went quickly back to the SRAM datasheet. While I'm clearly talking rubbish, I am still confused, particularly by the two different modes. Timing diagrams attached.

If I read correctly, I could use /OE *high* (i.e. connect it to PHI2) to gate writes, although without further logic, this would ruin reads. Probably better just to gate the /CS.

This is a bit confusing. For all the RAMs I've worked with, the RAM's Output-Enable-not pin is irrelevant when Write-Enable-not (WE\) is low. Just make sure you never have WE\ and CS\ low at the same time while Φ2 is low, because the processor does not guarantee that the address it puts out will be valid and stable before WE\ goes down. BDD's recommendation is that WE\ not be allowed to go down until Φ2 is high. His is a valid way to do it. However, today's RAM is often the fastest thing on the bus, meaning another way to avoid the problem is to qualify the RAM's CS\ with Φ2 since the RAM does not need the extra time to respond to being selected. It's fast. When the processor is writing (storing) data, the data bus is not guaranteed to be valid yet when Φ2 rises; but that's ok. It is guaranteed to be valid and stable before the specified set-up time before Φ2 falls, so the value the RAM latches in will be the right value.

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

(Can I just add my usual observation that phi2 is being used here as a convenient demarcation between the early part of the cycle, where address and control outputs are not yet stable, and the late part of the cycle, when they are. The 6502's timing for these purposes isn't referenced to phi2 levels, only to the falling edge of phi2. I think it's worth pointing this out... I hope it's not just pedantry.)

It's not pedantry, and in fact, is quite important. All timing originates from a clock edge and in studying the WDC timing diagrams for the 65C02 and 65C816, one can see that almost all of the critical setup timing is referenced to the fall of Ø2. Referencing from the rise of Ø2 is convenient in establishing a boundary beyond which a read or write access on a device is "safe." However, in the design of my POC V2's logic, I worked off the fall of Ø2.

Not paying attention to timing details can end up biting you.

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

In the ISSI SRAM (which I used in my POC V1.1 unit), /OE is a "don't care" when the device has been selected and /WE is low. The two different timing diagrams (write cycle #1 and write cycle #2) illustrate two approaches to the same thing. WC #1 is the cycle I use, in which the device is selected during Ø2 low and /WE is asserted when Ø2 goes high. Use of this cycle is required in my POC units due to the 65C816 placing the bank bits on the data bus during Ø2 low. WC #1 produces the quickest response to a write access, which both the timing diagram and the write cycle switching characteristics table highlight.

WC #2 gates CE, /CE and /WE simultaneously, and deasserts /OE at the start of the write cycle. As the SRAM will not respond to /WE until it has responded to selection, an internal delay occurs, t_HZWE + t_SA ends up being a larger number than in WC #1, causing the elapsed time from when the access is started until the device is ready to accept data to be longer than with WC #1. That may have consequences at high Ø2 speeds but is unimportant below 10 MHz. It would not be an ideal configuration in a system running at 20 MHz.

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

I'll have to take a look at that. I'm still pretty hazy on how one adds deliberate (and especially fixed, rather than expressed as a percentage of a cycle) delays to a signal to account for e.g. setup times after an edge rather than working directly from a clock edge.