6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Mar 28, 2024 2:47 pm

All times are UTC




Post new topic Reply to topic  [ 87 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Sat Jun 16, 2018 4:55 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3327
Location: Ontario, Canada
dolomiah wrote:
I have a website on hackaday with various pictures, hope that gives you an impression of what I have done.
Alright, I found a photo... perhaps no longer up-to-date, but it'll serve. I see you have bypass capacitors connected directly to the chips -- which is good -- but instead I wanna talk about the connections between chips. I'll start with the data-bus connections between the RAM (which is at issue in this thread) and the CPU.

Attachment:
entire breadboard.png
entire breadboard.png [ 1.51 MiB | Viewed 2953 times ]
Attachment:
databus + its return path.png
databus + its return path.png [ 655.84 KiB | Viewed 2953 times ]
When I say connections, I'm including both the signals and their return paths. :!: The image above shows that these form a loop, with the signal wiring in yellow on the bottom and left of the loop, and the return wiring in black along the top and right. (For clarity I'll ignore the red Vcc wires, but they too act as a return path.)

The signal wiring offers little scope for improvement. It's long, and not much can be done about that. But can the return wiring be improved? Yes, and one improvement is to add a diagonal directly between the two chips. But, interestingly and counterintuitively, that's still not the ideal path -- the route the return current most wants to take. What it wants most of all is to hug the signal path, even though that's *longer* than a direct route (ie, diagonal)! :shock: So, I'd consider adding a ground wire that takes the same, long-ish route as the yellow signal path. (This new ground wire needs to be connected at both ends; otherwise it isn't a path.)

Of course the CPU and RAM aren't the only chips, and signal connections go every which way, helter skelter. All these signals paths should have prospective return paths available, but that'd result in a complete rat's nest. A ground plane would solve the problem -- because it attaches every point with every other point -- but we can't do that, either.

More practical (though much less satisfactory) than a plane is to provide a coarse grid of return connections. The idea of the grid is to help ensure that any two arbitrary points will have a return path close by. The grid needn't be perfectly orderly. But, operating on the premise that any two arbitrary points may have a signal path between them, we want a return path reasonably close by. As an example, consider C and D in the image below. I would add a horizontal path from C to D, and also extend the path to meet the columns to the left and right. I'd also put a return path from A to B. Right now there's no chip at A, but presumably there will be one in future, and it might have a signal path to B. And right now the only return path to B involves a drastic detour. I hope I've managed to write this in a way that makes some kind of sense. If there are some edits later it won't be surprising. :roll:

Cheers! :)
Attachment:
loose ends.png
loose ends.png [ 693.78 KiB | Viewed 2953 times ]

_________________
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: Sat Jun 16, 2018 5:43 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Wow! Very impressive! All - dolomiah's breadboard work AND Dr Jefylls analyze AND his suggestions of possible countermeasures!
If you can establish a grid like suggested it might work.

Two or three bulk caps (22...100µF) at the top/mid/bottom of each of the supply rails may assist further.


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 16, 2018 5:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8114
Location: Midwestern USA
Dr Jefyll wrote:
I wrote:
tADS remains constant, but the midway point of the Ø2 low period changes according to the choice of clock speed

Assuming a 5V supply, the max tADS for a modern WDC 'C02 is 30ns. If we do the math for clock rates in the range from 1 MHz to 14 Mhz (and some systems are even slower/faster than that) we see that 30 ns puts us 6% to 84% through the Ø2 low period -- or roughly midway. :wink:

Very roughly! :lol: In the future, I'll say the address becomes valid sometime after the fall of Ø2, which will be almost as unhelpful as saying "roughly midway." :shock:

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 16, 2018 7:53 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
> In the future, I'll say the address becomes valid sometime after the fall of ϕ2

Thanks BDD - I genuinely believe that will be more helpful! (Personally I'd probably say something like 'some tens of nanoseconds after...' if talking about today's WDC parts. Of course with other implementations it will differ, as indeed it will differ with supply voltage, and so a vague statement is more accurate.)


Top
 Profile  
Reply with quote  
PostPosted: Sat Jun 16, 2018 8:49 am 
Offline

Joined: Wed Nov 18, 2015 8:36 am
Posts: 102
Location: UK
Everyone, thank you very much for the enlightenment. I have attached a bang up to date higher resolution picture as the one Dr Jefyll found is now more than 2 years old.

I have learnt some fundamental things here, and so amazed that I have somehow managed to build a fully featured microcomputer :o

Things I've learnt:
1) The 6502 is not off the bus during Phi2 low - the address bus will become valid sometime during this half of the cycle. I read the datasheet from GaBuZoMeu on the CRTC in more detail, and yes I can now see that it does need a multiplexor to allow access to memory without contention. My decoding logic has been qualifying all chip select lines with Phi2 - at the moment timing seems fine for 5.36Mhz, even though I can now see how to do this with more time for devices to respond during the second half of the cycle.

2) I had found my breadboard to have been a bit unreliable at times during the build - I did add both power and ground wires at various random places which seemed to help. I now have a better understanding of signal and return paths as outlined by Dr Jefyll, and so the reason why adding extra power and ground connections can help. I will also add some capacitors across the 5V and 0V lines - I assume this is to help smooth spikey demand current in fast switching devices.

The picture shows the full set up as it is today:
- Bottom row left to right : AY-3-8910, TMS9918a, 65c22-2, 65c22-1, 65c02, address decode logic. I will list everything else relative to this row for ease of identification.
- Above the AY-3-8910 is a 6551 ACIA
- Above the TMS9918a is the CAS/RAS address latching to connect to modern SRAM
- Above the 65c22-2 is the SRAM for the TMS9918a. Also, this 65c22 drives the SD card SPIO pins
- Above the 65c22-1 is the ROM (topmost) and SRAM. This 65c22 drives the BBC keyboard interface. The SRAM is the 70ns part working fine @ 5.36Mhz
- Above the 65c02 is more decode (3 to 8 decoder) to select one of 8 IO devices (I have 4 today - 6551, TMS9918, 2x65c22)
- Above the address decode logic is clock and reset circuitry, including the 4 bit counter which I use to divide the 21.4772Mhz crystal frequency down for use by TMS9918a, 65c02 and AY-3-8910

With this new insight, it means that due to it bugging me, I will likely redo the address decoding to be more efficient. Maybe the board can run at more than 5.36Mhz with more time in Phi2 high for devices to respond (I tried 10.7Mhz, but seems to be completely unresponsive!). I will also look at return paths and hopefully result in a more stable set up going forwards.

Very much appreciate everyone's input - such a great and knowledgeable forum :D

Cheers, Dolo


Attachments:
Mainboard-2018-06-16.jpg
Mainboard-2018-06-16.jpg [ 1.29 MiB | Viewed 2944 times ]
Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 17, 2018 10:46 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 993
Location: Canada
Hi dolomiah,

Have a look at this thread: http://forum.6502.org/viewtopic.php?f=4&t=5179

I had a similar problem with a W65C02 running with fast (15ns) RAM.

The problem ended up begin that the propagation delay involved in qualifying the write signal with Phi2 (call the qualified write /QW) caused the /QW to extend beyond the RAM /CE. While the RAM specifies that there can be 0ns between the release of /CE and /W, there can't be, say -6ns (a negative value).

The solution was to delay the clock going to the CPU by the amount of delay in producing the /QW signal. Another solution would be to use faster gates (74ACXX). It seems a delay in generating /QW around 6ns or 7ns is fine, but the 15ns I had was enough to cause problems.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 18, 2018 9:13 am 
Offline

Joined: Wed Nov 18, 2015 8:36 am
Posts: 102
Location: UK
Hi Bill

Yes, I have already been tracking your thread (very interesting), and this might be an issue for me too. I will try a single gate delay of Phi2 to the CPU and see if I get different results.

I am using 74HC04 and 00 parts which at 5V are around 7-8ns delay - so that should be enough I think.

** Correction - I need to have 2 gates delays, a 04 will invert the clock with one gate, then I need to invert again - so that's going to be around 16ns. Too much? **


Cheers, Dolo


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 18, 2018 1:10 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
According to what happens to Bill I assume 16ns are too much. Perhaps you can "invert" the logic instead of inverting the clock twice? Or simply use the /OE and /WE qualifier BDD has posted there. Then you are using a "known good" solution.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 18, 2018 1:48 pm 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 993
Location: Canada
I agree, 16ns might be too much.

If you have to real estate, then this solution offered by BDD to produce a qualified write (/QW) should work as an alternative to delaying the clock to the CPU:

Image

The AC logic is speedier than the HC logic. If this doesn't cure the problem then it may be elsewhere.

Do you have dual trace scope? It might be helpful to see the relationship between Phi2 at the CPU and you /QW and also between RAM /CE and /QW.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 18, 2018 5:35 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
After reading some datasheets and reconsider what Bill did observe with his design, I think you are suffering from the same problem that nagged Bill. This small delay between PHI2 getting 0 and /WE getting 1 and the short data hold time after write of the WDC CPU will cause all that trouble, if (!!) your RAM is very fast! (And b.t.w. with this circumstances my advice to stabilize the power supply is counterproductive :shock: as it causes the RAM not to slow down!)

Well, if you look at the specs of a moderate speed RAM it requires a data setup time (frequently named tDW) of about say 30 ns or more. The faster the RAM goes, the shorter this time is. And nearly no RAM requires the data to be valid after /WE gets 1. I think one can imagine that this setup time (with some safety margin) is the time it takes for the signals to travel from the pins to the memory cells. This means as well, that if the data starts to get floating it takes again this time to change the memory cells state. So using a slow RAM allows you to violate the proper timing sequence (first /WE becomes 1 and then data may start to float)!

Of course you cannot rely on using slow RAMs to mediate timing errors :). So using BDD's suggested /WR and /OE logic (or perhaps the refined one by Dr Jefyll http://forum.6502.org/download/file.php?id=6403&mode=view) is highly recommended.


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 18, 2018 9:59 pm 
Offline

Joined: Wed Nov 18, 2015 8:36 am
Posts: 102
Location: UK
Hello Bill and GaBuZoMeu

Thanks for your continued interest. So I have a cheapo PC scope, but have managed to get a 2 channel dump from it (100ns sweep, 2V per division). The screenshot is below - yellow trace is Phi2, green trace is the /CE line (active low) from my address decoding.

The output is based on a very simple loop:
Code:
loop
    lda 0
    bra loop


Before this loop starts, the machine goes through the normal boot code and then disables interrupts. So the above is the only code that runs which means there is 1 cycle where the 6502 is reading RAM, the rest of the time reading ROM. My scope has very limited memory, so I ran it machine at 1.34Mhz to get a longer trace at 1us sweep and confirm there is only 1 regular RAM access. At 100ns sweep this is the most the scope can show.

So the interesting thing here is it looks like /CE is starting to fall as Phi2 is rising - looks like no delay?!? But the fall of Phi2 and the rise of /CE seems to be in the order of 40ns to my eyes. I will dig out the decoding logic later and check where Phi2 is getting involved.

I'm out of time for a couple of days due to work, but I hope this may yield some further theories :-)


Attachments:
scope1.png
scope1.png [ 67.95 KiB | Viewed 2804 times ]
Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 2:14 am 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 993
Location: Canada
So that's RAM /CE?

It looks very like what I was seeing whe I was having trouble.

The more important signal to compare to Phi2 is the signal going to the RAM write line (the phi2 qualified write signal (/QW)) anad also the /QW with RAM /CE.

Also, the important place to look is when Phi2 is falling (end of cycle) and both /QW and RAM /CE are rising. Ideally Phi2 will fall followed (not ny much) by /QW rising followed by RAM /CE rising. The really nasty thing with fast RAM is when RAM /CE rises before /QW.

BTW, in your Hantek software, you should have the option to save an image under the file menu.

_________________
Bill


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 11:11 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
Please be careful: the screen shot is a nicely connected dot picture coming from 48 Msps measuring some signals around 5 MHz. Thats only 10 dots per cycle! This can be used to check whether a signal appears or not and whether its levels seemed to be correct. For timing analysis in this range you need faster equipment.


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 9:47 pm 
Offline

Joined: Wed Nov 18, 2015 8:36 am
Posts: 102
Location: UK
Hello Bill and GaBuZoMeu (and all)

I updated the code so the lda is now sta, this means I have one write cycle at regular intervals.

So I did a data dump out of my PC scope of Phi2 vs /CE and Phi2 vs /WE in to Excel, then aligned the time axis to show a graph of Phi2 vs /CE vs /WE. Hopefully you can see the jpeg.

What do you make of this - it looks ok to me, I think, but I am not sure what problem I am looking at any more! It appears that /CE is not far behing Phi2 going high, within 10ns, and /WE is around 20-25ns behing Phi2 going low. The distance between /WE and /CE is in the region of 80-90ns. /CE rises around 20ns before /WE.

@GaBuZoMeu - agree with your caution, but unfortunately this is the only sampling hardware I have. But the scope is consistent with the readings in terms of relative difference in time and level between the various data series.


Attachments:
ScopeDump2018-06-19.jpg
ScopeDump2018-06-19.jpg [ 336.23 KiB | Viewed 2755 times ]
Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 19, 2018 10:22 pm 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
dolomiah wrote:
but I am not sure what problem I am looking at any more!
:)
Well, if there is no more difference between using a fast or a slower RAM then you are one step further!

If you going to increase the speed I recommend the /WE and /OE logic the way Dr Jefyll suggested. (BTW I wonder how many people use /CS for gating reads and writes. To me this is somehow "unusual" although it works. I do prefer the classic(?) way using /OE = PHI2 & RWB and /WE = PHI2 & !RWB)

When it comes to video RAM - what are you going to implement? Should it be text or graphics or color graphics? 11,xx MHz reminds me that could be black&white pixel clock for 50 Hz screens?


Arne


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

All times are UTC


Who is online

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