Bill, it looks like you missed one of the changes I made after double-checking my work - so in your schematic /CS1 will do the opposite of what it's supposed to.

You need to send that line to CS2 instead, and feed /CS1 with an inverted copy of ROM /CE.

You're right!

I'll make the change after 5pm - gotta go...

Edit - Update: Okay, the drawing in my post below this one has been updated and using just 2 74XX00s ... This looks like it.

Just wish you could use faster logic or a slower CPU, but if anything has a chance to work without one of those or delaying the clock to the CPU, this should be it.

Also Dolo, remember to run the Phi2 to this circuit and any other device from pin 37 of the CPU - not pin 39. Leave pin 39 disconnected.

Also included in this post is the improved version Chromatix was talking about - using the 74XX10. If you could see your way to using a 74AC00 and a 74AC10 you would have only approximately 9ns or less of propagation delay in this circuit. Might cost a £, but that would be good for any clock speed the w65C02 is good for.

_________________
Bill

Sorry for the delay in updating my progress. I have some exciting news, but firstly many thanks to everyone who has contributed to the thoughts on this thread.

Quick run down:
1) I made an absolute buggers muddle of implementing the new decoding glue logic, so that took a while to realise
2) I only had one 74HC00, so moved to using 74LS00 parts only for decoding, with 1k pull ups
3) The output skew and peak voltage from the decoding looked weird, traced down to bad power on the decoding breadboard
4) Finally, she seemed to awaken as if all was normal:
4.1) Keyboard - Check
4.2) Video - Check
4.3) Sound - Check.
4.4) Serial - NOPE. Serial was working but only at the lower 2.68Mhz speed. At 5.34Mhz seemed to transmit fine, but glitchy receive. I suspected the 2Mhz part I am using is sensitive to clock speed and I was lucky previously, but..
5) After a little experimentation, putting smooth caps near the 6551 VDD and VSS lines sorted the serial glitch out.
6) So, back to square one but with optimised decoding logic?

NOT SO! So the obvious thing to do was put in the 15ns SRAM which was not working with the previous decoding logic. Voila, works absolutely nicely with no glitching. It was something I privately felt could happen given all the poor practices I had gotten away with in my original design, so it's excellent that taking back to reference practices has fixed the mystery.

In conclusion, the main issues with my existing design were (in order of impact):
a) Decoding logic had a lot of delay and contra-practices and using 70ns SRAM was probably masking this
b) Poor power handling e.g. need more smoothing caps across power and ground lines needed at higher clock, was probably getting away with it marginally up till now
c) Care with breadboard power and signal distribution - they are glitchy, noisy little buggers as the clock speed goes up. Having said that, they have allowed me to get on this journey in the first place, so have a soft spot for breadboard (for purely personal projects).

Many thanks again to all of your contributions - really pleased with the outcome on this one

Cheers, Dolo

Well congratulations - and I'm glad I could help.

You made a great spot with the decoding - great stuff

Congratulations!

Cool .

Feels good to get things working, doesn't it?

_________________
Bill

@GaBuZoMeu and BillO - Thanks both for your help, great knowledge and support

Not to take this off topic but this thread kind of exemplifies why I use GALs almost exclusively these days for glue logic. While it's not that difficult to come up with the logical expression you need to map out your memory space, it is a real exercise in logical analysis to determine the best set of real-world gates to implement your ideas. It's so much easier to just to write your logical expressions in CUPL and then let the compiler and the GAL determine the best 'black-box' configuration to implement it.

But that, however (to me anyway), is only the biggest benefit. There are others - to wit...

> Compact - you can generally do everything you could possibly need with one or, for very complex systems, two packages.
> Layout friendly - if you are making a PCB for your project the GAL (or other CPLD) allows you to redefine pins as required to simplify your copper layout.
> Changes/bug fixes/updates are a simple matter of re-writing the code and re-programming the device - leave the soldering iron in peace.
> Cheap - you can buy used Lattice GALs for chump change - many times a $1 apiece - and they are re-usable.
> Fast - PLCC packages down to 4ns - DIP packages down to 7ns. 10ns are cheaper. 15ns are the ones for chump change - you pay a bit more for the fast ones.

They are a bit power hungry although I have never seen one consume as much as the specs say they will - maybe 20% of that.

That's not saying GALS are infallible - lord knows I have just completed two projects that prove that succinctly - however, you can make the same mistakes in discrete logical plus a lot more with the added penalty of having to pull your wires out implementing a fix.

Consider them for you nest project Dolo. Using them is like listening to Diana Kral play Summer Samaba 'So Nice!' https://www.youtube.com/watch?v=Q3WbMpEuhrw

_________________
Bill

She can come sing for me any time!

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

Thanks for the advice Bill, I'm definitely interested in using programmable logic next time. The current project has some legs yet but I would like to try a 16 bit machine after this

Dolo

Here's another circuit I concocted to generate Ø2-qualified reads and writes. It uses one section of a 74AC139 1-4 decoder, along with the PHI1 output of my clock generator circuit.


Here's the clock generator circuit again.


When /G on the '139 is driven high, all /Yx outputs are driven high without regard to the state of the A and B inputs. As /G is connected to PHI1 of the clock generator, it will be high when PHI2 is low, which keeps /RD and /WD high while Ø2 is low. Reading and writing are inhibited.

When /G is driven low, which it would be when PHI2 is high, one of the outputs will be driven low according to the state of A and B. Since both A and B are driven by RWB, the only possible outputs are /Y0 being low when RWB is low, or /Y3 being low when RWB is high. So we get /RD = low when RWB is high and Ø2 is high, or /WD = low when RWB is low and Ø2 is high.

The state changes of /RD and /WD lag Ø2 going high by an average of 6ns at 5 volts, which is very slightly slower than the NAND gate equivalent.. However, it's still more than ample timing headroom for even the fastest 65C02 or 65C816 unit.

What's the advantage of this circuit over the read-write circuit that uses NAND gates? It takes up less space on the drawing. Other than that, it doesn't do anything the multiple NAND gate circuit doesn't do, although fewer connections are required. The circuit, however, is illustrative of how a particular piece of logic can be used in ways other than originally intended.

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

I know the discussion is very old and I'm not a gravedigger, but I want to express my gratitude to everyone who participated in this discussion.
I was having a problem with my 6502 and W65C02 test board purchased from mouser.com but which does not accept 65C02 instructions, sorry but I am deeply upset about this.
Thank you very much guys, after reading almost all the posts in this discussion I realized that my problems could be related to the decoding of I/Os, SRAM and ROM, I had already compiled msbasic, tinybasic and ehbasic and in general they loaded but at the same time typing a simple 3-line program, the lines mixed together, a for next did not execute.
I would never have associated these software problems with the hardware peripheral decoding problems, I never had these problems and with the 6502 to make matters worse I still used a super fast SRAM cache memory taken from an old 486 motherboard (15 ns) .
The fix was easy because I'm using GAL to decode the addresses, and what made me realize that maybe this was the problem was when I read the post where someone mentioned that PHY2 should be associated not only with RD but also with WR and this type of problem it could happen to anyone who uses the direct signal from the CPU to the memories and that was what I was doing.
I'm glad I made that mistake, so I learned this important lesson in the wonderful world of hardware.

After 3 weeks of struggling with this problem it was gone.

THANK YOU ALL!!!!

Welcome, and glad to hear you got your system working!