I'm banging my head against the wall here.

I had a working system spread across pcbs and bread boards (the WOPRjr from a previous thread) fully functional and stable.

I finally had a final PCB made. 4 layer, dedicated power and ground planes. Assuming proper layout, it should be even more stable than the previous ratsnest.

It crashes. Using a spectrum analyzer, I've determined it crashes consistently at the same spot. My code goes 3 JSRs deep, and finds its way back until the last RTS. stack location 0x01FF should read 0x82 for this final RTS. instead, it reads 0x88. As one would expect, my processor is completely lost at this point.

Using the spectrum analyzer, I followed code execution, and wrote every stack operation down. Both Pushes and pulls in the code and manipulation due to JSR/RTS.

As far as I can tell, everything is kosher until that final RTS, during which the wrong value is read from the top of the stack. According to the analyzer, the correct value was indeed pushed to 0x01FF during the first JSR. I tried to find any unexpected writes to 0x01FF, and couldn't, but my HP1670E analyzers triggering routines are semi-confusing, so I may have failed to see everything. I can't find anything in my code that messes with the stack, either via stack opcodes, or unintentional code errors.

One thing that possibly suggests that its a signal integrity thing is that reads on the data bus are about half a volt low when HIGH. I built up 2 boards, and both have the same issue. I have tried switching CPUs, ram chips, and ROM chips.

My next plan is to write a memory check routine as a way to check the entire bus.

Any ideas?

EDIT: The whole thing is running off a single 7805 reg, fed by my bench power supply at 9 volts. In addition to the computer, my video circuitry which consists of maybe 25 or so 74HC logic chips, a dual ported RAM chip and a 25.175 MHz XOC is on the board. Previously, the video circuitry had its own reg. The entire board draws about 200 mA. Other than the data bus being low on writes, all my signals look fine.

I hate to ask, but is the WE# to RAM qualified with Phi2? It's the first question where there's seemingly memory corruption. Nice if you could share a schematic, BTW.

You mean a logic high is 4.5 volts? That's not anything to worry about.

-- Jeff

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

WE and OE are both qualified with PH2. Both are constrained to only happen on PH2 HIGH.

I know that all things being equal, 4.5 HIGHs isn't a big deal, but I thought it could be a clue to the actual trouble.

I can post my Schematic, but I should warn you, its numerous KICAD sheets. Not even sure the best way to do it. Individual screenshots on this thread maybe?

Here's what I suspect are the relevant sheets (I believe anyway) from the schematic. First sheet is CPU RAM ROM, and some other stuff. Second sheet is the address decoding. Again, this was stable on some really janky breadboards before I did the PCB. Also of note, the problem persists if I remove the UART, and a 6522 and dual port RAM chip that are on different sheets (and I don't attempt to address them in the code).

Addressing scheme seems to work. I can get pretty far into the code before things go awry. I can initialize all the various memory buffers my kernal uses, clear my video buffer in RAM, and update the actual video RAM from that buffer. Lot of deep multi nested loops, reads and writes all over RAM,, and as mentioned, a few layers of JSRs deep. Only have trouble when the very top of the stack reads wrong on the last RTS.

New development. Its a complete hack, and I haven't truly figured out the problem, but I have a running system now.

All I did was a PHA before I do any other stack stuff. Since it was only having a problem with the top of the stack (0x01FF), I just moved the pointer a byte lower.

So I still don't know whats specifically wrong.

I still have some sort of bug involving the MCU that handles the keyboard, so until I fix that, I can't use my monitor routines to mess with memory locations, but that shouldn't be difficult. It worked before, right (just like my stack routines... )

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

Did you socket your SRAM? Do you have a spare IDT71256 to swap in?

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

The other thing about accessing 01FF is that there are lots of 1s in the address. So you might be seeing a signal integrity problem, perhaps ground bounce. Look at your decoupling, and your power supply distribution. (A logic analyser wouldn't be expected to pick up this kind of thing. Unless perhaps it's a super expensive one.)

Are you using a Western Design W65C02?

If so, then it's possibly worth changing where you pickup PH2 from.

Try using pin 37 (PHI2) rather than pin 39 (PHI2O).

With some SRAM types, the extra (unspecificed) delay of PHI2O can cause hold time violations, resulting in very wierd behavour like you are seeing. These problems could be worse on your multi-layer PCB because the data and address buses may be changing slightly sooner than on the physically larger prototype.

There are a few other threads discussing this issue:
- http://forum.6502.org/viewtopic.php?f=4&t=6700&hilit=phi2o
- When should Φ2 be used over Φ0? (Or: Φ0 vs. Φ2 vs. RWB)

You could try this by bending out pin 39 of the W65C02, then linking pins 37 and 39 of the socket.

Dave

Dan, you already have some very good suggestions from others. But here's a thought, and it's rather an odd one.

I'd be curious to try increasing the number of PHAs to a total of 2, then to a total of 4, then 8, then 16...

I have a hunch that one of these numbers may cause the problem to return. And that number would be a clue. For example, if it fails with 8 PHAs inserted (and we already know it fails with 0 PHAs inserted) then that suggests a problem with address line A3. (If you have a 'scope then that'd be a much easier way to check the address lines.)

And in fact I was already wondering about address lines. I had the notion one of them may be shorted to another, or to some other signal. It fits the scenario, because you have a previously successful design that failed to migrate to PCB. IOW, it's very likely a problem with the "build" (rather than the schematic per se).

-- Jeff

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

New clue: when text is displayed, sometimes portions are duplicated on other parts of the screen. Always in a consistent pattern.

This suggests I'm writing to more than one location in RAM simultaneously. To me this would suggest a timing issue, except it's so consistent. Not random at all. Maybe an address line that is badly soldered, or shorted to its neighbor that is bouncing around?

When I get home from work, I'll compare the memory location of correctly displayed text with it's evil twin to see which bit would have to flip to make this happen.

Writing to more than one location is possible if the address changes while both /CS and /WE are low.

But it is also possible that you're reading one memory location for two different addresses. An unconnected address line, or two shorted together, would both do that.

Nine address lines high could be a problem. I think someone had a similar problem where all writes worked except eight data lines high. It is hugely annoying to have a system which can write every value except $FF.

If a stack value switches from $82 to $88, I assume software problem. Did you make *any* changes to software? Is there any path where stack may be mis-aligned with, for example, extra/missing PHA/PLA/PHP/PLP? Does a software stack in page $02 underflow? Does stack introspection occur? For example, detecting break flag or clearing a carry flag?

Flag register $88 is negative flag set and decimal mode set. Does an interrupt occur during decimal calculation? That causes all kinds of chaos.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

I notice you’re qualifying with PH2 instead of clock. Put that together with the weak pull up strength I’m thinking you might actually be using NMOS 6502’s? If they’re not from a reputable source I would test with a BRA instruction if they’re supposed to be cmos.
I had that exact issue last week so maybe I’m just seeing it everywhere. viewtopic.php?f=4&t=7053

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1

Well, I had exactly (I mean exactly) this problem, only 2 days ago. The first byte was pushed to the stack along with it's mate during the first JSR. Several further return addresses were subsequently pushed and all successfully retrieved with RTSs except for the very first byte pushed, which was returned with a bit set wrongly. This caused a spectacular jump into the middle of an instruction.

I read somewhere, Garth's primer I think, about ground return paths on breadboard. I put several more power and ground connections between my breadboards and bingo, fixed.

Now, I know you are on PCB but your issue is so identical to mine that I had to post.