It's late but a couple of thoughts in case they help -

You're doing a 16 bit capture, is that intentional? You've got rdy and rst disabled, I guess maybe you have sync connected? Sync is not very important IMHO, and I would try an 8-bit capture (fx2pipe -8, and decode6502 -b) in case there's a bandwidth issue.

There are options for the decoder to display all the bus cycles inline with the code - when there are prediction failures I find that very helpful, to understand what was in the file and what it ought to have been. It's messy, but I leave it on all the time.

Are there I/O devices on the data bus that could easily be removed from it, to take them out of the equation for now?

It does sound like a potential address decoding problem, or loose wire. It's also possible for ICs to fall in such a way that they ignore an address line, or pull it to ground all the time. I've mostly seen that on really old DRAM chips though, in vintage computers.

I wonder if there'd be value in removing the 6502 and driving its address and related outputs directly, to see how the address decoding responds.

I suppose it's intentional, in the sense that I didn't do it by accident. I didn't think too hard about it though; I just followed the instructions on the wiki. I do have sync attached - it was easy to attach since I'm not using it and it's just floating. Rdy is tied high by a resistor, so I didn't bother including it in the capture. RST is attached to A5 and Ø2 is attached to RDY0(or 1). I think I see your point though... since with the Cypress board we can make sure that we get one sample per clock cycle, 8 bit captures are viable in a way they aren't with the 8-channel board.

There are no I/O devices on the main board, and nothing else is hooked up to it other than the LA. The I/O decoding logic is active, though, because the unit of the '139 that generates the RAM / ROM select signals is gated by the I/O decoder.

Now that is an interesting idea. I wouldn't have thought of that - but I think I can easily do it with some breadboard wires! Thanks for your thoughts, George!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

You've been coming some distance! Good updates.

So, you are still getting a lot of $55's? I have some ideas/suggestions, or at least places to troubleshoot:

1) Have you run some other devices or code on this current board? You had the LCD working on the last one, have you proven this board with something similar? Or at least some LED's? That would at least give you a starting place.

2) How much do you trust this logic analyzer? A short parallel: I was trying to get my Genesis gamepad working, but it would just start glitching. Tried all types of things in code, for hours. Then I just bashed the controller with my hand and it worked again temporarily. Took it apart, put it back together, and some buttons weren't working at all. Bought a new(er) controller and it worked instantly. The problem wasn't my code, it was the controller! The point is, the device giving you data could be bad/glitched/wrong/etc. This could include both hardware and software.

3) Have you tried pressing chips, pushing on wires, bending things? I'm guessing you checked continuity with all of those drill spots? Even a tiny jumper could change things drastically! Just checking for physical issues.

4) Are you sure the chips are functioning ok? Or are they "too good"? Golly I remember one time a '161 was making my whole screen snow unless I warmed it up, but other '161s were fine. Turns out I had a timing issue, but my "canary" '161 was just too good at it's job apparently. I know 74AC' chips have fast slew rates, maybe it's something like that?

5) Does your reset line supervisor start the reset process at 4.5V or more? Any small shift in voltage on that line would make it reset then. I usually go with 3V threshold versions when possible.

6) I've watched a lot of vintage computer repair videos, and the main things to check first are: power, clock, and reset. After that, check for bus contention and other things. I know you know this stuff, but I'm reminding you, maybe it'll spark something in the brain?

Hopefully things improve soon. Look for small victories, it helps relieve tension. Thanks for the updates!

Chad

No I/O, or even LEDs are attached to this board. It passed the NOP test, but as soon as I started using RAM it went splat.

A medium amount, I guess? I think mostly my difficulties with it are due to my inexperience using it, with its general persnicketiness being a contributing factor. I am starting to get more consistent results, thanks to George's input. The dev-board itself is a proven design, but my particular one is clearly not a very well made one. (Messy soldering, flux residue all over the back of it, and so on. A couple of the pins on the fx2 were bridged with solder and I had to separate them with a scalpel. Maybe once things settle down I'll go ahead and pony up the $12 for the one that hoglet uses.)

For sure; on that topic, earlier I took George's advice and pulled the CPU to test the decoding logic by driving the address lines directly. When I reinserted the CPU I got exciting new chaos! Turns out that one pin on the CPU didn't have continuity with the leg on the socket, so A14 was floating! The little socket fingers had gotten stuck somehow, I guess. I pried around in there with a bodkin and managed to free them up so I'm back to the old boring chaos.

I definitely have a bad AC163. That was an easy one to find, though, because it's my prescaler and the clock signal was wild! The other day I switched it out for an HC163, and the clock is now working. All the other glue logic chips seem to be doing what they're expected to.

In fact, yes (it's a DS1813-5). And it was causing me problems just like you describe! I tidied up my ground network and added some bypass caps on either side of it and now it's behaving. (Also, reset goes to the logic analyzer, and it seems to put a relatively heavy load on it! The DS1813 holds the reset line at 5.1V normally, but when I connected it to the logic analyzer it drops to 4.8! That load, along with my previous not-so-good ground / bypassing in the neighborhood of the DS1813 made for some truly scary looking traces on the scope!)

Thanks a lot for your encouragement, Chad. It really helps with morale!

I've narrowed the problem down to the RAM. If I remove the RAM IC from the board, the RAM test completes successfully (which is to say, it notices that what it writes to RAM is different from what it reads back from RAM and jumps to the appropriate failure loop). With the RAM on the board it goes splat the first time it executes LDA 0,X. When I drove the address lines directly as George suggested, with just the ROM on board I could read from the ROM no problem, and the signals on the data bus were rail to rail. With just the RAM on the board I could also get it to drive the data bus, but the high voltage seemed low (4.7-8 or so) but still high enough for a logic 1. With both the RAM and ROM on board, though, I would read 700 or 800mv on the data bus, which should never ever happen. This seems like bus contention for sure. But I can't figure out what can be happening to cause it. ROM_CS and RAM_CS are generated by a `139 so they can never both be low at the same time. I am stump-ed.

This is the RAM I'm using: I grabbed some of them from that Ali Express seller that Michael (K8LH) recommends. I guess it's possible that my entire batch is bad, but it seems unlikely that they would all fail in *exactly* the same way. I think either I made a mistake somewhere connecting it (but I can't find one!) or there's some aspect of it that I've failed to understand that has caused me to make a bad design decision.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

One other thing that's maybe worth mentioning; this is the same RAM I was using in the breadboard version of Blue August. That one worked well enough that I could get it to bank out the ROM and run some code from RAM. So, that's yet more evidence that it's not the RAM chips themselves that are bad. (Or, at least, there's one good one in there somewhere, I and I randomly happened to grab it by good luck, that one time!)

Since that build I did update the glue logic with a slightly different banking method that uses an HC11 instead of an HC32. It shouldn't matter for now, since my test code doesn't do any banking. The ROM/RAM\ signal should just always be high. Earlier I verified that it was, in fact, high, while I was checking my decode logic. But just in case, here it is again:

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Hm! Looking at that glue logic, and the datasheet for the RAM, I have two ideas:

1) Which speed is the RAM chip you have? The -35 or the -15? Bill (plasmo) has told me multiple times that anything below 25ns is just too fast and he himself does not use it [ correct me if I'm wrong Bill! ] Also, are you sure you are writing the correct data to RAM? I know you are saying it's an LDA 0,X instruction, just checking all bases. If you have a write problem, because jumbled data is ending up on RAM, it would definitely mess things up!

2) Have you tried just the most simple design possible? That glue logic looks, well, like a lot. Not a *lot* in the grand scheme of things, but for a redesigned "keep this as simple as possible" test board, I would say it's too much going on given the issues you are having. Start with those same exact chips in a breadboard, let's say. 6502, RAM, ROM, and a single 74HC00, let's say. Are you getting the same results? Are things exactly the same, or are there different errors? That would tell you if your chips are ok or not (or if the breadboard is working or not...). And if you really are having bus contention, hopefully something like this would show one way or another. Sometimes it's ok to scrap something and start fresh. It's just easier to do that in code than with wires unfortunately.

Your floating A14 seems like an issue. I know it wasn't the original cause, but what *else* could be floating? What else could seem fine but really is not?

Last thing, all of this is a learning process. Mistakes are made by the best of us, but we should learn from them never-the-less. Just think of all the *learning* you are getting right now! It's SO much learning!

Thanks for the updates, do whatever you think is best, but don't be afraid to scrap it and try again fresh.

Chad

It is the 15ns one. That is... surprising to me. The W24512-AK has been discussed may times here as a good and very inexpensive part to use in fast 6502 systems. I guess writing to RAM is kind of like quantum mechanics. The right data is going out to the RAM. Is it getting into the RAM? I don't know without observing the RAM, and observing the RAM makes it go splat! I'll post a current capture in a bit so you can see what I mean by "splat."

Yes and no. The glue logic is the same as Peanutbutter-1 except for the following:

• Using 128k of FLASH ROM instead of AT28C256
• Using 64k of SRAM (W24512AK-15) instead of 32k (71256SA12TPG, actually a 12ns part)
• The bank signal
• The clock stretcher

I did use the W24512 in the much simpler breadboard system I threw together last week or so for the logic analyzer thread. (I called it "minimal," but it is clearly not as minimal as Bill's zero-glue system. ) That system seemed to work OK, but I'm honestly not sure how deeply I tested it. I may have never actually used the RAM... Your point is a good one, though; my plan for today is to isolate things. Disable the clock stretcher, tie A15 directly to the `139, and see what happens. I'm also suspicious that maybe the problem is mechanical again. I don't have any 32 pin "skinny" sockets, so I rolled my own with some machine pin headers. Maybe I got a bad strip? But before I start desoldering things, I'd like to check every less drastic possibility!



Actually, I have learned a lot this week. Although it's frustrating to be stuck on something that seems to be already "checked off," as it were, I've gotten much more comfortable with the LA and the decoder, which were totally new tools to me. I also got some crimpers and have been making my own Dupont cables. I've also been getting much better wire-wraps with the new spool and tool, and I think the soldering on this board is a lot better than Peanutbutter-1's. All in all, not so bad!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

Definite progress this afternoon!

First, even though I wanted to leave desoldering as a last resort, one of the little inserts in the machine pin strip just fell out when I pulled the RAM IC! So I desoldered those machine pin headers. Rather than do the same thing again - in case the whole batch of pin headers is bad - I cut up a 32 pin wide DIP socket to make a 32 pin narrow DIP socket. The back of the board looks much less pretty than it did... I am not so good at desoldering. But, the connections are all solid, and nothing is shorted!

Second, the reset line was still not as quiet as I would like, so I moved it to the opposite side of the board and redid the whole area around the prescaler. And the reset signal *STILL* wasn't great. I didn't understand it - Peanutbutter-1 has a really quiet reset. In fact, the whole board is really quiet. So I started probing and cutting wires. It turns out this is yet another cautionary tale about ground return paths!

I have in mind to eventually connect this main board to other boards with IDC cables using those right-angle pin headers that are along one edge. Following the advice in the Primer, those are 20 pin headers, with every other pin connected to ground, so that every signal will have a paired ground return signal. There's also a single row of pin headers connected to those right angle pins via the protoboard strips for wire wrapping the signals I want to export. I don't have all of them connected, but I have been using the middle connector of the three to attach the LA. From left to right the pins were (blue) D7..D0, RESET, Ø2. After cutting the RESET wire, I happened to probe the (now disconnected) RESET export pin by accident. Imagine my shock to discover Ø2 pulsing away on that pin! It was such a strong signal that I was sure I must have bridged those pins and was kicking myself for not checking continuity. But, in fact, when I disconnected the power and tested continuity with my multimeter, the pins WERE NOT connected! Fortunately, I now know all about how to manage problems like this from my breadboard adventures. That orange jumper wire is occupying the pin formerly occupied by RESET, and is connected to the prescaler's GND pin. All the noise instantly disappeared.

Anyway, with the reset line finally quiet and the RAM domiciled in a good set of pins, I finally have a functional board. It's not 100% yet though. After all of the above, I finally managed to do what I'd set out to do in the first place, which is de-activate the clock-stretcher and the bank register. With both those systems deactivated, the system (finally!) was able to successfully complete the RAM test without errors. I then reactivated the clock stretcher and tried a variety of oscillators. My 24MHz oscillator seems to be dead - - I don't remember toasting it, but I must have I guess. Anyway, Blue August passes the RAM test with a 20MHz oscillator (10MHz / 2.5MHz fast / slow Ø2s) but not with a 25.175MHz one. That's a little slower than I'd hoped, but still not too bad.

However, the banking strategy is simply not working. When I re-enabled it, the board freaked out again. I have made some kind of real mistake there, I guess, and will have to think it through again.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

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

Good for you, that’s because you are a better designer than I and you used to race car. 10, 12, even 15nS RAM are scary fast and I’m velocipede and old pickup kinda guy. My very first design using 10nS RAM will be here this week, it is a small board and a very simple design targeting 40Mhz 6502. I’ll first check out the concept with 25nS RAM and go from there.
Bill

Great news overall! Glad it worked out in the end, even without what you were wanting. Nice pictures too!



Good to know! I've been scared away

Chad

Chad,
You are not afraid to ask questions, have some design experiences, comfortable with making circuit changes, have good test instruments you trust, and now using CPLD that allows you to change/troubleshoot rapidly so perhaps you are ready to deal with 10nS RAM. So keep the board small, use power/ground planes, keep the data bus path short and direct, have a good memory diagnostic, and be very skeptical of what you see on your scope (it absolutely will lie to you). Maybe it'll be kind to you. Right now I'm approaching my first 10nS RAM very, very carefully.
Bill

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

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

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