6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 5:31 am

All times are UTC




Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Sat May 25, 2013 7:09 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
Forgive me if I'm saying things you already know. Since you're rather new here, I don't know how much you know about different aspects, although obviously you've put a lot more thought into memory protection than I have. Of all the knowledgeable people on the forum, each has strengths that others don't have (which I guess is part of the reason for a forum, huh?). We all wish each other (including you) success of course.

Quote:
While they're great (and intended!) for wire-wrapping, I'm afraid they won't fit solderless breadboards, neither turned-pin sockets. :( Pins are too thick for them!

Ah yes, regarding the pattern. WW pins (of single in-line or DIP, not a square PLCC socket) can however go into all the solderless breadboards I've used-- with care. I've never damaged a solderless breadboard with .025" square posts, but it's probably borderline. I don't do any computer work with solderless breadboards though, as they're the worst of all worlds for that, regarding inductance and its many bad effects on fast digital lines. Fortunately (in that regard), you said you're using Rockwell and GTE parts which I don't think ever came in more than 4MHz. With slow parts at 1MHz, you can get away with murder. But turn up the speed, or even use faster parts at slow clock rates (ie, the output slew rates are faster when they do change state), and you can get into trouble. In the computer I mentioned above that took about 2mA for the entire computer (including LCD), I did initially breadboard that with solderless breadboard, but it was with 2MHz parts, and spent most of its time at 170kHz. Make sure you look at the sticky topic, "Techniques for reliable high-speed digital circuits" and the "Construction: Avoiding AC-Performance Problems" page of the 6502 primer.


Quote:
65xx-68xx style hardware has already a ø2 (aka Enable) input for that matter; however, since their R/W line cannot be qualified with ø2 (must be stable some time before) it's best to deselect them -- thru the 6522's CS2 line tied to my WD\, or simply disbling the I/O decoding (the originally intended protection) altogether.

Make sure your 6522 selects are not qualified by phase 2. They, like R/W, must be valid and stable a specified minimum amount of time before phase 2 goes up. (I found out the hard way.)

Quote:
Although SRAM is usually interfaced more like the Intel-style, the use of this circuit won't allow the simple design of tying OE\ to ground -- see bus contention issue above. Either the SRAM gets deselected when WD\ goes active, or OE\ gets qualified with ø2 and negated R/W (most recommended)

All the SRAMs I've worked with simply ignore OE\ when WE\ goes down. IOW, they will definitely not try to put data out on the bus when they're supposed to be taking data in to write.

If you find a source of 74ABT688 (or '521-- same thing), please let us know. I have not been able to find any, in any package. 74AC is the fastest I've been able to find a '688 or '521 in.

_________________
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: Sun May 26, 2013 6:57 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
BigEd wrote:
BigDumbDinosaur wrote:
RDY is an asynchronous input, so the rapidity at which it would return to logic 1 is not a real concern. If it takes too long you get an extra wait-state for free. :lol:

Hmm, I'd be careful with that kind of thinking: there are setup and hold constraints to be met. Violate those and you could have some difficult to debug misbehaviour. (Which is to say, it's not an asynchronous input: tPCS and tPCH constraints apply; see page 29/30 of the current datasheet.)

Cheers
Ed

Actually, the fact that the W65C02S has a static core means it can be halted by RDY at any time during any part of the cycle and not malfunction. I've toyed around with RDY on my POC unit and randomly asserting it doesn't seem to faze the '816 at all. As soon as RDY goes high the MPU starts right up and finishes whatever it was doing without error.

However, I was also tossing in a bit of dry humor about getting "free" wait-states.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun May 26, 2013 7:20 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Ed is right. The fact that the W65C02S has a static core does not mean you are free to violate the setup/hold times for the RDY signal. According to the data sheet the RDY signal is sampled on the negative edge of the PHI2 clock, so it needs to be stable at that point.

If you don't adhere to the setup/hold times, you can cause undefined behavior. This could happen if the RDY input splits in two (or more) paths inside the device, and each of those paths leads to a different flip flop. Due to timing differences, one flip flop could capture RDY when it's low, and the other could capture it when it's high, leading to a bad internal state.

Edit: In addition to the problem with multiple paths giving different interpretations to an input, there's also the issue of metastability when setup/hold times are violated.


Top
 Profile  
Reply with quote  
PostPosted: Sun May 26, 2013 10:57 am 
Offline
User avatar

Joined: Wed Sep 29, 2010 9:19 am
Posts: 22
Location: Almeria, Spain
GARTHWILSON wrote:
Forgive me if I'm saying things you already know.
There's nothing to forgive... I've been lurking here for a while and I'm aware that your advice (from all of you, that is) is very valuable. Even if you say something I already know, it's always good to have a reminder, and could be very helpful for another newcomer arriving here, too.

It goes without saying, in a nice forum like this one, everybody wins!

Quote:
WW pins (of single in-line or DIP, not a square PLCC socket) can however go into all the solderless breadboards I've used-- with care. I've never damaged a solderless breadboard with .025" square posts, but it's probably borderline.
I usually don't like to force things... if it doesn't fit easily, I won't push any harder, just in case... so that's probably the case.

Quote:
I don't do any computer work with solderless breadboards though, as they're the worst of all worlds for that
I've been cursing on them for decades :evil: and that's for analog work! But maybe my theoretical background is not that strong, so the are very valuable for experimenting things -- once one is aware of their limitations.

This far, my current 6502 computer is on a, ahem, solderless breadboard. But that's going to change, obviosuly.

Quote:
Fortunately (in that regard), you said you're using Rockwell and GTE parts which I don't think ever came in more than 4MHz. With slow parts at 1MHz, you can get away with murder.
Now I'm using a 1 MHz 65SC02 from GTE, and a 2 MHz Rockwell VIA. The EEPROM (2816) is rated 250 ns and the SRAM... whatever NEC means by -3 for their 6116 equivalent! (it looks like 150 ns -- huh, NMOS??? :x ) But quite surprisingly, this combo is able to run rock steady at up to 4.6 MHz -- and that's on a breadboard! The extremely simple decoding is mostly the "culprit". On the other hand, I'm having problems with a thight, soldered circuit at 1 MHz... but I'll start another thread for that.

Quote:
Highly recommended reading! I feel I should get into the world of WW...

Quote:
Make sure your 6522 selects are not qualified by phase 2. They, like R/W, must be valid and stable a specified minimum amount of time before phase 2 goes up.
Yes, I did -- read your advice a while ago. But you're doing well pointing this again, it's an easily overlooked issue which could be difficult to troubleshoot!

Quote:
Quote:
the use of this circuit won't allow the simple design of tying OE\ to ground<snip>
All the SRAMs I've worked with simply ignore OE\ when WE\ goes down. IOW, they will definitely not try to put data out on the bus when they're supposed to be taking data in to write.
Certainly, and I usually tied OE\ to ground; but with my protection circuit, it could happen that the CPU is trying to write but WE\ does not go down (because the protection circuit gets in the way and disables it).

Anyway, I think the recommendation from BDD of qualifying reads (thru OE\) with ø2 makes a lot of sense... especially if the system is running at a much slower speed than its components are rated -- say, 1 MHz with 4 MHz parts. If a fast CPU is going to write to RAM, it may put the data on the bus quite early in the (slow) cycle, probably well within ø2 low. And with fast memory and fast decoding, the SRAM may put the supposedly read data by then because WE\ is still high -- it won't be asserted until ø2 goes high. Thus, a brief bus contention will happen...

Quote:
If you find a source of 74ABT688 (or '521-- same thing), please let us know
I'll do :wink: Anyway, I think I'll stick to AC for a while.

Now I'll post about my system(s) in other threads... Cheers,

_________________
---
Carlos J. Santisteban
IES Turaniana
Roquetas de Mar, Almeria (Spain)


Top
 Profile  
Reply with quote  
PostPosted: Sun May 26, 2013 8:14 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Arlet wrote:
Ed is right. The fact that the W65C02S has a static core does not mean you are free to violate the setup/hold times for the RDY signal. According to the data sheet the RDY signal is sampled on the negative edge of the PHI2 clock, so it needs to be stable at that point.

If you don't adhere to the setup/hold times, you can cause undefined behavior. This could happen if the RDY input splits in two (or more) paths inside the device, and each of those paths leads to a different flip flop. Due to timing differences, one flip flop could capture RDY when it's low, and the other could capture it when it's high, leading to a bad internal state.

Edit: In addition to the problem with multiple paths giving different interpretations to an input, there's also the issue of metastability when setup/hold times are violated.

However, don't you think that WDC would have mentioned such a thing in the caveats section? Yes, RDY is sampled at the fall of the Ø2 clock. So are IRQB, NMIB and RESB. Nothing in the timing diagram or caveats admonishes the system designer on possible undefined behavior if RDY is asserted at, say, right after Ø2 goes down. It appears that all that will happen is that response to RDY would be delayed one cycle, which is supported as such by the 65C02 data sheet:

    3.10 Ready (RDY)
    A low input logic level on the Ready (RDY) will halt the microprocessor in its current state. Returning RDY to the high state allows the microprocessor to continue operation following the next PHI2 negative transition. This bi-directional signal allows the user to single-cycle the microprocessor on all cycles including write cycles. A negative transition to the low state prior to the falling edge of PHI2 will halt the microprocessor with the output address lines reflecting the current address being fetched. This assumes the processor setup time is met. This condition will remain through a subsequent PHI2 in which the ready signal is low...

Emphasis added.

As I said, experimenting with the POC unit has demonstrated that RDY can be asserted without ill effects at any point in the machine cycle.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 27, 2013 5:01 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
Quote:
experimenting with the POC unit has demonstrated that RDY can be asserted without ill effects at any point in the machine cycle
MTBF is a numbers game. Until you reveal some numbers, we can't possibly be impressed with your experiment.

I've heard 65xx family device have had application in Medical Devices. I wonder if you'd like to have a pacemaker implanted -- if the team that designed it shared your views regarding timing specifications! :roll:

Dr J

_________________
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: Mon May 27, 2013 5:12 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8544
Location: Southern California
Fortunately they will follow more-stringent testing and approval requirements for medical equipment than they do for drugs! :lol: As one doctor put it, 90% of prescription drugs belong in the toxic-waste dump.

There's part of my designs that have been going into aircraft for the last 20+ years that uses a transistor in a way you won't find in any textbook though, and supposedly can't work, yet it has never shown itself to be unreliable. I used it for years before finding (as I suspected) that I'm not the only one who has discovered the effect. If it were to fail though, it would just make communication and entertainment a bit irritating. The plane would not stop flying.

_________________
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: Mon May 27, 2013 5:18 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigDumbDinosaur wrote:
Nothing in the timing diagram or caveats admonishes the system designer on possible undefined behavior if RDY is asserted at, say, right after Ø2 goes down.

Well, the timing diagram shows that RDY should be stable in the setup/hold interval around the falling clock edge. This is typically all the documentation you need. However, you are right about the IRQB, NMIB and RESB signals, which would be assumed to be completely asynchronous wrt to the clock.

To be safe, I would stick to the documented setup/hold times for RDY, or ask WDC to clarify. Given the fact that RDY affects many more flip flops inside the device as the other 3 signals, there may well be a difference.

Quote:
As I said, experimenting with the POC unit has demonstrated that RDY can be asserted without ill effects at any point in the machine cycle.
That would depend on how many combinations you've tested. It could be that the ill effects are subtle, and only occur when certain types of instructions are executed, and only once in 10 million times.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 27, 2013 5:33 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8507
Location: Midwestern USA
Dr Jefyll wrote:
Quote:
experimenting with the POC unit has demonstrated that RDY can be asserted without ill effects at any point in the machine cycle
MTBF is a numbers game. Until you reveal some numbers, we can't possibly be impressed with your experiment.

I've heard 65xx family device have had application in Medical Devices. I wonder if you'd like to have a pacemaker implanted -- if the team that designed it shared your views regarding timing specifications! :roll:

Dr J

MTBF? How did hardware failure get into the picture? If the possibility existed of the MPU failing because an input was mistimed it's highly unlikely that such a thing would go unmentioned in the data sheet. This would especially be the case for a medical-grade device. If WDC knew of such a possibility and failed to describe it in the data sheet any lawyer could use it as prima facie evidence of negligence.

Arlet wrote:
Well, the timing diagram shows that RDY should be stable in the setup/hold interval around the falling clock edge. This is typically all the documentation you need. However, you are right about the IRQB, NMIB and RESB signals, which would be assumed to be completely asynchronous wrt to the clock.

RDY is listed with IRQB, NMIB and RESB on the same timeline, which strongly implies that all four share common timing characteristics. Again, if RDY had a special timing requirement don't you think that WDC would have created a separate timeline for it, or at least discussed the timing requirements in the caveats, as they did with the 65C816's ABORTB input?

Quote:
To be safe, I would stick to the documented setup/hold times for RDY, or ask WDC to clarify.

Such should be the case or else the MPU's response to RDY won't be what it expected. I'm not recommending to anyone to be cavalier with timing in any respect. What I am trying to get across is that sloppy RDY timing isn't going to kill the MPU, only make it not respond to a wait-state in a timely (!) fashion.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon May 27, 2013 5:49 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigDumbDinosaur wrote:
What I am trying to get across is that sloppy RDY timing isn't going to kill the MPU, only make it not respond to a wait-state in a timely (!) fashion.

But you don't know that. There could be circumstances where parts of the device respond to the wait state one cycle earlier than other parts. For instance, the PC incrementer could see that the RDY was high, and increment the PC, but the carry flag updater could see that RDY was low, and not update the carry flag.


Last edited by Arlet on Mon May 27, 2013 6:01 am, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Mon May 27, 2013 5:54 am 
Offline

Joined: Sat Oct 20, 2012 8:41 pm
Posts: 87
Location: San Diego
BigDumbDinosaur wrote:
What I am trying to get across is that sloppy RDY timing isn't going to kill the MPU, only make it not respond to a wait-state in a timely (!) fashion.


That's what I thought you were saying and I agree.
If you want to put a toggle switch on RDY and then toggle it any time you want then there will be times it will not meet setup time but will then be read on the next cycle just like IRQ. Of course setup time would be taken into account in an actual design.


Top
 Profile  
Reply with quote  
PostPosted: Mon May 27, 2013 6:15 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
BDD wrote:
What I am trying to get across is that sloppy RDY timing isn't going to kill the MPU, only make it not respond to a wait-state in a timely (!) fashion.
No sweat, I actually think you explained fairly well. And, to be honest, I would've agreed with you if you'd asked me earlier. But Arlet's first post set me straight.

There's lots of intersting reading if you follow the link he provided. MTBF is very much part of that vocabulary, btw.

cheers,
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: Mon May 27, 2013 1:09 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
Interesting - I hadn't noticed that the interrupt inputs have the same timing description. Perhaps we do tend to assume that they are asynchronous inputs - although in many designs they are in fact produced synchronously by other devices on the same clock.

In the NMOS 6502 we do see a particular front-end stage on the chip for the interrupt inputs, but not for RDY. See for example viewtopic.php?p=25814#p25814 - the best one can do is have high-gain stage, because the usual solution of multiple flops wouldn't fit the function.

By coincidence, I've just read a bit about the original IMPs (nodes on the Arpanet) which were variant Honeywell 516s. It seems they had metastability problems, down to a design defect, with an MTBF of hours to days. The people at BBN built a test circuit to irritate the interface enough to make the problem observable on a 'scope. (Computing in the Middle Ages: A View From the Trenches 1955-1983)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3

All times are UTC


Who is online

Users browsing this forum: No registered users and 36 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:  
cron