BigEd wrote:
I suspect the goal is avoid contention, at those points where the bus is turned around. Typically, that would be just after the CPU read an operand, and at the start of a cycle where it writes to a CMOS memory or peripheral. And then again just after a write, where the CPU needs to read the next opcode.
Careful balancing of delays is one approach. But I think the most usual is to make use of phi1 as a dead period and only to drive the bus (at either end) during phi2.
(I've a feeling I've missed something, so hopefully someone will come along and correct me.)
The discussion was raised (somewhere else) as a concern for what happens if you change a ROM from NMOS to CMOS and the NMOS CPU erroneously tries to write to that ROM. I then started to think of my own solution, in which I have both CMOS and NMOS talking to each other.
The problem is that I have to have the timing within a few tents of ns to get the CPU to pick up the correct (read) response. I doubt that using phi1 is going to help since the MOS6502 spec has a minimum for the databus hold time after phi2 drops (THR of 10ns). I have actually seen that shutting down data towards the CPU too early gives errors on memory read, even up to 50-100ns after phi1 goes high. At least on some of the MOS6502 I have tested with (but not all).
My solution has been to disregard the phi1&2 and use the address bus to reconstruct a clock, then time the response after that change happened. It seems to be more consistent. It could be due to some old NMOS6502´s starting to fail, or maybe they just drift out of spec.
Using a auto-direction level translator (TXB0108PWR) seems to work, but in some cases there are things happening on the bus that confuses the direction. E.g. some MOS6502 works nicely with this, but about 1 in 4 does not work. I don´t think I had the same problem with SN74LVC4245ADBR, but any contention would be a poor solution anyway, so I would like to get the TXB to work.
I have been playing with the idea of having some way to measure bus contention and actively changing the timing through the CPLD to account for NMOS6502 component variations, but I haven´t found any useable way to get this going (yet).
So, the problem may partly be related to the age of NMOS components, or related to poor specs (or variations) within the NMOS6502 ICs. Still, I need a way to handle this.
What would you do?