Z80 Binary Front Panel Design

binarybootstrapmicroprocessorswitchesz80

Hello fellow engineers,

I need some design design help with a Z80 based computer I am building. It will feature a binary Front Panel.

The following functions may be performed via the front panel. These are the usual things one would find on a vintage mini-computer.

Bootstrapping
Memory examination and loading.
CPU status display
CPU cycle identification LEDs
Mode identification (Instruction Fetch, ISR, I/O, DMA, etc.)
Processor control
Interrupt control
Memory protect
Reset
DMA assert
Clock speed selection
Run / Stop
Front Panel Design Choice

A front panel can be built in several ways. A lot still needs to be decided here. There are basically two design options named A and B.

Option A: The Front Panel is tied directly to the address, data, and control buses which it monitors. Additional hardware is employed to read and write to memory and load (and track) the program counter. The original Altair 8800 actually jammed a Jump instructions onto the bus when the Run switch was depressed.
Option B: The Front Panel is essentially an elaborate LED display and binary input peripheral that is controlled by software (a driver). This could add CPU register display.

Considerations are noted below.

Certainty: In Option A, the actual state of the buses will always be faithfully displayed. In Option B, the state of the buses may not always be reliably depicted because an intermediating software layer is required which is less reliable than hardware. Also, the software will need to distinguish between the reported state of the processor, and the actual real-time state of the processor when displaying the front panel status.
Readability: If, in Option A, the Front Panel LEDs follow the buses at all times, indeterminate displays can be expected representing the bus between valid data times. This could prove misleading. At a minimum, latches will be needed to capture the bus states at the proper time. This will take a bit of hardware. Option B poses no such problems – or rather, this is done in software.
Confusion: The display is to run during user applications. In Option B, the display software will need to run with the application. This complicates things. How frequently can the front panel get updated? Should it be updated after every instruction?
Authenticity: Option A is tied to the hardware and is representative of the actual front panels used on vintage mini and mainframe computers. Option B has a more modern and emulation feel to it.
Utility: Can the front panel be designed in a way, with either Option A or Option B, to support breakpoints and debugging?

Here a few thoughts on Option B.

A. Using Option B, the front panel could be updated on every instruction using instruction fetch bus signals, interrupt(s) and a few gates. But application performance will nose dive.

B. Alternatively, a front panel driver could take periodic snapshots of the processor state at a specified rate and posts the findings to the front panel.

C. If Option B is used, the Front Panel could be ignored during application execution and made available to the application for blinky lights and switch inputs which is appealing and has much merit. Option A does not provide for application use of the Front Panel.

D. Utility, as defined above, and availability to the application are most important design considerations. Certainty, as defined above, is the next important design consideration.

Option A, I fear, will significantly add to the chip count.

Does anybody have any thoughts on this? Has anyone solved this issue before me?

Best Answer

I would suggest using a CPLD or FPGA to interface the bus to something like a 16x8 LED matrix. Such a design would make it possible to switch among different display modes (e.g. it could have a mode that captures the address of /M1 cycles and would thus display a program counter in addition to the address bus). If you use a multiplexed LED, it would be good to have the CPLD/FPGA keep a count of what fraction of the time each light should be on, and adjust the brightness of the LEDs accordingly.

Another possibility would be to use a fast ARM chip to watch the bus and handle things in real time. It's possible for an inexpensive ARM7-TDMA to sit on a 1.19MHz 6502 bus and emulate a RAM chip (even without access to any signals other than A0-12 and D0-D7!); a 4MHz Z80 bus might be a little harder, but Z80 doesn't do things on absolutely every cycle the way a 6502 does.

Related Solutions

Electronic – How to z80 uses a 4-bit ALU and return results in a single clock cycle

The instruction actually ends at the end of T2 of the M1 cycle that reads the next instruction, as explained at z80.info

So, an instruction such as: SUB r can be broken down like this:

M1 / T1
M1 / T2 : read opcode
M1 / T3 : opcode is decoded as SUB r. A is loaded into op1 latch
M1 / T4 : r is loaded into op2 latch
------------
M1 / T1 : low nibble of substraction is calculated and stored in result low latch
M1 / T2 : high nibble of substraction is calculated and written to register file,
          result low latch is written to register file, 
          next opcode is read from memory

This overlapping scheme is only used if the operation writes to a register. If it writes to memory, no overlapping can be happened because that would collide with the M1 cycle trying to read an opcode.

Another example: INC HL. This increments a 16 bit register, so the 4-bit ALU must be used four times. INC HL has one M1 cycle that lasts 6 clock cycles. Its breakdown is this (the number of clock cycles for every machine cycle is taken from the Mostek MK3880 Z80 Technical Manual):

M1 / T1 :
M1 / T2 : read opcode
M1 / T3 : opcode is decoded as INC HL
M1 / T4 : L is loaded into op1 latch
M1 / T5 : low nibble of L is incremented and stored into result low latch
M1 / T6 : low nibble of H is loaded into op1 low latch,
          high nibble of L is incremented and written back to register file
------------
M1 / T1 : high nibble of H is loaded into op1 high latch,
          result low latch (new value of low nibble of L) is 
                               written back to register file
M1 / T2 : high nibble of H is incremented and written back to register file,
          read next opcode, etc...

ADD HL,DE : it lasts 11 clock cycles with the following breakdown: 4+4+3

M1 / T1 :
M1 / T2 : read opcode
M1 / T3 : opcode is decoded as ADD HL,DE
M1 / T4 : L is loaded into op1 latch
------------
M2 / T1 : E is loaded into op2 latch
M2 / T2 : low nibble of L+E is calculated and stored into result low latch
M2 / T3 : high nibble of L+E is calculated and written back to register file,
          low nibble is also written to register file
M2 / T4 : H is loaded into op1 latch
------------
M3 / T1 : D is loaded into op2 latch
M3 / T2 : low nibble of H+D is calculated and stored into result low latch
M3 / T3 : high nibble of H+D is calculated and written back to register file,
          low nibble is also written to register file

Can binary code such as an embedded OS or user application code be stored using silicon physical gates

In fact, there are hard-coded bits of data on many processors and other such devices, even complete bootloaders.

There are many ways to do that, sometimes it's just an array of hardwired shorts to VCC or GND that are selected in a grid, just like the bit-cells in an EEPROM device.

Or sometimes it's a row driver with diodes and pull down or pull up resistors, or a similar trick, where the row driver decodes the address it's given, much like a 3-to-8 decoder, but larger:

Consider this "8 row, 3bit Hardwired rom":

schematic

^{simulate this circuit – Schematic created using CircuitLab}

And since I'm not a chip designer, I'm probably overlooking some details here and there, but I'm quite sure there's a lot of ways this similar trick gets done. In some, or even many, cases they may make a grid with all diodes, or links, present and then laser etch away the paces where they want the opposite bit to come out, for example with unique IDs, where every chip gets lasered an increasing number in a fixed spot in the memory, that will not decay over time like Flash or EEPROM (though the latter has become nearly ageless by now).

Best Answer

Related Solutions

Electronic – How to z80 uses a 4-bit ALU and return results in a single clock cycle

Can binary code such as an embedded OS or user application code be stored using silicon physical gates

Related Topic