This is exactly what needs to be done. Use the /OE and /WE qualifier given from the schematic of BillO's post (near the top of the page):

As your memory map requires only 3 select signals /CE_RAM, /CE_ROM, and /CE_IO you may use a 74HCT85. It is a 4 bit magnitude comparator.
If you setup the B inputs to $B while feeding A15..A12 to the A inputs and set inputs A<B, A>B to 0 (false), A=B to 1 (true) then the output signals of the comparator would match your address map - you only have to invert them to be low when valid. A<B would become true if A15..A12 are $0..$A => RAM. A=B is only true if A15..A12 = $B => IO. And if A15..A12 are $C..$F the output A>B is true => ROM.

It is pretty slow. I takes roughly 50 ns to do its job. This is no problem for RAM or ROM. But you have to verify what the requirements of your I/O device is. Many 65xx IOs require chip select to be valid a lengthy period before the rising of PHI2!

If you have slower RAMs and/or ROMs (e.g. 55 ns or 70 ns types) use them instead of the fast ones.


Cheers,
Arne

This is the approach I use myself. But it's not the only acceptable way.

These remarks seem to overlook the fact that /CS1 of the RAM is qualified by Phi2. (In the other thread it was a different story.) But since /CS1 is qualified by Phi2, and with just a single gate delay, can we agree that the RAM, at least, is being driven satisfactorily? (It does seem there might be room for improvement in other areas, and I'm still mulling that over.)

-- Jeff
ps- I took the diagram and compacted it a bit. Dunno if I succeeded in making it more readable, but FWIW here it is!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Saved by the Canadians! Now I can read the schematic.

It seems to me that since RAM is in contiguous space, as is I/O and ROM, judicious use of 3-8 or 4-16 decoders might substantially reduce the number of gates delays incurred in generating chip selects. In particular, there are four gate delays to the RAM's CS2 input, which even with 74AC logic would be quite slow. I am suspecting that the total delay to CS2 is skewing the RAM's selection too much relative to the clock. This would be particularly problematic during read cycles, as the 65C02 has fairly strict timing requirements in order to assure a valid read.

As often noted, chip selects should not qualified with Ø2, especially if there is any desire to run the machine at a high clock rate. This seems to be a common 6502 design "feature" in home-built equipment, one which puts needless constraints on performance. Chip selects should solely be the product of the address bus state. The reason why becomes evident when the 65C02's machine cycle is considered (timings assume five volt operation):

• At tADS, the address bus will become valid. tADS is 30ns maximum after the fall of Ø2. This is when chip selection should be made. The address bus will remain stable until tAH, which is 10ns minimum after the next fall of Ø2. Not stated by WDC is the maximum for tAH, which will be something less than tADS, since the 65C02's internal gates cannot instantaneously change state. Timing calculations on tAH should assume the 10ns minimum.
  
  
• During a read operation (RWB is high), the 'C02 will sample the data bus at tDSR, which is 10ns minimum before the fall of Ø2. Any data bus gyrations that occur prior to tDSR are effectively ignored by the 'C02. Once tDSR has been reached, the data bus must be settled and must remain stable until tDHR, which is 10ns minimum after the fall of Ø2. The device being read by the 'C02 must drive the data bus for at least tDSR + tDHR if the 'C02 is to read valid data. Furthermore, that device must continue to drive the data bus until tDHR has expired.
  
  
• During a write operation (RWB is low), the 'C02 will drive the data bus at tDMS, which will be 25ns maximum after the rise of Ø2. The 'C02 will continue to drive the data bus until tDHW, which is 10ns minimum after the fall of Ø2.

Late (relative to the clock) chip selection may result in the 65C02's timing requirements not being met. Gate delays in the chip selection glue logic in themselves may cause problems, but definitely will exacerbate the situation if selection is qualified with the rise of Ø2 In such a design, selection may not occur until late during Ø2 high, and if during a read cycle, may result in the 'C02 reading garbage because the device being accessed did not drive the data bus during the tDSR + tDHR timing "window."

Using Ø2 to qualify chip selects is, in my opinion, questionable design practice. Where Ø2 should be used is to qualify reading and writing, using the circuit previously presented (repeated below), or a variation thereof. An exception is when 65xx I/O hardware is used, e.g., 65C22 or 65C51, in which case read/write must not be qualified by Ø2 and furthermore, chip selects must be valid before the rise of Ø2.

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

Yeah, I realized later that, despite the delay in creating CS2, Phi-2 rises after that point and the creation of the Phi2 qualified /CE1 is in control and this is verified by the last timing traces provided. But it seems that is more by chance than design in this case. Nonetheless it's getting the job done in enabling the RAM on time.


At the beginning of the cycle, yes. However, if we look at the same timing diagram, there may be a timing violation on when the write cycle ends. It looks like /CE lags the fall of Phi-2 by as much as 15ns. A W65C02 is only guaranteed to hold the data valid for 10ns (regardless of clock speed or supply voltage). It seems borderline at best. Might this cause the problems being experienced?

_________________
Bill

I'd say it would explain a dependence on RAM speed. A slower RAM chip would be less sensitive to changes in the data bus slightly leading the de-assertion of write-enable.

Yeah, there could be an issue -- but on the address bus, which is almost guaranteed to change, and promptly. This could result a write to some "innocent" address that's not supposed to be involved. (The data bus is merely tristated by the CPU after the end of a write cycle, and capacitance will typically hold the value until something else starts driving. So, unlike the address bus, there's no abrupt change very closely following the fall of Phi2.)

Dolomiah, can you confirm that your design uses only the Phi2 signal which is sent to the CPU input on pin 37? IOW, can you confirm that the clock outputs on pins 3 and 39 connect to nothing? At the moment I'm particularly interested in the Phi2 fed to the NAND whose output drives RAM /CS1.

And that NAND is an 'HC00 or 'LS00, is that right? You might wanna try swapping in something faster -- ideally an 'AHC00 or 'AHCT00. 'ALS00 or 'AS00 are a second choice. 'AC00 or 'ACT00 would be worth a try although they may create other problems. I'm just looking for an alternative that doesn't demand drastic changes -- which seem unwarranted, given that the slow RAM works.

J

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Considering the problem worsens with faster RAM, I agree. I just put a scope on a W65C02 and the address begins to change 5ns-6ns after the fall of Phi-2. The additional 10ns a fast RAM will have in Dolo's system until /CE begins to cut off the write is plenty enough to cause concern.

_________________
Bill

That does sound alarming, Bill!

dolomiah, in my previous post I suggested upgrading the NAND gate that generates /CS1 for the RAM. A faster NAND would cause /CS1 to go high sooner, relative to what the CPU is doing. Upgrading the NAND will gain a few ns, but it might not be enough. OTOH it's fairly easy, and worth a try, IMO.

A more potent remedy is to delay the CPU. The oscillator would continue to drive everything it presently drives except the CPU. From the oscillator you'd add a connection to a new gate which in turn drives the CPU's Phi2 input on pin 37. The new gate needs to be non-inverting, so an AND or OR would work, or a buffer such as 74_125. You could also try two inverters in series, although that might result in too much delay.

Yet another experiment you could try is a slower CPU, if you can lay hands on one. For example a Rockwell 4 Mhz 'C02 should be easily capable of running at your 5+ Mhz rate. But unlike the WDC part it won't be in such a hurry to place the next address on the bus, thus making the other remedies unnecessary. This assumes we've correctly identified the problem, of course. We'll know more if you're able to try some of these experiments.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hello all. I love the curiosity, energy and enthusiasm of folks on this forum - thanks to one and all for all your inputs. Apologies for delays between replies, work has been consuming rather a lot of my time.

So, there are a large number of potential issues, suggestions, ideas, experiments and questions in response to me providing the decoding logic - a lot to ponder here!

Let me try and provide a few more details in response to some questions (I've tried to go through all the replies, hopefully I didn't miss any biggies):
- Thanks to Jeff and Bill for providing a monochrome and tidier diagram that BDD can read, looks very good to me also
- @Chromatix - I did mention that I didn't think the logic was optimal, but the guidance that you and others give in terms of using address to qualify Chip Select and Phi2 with RWB to qualify Read-Write is a good one that I will look at. Without more clever parts than NAND and NOT, I haven't yet worked out how to minimise the number of gate delays. Four is a lot, and there may be nice ways to use the /CS1, CS2 with /E1, /E2 and E3 lines for RAM and 138 decoder - but I haven't figured it out yet. But might not be the problem of course..
- @BillO - yes the 4 gate delay is quite large. I had and still have a constraint on what parts I have, so LS and HCT type NAND and NOT parts is in my bag of bits and I fancy to try and keep it that way (I'm a tight-arsed British bloke doing things purposely on the cheap!). But, as pointed out by you and others, the address becomes valid way before Phi2 rises, so for the moment I am hoping this is not the issue. If other things don't work then I will have to fork out on some faster parts perhaps.
- @GaBuZoMeu - The 4 bit comparator idea would indeed work, but I didn't have one at the time and hoping not to have to buy more parts! I will do if I must at some point
- @Dr Jefyll - Although I am qualifying /CS1 with Phi2, it seems this is bad. I need to make /CS1 only use address, and then use Phi2 for /WE and /OE. /OE is tied low, but of course I can change that.
- @BDD - Yup, as you note, 4 bit decoders could do the trick here. I don't have any yet, so will try other things first. I think it was a couple of years ago now, but you probably told me about the mistake of using Phi2 to qualify selects - which fixed my problem when moving from 6526 PIA to 6522 VIA! So I am now only using Phi2 to qualify RAM /CS1
- @Dr Jefyll - In answer to your questions : Yes, I am using a single Phi2 source for all clocks, definitely not using the 6502 clock output on pin 3 or 39. The Phi2 in the diagam is the same Phi2 that feeds the 6502 on pin 37.

So, you may have determined from my decode logic and other things I have said, that I haven't been looking deeply at the datasheets

But somehow, she runs fine with 70ns RAM (did I just call my creation she!?). I am tempted to just let it go, but another part of me wants to sort out some basics. I like the principle of not using Phi2 for any chip select that you have all basically applied to your own works.

So I will start with that. Looks fairly straightforward:
- I will connect /OE to a NAND which has R/W and Phi2 as input
- I will connect /WE to a NAND which has inverted R/W and Phi2 as input. This will introduce an extra gate delay of course (currently direct connect to R/W)

So that will bring my decoding in to line with the core principle of letting address select the RAM, and then Phi2 with R/W select read or write. Except for the ROM - I don't see this where my problem lies though.

That's the start of the experiment. When I have done that, I'll come back with my findings. Thank you all again, really enjoy these interactions.

Cheers, Dolo

Dolo, this might not be a good idea at this point. At best I don't see it getting you any further if you can't reduce the propagation delay with faster parts. Try Jeff's suggestion of delaying the CPU first.

- Take the output of your oscillator and run that to everything that needs Phi-2 EXCEPT the CPU. (Don't use pin 39 as your Phi-2 for the system when using a W65C02)
- Then, starting again at the output of the oscillator, drive pin 37 of the CPU trough one non-inverting gate, or two of your fastest inverting gates.
- Leave pin 39 unconnected.

This will introduce a delay going to the CPU so that it does not try to change addresses before the RAM can finish it's write cycle.

See attached.

_________________
Bill

That's a fair point. Presently we have one gate delay between Phi2 falling and the RAM ending its write... and it will still be one gate delay after changing to the traditional design! So, no progress (assuming the problem does lie with a sloppy end-of-write, which seems entirely plausible).

But dolomiah has been offered a lot of advice, and we can't necessarily expect him to test it all. That said, I think the easy mod (added delay) has a better chance of working than the more complicated mod (ie, switch to the traditional design). Indeed, I hope you don't end up doing both! It won't be surprising if the traditional design ends up needing some delay added, using the exact same instructions.

If/when you do implement a delay, remember a 74LS gate needs a pullup if it's to drive the CPU's Phi2 input. Have fun, and keep us posted!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(Speaking of gate delays, I seem to recall that the useful-looking '138 decoder was very slow in the original TTL, and therefore not quite as useful in practice as it looked in theory. This might be a false memory, or it might be false when using newer TTLish families, but I'm using it as a prompt to note that gate delays are not all created equal - check the datasheet for the logic family in question.)

Edit: linkify.

The 74HC138 apparently has a maximum propagation delay of around 30ns, from any of the relevant inputs. That seems broadly consistent with the logic diagram, which shows 3-4 gates in each path.

Thanks - that doesn't sound like a problem then!

The 74AC138 is substantially faster and with stronger outputs to boot. I used it in POC V1 and it would easily keep up with a 15 MHz clock.

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