Project: semi-fail - suggestions please

[hoglet]

I've just had a quick look at your schematic.

In my experience, RAM timing issues can cause some very weird failure modes.

As mentioned earlier by BDD, on the W65C02 it's recommended not to use Phi2O (pin 39), as Phi2 (pin 37) is the main timing reference.

By using PHI2O in your GAL to gate the RAM write-enable signal, the RAM write actually happens later than is ideal.

Edit: One other thing I spotted is that the RAM CS signal is tied low. Isn't the effect of this that I/O writes will also write to the RAM? This seems wrong.

Dave

[LIV2]

hoglet wrote:

I've just had a quick look at your schematic.
Edit: One other thing I spotted is that the RAM CS signal is tied low. Isn't the effect of this that I/O writes will also write to the RAM? This seems wrong.

Yeah that's definitely not good. looking at his CUPL for the GAL you're right it'd be writing to RAM whenever writing to IO space

Code: Select all

/* Intermediate values */
a = A15 & A14;
b = A10 & A11 & A12 & A13 & A14;


/* Output definitions */
RD = !RW;
RAM_WR = !(Phi2 & !RW);
RAM_CE = A15 # b;
ROM_CE = !A15;
IO_CE = A15 # !b;

Presumably you could modify the RAM_WR to assert only when the RAM is selected which would mean not having to solder on some bodge wires etc

[GaBuZoMeu]

Perhaps my eyes are ricking me - tracking R/W down it is grounded or say connected to p12 of the GAL. This could never work. I'm sure R/W is meant to be connected to p14 or p23 of that GAL - correct?

[BigDumbDinosaur]

Could you please post a memory map for your machine?

[BigEd]

hoglet wrote:

This related thread was also quite interesting. On an Acorn Atom the 60Hz VSYNC signal is asynchronous to the 6502 clock. It's possible to write a program that will fail after maybe an hour due to metastability propagating through the 8255 and on to the 6502.
http://www.stardot.org.uk/forums/viewto ... 9&p=200632

Indeed, that was extremely interesting: the 6502 was following an 'impossible' program flow, probably because the C bit being set by a ADC instruction was not happening, even when the top bit of the result was coming out right. As shown in your image, the data as seen by the 6502 was, sometimes, not even a valid digital level. The same thing could happen on-chip if setup times were violated, and possibly also for hold times. Many many instructions work perfectly, but one case didn't.

[BillO]

hoglet wrote:

I've just had a quick look at your schematic.

In my experience, RAM timing issues can cause some very weird failure modes.

As mentioned earlier by BDD, on the W65C02 it's recommended not to use Phi2O (pin 39), as Phi2 (pin 37) is the main timing reference.

By using PHI2O in your GAL to gate the RAM write-enable signal, the RAM write actually happens later than is ideal.

Edit: One other thing I spotted is that the RAM CS signal is tied low. Isn't the effect of this that I/O writes will also write to the RAM? This seems wrong.

Dave

Phi-2 is now coming off the oscillator (pin 37)

It will write to RAM, but in an area that is not used (shadowed by the I/O).

I think we need to keep in mind this works just fine with an R65C02 or with an NMOS CPU. No issues at all. The problems are only seen with the WDC part.

[BillO]

GaBuZoMeu wrote:

Perhaps my eyes are ricking me - tracking R/W down it is grounded or say connected to p12 of the GAL. This could never work. I'm sure R/W is meant to be connected to p14 or p23 of that GAL - correct?

?

R/W from the cpu goes in to pin 11 of the GAL , Phi-2 in on pin 10 and the Phi-2 qualified R/W is output on pin 16.

Pins 13, 14 and 23 are unused inputs and are tied to ground.

[BillO]

BigDumbDinosaur wrote:

Could you please post a memory map for your machine?

Simplified (hardware) memory map is:

0000 - 7BFF RAM
7C00 - 7FFF I/O
8000 - BFFF Bank switched ROM
C000 - FFFF ROM (ACIA monitor and EhBASIC)

Things done so far:

System Phi-2 now connected to pin 37 - pin 39 floating
NMI, IRQ and SO tied to Vcc, RDY and Reset held high trough 3K resistors
RAM /CE and /OE tied together (although this should not be needed).

Behavior has changed, but it's still not working with the WDC chip. Before, as I said I'd see toggling on the VP line before it went dead - so I presume there were glitches happening on the IRQ or NMI lines. Now there is only a single pulse in VP when reset occurs as it should be. There is no activity on the RDY line and it is no longer stopping dead. Instead it begins the memory test, runs for a few cycles and then goes back to the "Memory size ?" prompt. Entering anything there it will still just go back to that prompt. This behavior is consistent all the way out to 14mHz.

[GaBuZoMeu]

Sorry for my last post. Seems that I was tricked somehow

I have not try to get the source fpr EhBasic, if it scans memory similar to M$Basic it might get puzzled by the I/O circuitry. Would it work if you simply enter a valid size?

Cheers

[BigEd]

BillO wrote:

...There is no activity on the RDY line and it is no longer stopping dead. Instead it begins the memory test, runs for a few cycles and then goes back to the "Memory size ?" prompt. Entering anything there it will still just go back to that prompt. This behavior is consistent all the way out to 14mHz.

I suppose then that you see Sync is still active, throughout, as the machine hasn't crashed? It does sound rather like our problem. Perhaps, having now clocked everything with the same input clock, it's worth adding a buffer ahead of the CPU so it gets a very slightly delayed clock - the problem with the fast parts being that they are too fast.

[BillO]

GaBuZoMeu wrote:

Sorry for my last post. Seems that I was tricked somehow

I have not try to get the source fpr EhBasic, if it scans memory similar to M$Basic it might get puzzled by the I/O circuitry. Would it work if you simply enter a valid size?

Cheers

No. Same exact behavior - unfortunately.

[BillO]

BigEd wrote:

BillO wrote:

...There is no activity on the RDY line and it is no longer stopping dead. Instead it begins the memory test, runs for a few cycles and then goes back to the "Memory size ?" prompt. Entering anything there it will still just go back to that prompt. This behavior is consistent all the way out to 14mHz.

I suppose then that you see Sync is still active, throughout, as the machine hasn't crashed? It does sound rather like our problem. Perhaps, having now clocked everything with the same input clock, it's worth adding a buffer ahead of the CPU so it gets a very slightly delayed clock - the problem with the fast parts being that they are too fast.

Yes, SYNC is now active all the time. I could use the buffered Phi-2 signal I send out on the I/O bus for a quick test that woudl give me about 9 or 10 nS delay.

Interesting this is, just a while back as I was putting a 10x scope probe on the RDY signal, it started working fine as long as I had the probe on RDY. For a few minutes - now I can't reproduce the effect. This was before I had changed the resistor on RDY from 10K to 3K. However, at least now the machine is running and not dying. I feel progress has been made.

Update:
Holy cr#p! That worked!!! Delaying the clock to the W65C02 by a few nS has done the trick!!! It is now cruising along at a comfy 15mHz without a hiccup.

Awesome!

Thanks Ed - and to everyone else for pitching in on this one.

So it looks like these 15nS RAM chips are too fast?

[GaBuZoMeu]

First of all - congratulation!

Hmm, this is a bit puzzling - you now use the crystal clock directly for everything but the CPU and the CPU requires a brief delayed clock (say one or two buffer delays) ???

Indeed strange - and not very comfortable, as you cannot switch between various CPUs by simply plugging. Somehow unpleasant.

[BigEd]

That's a good result! I think - I hope - with a suitable diagram of the glue logic and the timing, it'll be more clear what went wrong. I suppose it could be that 15ns RAMs are not really compatible with the timing constraints of the CPU, but it could equally well be that reconfigured glue logic would sort the problem out more conventionally than a delayed CPU clock.

[BillO]

BigEd wrote:

That's a good result! I think - I hope - with a suitable diagram of the glue logic and the timing, it'll be more clear what went wrong. I suppose it could be that 15ns RAMs are not really compatible with the timing constraints of the CPU, but it could equally well be that reconfigured glue logic would sort the problem out more conventionally than a delayed CPU clock.

The only glue logic between the CPU and memory is the GAL. The one in there now is rated at 15nS, but I do have one at 7nS that I could try.

Just as an aside, the bodged clock timing works with both the R65C02 and the NMOS 6502's at their rated speed.


Update: No, The 7nS GAL still needs the clock bodge.