6502 project

[akohlbecker]

drogon wrote:

I never had a properly working system when I was trying to drive Rdy to stop the CPU. I did start a thread or 2 here about it too, but while it seems it should work it didn't for me, so I'm really keen to see your ideas - if it works.

see e.g. viewtopic.php?f=4&t=6743&hilit=rdy

In my systems it was to establish a communications method between the ATmega and the 6502/816. I resorted to a slightly different tact in that the ATmega MCU would never stop the 6502/816 CPU but the CPU would execute WAI causing it to stop at which point the MCU which was monitoring the Rdy line on an input pin would 'wake up', /BE the CPU, do a data transfer, un-BE it, then send it an interrupt to get it to carry on.

There are (were) issues with interrupts but I solved that in external logic. (inside a GAL)

Looking forward to seeing your systems using Rdy - hope it works well.

-Gordon

That is quite curious. I'm using RDY with Ben Eater's VGA card kit to stop the CPU during the display phase, and it is working properly. The card is asserting/de-asserting RDY and BE at the same time (they are connected together) on the falling edge of the CPU clock. Not sure what's going on with your circuit

TIming wise, I think it works because when RDY and BE are brought low the CPU stays in the data transfer state after the cycle finishes, so we don't care about delaying BE, then when they are brought high, there is a full cycle with BE high until the CPU registers RDY being high, so it is able to finish what it was doing.

[akohlbecker]

In other news, PCBs arrived today! Just in time for some week-end soldering.

[Dr Jefyll]

akohlbecker wrote:

That is quite curious. I'm using RDY with Ben Eater's VGA card kit to stop the CPU during the display phase, and it is working properly. The card is asserting/de-asserting RDY and BE at the same time (they are connected together) on the falling edge of the CPU clock.

A careful look at the datasheet reveals there's a fairly wide timing window (relative to the 65xx CPU clock) during which it's safe to change the state of RDY. But there's also a comparatively brief interval (defined by tPCS and tPCH) during which RDY must remain stable -- either high or low, but not in transition. More on that in this post.

As I recall, Gordon's unsuccessful experiment drove the RDY pin with a signal derived from a separate processor that used a separate clock source. The independent clock source introduces a random element, making it possible that RDY may change at any time within the 65xx clock cycle. This means that tPCS and tPCH would occasionally get violated, with the accompanying risk that the processor will go off into the weeds.

Your own project does not involve a separate clock, so that random element is absent. RDY always changes state at a certain time within the 65xx cycle, and apparently the circuit you've chosen is such that tPCS and tPCH requirements are met.

PS- Congrats on the PCB's!

-- Jeff

[akohlbecker]

Dr Jefyll wrote:

Your own project does not involve a separate clock, so that random element is absent. RDY always changes state at a certain time within the 65xx cycle, and apparently the circuit you've chosen is such that tPCS and tPCH requirements are met.

PS- Congrats on the PCB's!

-- Jeff

Looks that way. Thanks

[akohlbecker]

UPDATE: It's alive! I had it soldered for a few days but it didn't work on the first try. Had to spend some time troubleshooting, but it turned out to be a software issue and not hardware.

Code: Select all

X.oe

in WinCUPL is active high, not active low... Once that was fixed, it booted up like a charm.

I need to wire my keyboard module and LCD properly, and test it with my VGA card next. Pretty happy with the results!

[AndrewP]

Looking good!