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.

  1. 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.

  2. 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.

  3. 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?

  4. 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.

  5. 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?

  • 1
    \$\begingroup\$ What exactly are you trying to achieve by building this system? You could run a simulation of a Z80 (no hardware at all) with all of the features of "option B" on a modern ARM chip and have it run faster than a real Z80. If your main interest is in software development, this would be the way to go. On the other hand, if you want to re-create the experience of working directly with hardware -- something like the Altair -- then option A would be the way to go. \$\endgroup\$
    – Dave Tweed
    Jun 19 '15 at 11:52
  • \$\begingroup\$ The system will be like an Altair 8800. I was thinking to extend the functions of the front panel to show register values, not just memory locations. Also, with 24 LEDs, it might be nice to make them available to application programs. \$\endgroup\$
    – Harry Pots
    Jun 19 '15 at 22:03
  • 1
    \$\begingroup\$ What's wrong with having the front panel show intermediate states? When you run your clock at 4MHz you'll see intermediate states anyway because of human persistence-of-vision. When you run it at 1Hz the intermediate states will last for a fraction of a microsecond so who cares? \$\endgroup\$
    – user253751
    Nov 9 '17 at 22:46
  • 1
    \$\begingroup\$ The is an article thet provides all the information needed for building a s-100 bus front panel at computerarchive.org/files/computer/magazines/… I built one in my youth tat functioned wonderfully with my z80 system. \$\endgroup\$ Aug 20 '18 at 17:28

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.

  • \$\begingroup\$ This will be a retro computer w/ a Z80. All parts will be through hole. Does this rule out ARM's? The panel will use discrete LEDs like the Altair 8800. This is an interesting approach though. I could build the vintage Z80 stuff independent of the display. Thanks. I will give this a think. I need through hole parts though because I want to make this a kit. \$\endgroup\$
    – Harry Pots
    Jun 19 '15 at 21:54
  • \$\begingroup\$ If you want to make a kit, I would suggest that it might be good to have an assembly which contains a surface-mount board and a through-hole header that fits in a DIP40, DIP48, DIP64, or other such socket (depending upon exactly what you decide to include; address, data and control lines plus a 16x8 LED matrix would get you over 48 pins pretty quickly). \$\endgroup\$
    – supercat
    Jun 19 '15 at 21:57
  • \$\begingroup\$ Hi supercat20,I was wondering, would a front panel that loads CPU registers be more interesting? \$\endgroup\$
    – Harry Pots
    Jun 20 '15 at 18:38
  • 1
    \$\begingroup\$ @HarryPots: Having a front panel show the present state of CPU registers could indeed be very interesting, but an external device couldn't know the values of all CPU registers in real time unless it duplicated almost all of the functionality of the Z80 inclulding instructions like "DAA". The front panel could show the PC in real-time pretty easily, since every code fetch drives /M1 while outputting the PC on A0-A15, but other registers would be much harder. One thing I don't think I've ever seen done that might be interesting with the PC, if you had enough LEDs, would be... \$\endgroup\$
    – supercat
    Jun 20 '15 at 19:15
  • 1
    \$\begingroup\$ ...to have a mode where, for some range of addresses, the LEDs would indicate how many times in each ~1ms interval instructions were fetched from each address or group of consecutive addresses within that range, thus providing a "visual profiler". \$\endgroup\$
    – supercat
    Jun 20 '15 at 19:16

I suggest the difference between option A and option B is your desire to provide a boot environment, typically in ROM, to interface with the front panel.

Option A requires no boot environment and is functional with no initial boot environment. By the way, Option A can be implemented as Z80 Input (switches) and Output (LEDs) ports. I don't recall if the Altair allowed output to the LEDs but the left 8 address switches were also called sense switches.

Option B requires software that must be non-volatile and must execute when the computer is powered on. The KIM-1 ROM controlled the keypad and LED interface as well as the cassette tape interface.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.