6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 7:37 am

All times are UTC




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: NMOS to CMOS tug-of-war
PostPosted: Sat Sep 16, 2017 5:26 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
As you may know, the NMOS components can output many mA if you try to force an low output high, while it is easy to push the NMOS high down (due to its internal pullup resistors). This creates a conflict if you combine old NMOS components (or machines) with CMOS upgrades.

I have been monitoring the NMOS6502 databus when it accesses a CMOS memory expansion, and it doesn't look nice. E.g. the latency of the NMOS 6502 and any CMOS components are not always the same, so conflicts arise very easily. Since I am working with a very fast CPLD device, I can time the response exact to get rid of conflicts, but this is probably not true for all of the old components out there (the unit I work with is an upgrade to plug into old systems).

The proper way to do this may be though a tri-state buffer. I am using a 3V to 5V level-shifter which gives proper level translation, but with the apparent CMOS to NMOS tug-og-war not only a possibility, but quite a reality, I am cautious.

In my latest implementation I have used TXB0108PWR buffers for data, but I am wondering whether SN74LVC4245ADBR (which I used in an earlier prototype) is a better choice. As you can see here, LVC components power up in tri-state.

The best would probably be to use LS components, but there are no level-shifters in LS technology.

What are your thoughts on this?


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2017 6:32 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
What is the goal?

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Sep 16, 2017 8:30 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.)


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 21, 2017 10:33 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
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?


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 21, 2017 11:29 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Ouch - reconstructing a clock from address bus changes seems like a very last-resort kind of thing to do!

The only idea I have for monitoring bus contention is to put some very low value resistors in series with the data pins of one of the devices and to monitor the voltage drop across those resistors with a scope.

The example of writing to a ROM is an interesting one, as that won't be momentary. The simple answer would be to select the ROM only for read cycles - I'm not sure if that's usually done.


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 21, 2017 2:23 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BigEd wrote:
I've a feeling I've missed something
I feel the same way -- not sure I understand what the difficulty is. But I can't visualize the system. A rough block diagram showing just the bus connections between the devices would be helpful. :!:

With 6502 (both NMOS and CMOS) contention is avoided by simply by designing to ensure no device (CPU, level-translator, memory, peripheral) drives its data bus pins when Phi2 is low. (A '02 or 'C02 cpu follows this rule implicitly. '816 is a different story.) Across the whole system, all segments of the data bus float. Then when Phi2 goes high, one and only one device drives each segment of the bus. IOW, no contention, ever (assuming ROM is only selected for read cycles). Apologies if I'm stating the obvious; it's only because of this feeling that something's been missed.

Since the auto-direction level translator seems to be troublesome then I'd switch to the simpler, non-auto alternative. Granted, you'll have to run the CPU R/W signal to it, but that's easy enough.

-- Jeff

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 21, 2017 7:08 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
kakemoms wrote:
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).

Do you have 74LS logic in there? If a line has only CMOS (which essentially presents no DC load), the capacitance on the line (a few pF per pin) holds the data plenty long after the line is no longer being driven. I'm not talking about just nanoseconds or even microseconds. When I was making the tester for the 4MB SRAM modules shown on the front page of my site, I happened to observe the undriven lines holding the data for milliseconds. I did not experiment to find out how much further I could go with it. My point however is that you don't have to worry about a lack of hold time if there's no 74LS or other DC load on a line.

If there were still any problem, you could do variations on this circuit (which was originally for eliminating the chance of nanosecond bus contentions at the clock edges on the '816).

I'm sure your old NMOS parts won't start failing just from time. Running hot could reduce the life, as can of course abuse, for example ESD (electrostatic discharge). Otherwise they should last a lot longer than we will.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 22, 2017 6:24 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
Ok. A simple block diagram (with CS signals omitted):
Attachment:
IMG_5901.png
IMG_5901.png [ 23.34 KiB | Viewed 1554 times ]


Basically I connect (my device) towards the data/address bus through level-translators. It should be a simple problem in which the CPLD part here acts as SRAM memory. If I do the timing adjustment very accurately, things work most of the time. If I miss the timing with a few 10s of ns, I get errors. Usually on only one or two of the data lines. If I change the NMOS6502 (to another component), the errors magically disappears (or reappears).

So:
1) I know I can get it working.
2) It does not work for all NMOS6502 cpu´s (MOS brand), even if they work with normal SRAM.
3) The bus contention only happens at some of the data lines
4) Original MOS6502 specs seems widely out of range

I guess, as you stated, it is better to use a non-auto direction component. The strange thing is that the errors can appear at only one or two of the data lines.


Last edited by kakemoms on Fri Sep 22, 2017 8:45 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 22, 2017 7:00 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
What is the purpose of using the NMOS 6502? If you're making a new computer, there's no reason to use NMOS. The CMOS version has a ton of benefits over the NMOS. See http://wilsonminesco.com/NMOS-CMOSdif/ . The time to favor NMOS is for example if you're using a Commodore 64 which used the 6510 which was never made in CMOS, or that you're writing code for others with legacy machines who won't be changing the processor to the CMOS one for you. Those are legitimate reasons. Outside of that, let me encourage you strongly to switch to the 65c02.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 22, 2017 8:48 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
GARTHWILSON wrote:
What is the purpose of using the NMOS 6502? If you're making a new computer, there's no reason to use NMOS. The CMOS version has a ton of benefits over the NMOS. See http://wilsonminesco.com/NMOS-CMOSdif/ . The time to favor NMOS is for example if you're using a Commodore 64 which used the 6510 which was never made in CMOS, or that you're writing code for others with legacy machines who won't be changing the processor to the CMOS one for you. Those are legitimate reasons. Outside of that, let me encourage you strongly to switch to the 65c02.


Its an expansion unit that connects to the 5V data/address bus (of an existing system). The NMOS is not part of my design, but I have to interface to it.


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 22, 2017 12:26 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
kakemoms wrote:
Its an expansion unit that connects to the 5V data/address bus (of an existing system).
Do you not have access to Phi2? I still don't understand why the situation is so challenging. (But the diagram is a big step in the right direction -- thanks!)

Quote:
If I do the timing adjustment very accurately, things work most of the time.
What operation is taking place when the failures occur? For example, is it when the 6502 is doing a write to the CPLD? (Writes to the CPLD should occur on the falling edge of Phi2. Reads from the CPLD should cause it to drive its databus pins during the entire time Phi2 is high.)

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 29, 2017 4:08 am 
Offline

Joined: Wed Mar 02, 2016 12:00 pm
Posts: 343
Dr Jefyll wrote:
kakemoms wrote:
Its an expansion unit that connects to the 5V data/address bus (of an existing system).
Do you not have access to Phi2? I still don't understand why the situation is so challenging. (But the diagram is a big step in the right direction -- thanks!)

Quote:
If I do the timing adjustment very accurately, things work most of the time.
What operation is taking place when the failures occur? For example, is it when the 6502 is doing a write to the CPLD? (Writes to the CPLD should occur on the falling edge of Phi2. Reads from the CPLD should cause it to drive its databus pins during the entire time Phi2 is high.)


I am not using phi2 since timing variations make its use less than stable. Edges are at least +/- 50ns. I will try to sample it for some machines so you can see what I mean.

The problem is when TXB drives the databus, so for NMOS6502 read.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC


Who is online

Users browsing this forum: MSN [Bot] and 67 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: