6502.org Forum Projects Code Documents Tools Forum
It is currently Fri Apr 26, 2024 2:34 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Newbies

All times are UTC




Post new topic Reply to topic  Page 1 of 2
  [ 30 posts ]  Go to page 1, 2  Next
  Previous topic | Next topic 
Author Message
J64C
PostPosted: Tue Jul 13, 2021 5:30 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Hi Guys,

I keep seeing posts about making sure that write operations are 'qualified' against PHI2. With examples of how to do so, like below.

Attachment:
RDnotWRnotCkt.jpg
RDnotWRnotCkt.jpg [ 14.98 KiB | Viewed 2994 times ]


Is this a 'do in all circumstances' thing or are there just certain situations where this should be done. Because when I monitor the write operation on the scope, it seems that the write terminates at the same time PHI2 goes low, which seems valid (to my uninitiated mind) to me.

Attachment:
bmp_118_003.jpg
bmp_118_003.jpg [ 49.8 KiB | Viewed 2994 times ]


So I am wondering what the purpose is of qualifying the write operation?

Many thanks!
Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Tue Jul 13, 2021 5:54 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
This is from about 70% of the way down the 6502 primer's address-decoding page:

    You must have a way to make sure RAM cannot be written when Φ2 is low! [...] Looking at the 6502's timing diagrams in the data sheet, you will see that the address lines are not guaranteed to be valid and stable before the R/W goes low; so it is possible to write to unintended addresses. With an extremely simple program that you might use to see if the computer is working at all, the other addresses it writes to might not be ones you're using yet; but soon they will be, and you'll start writing garbage over your variables, or your stack space, or even your program, when you still need those areas to remain intact. The result will likely be a crash.

To further clarify: The problem is not at the end of the write cycle, but at the beginning. The address seen by the RAM may not be correct yet and with enough setup time when the R/W line goes down. It may also be very hard to figure it out, because the data are not out yet, and even if they were, the glitch may only be long enough to corrupt something and not long enough to get a full write to the wrong address.

_________________
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  
J64C
PostPosted: Tue Jul 13, 2021 6:05 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Ahh got ya! So with the address at an indeterminate value early on, you could potentially be writing garbage all over the place at every clock cycle. Right?

If my thinking is correct, this could lead to some obscure crashes.

Huge thanks for the clarification. I did read this on your primer now that you point it out. As you (and we all) appreciate, there is a huge amount of information on your site. Easy to miss things (or not fully absorb) on the first read through.
Top
 Profile  
Reply with quote  
J64C
PostPosted: Tue Jul 13, 2021 6:21 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
I see what you mean, the write pin gets enabled immediately on the clock going low. Which is not too healthy if addresses aren't stable yet.

Attachment:
bmp_118_004.jpg
bmp_118_004.jpg [ 55.08 KiB | Viewed 2989 times ]


Top
 Profile  
Reply with quote  
GARTHWILSON
PostPosted: Tue Jul 13, 2021 6:29 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8428
Location: Southern California
Thanks for the picture. It's even more extreme than I thought. [Edit: I should have looked at the sweep speed. I was forgetting you were at only a Hz or two.] Also, it will take a little time for the effective address to propagate through the initial row and column logic in a RAM. Whether or not that gets through before the R/W logic propagates through, becomes a race condition, I suppose. We are not told what goes on inside it.

_________________
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  
J64C
PostPosted: Tue Jul 13, 2021 7:35 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Probably looks exaggerated in that pic as it’s only clocked at 1Hz there.

I’ve had to step out from home for a few hours, but before I left I did a test at 1.5MHz and the write signal trailed the down going PHI2 signal by 16nS.

A quick look at the data sheet says that the address setup time at that clock speed could take as long as 150nS. So that leaves a hell of a lot of room for data corruption on the RAM. I can see now why qualifying the write signal is so important.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Jul 13, 2021 7:40 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
J64C wrote:
I see what you mean, the write pin gets enabled immediately on the clock going low. Which is not too healthy if addresses aren't stable yet.

The 65C816 has similar behavior during a write cycle, which I noticed that when I was doing logic analysis on my POC V1.2 last year. The 816 doesn't immediately drive RWB low at the clock's fall on a write cycle but does do so before the address bus has settled.

BTW, here is the read/write qualification circuit I have used in my POC V1 series, which are all discrete logic.

Attachment:
read_write_qualify_alt.gif
read_write_qualify_alt.gif [ 46.98 KiB | Viewed 2980 times ]

The entire circuit can be realized with a single 74xx00 NAND, with one gate left over for some other purpose. 74HC logic in that circuit is reliable to 12 MHz. Beyond that, 74AC or 74AHC produces more timing headroom. My POC V1.2 unit, which is all 74AC logic, easily managed 20 MHz with that read/write logic—access to I/O and ROM had to be wait-stated at that speed.

Although it doesn't look like it, there is only one gate delay in asserting /WD. RWB will be low well before the rise of Ø2, which means the output of the gate used as an inverter will go true right away. When Ø2 goes high its effect will be on the second gate, which means /WD will go true one gate delay after Ø2 goes high. With 74AC logic, that delay averages around 6ns.

The key takeaway is your decoding logic should generate an appropriate chip select as soon as possible after the fall of the clock, but access to the selected device (meaning read or write) should not occur until after the rise of the clock. The only caveat is that does not apply to 65xx peripherals, such as the 65C22. They are driven by Ø2 and "understand" the 65C02 bus cycle. All control inputs to 65xx peripherals must be valid before the rise of the clock.

Quote:
A quick look at the data sheet says that the address setup time at that clock speed could take as long as 150nS. So that leaves a hell of a lot of room for data corruption on the RAM. I can see now why qualifying the write signal is so important.

Address setup time is affected by operating voltage. The number you quoted is with the 65C02 running on 1.8 volts. On 5 volts, address setup time is 30ns maximum.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
J64C
PostPosted: Tue Jul 13, 2021 7:54 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Ah ok! I thought 150nS seemed excessive. I’m presently reading from an iPhone in the car (no I’m not driving :lol: ) and missed the voltage thing there.

Still the 30nS max time, is still a fair bit behind the 16nS (actual) write request. I know in practice the addresses are probably set up much earlier than the ‘max’ time. But yeah, we have to plan for worst case scenario.
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Tue Jul 13, 2021 8:11 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8143
Location: Midwestern USA
J64C wrote:
Ah ok! I thought 150nS seemed excessive. I’m presently reading from an iPhone in the car (no I’m not driving :lol: ) and missed the voltage thing there.

Still the 30nS max time, is still a fair bit behind the 16nS (actual) write request. I know in practice the addresses are probably set up much earlier than the ‘max’ time. But yeah, we have to plan for worst case scenario.

I have long suspected the timing figures in WDC's data sheets are from back when their parts were 1.2µ geometry and were not static cores as they are now. Some of the quoted timing values almost seem impossible when considered against the maximum rated clock speed of 14 MHz. Plus it has long been common knowledge WDC's data sheets have errors that have crept in over the years.

My experiences, as well as those of some of our other members, strongly suggest the internal gate delays in the current static cores (which are 0.6µ geometry) are much smaller than the quoted timing figures would make them seem. I was running my POC V1.2 unit at 20 MHz, despite the official 14 MHz top speed rating of the 816, and that was with discrete logic. Furthermore, if you extrapolate the FMAX vs VDD curve in the data sheet you can see that the C02 and 816 should be able to reach 25 MHz running on 5 volts.

So don't let that 30ns give you pause. Base on the logic analysis I did on V1.2, the setup times are much shorter and there is plenty of timing overhead with which to work.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
J64C
PostPosted: Tue Jul 13, 2021 8:21 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Nice! I’m certainly not stressing about it, I’ll be adding the write qualifier either way. Better to be safe than to be chasing my tail for faults that shouldn’t be there. :lol:

From everything I have been reading (mainly on this site), it seems that WD is being very conservative with their ratings, which is awesome!
Top
 Profile  
Reply with quote  
J64C
PostPosted: Tue Jul 13, 2021 9:04 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Back home now. Here's the relationship between PHI2 and the Write signal (at 1.5 MHz and 5V supply on the W65C02), for those that might be interested. :D
Attachment:
bmp_118_008.jpg
bmp_118_008.jpg [ 65.29 KiB | Viewed 2969 times ]


Ignore the bounciness as it was a quick test with a long wire feeding the clock. Not lab conditions by any stretch. :lol:
Top
 Profile  
Reply with quote  
BillO
PostPosted: Tue Jul 13, 2021 4:10 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1000
Location: Canada
You probably already know this, but the system clock (phi2) with the W65C02 should be the same signal as is going to into Pin 37 of the CPU, not the Phi2O coming out of pin 39 as it was in the old NMOS days. In fact, in my experience the old NMOS systems work better this way too. At least they seem to overclock better.

_________________
Bill


Last edited by BillO on Tue Jul 13, 2021 11:53 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
J64C
PostPosted: Tue Jul 13, 2021 9:47 pm 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Yep. Pin 37 is where I’m driving the system clock in to. :D
Top
 Profile  
Reply with quote  
J64C
PostPosted: Wed Jul 14, 2021 12:25 am 
Offline

Joined: Sun Jul 11, 2021 9:12 am
Posts: 137
Added a quick visual representation, for anyone's benefit (probably more so my own :lol: ) as to what the qualified write looks like compared to the normal write.
Attachment:
qualified_write.png
qualified_write.png [ 6.09 KiB | Viewed 2919 times ]


Top
 Profile  
Reply with quote  
hoglet
PostPosted: Wed Jul 14, 2021 2:06 pm 
Offline

Joined: Sun Jun 29, 2014 5:42 am
Posts: 337
J64C wrote:
Added a quick visual representation, for anyone's benefit (probably more so my own :lol: ) as to what the qualified write looks like compared to the normal write.

To be completely accurate, I think the unqualified write signal should also have the same gray transition period as the address bus.
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 30 posts ]  Go to page 1, 2  Next

Board index » 6502.org Users Forum » Newbies

All times are UTC


Who is online

Users browsing this forum: No registered users and 9 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:  
6502.org is an ongoing project by Mike Naberezny and contributors.