Mickey Mouse logic, address decoding, power management, etc.

[BigDumbDinosaur]

BigDumbDinosaur wrote:

Disabling IRQs with SEI immediately before executing WAI will cause the MPU to restart on the instruction that follows WAI, provided the interrupt is an IRQ.  The result will be a single-cycle response to the interrupt—the vector at $FFFE-$FFFF will not be taken.

I neglected to mention that in addition to not taking the IRQ vector when WAI is terminated by an IRQ, no stack operations will be performed.

[No True Scotsman]

So the WAI should be preceded by some code that saves the user session, and followed by code that restores the session. Is that about the size of it?

[BigDumbDinosaur]

No True Scotsman wrote:

So the WAI should be preceded by some code that saves the user session, and followed by code that restores the session. Is that about the size of it?

That would depend on what constitutes a “user session.”  Generally, there is nothing special that needs to be done immediately prior to executing WAI.

As the WDC 65C02 is a static-core design, it will retain whatever is in the registers while WAIting.  The MPU is stopped when the clock goes from low to high during the third instruction cycle, and upon receipt of an IRQ or NMI, restarts on the next low-going transition of Ø2.  The result is an interrupt response latency of one cycle maximum.

Incidentally, RDY is driven low while the MPU is WAIting.  Your glue logic could sense that and perhaps de-clock other parts of the system during the WAIt period, thus further reducing the quiescent current consumption.

[barnacle]

Oi! I managed to retire from that job three times, and they kept calling me back

(I suspect we/they could do better these days; more recent processors take stupid low standby current!)

Neil

[No True Scotsman]

BigDumbDinosaur wrote:

That would depend on what constitutes a “user session.”

Here's the scenario. An inactivity timer on the ESP32 expires. It must instruct the 6502 to execute WAI, either by interrupt or by an in-band command sent over the terminal connection. (The ESP32 is also the terminal, remember?)

In the first case, WAI would have be executed within an interrupt handler. I presume that means the CPU would still be WAIting inside the first interrupt handler when the "wake up" interrupt arrives. Looks messy.

It's probably a non-issue though. The second case seems more straightforward. The 6502 is running a loop that polls the terminal every so often. It'll eventually read the in-band sleep command and execute WAI. Upon wakeup, it'll continue in the loop where it left off.

[No True Scotsman]

Michael wrote:

Could you drive the DACA/DACB input with the A0 address line?

I'm liking this 74HC139-based IO breakout so much that I'm going to order 139s and wait for them to arrive before I proceed. Should I use HCT instead?

The down side is that the new decoder will only use one NAND, wasting the other three. So what are your best design ideas for a Mickey (or Minnie) Mouse NAND gate?

[No True Scotsman]

Ubuntu doesn't like me drawing pictures. I've tried at least half a dozen Linux paint programs; they all have atrocious UIs.

I went so far as to try installing Paint Shop Pro 3.11 on DOSBox. Windows 3.11 worked fine, but every distribution of PSP I tried had its own set of issues.

When I went to scan this hand-drawn picture just now, the scanner app couldn't connect to my scanner. After trying several software solutions, one app helpfully revealed that something was interfering with the connection. I turned off everything on the USB strip but the mouse, keyboard, and scanner, and finally got results.

Here, scanned, rotated, cropped, resized, and contrast-enhanced for your viewing pleasure is my complete decoder. Seeing it all together like this illustrates how two NAND gates were eliminated. Now if only I could get rid of that last one.

EDIT: Yes, I did completely forget about the Paintbrush app bundled with Windows 3.11, which would've been just about perfect for my needs.

[No True Scotsman]

GARTHWILSON wrote:

In that case, you might find that you don't even need to power down, if using the W65C02S's SToP or WAIt instruction will bring the dormant power requirement down to a negligible level....

If I'm reading Rockwell's R65C02 datasheet correctly, it appears that an external device can put the CPU into standby mode by stopping the clock with PHI0 high.

If that's the case, no WAI or interrupts would be needed, right?

I looked in my parts box to see which 65C02s I have. A strong aroma of new electronics assailed my nostrils when I opened the lid. While I was in there, I squinted at all of the chips with a magnifier under a lamp, and wrote the part numbers on the bags.

Anyway, these here say W65C02, but the manufacturer logo on them is UMC, not WDC.

[barnacle]

No True Scotsman wrote:

Ubuntu doesn't like me drawing pictures. I've tried at least half a dozen Linux paint programs; they all have atrocious UIs.

There's always the possibility of installing Kicad and outputting the schematic to a monochrome pdf.

Though, of course, the pencil on the back of an envelope method is an old, tried, and honorable approach.

Neil

(I note that amongst some of the coloured pencil brigade, the approved method appears to be capture an image with a camera, import that image into an MS Word document, output as a pdf, and send that as an attachment.)

[GARTHWILSON]

All the 65c02's can be stopped indefinitely with Φ2 high, unlike the NMOS 6502's.  WDC's can be stopped in either phase, and stopping with Φ2 low would probably be good for keeping things de-selected (or at least outputs disabled), thus taking less power when you want to get down to microamps.

As for a way to do diagrams, my stuff is all done with pencil, and I scan it with my Epson scanner, with Xsane software running under Ubuntu Linux, and never had any trouble with it, and I process the scans with Gimp for clean-up.  For simple things I post on the forum, I do sometimes actually reach under my desk for an envelope out of the trash can, sketch something on the back, and finish it off as above.

[Michael]

I don't see an easy way to get rid of that one gate. I only eliminated it by squeezing the essence of a ROM Emulator into an SBC design which involved using a $2 microcontroller and swapping out the ROM with RAM (keeping the ROM as an 'image store'). The ROM Emulator copies the 64K 'A' or 'B' half of the 128K Flash ROM into 64K RAM memory at power-up and while the ROM isn't available to the 6502 in 'RUN' mode, the ROM Emulator does support using the SBC as a stand-alone EEPROM / Flash ROM programmer (a 32-pin ZIF socket is recommended).

The USB-serial port on the microcontroller connects to a terminal program on a host PC at 115,200 bps and provides three basic functions to support a simple development environment;

(1) Load - RAM with one or more hex files
(2) Run - switch to 6502 'RUN' mode with a 1, 2, 4, or 8 MHz clock
(3) Save - program 64K 'A' or 'B' ROM with the 64K image in RAM (takes ~10 seconds)

I would like to sample some 128K I2C EEPROMs which should be accessible to both the ROM Emulator and the 6502 in 'RUN' mode;.

[No True Scotsman]

GARTHWILSON wrote:

As for a way to do diagrams, my stuff is all done with pencil, and I scan it with my Epson scanner, with Xsane software running under Ubuntu Linux...

I installed Xsane, but it wasn't a software issue. Disconnecting the printer and a handful of thumb drives from the USB strip is what fixed it.

GARTHWILSON wrote:

... and I process the scans with Gimp for clean-up.

That's what I did with the above picture.

[No True Scotsman]

Michael wrote:

I don't see an easy way to get rid of that one gate.

If I use a 74HC132, I could use some of the other gates as inverters in the clock circuit.

[No True Scotsman]

barnacle wrote:

There's always the possibility of installing Kicad and outputting the schematic to a monochrome pdf.

I'll get around to learning KiCAD eventually. For now, I'm working with budget Veroboard. I haven't seen an actual Veroboard branded stripboard in ages, come to think of it.

[Dr Jefyll]

No True Scotsman wrote:

I could use some of the other gates as inverters in the clock circuit.

Yup. But instead (or as well) it's good to be aware of the following. These little beasties can also solve problems having to do with speed.

-- Jeff

Tiny, superfast gates rival programmable logic

Quote:

Logic gates are traditionally supplied in 14- and 16-pin packages containing several identical gates -- an arrangement which often won't exactly suit your needs. For example, a 74ac00 gives you four NAND gates whether you need that many or not. But that barrier -- and the speed barrier -- collapse when using single-gate devices such as those in the 74LVC1G series (NXP, Texas Instruments). Even the largest of these devices are pretty small. And, with typically one gate per package (the 2G series have two gates), they're far less likely to result in leftover, unneeded gates.

A more important factor is routing. PCB traces can be shorter because each device gets located in the spot it's needed. And, best of all, these chips are FAST. They have a maximum propagation time around 3 ns. For example, 2.7ns is the maximum for a SN74LVC1G10 3-input NAND driving 15 pF at 5 volts Vdd. (Low voltage operation is somewhat slower.)