This is the RAM base board of VGAxRAM. The DIP RAM is standard 32-pin 128kX8 RAM while the SMT is CY7C109. I made the pad fingers as long as possible to help with manual soldering. It is two layer board with most traces on top. The bottom layer is ground fill plus remaining 4 signals. Bottom layer is a pretty good ground plane. I have successfully used this board many times replacing slower DIP with faster 25nS CY7C109.

Later I added a CPLD (EPM7064S) to the RAM baseboard (RAMxVGAxPS2), then I had no choice but making it 4-layer PC board.
Bill

Edit, replace the color gerber with B&W.

Found the problem. D7. The the pin from the adapter into the PCB socket on the board seems to have picked up a dark coating which was introducing resistance, reducing high signals to/from the RAM IC to barely anything. On the scope it kind of looked like severe bus contention. Cleaned the pin with some IPA and, so far, it's been fine at 128KHz. Will do full testing this evening as am on lunch at the moment. Can't find that coating anywhere else on the main board/adapter.

Thanks for all of your suggestions & input on this .

Apologies for the slight focusing issue:

Hi Bill
Thanks for posting that and good to know that your one works. As you can see above, I found the culprit. One lesson I will take away from this is to not be pin for pin match pefect in the future as others have said and you've demonstrated.

Tested at 8MHz and still working, so that's it. Now to test the wait state stuff

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

Tested at 16MHz. RAM accesed successfully at 16MHz, ROM at 8MHz (Had to wait for 32MHz oscillators to arrive, hence the delay).

[edit] See below

ROM access - PHI2 clock



ROM access - GLCK (Global) clock (wave form blurriness down to display update when photo taken, not wave form)



Brief RAM access - PHI2 clock




Next up: Full implementation of paging and the MR (memory register) in the CPLD.

MR:

It's a little unstable at 16MHz. The SRAM is a AS7C4096A-15JIN, so should be good up to about 32MHz PHI2, so this might be a limit imposed by the CPLD and the address decoding.
The CPLD is a 7ns ATF1508AS, but the address decoding does take into account A19 down to A8 and some registers, so although it's macrocell to macrocell (so much quicker), it's still going to slow things down.. The other possibility is that it's a bit much for the 65C02S as that's 14MHz rated, but I've never had a problem before with them at 16MHz.

I'll look at writing a test CPLD design which simplifies the decoding and we'll see if that improves things. If it does, then I'll have to make a decision about going for 16MHz and reducing the address capabilities - or dig out a 24MHz crystal and see if it's happier with that (i.e. 12MHz).

One final possibility is that I added 100 ohm resistors to the clock sources and these are causing problems. These values might be too much and maybe I need to reduce those down. It's difficult to see the wave form accurately, as my scope is Rigol DS1102E 100MHz using x10 probes, which (if I understand this correctly) is going to give distortion above 10MHz. The wave forms can be seen in the post above - see the GCLK one.

It is quite possible the size of your board and number of parts is preventing it from running much higher than 16-20MHz. Simplification of design is really important for overclocking purpose. I'm using 25nS RAM and 10nS CPLD (EPM7128S) and I can achieve 30+ MHz operation, but the design is dead simple and fit on 50x100mm board or smaller. If I plug the overclocked 50x100mm board into a backplane to drive other boards, then its top speed dropped down to 25MHz or even lower, depending on loading.
Bill

16MHz doesn't seem over-ambitious for a system with a 15ns RAM and 7ns CPLD. You've got 62.5ns total cycle time. It takes around 12ns for the processor to output the address at the beginning of the bus cycle (I seem to remember someone on here measured this, plus it's consistent with maximum speeds people have had systems running it). It takes 15ns for the RAM to output data, and you need the data to be valid 10ns before the end of the cycle (falling clock edge). That gives a total of 37ns, so you have 25ns spare for address decoding and propagation through the CPLD, which seems plenty.
How does the instability manifest? Does it occur if you're only accessing RAM or does it only occur if you're using ROM? If the latter it could be a problem with your wait state generator. Otherwise it could be a signal integrity issue. Typical CPLDs driving a W65C02 will have reduced noise margin because they output TTL compatible logic levels whereas the W65C02 has a logic threshold around 0.5*Vcc. Also, the clock rise and fall times need to be fast (5ns or less).

Seems D0, D1, A6, A7 have what looks like bus contention and it happens at 1.5, 8, 10, 16MHz - basically any speed I test at. Happens with DIP and also the adapter SRAM. The only other things on the bus: 65C02, ATF1508AS CPLD, SST39SF010 Flash ROM

This is D0:



I've removed all bus-connected devices and cannot find any adjacent bus traces which aren't open circuit between them.

Removed the RAM and ran from ROM: No issues. I think I have a timing issue from the CPLD.

[edit]: Not the WSE / Wait state.

[edit2[: Yep, is CPLD. I removed all the banking and registers and now I have no contention.

It's odd that you're getting contention on A6 and A7. Nothing should be driving the address bus except the CPU.
How are you programming the CPLD? Are you using WinCUPL or are you using Quartus + POF2JED? If the latter, I had problems with that - it didn't always program the CPLD correctly. If I used an EPM7128 and programmed it with the POF file, it worked, but the JED file out of POF2JED programmed into an ATF1508 didn't do the same thing.

I'm programming the CPLD via a dedicated onbaord JTAG header using an ATDH1150USB-K and WinCUPL.
A6 is connected to pin6, A7 to pin 77. Both are dedicated I/O pins with no additional CPLD functions. Also checked for double assignments and anthing driving them in the code, but all is fine.

I set up a simple program that writes ascii 77 to RAM location $5000, runs through 750 NOPs, reads $5000, sends the result to the Octal latch leading to the LEDs, runs through another 750 NOPs and loops.
It works and I can see the 01001101 binrary bit pattern on the LEDs. D0 & 1 remain OK, but A6 and A7 are doing this:

A6:


A7:

Yes, they sure look like contentions. Don’t know how CUPL works but in Quartus I need to assign pins number to A6, A7 and draw input pins for A6, A7 even if they are not connected to anything internally. Otherwise Quartus fitter may assign internal functions to these pins.
Bill

After spending quite a while bit-by-bit reducing my CPLD design to almost nothing, the issue still existed. I then unplugged my Bus Monitor and the issue disappeared... Argh.
I did this before when checking D0 and D1 (it made no difference), but at the time I didn't know about A6 and A7 being a problem as well...
I think I'll go to bed.

[edit] Presently running at 16MHz without issue with full CPLD design. Need to do further testing.
The bus monitor simply uses a microcontroller which switches between 74HC245's (one for address bus LSB, one for MSB, on data bus), sampling the data. They are wired in one direction only.
So it's puzzling and I've not had this before with other projects. I wonder if capacitance could also do that as the ribbon cables add an extra 2.5 inches to the buses?