Troubleshooting 65816 ROM/RAM, Part 2

Earlier this month, I posted Troubleshooting 65816 ROM/RAM. I have updated that posting as I have had updates. Unfortunately, I have not been able to make much progress. I am unable to get ROM (and then RAM) to work properly.

Symptom: If I manually set the RAM's CS# line high and the ROM's CS# line low, ROM reads work fine. If I try to manage the CS# line based on address decoding -- whether directly with the A15 address line or through decode logic in a PLD -- I am unable to get the ROM to read. For the times where I have gotten the ROM to read, RAM reads of (attempted) written data, return $FF.

At one point, I was able to get this to work, as seen in the following video. I must have gotten lucky, because I have not been able to reproduce the results; it worked one day and failed the next day when I turned the system back on (with no configuration changes).

Schematic (updated schematic later in post):

Using the above schematic, I get results as seen in the following video. Note: I see that the clock line got disconnected before recording. The clock does work. :)

I have been referencing Western Design Center's W65C816SXB schematic. I have also been watching Adrien Kohlbecker's video series. I believe there's a high probability that this is a timing issue, but for the life of me, I cannot pin down the issue. I have tried adding delays in numerous locations (e.g., on the '245 OEB, on the ROM/RAM CE#), and varying the duration of the delays. I am running a slow clock at this point (<10 Hz).

I have reviewed the supported signal levels for my ICs, and I believe I should be OK. The ICs used in the schematic above:

• The clock is coming from an SN74AHC74N.

• The processor is a W65C816S6TPG-14.

• For bank address latching, I am using SN74ACT245PC and CD74AC573E ICs.

• I am qualifying MEMOEB and MEMWEB with the CLK using an SN74AHC00N. I have tried qualifying OEB_RAM and OEM_ROM with the CLK also.

• The Flash ROM is an SST39SF040-70-4C-PHE. I also tried a AT28HC256-70PI.

• The RAM is a 71256SA15. I also tried an AS6C4008 and an AS7C1024B.

• The PLD is a GAL22V10D-15LP. I also tried using an EEPROM for the decode logic. I also tried using A15 and A15# directly.

I have replaced all ICs. I have seen the same issue on the breadboard, solderable breadboard, and PCB versions.

Watching Adrien's videos, I realize there will be more optimization required for timing, but I would think what I have so far would at least run with a slow clock.

Suggestions? I'd be grateful for any pointers. Thank you!

Additional Details Based on Questions and Suggestions

My current PCB:

PCB routing:

GAL setup:

To Do

I have been receiving many suggestions for things to try. Thanks, everyone! Now on my near-term to do list:

1. Read through some online resources.

   1. Timing Diagrams. Visualizing 65xx CPU Timing. (laughtonelectronics.com)

   2. 6502 Primer index (wilsonminesco.com)

   3. 6502.org • View topic - Managing the 65816 multiplexed bus

2. Incorporate VDA and VPA into my address decoding logic.

3. Qualify RAM WE# with PHI2. [Temporarily, removed RAM]

4. [DONE] Switch back to HC chips.

5. [DONE] Improve VCC and GND connections (bodge wire on PCB).

6. Possibly, try slower RAM.

7. Smaller item: swap my reset circuit's 1K pull-up resistor with a 3.3K.

Updates

To reduce the number of variables, I have removed the RAM and GAL. I am decoding for the ROM enable with A15#. I have changed back to the HC family of ICs. I have also added bodge wire to the back of the PCB for all VCC and GND connections for the ICs being used as part of the core 65816.

I am getting the same results. If I keep the ROM CS# connected to GND, reading ROM seems to be fine. If I try to drive ROM off A15#, reads are not working.

Updated schematic:

Video showing what I am seeing on my logic analyzer and Arduino logging:

Resolved!

After sharing my challenges on the 6502.org forum in this thread, I received many great suggestions for troubleshooting the issue. Ultimately, the assembly code I was using to test the setup was missing a reset vector. Thank you to Adrien Kohlbecker and all the great community members at 6502.org for the help! If you are not familiar with that forum and are working on 6502, 65816, or related technology, check it out. As a reminder, Adrien has a video series on the 65816 available on his YouTube channel.

As far as the assembly code, I updated it as follows.

My debug output (with RAM reinstalled in the circuit) now looks like this:

Finally... Moving On

I have learned a great deal through this troubleshooting process, and I am grateful to everyone who has helped along the way. Thank you! I can now return to building my system. Next: extended RAM and basic I/O with a VIA.