Rebuilt a simple breadboard setup with address decoding based on Michael's diagram here viewtopic.php?f=12&t=6844&p=108973#p88176 and having a mysterious problem that I can't figure out. Writing this in the hope it might trigger some suggestions for how to debug.

The setup decodes RAM from $0000-bfff, an IO page at $c000-c0ff and ROM from $c100-ffff. I use Michael's clock-qualified read and write along with the /io flag to access ROM and RAM as shown in the diagram. The VIA is selected with the same /io flag and has registers mapped to A0-3 (so appear 16x in the $c1xx page). I have the 65c02 r/w connected directly to VIA's corresponding pin - afaik it handles the clock-qualified access?

I use the second half of the '139 like Michael shows so that A4-5 (not 6-7) generate four /iox signals. I use /io1 for lcd, /io2 for kbd shift register and /io3 for sd shift register (not wired yet). I also have a speaker set up on a portb pin which I can drive with a timer. /io0 is not connected so when I r/w to $c000-c00f I can manipulate VIA registers with no device active. For example with the LCD I set up portb control pins and porta data pins without enabling the device, and then BIT $c01x to enable the LCD while presenting the correct data and control values.

This all seems to work fine for several thousand instructions including initializing the LCD, clearing the screen and writing some text, but then at one point it returns from a JSR (which is called multiple times earlier) and unstacks $f11d after originally storing $f01d, so returns exactly a page beyond where intended. I have a simple monitor trace (below) where I can't see any other access to those stack locations. I've inspected memory at several intervening points and it seems like the stored value $f0 is correct until some time just before it reads the wrong value. My best guess is some kind of timing issue but can't understand why it happens in this repeatable way after so much other code runs correctly, nor any theory for how it gets that particular value wrong.

I've run the same binary image in a simulator without seeing the problem, so it doesn't appear to be a software issue. I've run various memory tests for data bus, addr bus including extensive use of the stack and recursive JSR and that all seems to be fine as well (code here viewtopic.php?f=4&t=144&p=109620#p109620 ).

Please lmk if you have any ideas on what else I could try.

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

I'd agree that it's probably a timing issue. Broadly, there are perhaps three flavours of data error, as opposed to address error
- a read error - the RAM contents is correct but the CPU got something different
- a write error - when the RAM was written the wrong value got written
- a misdirected write - some other write to RAM affected this location (possibly in addition to what it should have done

If you read up on decoding logic, you'll see the need to gate the RAM's write enable (or chip enable) until after the address, and preferably also the data, are stable. Conventionally, the system clock is used for that.

Because the address will change on the cycle after a write, it's important that the RAM is no longer trying to write at that point. In other words, the write enable (or chip enable) must be deasserted before the CPU (or any other logic) can affect the address bus.

What bus monitor are you using? It might be worth spending $12 or so to pick up an FX2 board and learning to use Hoglet's decoder. Among many nice things, one thing it does is number the bus cycles in a capture, which makes it a lot easier to talk about what's going on!

I've had similar problems with some of my builds, where it seems like things are generally working but there are intermittent glitches. They're frustrating to debug because they're repeatable (in the sense that the glitch happens the same way every time), but not reproducible (in the sense that you can't make it glitch on command by calling a specific subroutine or using a particular instruction). This usually seems to be noise related. How fast are you running this? Noise problems usually get worse if you go faster. Also what specific parts are you using? Some forum members have had similar head-bangingly frustrating problems with some specific RAM ICs. The conclusion was, I believe, that the RAM is internally a 3.3v part and the external interface wasn't quite adequate for a 5v system. I believe the thread was called "Strange Memory Write Problems." Meanwhile, I'd like to see a photo of your breadboards.

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

(Good point, a problem like this could be a noise problem: supply noise, ground bounce, crosstalk. A solid power supply, adequate decoupling, a good ground plane or grid, might be helpful if not already present. Overfast edges can be a problem too, so watch out for various logic families.)

Here's a current picture. I pulled out the arduino address and databus monitor cables for clarity, but left some of the individual pin jumpers.

I'm currently using 65c02-Tool for monitoring.

iirc I did buy an fx2 board for hoglet but haven't tried to use it yet - good excuse for the weekend!

I'm working on a simple schematic to add here later. One thing I noticed while sketching was (a) Michael's drawing says "untested" and (b) it's using the phi1 output for qualified read/write. I know the W65c02 datasheet says this is no longer spec'd/tested, so maybe it is lagging phi2 enough that it causes some problem when i'm accessing one of the IO chips immediately before/after RAM? I can try looking with the scope later on, and i guess an easy test would be to run phi2 thru a nand gate instead (isn't that what they'd do inside the chip h/w anyway tho??).

I've been running super slow for monitoring - you can see my beneater clock hooked up in the picture. So only a few Hz or even single step, but seems to behave similarly if I drive with a 1Mhz clock, so more likely edge-related thing I guess?

Specific parts:

WDC 65c02 and 6522
RAM: AS6C1008-55PCN - i have a16 wired high, i'll try pulling low instead to use the other half but I don't think it's a memory problem.
eeprom: AT28C256-15PU

demux - SN74LS139AN <= need to double-check but I might be mixing LS and HC here which is probably a bad idea
shift reg x 2 - SN74HC595N
comparator - SN74HC682N

also econoreset which is nice for clean startup once I had adequate over-current threshold on my power supply.

I think that's all the active parts currently.

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

Ah, if you qualify writes by a signal that's delayed relative to the CPU's activity, you may find you are still writing when the address lines change at the beginning of the next cycle. This could cause a stray write, or a RAM malfunction.

Schematic coming once I finish drawing it…

Here's a rough sketch of the schematic (gdocs source).

I did confirm the '139 is LS so will find an HC version to replace it on the weekend.

I doubt it. Michael's drawing says "untested," but many of them have been tested by me ( ) and they work great! I haven't built this particular one, because I don't have any `682s, but I have built several very similar ones using `688s.

Although the WDC docs do discourage folks from using the Ø1 output in new designs, one of the stated purposes for these chips is to keep vintage machines running by replacing their old dead CPUs. Those old designs often rely on the Ø1 output. As Garth says in the Primer, it's silly (especially for retro hobbyists!) to abandon a 50 year old time tested design just because WDC has stopped a production test. The transistors are still there.

That being said, there's a better way to get a symmetrical two-phase clock, which is use a double-speed oscillator and run it into a flip flop (such as half of a 74AHC 74). Use the Q output as Ø2 and the ~Q output as Ø1. Like this picture from the Primer:

Aha! That is the same series that other members have had trouble with. In the thread I mentioned it was a smaller capacity chip (the Alliance AS6C62256) but I wonders, I does. Do you have a RAM chip from a different manufacturer you could try switching out?

Yeah, unless you want to do a lot of thinking about what's driving what and adding strategic pullup resistors. Also, that `139 is doing a pretty important job. Ideally it would be a 74AHC (although HC will probably work fine at your 1MHz and slower speed).

Your wiring is beautifully tidy! I'm going to give you some suggestions. Unfortunately my "shop" is a wreck (thanks to being in the process of building an actual shop) so my electronics stuff isn't really available for photo demonstrations. I'll just have to try and describe verbally.

In the top, main part, of your system, you have power and ground rails running vertically. All the rails are connected together by horizontal rails at the top and the bottom, so your layout looks like a sideways ladder. That's good! However, there aren't enough horizontal connections between those vertical "rungs." Look at, for example, your `139. There's a short black jumper that connects its GND pin to the GND rail on its left side. You should add a longer black jumper that connects that same pin to the GND rail on its right side (where the two yellow wires are running). You should do that for every IC so that instead of it being like your chips are hanging off of a ladder, it's like they're living in a grid with a resolution of one "GND square" per IC.

The other thing is that your bus wiring generally runs horizontally, while your power wiring generally runs vertically. Ideally, wherever you have those horizontal arches of signal wires, there would also be arches of GND wires - one every other signal wire. That might not be practical, but you could try adding one or two GND arches per bus "bundle," especially to the ones that sort of "submerge" in the breadboard to go under some other signals and come out the other side. When I'm doing breadboard wiring I try as much as possible to have the signal wires running directly above the power rails. If they have to cross a breadboard I put a power rail there using jumpers.

Here's a picture of one of my projects: download/file.php?id=20708&mode=view If you look at all the little green jumper wires you can see how every IC has a row of them right next to its GND pin connecting the adjacent GND rails. If you look at the white signal bus wires right in the middle of the board you can see that right under them is a vertical row of green staples so that there is a GND path that directly tracks them.

Edit: One really important thing I meant to mention and forgot to include: your clock signal is REALLY long. Give it its own dedicated ground wire that runs right next to it over the breadboard surface, and where it's airborn make it into a twisted pair of CLK/GND. Your clock module only has ONE connection each of GND and VCC. Do the same thing to it as to the main part of your system (give every IC a connection to both GND rails) and then connect its top rail to the main system's bottom rail 4 or 5 times along its length (basically, wherever one of the ladder "rungs" connects to the bottom rail of the main system).

_________________
"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!

Here are a few more data points.

- Replacing the LS139 with an HC version made no difference. Fails the same way.

- I changed the .org of my ROM code from $f000 to $e111 to flip the parity of all the jsr addresses, with no other changes. The IO addresses remained in the same place in the $c0xx page. The failure mode is identical - it returns $100 beyond where it should, at the same call location. In the original case it read $f113 instead of $f013. With the modified org it read $e224 instead of $e124. See side-by-side traces attached

- trying to understand how it could be a software issue I sprinkled in some `lda $1ff` instructions so I'd see where the value changed. Here's a fragment of a trace where you can see the value morph. This is after successfully doing several jsr/rts involving the top-of-stack at $1ff, and passing my memory tests which heavily exercise the stack in a number ways.

It's as if somehow interactions with the VIA are affecting that memory location, but I'm having trouble imagining a scenario where the byte at $1ff magically increments when $ff doesn't appear on the LSB of the address bus at any intervening point.

Any other debugging ideas? I'll try to organize a PC with hoglet on the weekend. I'll probably also try some clock alternatives - all these tests are still clocked super slow, <1KHz. I'll also try to dig out a different memory chip - I think it's only 32Kb so will leave a hole from $8000-$bfff but I guess that doesn't matter for this purpose.

I've also attached the org .f000 listing if anyone wants to stare at it - it's a bit of mess as chop and change...

woohoo!

Dinosaur's suggestion of using symmetric Q, /Q outputs from a '74 flipflop halving the input clock (replacing the w65c02's phi1 output) seems to fix the problem, at least at for the sub-1khz speeds i'm experimenting with.

I also narrowed down where the phantom write happens (below). Surprisingly to me, read/write to IO page ($c0xx) doesn't seem to be implicated, but I guess phi1-qualified /mr and /mw signals are enough out of phase with the /phi2, /hi and /io signals that we still have the write enabled as the address bits change?

I find it odd that so much seems to work correctly before we get to this repeatable failure point but the hardware details are still very mysterious to me.

Is there a good tutorial that would help me understand the two write-cycle timing diagrams in the RAM datasheet https://www.alliancememory.com/wp-conte ... eb2007.pdf ? I haven't had enough practice to grok them on their own.

Progress!

I still suspect a noise issue of some kind. The W65C02's clock outputs don't lag the clock generator by enough to cause logic problems at your very slow speeds. But the W65C02 is fussy about edges (especially clock edges) at all speeds! Sometimes noise glitches like crosstalk happen at only very specific emergent combinations of conditions and can be really tough to pin down. Can you look at your clock and address lines on a scope? Now that you have a potentially working configuration you could do a before/after comparison.

Jeff's excellent timing diagrams here might help: viewtopic.php?f=4&t=2909
One of Ben Eater's "Build a 6502 Computer" videos also has a discussion of RAM timings: https://www.youtube.com/watch?v=i_wrxBdXTgM
I've learned a lot from threads like this one: viewtopic.php?f=4&t=5180
I also *really* like this article from an old magazine: https://www.atarimagazines.com/computei ... /page9.php Of course, it's talking about the old NMOS6502, but many of the principles are unchanged.

None of these will precisely explain the memory timing diagrams you're talking about, but once you get comfortable with the 6502 timing diagrams, the memory ones aren't that much of a challenge.

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