LED power from 54/75 HC/HCT

[Interocitor Steve]

If memory serves me correctly, LEDs can be driven as shown below with a 4049 chip.

I am figuring for 10ma for each LED with a 5V supply.  (330 ohms)

Also, I don't think to 4049 likes open input pins.  So, do I need to set a default voltage for the tristate signals on the address and data buses? 

I have spec'd a 10K resistor to keep the 4049 input from floating. 10K shouldn't be a significant load to any other tri-state bus device.

Is this correct??

The a0, a1, ... a7 signals are Z80 address pins.

=Steve.

[Sergey Kiselev]

I wouldn't use CD4000 series to drive LEDs. Their output current is fairly low. Moreover their input levels are not TTL compatible. I'd recommend using 74HCT instead. You can use bus drivers such as 74HCT244 (74HCT541 or 74HCT245 for more reasonable pin-out) that have 8 drivers per package.

If your intention is to monitor the bus activity, instead of using simple buffers, consider using latches, e.g. 74HCT573, and connecting the latch input to /RD and /WR inputs through a NAND gate, so that the latch is transparent when one of these signals is active, and it outputs previously stored value when these signals are inactive.

Regarding floating bus - generally it is a good practice to add a pull-up resistors on data bus. The address bus shouldn't be floating unless you have a DMA controller (in which case it will float for a short period of time when CPU and DMA pass the control of the bus between each other)

IMHO 330 ohm / 10 mA is too much for modern LEDs. 470 ohm is more reasonable, or even 1k if you use "true green" or blue LEDs.

[Rob Gray]

Your LEDs are back to front.

[Interocitor Steve]

Hello Sergey & Rob,

Thanks for your help guys.  Here is the updated schematic. 

It looks like the HCT541 will sink and source current equally well.  (The 4949 is good at sinking, not so much sourcing)

I was thinking about the pull-up on the bus.  It seems better to pull up instead of pull down.  That means that the default status of an open bus would be all high with all LED's lit.  That makes your suggestion, Sergey, about using RD/WR to latch the data appealing.  I had planned to show the bus all the time as that would be useful for initial debugging.  Constant status would reveal stuck or shorted lines.  But maybe I don't need that.  I really don't want the LED glaring at me all the time if the bus is inactive.

I decide to go with 680 ohms as the LED current limiting resistor value - only because I like the color bands of that value.  I will be more particular when I actually start assembly.  I will determine the brightness at that time.

Rob, I often make mistakes about polarities - especially when I can't make up my mind about a design choice.  I appreciate the catch.

=Steve.

[Sergey Kiselev]

Hi Steve,

If you don't want the LED's to light up all the time, you can connect /RD and /WR signals (or /IORQ and /MREQ) through an AND gate (since all the signals are inverted, AND will work as negative logic OR) to /G1 and /G2 pins of 74HCT541. This this enable LEDs only when a valid address is present on the bus.

-SK

[Interocitor Steve]

Hi Sergey,

It just occurred to me that pull-down resistors on the bus back-plane are a good idea.  That takes the burden off of all other card designs.  If the bus devices are really tri-state, then any 10K, or so, resistor should work with CMOS, HC, or HCT parts.  The Z80 I am using is a CMOS part.  Input current for a LOW is about 1uA.  Assuming ten parts looking at any signal on the bus, that only makes 10uA total.  Through 10K is only 0.1 volts.

By comparison, 75LS inputs (TTL) need about 400uA for a low.  Doing the math, that's 4 volts.  So a 10K cannot be used for a TTL LOW.  TTL gates cannot be used, at all.  I don't have any TTL inputs in my design, so I will try it.  I can use a pin header with resistor packs and just stick it into a bus slot.

Also, a Z80 card could be tested with no memory.  It would read NOP instructions (0x00) and march through memory.

=Steve.

On Tuesday, January 28, 2020 at 7:56:49 PM UTC-5, Sergey Kiselev wrote:

Hi Steve,

If you don't want the LED's to light up all t. . .

[Sergey Kiselev]

At least for the Z80 data bus it is a good practice to use pull-up resistors. This will result in CPU reading 0xFF value if nothing drives the bus. The corresponding instruction is RST 38. And the fact that it is "by default" placed on the bus is useful for implementing interrupt mode 0. In this case, a hardware interrupt will automatically result in a call to address 0x38.

[Interocitor Steve]

Hi guys,

It seems I make a chart like this every ten years of so.  It shows what values on pulldown-resitors are needed for various logic family INPUTS.

I have not made the complementary chart which shows the OUTPUTS of the logic families and weather or not they can drive the pull-down values.

This shows that a 10K resistor bus pulldown should be fine.  I do not know what the drive capability of HCT chips are, but I think they will work into one 10K load.

I welcome comments from HW folks.  I spent most of my time with SW.

=Steve.

[Interocitor Steve]

Looks like we just cross-posted.  Lemme chew on your post :)

On Wednesday, January 29, 2020 at 12:06:24 AM UTC-5, Sergey Kiselev wrote:

At least for the Z80 data bus it is a good practice to use pull . . .

[Interocitor Steve]

Hi Sergey,

I just reviewed the specs on Mode 0.  So you are saying that a Mode 0 interrupt could be used to grab hold of the processor if it is off in the weeds somewhere, yes?  And you wouldn't need to put any instruction onto the bus for Mode 0, just let the processor read the FF.  Just have a vector loaded into 0x38 and you are on your way.  Sweet.

My intentions with the 0x00 pull-down hardware approach is to debug hardware.  I want to see the address increasing on successive fetches.  I designed a board for this - very simple.  So I could insert the pull-down card when troubleshooting hardware, then remove it when debugging software.  Cool.

I have started work on the schematic for the front panel.  I have decided to use the latches you recommended and capture bus data instead of live wiring the bus to the LEDs.  I think I can mask out Refresh memory reads.  I would like to have hardware that effectively makes refreshed disappear.  I toyed with the idea of using bus drivers for the address bus which would prevent the CPU addresses from getting out to the bus during refreshes.  But maybe that's a bit too much.  It introduces more HW that might have to be debugged in addition to the rest.

=Steve.

On Wednesday, January 29, 2020 at 12:06:24 AM UTC-5, Sergey Kiselev wrote:

At least for the Z80 data bus it is a good practice to use pull-up resistors. This will result in CPU reading 0xFF value if nothing drives the bus. The corresponding instruction is RST 38. And the fact . . .

[Sergey Kiselev]

A couple of clarifications:
1. Hardware interrupts normally are used when a peripheral device requires processor's attention. For example when UART receives a character, or alternatively when it sends a character and is ready to send the next one. Another common interrupt source would be a timer. The interrupt in this case is triggered at a preset time intervals and can be used for time keeping, drawing the next frame (e.g. in games), process scheduling/switching (in multitask operating systems), or any other synchronization purposes.
(For processor in the weeds scenario there's sometimes watchdog hardware that would reset the CPU if it gets "stuck")
2. RST 38 results in a call to address 0x38. That address might contain a JMP instruction that jumps to the actual interrupt service routine code (x86 has an interrupt vectors table with the addresses, not 8080/Z80)

-SK