Z80 Front Panel Interface

[MrAureliusR]

Back in November of last year, I became interested in designing a Z80 based computer. At the time, even though I studied at length, I didn't have the patience to wrap my head around it all and I lost interest.

Recently, I decided to give it another shot. This time, I used my larger breadboard, and instead of using the cheap jumper wires that come with breadboards I did all the wiring by hand, with solid core wire. This made everything neater, and the colour coding helps me to keep it all organized.

Before I get further in my project, I want to build a simple bus monitor, à la PDP-8 front panel. Lights for the data and address line a, plus the added benefit of a 7-segment decoder. So far, all I have is the Z80, a 28C256, and a Toshiba SRAM (32k I think). However, for the first stage, I'm planning on using only 4k of each, for a total of 8k mapped memory.

I have some bus transceivers and buffers, and I can build the simple LED/7-segment part of the panel. My question is about the auxiliary switches and also some design philosophy. A user named grumpydoc gave me tons of info on different memory decoding/bank switching schemes. However, I want to be able to enter basic programs line by line into my RAM. I've watched a series of YouTube videos, in which a 6809 based system is built on protoboard. The 6809 seems to have a HALT input - he starts the system with the processor stopped and disconnected from the bus. He then enters a basic program through switches, and once it's completed, he puts the 6809 back on the bus, releases the halt for a second, and then examines the contents of memory to see if it ran correctly.

Essentially, I want to do the same. So:

- what is the equivalent of HALT on a Z80? The /HALT line is an output only, to let the user know when the processor is halted, but how to get it there?
- I may end up using a small micro to handle the Mem+, Mem-, Store and other buttons. I like how in the videos, pressing Store/Load automatically advances to the next position in memory.
- I'll also need an Addr/Data toggle to determine what the switches are controlling.

I've been trying to find schematics for a design online, but it's almost like I can't find the right search terms. "Bus Monitor" seems to me to be the most descriptive name, but it doesn't bring up what I'm looking for.

Any and all suggestions are greatly appreciated!! The reason I want to use a front panel design is tl familiarize myself with basic Z80 assembly and opcodes. Once I'm confident I'll move to a cross-compiler and burn EEPROM directly.

[Skimask]

HALT on a Z-80 is an instruction.  Pulls the *HALT output pin low.  The Z-80 basically executes NOPs until an interrupt or a reset is tripped and it continues accordingly...

[Skimask]

The Z-80 was killing Jedi's before Palpatine was...

[T3sl4co1l]

There's a WAIT signal, primarily used for slow memory (e.g., waiting for full RAS and CAS cycles on DRAM), but also used for IO (say you have an IO-mapped parallel ADC that takes some time to produce a conversion -- unlike today's vast array of SPI ADCs, which do the conversion while pumping data out!) and, if you wanted to feed the processor bytes by hand, you could apply a little logic so that a debounced pushbutton holds WAIT until you're readied your next byte, and so on.

This isn't so great for memory.  What you'll want is either holding the processor in RESET (it starts at 0000h when released) or stalling it with a bus mastering cycle (I forget what does this, but it's in the datasheet).  Which, after all, is what you're after: you want to assert the address and data buses to program the memory by hand.

Tim

[dajt]

I'm working on the same thing. My idea is to use the WAIT line to allow single stepping and the BUSREQ (I think) signal when I want to program the EEPROM.

BUSREQ should tell the Z80 you want the bus and it will respond by asserting BUSACK when it has tri-stated its bus connections.

But I can't get as far as making the shift registers work correctly with soldered connections. Fine on the breadboard, flaky when soldered.

Regards,
David.

[grumpydoc]

I'm working on the same thing. My idea is to use the WAIT line to allow single stepping and the BUSREQ (I think) signal when I want to program the EEPROM.

Not sure how you use WAIT for single step.

There is a neat way to do single step with a bit of external logic  - basically you toggle a bit on an output port to initiate counting a couple of m1 cycles and then generate an NMI - set up the stack to "return" to the instruction you want, fill the registers and then do a "RETN". Get it right and the CPU executes one instruction and then takes the NMI giving you control back.

The Nascom 2 used that approach - I'll see if I can did the circuit (and software to use it) out.

[MrAureliusR]

Or, of course, you can just hand step the clock. Great thing about the Z80 is it's totally static. You can completely stop the clock if you want.

Well, I have the breadboard all wired up. Simply using 8k of ROM and 8k of RAM (though I'll mostly be programming some basic stuff into RAM by hand for now). However I'm having the opposite problem -- my breadboard is the type that has the big metal plate as a base. This, combined with the many wires for the data and address buses is causing all sorts of strange interference. I'll either temporarily strip it all back to just RAM, or transfer everything to a protoboard. Wish I could find one similar to the 6809 design I've been watching. Eurocard format, with good quality FR4 and double sided plating on the holes. Plus spots for D connectors, DIN 41612, etc.

I've found a basic 'front panel' design, but I'm also spinning my own. I'll post schematics here if it works (lol). The basic memory decoding is working. Just as grumpydoc showed me, when you're only using 8k pages, all you need is an LS138.

[dajt]

I'm working on the same thing. My idea is to use the WAIT line to allow single stepping and the BUSREQ (I think) signal when I want to program the EEPROM.

Not sure how you use WAIT for single step.

Actually, I didn't explain that correctly.

I am using wait to give the bus sniffer time to decode and display the address lines during the M1 cycle. I could keep asserting wait at this point to halt the processing.

I'm also considering a switch to use either a crystal or a line from the MCU controlling the bus sniffer as the clock. Then I can make the clock stop or go any speed I want when using the MCU line.

Regards,
David.

[T3sl4co1l]

Or, of course, you can just hand step the clock. Great thing about the Z80 is it's totally static. You can completely stop the clock if you want.

Ehh, Z80C...

I have a few NMOS that get heartburn if the clock is ~50% outside of spec

Tim

[MrAureliusR]

Anyway, back to my original point. I found some 74LS642's I think, bus tranceivers. Plus I've got the LS241 and 244's handy. I might cheap out and just use an ATmega to control the front panel interface.

I want to be able to view the contents of memory, and program the SRAM from the panel as well. I guess I need to think of the panel as another unit on the bus - it essentially replaces the CPU. So I suppose I just program it to assert all the same lines that the CPU would when reading and writing the SRAM.

I wanted to do it with logic chips only, but I just don't seem to have the right ones on hand. I contacted Matt Sarnoff of Ultim809 fame to ask about his front panel. I'm basically just trying to get ideas.

All it needs to do is display the address and data buses, have switches to enter data, have switches to stop, reset,and otherwise control the Z80 (perhaps also change the clock source, or stop it at will). So there will be Address +, Address -, Load, Reset, and I guess a 'Load Address' button in case I want to jump by more than a couple addresses. The Load button should also auto-increment the address. Also, when the address is changed, it should immediately display the contents of that address.

This many buttons, switches, and bus lines overwhelms almost all the microcontrollers I can think of (in terms of pin count). I suppose the micro doesn't need to interface with the data bus directly... it's not doing the display, the 7-seg driver will handle all that.

Any suggestions, or if anyone can point me to a good design, is much appreciated. I have found one basic front panel schematic. I'll post the link here when I'm back on my PC.

Thanks everyone!

[dajt]

I'm using shift registers to interface with the busses, so for ex. the address bus can be read with 4 lines, or use 3 shift regs and add the data bus into that, read all three with 4 lines.

I'm using a cheap Chinese arduino nano as the panel controller and I'm pretty sure I ended up with enough lines to work with the address and data bus, and program the EEPROM, plus handle some of the Z80s control signals.

[retrolefty]

Or, of course, you can just hand step the clock. Great thing about the Z80 is it's totally static. You can completely stop the clock if you want.

Ehh, Z80C...

I have a few NMOS that get heartburn if the clock is ~50% outside of spec

Tim

I've got a Z80 manual by Zilog somewhere around here, had it sense the early 80s, and I'm sure even the original talked about being total static capable?

Anyone also recall the 'undocumented' machine instructions that were discovered?

[MrAureliusR]

Or, of course, you can just hand step the clock. Great thing about the Z80 is it's totally static. You can completely stop the clock if you want.

Ehh, Z80C...

I have a few NMOS that get heartburn if the clock is ~50% outside of spec

Tim

I've got a Z80 manual by Zilog somewhere around here, had it sense the early 80s, and I'm sure even the original talked about being total static capable?

Anyone also recall the 'undocumented' machine instructions that were discovered?

Yup, z80.info has links to the complete list of undocumented opcodes.

Thanks for the suggestion -- I think I have a basic design in mind now. I'm going to use the 74F241 buffers to buffer the incoming data and address lines, plus some of the other status lines that are output by the Z80. Then, to control the buses, I'm going to use 74HC574's, that are controlled by the 16 switches, and activated by pushing the correct button. For example, pressing 'Load' after switching in data will assert that data on the data bus, and also write the data into the SRAM, or EEPROM, depending. The BUSRQ line will be attached to a swtich, as will the RESET, and WAIT lines, so I can stop the processor, disconnect it from the bus, and then program the SRAM. Also, the panel needs to display the address and data on 7-segment displays -- this has actually become the hard part!

There are very few 7-segment driver chips that do the full hexadecimal code. All the common ones (4056, 4511) just do 0-9 and then a few other useless characters beyond that. The chips that DO handle full hexadecimal are anywhere from $4 up to $20 a pop. I wanted to be able to control ALL the digits from one chip -- multiplex all 6 digits. The Maxim ICM7212 can handle 4 digits, and does full hexadecimal. Unfortunately, the MAX7219's I have don't do hexadecimal, which sucks as they can do 8 digits, and it multiplexes them automatically. This way I could have one micro, and one chip to handle the display side.

I believe that the Ultim809 used intelligent LED displays, that could decode and display the data themselves. I have one single display that does this, but it's a really cool old HP chip and I don't want to sacrifice it. Plus I'd need five more anyway. So my dilemma is whether to go with a microcontroller design, a decoder chip design, or an intelligent display. I'm going to Toronto for a week, and I'm going to hit both Active Surplus and Sayal Electronics, so hopefully I can pick something up that will work well.

My other question was is it okay to use a buffer, such as the 74241 in both directions simultaneously? That is, when the processor is disconnected from the bus, one 241 will buffer the data bus coming to the card, in order for it to be displayed. This is necessary for examining the contents of memory, but also for displaying what I've input after it's been asserted by the 74574. I was going to put the 74574's output back through another 74241 to buffer it back onto the bus. When the processor is connected to the bus, this second buffer will be put in the high-impedance mode. Or is this buffer unnecessary? Does the 74HC574 buffer the output of the switches well enough to connect it directly back to the bus? Or, I could use the 74LS645's I have -- they are bus transceivers, so they buffer in both directions, though I have to read their datasheet a little better to understand if they need to be switched back and forth. I like the 74F241's because they are easy to enable and disable, and I'm pretty sure their outputs are tri-stated when they're inactive.

Does this sound like a good design? I was going to take some elements of a design I saw, namely, the busses should be pulled down by resistors by default. This helps keep the bus stable. I guess they don't need to be strong pulldowns (or pull-ups, I guess), but I don't want them to be super weak, either. These would be for the switches, so that they'd keep the bus pulled low.

However, on a separate issue, would it make sense to have the address and data buses pulled low through weak pulldowns to help fight noise? Does the Z80 source enough current to pull a line up that's being pulled low by say a 100k resistor or something? The reason I ask is that the bus lines slowly get longer and longer, the more things that get added to the bus. Or should I just put buffers directly beside the Z80? All the designs I've seen only use one buffer per bus, and usually that's on the 'Front Panel' interface, or sometimes when the bus jumps to another card via a ribbon cable. So far, my new design is small (I ended up ditching the huge breadboard and moved everything to a piece of stripboard, which itself will probably get ditched in the near future when I get a nice Eurocard size protoboard to work with) and I think will have very little noise. But once I move the design to a bigger board, and there's more and more things on the buses, will I need to start thinking about things like this? Eventually, there will be RAM, ROM, a UART, possibly sound and video chips, removable storage such as CompactFlash, etc etc, all connected to the data and address buses, through wires. I've been using regular 24AWG insulated red wire to make most of the connections so far.

Anyway, enough for one post. Again, I really appreciate everyone's help! I will be SO excited when I enter in my first program via the switches, and then see the result in memory! Oh boy -- I'll feel like a kid who just got an IMSAI 8080 for Christmas, and sees the lights blinking for the very first time!!!

Cheers everyone!

[T3sl4co1l]

Datasheet for the Z0840004 says 110ns minimum pulse width (low or high), 250ns min cycle time (i.e. 4MHz max), 2000ns max pulse width (low or high) (presumably, 250kHz minimum).

At least, that's the kind I have a few of; was there a static NMOS version too?  Maybe the 084s are the odd ones out, cost-reduced or something?  (They still draw a whopping 200mA though...)

The 84Cs specified in the same datasheet are static though.

Tim

[Simon123]

You get into halt with single byte instruction 76-hex. It also starts "doing NOPs" until you reset it or put interrupt in.
I built it like this https://sites.google.com/site/elektronikasimon/z80-computer .

[MrAureliusR]

So after my recent trip to Toronto to pick up parts and stuff, I've come a lot further on the front panel. I've been labouring over it for hours at a time, and I feel like I should have more done, but I'm trying to go slowly and do everything 'right' so everything 'works' when it's done.

Here's a look at everything from the front (I've added more since I took this photo yesterday):



The board on the right is the "input" board, which takes the switches and button presses and sends them onto the bus, and the left board is the "output" board, which takes whatever is on the bus and displays in on 7-segment displays.

Here's the back, and a newer one of the front:

[KD0RC]

Another thought on front panels is the one from the HeathKit H8.  Although designed for the 8080, it worked great with the Z80.  In the day, I upgraded mine from the original 8080 board to a Z80 board that came with a better front panel monitor (did things in hex instead of that goofy split octal...).  Find a schematic for that and you will likely get some good ideas for yours.  The firmware was all out in the open, so you would not have to reinvent that unless you are after total DIY.

[rob77]

@ dajt - re: flaky when soldered. it reminds me the time when i was interfacing an 32k SRAM to an AVR 8515. i had a similar flaky behavior when soldered - the issue was a short address latch enable pulse for the latch i used - solution was a 33pF capacitor soldered between ALE and ground... maybe your breadboard parasitic capacitance is the reason why it works on the board but flaky when soldered

@ retrolefty - sure i remember those undocumented codes - i was using them whenever possible because i found it to be cool back in those times

regarding the clock - i do remember some replica Z80 CPUs produced over here (eastern block at that time) which were not static, so probably there were more of those replicas produced all over the world

[dajt]

Thanks Rob77. Did the cap hold the line low while it was charging?

I let the magic smoke out of the Nano, so development is halted for a while. It's happened a couple of times now, when I have the Nano on both external 5v and USB, and the Open Bench Logic Sniffer attached too. So that's two devices on the USB bus, and external power, with all the grounds connected.

It usually seemed to work okay but about 3 times lots of grey smoke came from the Nano. Looking under a magnifier it seems the diode near the USB/external power switch has burned and cracked.

It's a shame. But I've just ordered a bunch of cheap Arduino Mini Pro clones to replace it so will be going again in about 3 weeks.

And that's right on the heels of a cap exploding yesterday when I didn't bother to check the power I gave an LM386 amp circuit was 12V DC, rather than AC. Luckily I was looking the other way when it went off, but there was stuff everywhere.

Regards,
David.

[rob77]

in fact the capacitor was just deforming the raising and falling edge and therefore making the ALE pulse a tiny bit "longer". obviously it was soldered to the pins of the latch, not the MCU. so if you have latches in your design, then it's worth of checking the latching signals. Z80 got no addr/data multiplex as 8515 does, so i assume you have a different , but similar issue.

[SL4P]

There are very few 7-segment driver chips that do the full hexadecimal code. All the common ones (4056, 4511) just do 0-9 and then a few other useless characters beyond that...
I believe that the Ultim809 used intelligent LED displays, that could decode and display the data themselves. I have one single display that does this, but it's a really cool old HP chip and I don't want to sacrifice it. Plus I'd need five more...

Look for the TIL-311 (decoder & display in one) they'were quite common back in the day, and are available on eBay. Not too cheap, but worth it in time saving and pleasant display.

[Dave Turner]

I have a copy of the Z80-CPU Technical Manual (1976 Edition). I've scanned the AC Characteristics and the AC Timing Diagram pages. Unfortunately I can't post the the resultant 4Meg files.  If they would be of interest I can email them preferably to someone who can make them available generally.

[C]

Any and all suggestions are greatly appreciated!! The reason I want to use a front panel design is tl familiarize myself with basic Z80 assembly and opcodes. Once I'm confident I'll move to a cross-compiler and burn EEPROM directly.

After all is done, have you thought of just how much help will a front panel for a Z80 will assist you in learning?

At speed if you have leds displaying the address buss, what you will see is just a difference in the led's brightmess. You would have a ball park hint that address area is being used but not see a read or write to a specific location, it just happens to fast.
Unless you have the static cmos version of the Z80 you will not be able to single step the Z80 or slow the Z80 enough to make the LED's really usable.

If you are trying to learn what a Z80 instruction really does, you will not be able to see the results of most instructions do as the result of the instruction is modifying a CPU register and the status flags.

When you see the nice front panel of a PDP-11 you are probably missing a very important difference between the PDP-11 and most 8 bit processors. The PDP-11 is static at the microcode level. Leaving the PDP-11's microcode clock stopped or running it a a very very slow rate is allowed. You can also see the contents of the PDP-11's internal registers at a memory location. So for a PDP-11 the front panel serves a very important part of the PDP-11 system. 

If you want something close to the same for a Z80, you will need to run some software on the Z80 to get it to display what is hidden inside the processor. This is the debug monitor software software that is a part these Z80 systems. Due to the large amount of information contained in the Z80's registers this is normally dumped out a serial port for display. Note that while using the monitor program debugging software the Z80 is still running.

So a front panel display for a Z80 will only give you a  hint that the Z80 is doing something. And note that all those LED's will be creating a LOT of RFI noise.

So the LED displays will be of little help when directly connected to a Z80. The simple inverter connected to a led with a series resistor is about as cheap and easy you you can get. There is one thing here that could make things a little better. Put a Data selector in front of the inverter. This would allow you to select what is going to the display. One very nice source would be to latch what captures what is written to an output port or memory location. 

So how could you boot strap up a Z80 to the level where the monitor program will be able to assist. If you look at the Z80's instruction set you will see that an instruction of 00 hex is a nop. If the Z80 gets a 00 on the data buss during M1 the Z80 will do a NOP Instruction which has a side effect of increasing the PC register by 1. The Z80 will do a loop of M1 cycles( a read) of all memory addresses( 0000 hex - FFFF hex -0000 hex and repeat). This loop will make it easer to test that memory select decoders are functioning. An M1 read is very close to what is needed to read the monitor program from an eerom.

Now if you still want a front panel instead of or in addition of dumping the data out a serial port you could have the monitor program output the data to some data latches that is then is displayed on the front panel.

C
   

[retrolefty]

C

Unless you have the static cmos version of the Z80 you will not be able to single step the Z80 or slow the Z80 enough to make the LED's really usable.

 Unless my memory is completely shot, I seem to recall that even from the initial release from Zilog, all Z-80s are fully static and can work at any speed to rated full speed?
The fact that the chip supports unlimited wait states and DMA requests seems to me that single stepping is certainly possible?

 I believe that only if the design is utilizing external dynamic memory, which is dependent on the Z-80's automatic memory refresh, would stopping/single stepping the CPU clock be an issue.

 

[Dave Turner]

Unless my memory is completely shot, I seem to recall that even from the initial release from Zilog, all Z-80s are fully static and can work at any speed to rated full speed?
The fact that the chip supports unlimited wait states and DMA requests seems to me that single stepping is certainly possible?

 I believe that only if the design is utilizing external dynamic memory, which is dependent on the Z-80's automatic memory refresh, would stopping/single stepping the CPU clock be an issue.

The original Z80s were fully static though I understand some later clones are not. External circuitry was required to refresh any dynamic RAM thus is practically independent of the Z80 itself.

Note that while the clock can be easily single stepped one needs to be aware that the number of clock cycles required to complete an instruction is instruction specific.