I don't believe you understand just how RDY (more specifically, the internal circuits in the 'C02 that are attached to RDY) works. It is a CMOS input and like any other CMOS input, cannot be floated. The 'C02 only drives RDY low when a WAI instruction has been executed—RDY will not be driven high when the 'C02 restarts following a hardware interrupt. Therefore, a pullup resistor is not an option, which is explained on page 30 of the 'C02 data sheet.

You can use a higher value than 3.3K, but be aware that going too high will make RDY more sensitive to noise and could expose your system to random false wait-states. I have not experimented with values higher than 3.3K, but do know that back when WDC was incorporating a RDY pullup into the 'C02 (this was before die production was moved to the TSMC foundry) the value was 10K, which would draw 0.5mA during a WAIt.

If you are truly paranoid about quiescent system current consumption while the 'C02 is stopped, use the STP instruction, which does not affect RDY and completely puts the MPU to sleep until a reset occurs.

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

I'm taking the signal to pull RDY high again straight from the /IRQ, /NMI and /RST inputs, which are generated externally to the CPU. This might delay RDY by one clock cycle - that is all.

Understand this: there is no diode in my circuit. There is a gate driving RDY, either high or low, through a resistor - so RDY is not floated. There is an XOR gate connected across the resistor, to detect when the CPU pulls RDY low when the gate is not driving it there. RDY is automatically pulled high again when a wakeup signal arrives, allowing the CPU to resume. All of that is in the diagram posted above.

Now, I understand I'm pursuing a relatively high-complexity design here - though since I haven't described much of the project yet, you might not understand the rationale. That's fine, since I also know about unit-testing. I can prototype each subsystem and check its behaviour at low speed before committing to a PCB build. Some of the subsystems can live on separate daughterboards for modularity, and be reused or duplicated in later versions of the design.

There will be an awful lot of software to write, too - but I want to have a good idea of what the hardware looks like before I embark on that odyssey. Software is something I *know* I can do; hardware is where my skills are less proven, but I *am* doing my homework.

What I think BDD is saying is that the 'C02 does not drive that pin unless a WAI is executed.
Therefore there will be little or no current through that resistor unless the 'C02 executes a WAI(since this is a CMOS input, it draws virtually no current).
If you never use that instruction(there's not much reason to, outside of testing), then the current is never drawn and there is no wastage.

This is probably outside the scope of your problem (if you don't want any kind of external chip programmer), but one of the ideas I came across is to use a CPLD as a boot ROM. I wrote one up in Verilog but never tested the hardware. It's workable even in the smallest 32 macrocell CPLDs, as it mostly uses "product terms" which seem to be plentiful. In my case, I had a boot ROM and SPI controller in the CPLD. The CPU would boot into it, read the first 256 bytes from SPI memory into zeropage, then JMP $0000 continues the loading process from there. Could be handy maybe if you already wanted programmable logic in the design anyways.

I'm perfectly aware of WAI's behaviour in that respect, and have in fact mentioned it at least twice in this thread already. The problem is *precisely* that WAI causes that power dissipation in the resistor, when I want to use it to *save* power.

So there are good reasons not only to use WAI, but to detect externally when it has been used, in a battery-powered device.

Without WAI, the CPU must be put into a tight polling loop when idle, even if input is signalled by IRQ. In such a loop, the CPU is constantly fetching instructions from RAM or ROM. This means that memory chip is selected and drawing active power (milliamps) instead of standby power (microamps). Likewise for the CPU itself and the glue logic which is constantly seeing transitions on address, data and control lines.

With WAI in effect, the CPU halts. The 6502 has no native way to indicate that it's making no active fetches (the 65816 does), but that XOR-gate arrangement can detect that WAI is in effect, and gate off the /CE signals - it just needs NAND gates to be one input wider, or the use of one of the spare selectors on a more complex decoder chip if that's in use ('138, '47). It's not necessary to negate BE, I think, since the address and control lines will be held stable by the CPU and the data lines will be tristated anyway. (Question: does the WDC chip have "bus keeper" circuits on the data lines, or do I need to put very weak pull-downs on them to stop them floating around?)

For extra credit, the WAI detection could also be used to switch over to a slow clock (to save more dynamic power caused solely by Phi2 transitions), such as the low-power (microamp) 32kHz oscillator attached to an RTC chip, and power down the main (milliamps) CPU clock oscillator. The latter would take a millisecond or so to come back up when required, so the logic associated with that might be challenging. Or the clock switching could be under software control, so that WAI can still be used for ultra-low-latency interrupt service with minor power savings.

None of this, of course, would be of concern to a basic computer that's always run off mains power. The total power involved from all sources would be well under one watt. So my first prototype might lose some of this logic in the name of simplicity, but it's still interesting for me to work it all out and see what the ramifications are.

Not so! Just where are you getting this information?

Please take a look at the STP instruction, which completely stops all activity in the MPU, reducing current consumption to a few microamperes. The fact that the 65C02 has the ability to go catatonic in response to an instruction and reduce its current consumption to such a low level is why it is used in implantable medical devices.

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

Sure, but the only way to get out of STP state is to assert /RST. I'm not quite comfortable with that.

Also, I still have the problem of inactivating the external devices. Without the RDY signal, just how do I do that?

Write a signature somewhere in (static) RAM that indicates that the cold reset procedure has been carried out. Subsequently, when reset is asserted, examine that location for the signature and if it is present, skip the cold reset and resume somewhere else. This arrangement is possible because SRAM always powers up with random garbage in it. The likelihood of SRAM powering up with your signature is nil if the signature is of reasonable length.


Take a look at the 65C02's SYNC output. During normal operation, SYNC will go high on each opcode fetch. As the 'C02 will be catatonic following execution of a STP instruction, SYNC will remain continuously low. A little imagination you tell you how to use that information to inactivate other hardware when the 'C02 is SToPped.

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

Perhaps. But I'm not seeing any reduction in complexity from my XOR-gate solution.

In the rail transport industry, in which I worked for many years, there are three goals to be reached in operating one's railroad: "cheap," "fast" and "reliable"—by extension, "reliable" is the same as "safe," as in no train wrecks. The kicker is you can only get two out of three. If you want "cheap" and "fast," it's not going to be "reliable." If you want "fast" and "reliable," it's not going to be "cheap," and so forth.

The funny thing is designing computer systems is pretty much the same. So pick your poison and run with it. You're the one setting the requirements and drawing the schematic. Do whatever it is you want.

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

This xor idea seems interesting to me: I'd love to see it in its own thread. If it works, that's great. If it doesn't, perhaps it can be fixed. If it can't, perhaps we learn something interesting. Chromatix has already shown the circuit he's thinking of, in the right corner of the schematic posted upthread.