Do you spot any fatal flaws in mine?

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

Okay, seems to have worked?

Perhaps you're referring to the RDY input on the CPU as floating? Some earlier 65C02 chips had an internal pull-up on RDY. I saw some years ago that the WDC W65C02 datasheet stated that RDY no longer has an internal pull-up. Granted, that could cause a problem with a CPU that doesn't have the older internal pull-up resistor. I did notice that Doug's circuit is using a G65C02P... which I believe does have the pull-up.

Good find

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

Why have you got A15 connected to OE on the RAM? When you do a write to RAM you'll end up with both OE and WE low, which sounds like a bad idea to me.
Strictly according to the spec sheets, a 150ns access FLASH device isn't fast enough to run the processor at 8MHz without wait states. Clock low to address valid is 30ns max at 5V, data setup to following clock low is min 10ns, so you have 1 clock period - 40ns for access time. At 8MHz that's 125ns - 40ns = 85ns.
The ROM is gated only by A15 high from what I can see (CE = !A15, OE always low). So if you ever try to write to ROM you'll end up with the CPU and the ROM both driving the same bus, which is bad.
The I/O decoding logic looks completely wrong to me. Your '138 is gated by A15=1, A12=A13=A14=0. So addresses in the 8000-8FFF range. But we already saw that any address with A15 high selects the ROM, so you have a clash there. Then, you've used A0, A1 and A2 to select between devices, but each VIA uses A0-A3 to select one of the 16 internal registers to be accessed. You need to use A4-A6 to select between devices instead of A0-A2.
You have a 74HC10 with only 1 gate out of 3 used as an inverter, and a 74HC02 with only 1 gate out of 4 used - seems a bit wasteful.

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

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

I remember studying Douglas' decoder circuit back in 2016;

The old Commodore 1581 Diskette Drive used a similar decode logic, also using a 74LS139.

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

A variation of Douglas' method might be a good single chip decoder candidate to duplicate the memory map of the Potpouri system in "The Primer" (1st drawing below). Tweak the logic a bit and use a 64K RAM chip for an additional 8K of RAM (2nd drawing below). Both designs are "untested"...

Thanks, Garth. That's the way I thought it was supposed to be done, too.

Jon

Okay, I made some drastic changes, based on what all of you have more or less suggested:
https://github.com/jmstein7/65c02_errata/blob/main/Schematic_revised.pdf

Still stinks

Jon

PS I'm using a WDC 65c02. Got them from Mouser.

PPS This is a generic pcb version of it:
https://github.com/jmstein7/65c02_errata/blob/main/PCB_default.pdf

Weird... it keeps turning my VCCs into GND?

Well, not sure about your latest schematic... seems the first sheet is mostly unchanged, i.e., still no actual reset circuit. The second sheet has issues... look at the '138 decoder. You have A0, A1, A2 going to the 3 inputs, which basically has the outputs at single addresses. Yet you're using these for chip selects for the two VIAs and the ACIA. The VIAs require 16 addresses each and the ACIA 4 addresses. Needless to say this doesn't work.

Also, you've added a 3-input NAND gate and only one gate is used, but configured as a basic inverter. Yet, you have 3 unused gates on the 7402 NOR gate, one of which could be used as an inverter.

I'm going to suggest you back up here.... write some design goals down first. Meaning, define your I/O devices and include how many memory addresses each one requires. Do the same for your desired memory configuration, both RAM and ROM. Include control signals for each device and finally build a memory map to include everything. You then need to define how you generate the signals to support each chip (RAM, ROM and the I/O devices).

Again, it helps to look at some other designs to see how they work. I'll include an old one from my earlier stuff... just the CPU, RAM, ROM and basic decode circuitry to define an I/O page at $FE00 and break that down into 8- chip selects using a 74138. This is quite simple.... my original design for this dates back to the 1980's.... shortly after I got my first Rockwell 65C02.

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

I give up.

It's a pity you're discouraged, Jon. I hope that turns out to be temporary.

One of the advantages of breadboarding, or of simulation, is that you can iterate and debug the design. Whereas, with PCBs, there's a lot of checking, and then a wait (and some money) and then quite possibly some debugging and some fixups and maybe a second revision.

Having said that, I think in most cases there needs to be some careful review and checking, and thoughtful analysis, because trying to debug just by making changes and hoping has only some chance of getting to a good outcome.

As an example, when it comes to programming, I don't usually stray beyond the range of ten to twenty lines of code, and in such simple cases, I can usually hack about until the program does what I want. If I were to tackle something in the hundreds to thousands of lines, that approach would be, I think, unfruitful.

That is to say, beyond a certain level of complexity, there's no substitute for being organised and careful and checking what you do. I don't think that should be an absolute obstacle for anyone, but it might be a skill and a mindset that takes a bit of an adjustment.

I hope this is helpful - and not adding insult to injury!