View Full Version : 21st Century Front Panel puzzle

September 20th, 2009, 06:16 PM
My restoration project (IMS 5000) is stalled for lack of good enough view of hardware behaviour, so I've been searching for tools to provide "Front Panel" type functionality, only better.

I've checked out a number of Z80 In-Circuit-Emulators, some of which are very smart and provide display and control on PC via serial. But they are either no longer available, expensive, require unique PCBs, or depend on external systems such as PIC programmers or SBCs.

Furthermore, while ICE devices give access to the 38 lines on the CPU, you are still blind to the remaining 60-odd lines of the S-100 bus (some of them potentially important to system diagnosis) without additional poking and probing. Also, I'd prefer to keep the system processor in the circuit under test, rather than displacing it.

There are quite a few designs for "retro" Front Panels that that involve several hundred solder points and deliver little more than LED displays and DIP switches. The more capable ones are pretty much SBCs in their own right and therefore complex and expensive to put together.

Does anyone know of, or have ideas about, a hybrid that a non-professional hobbyist could put together, say on a S-100 prototype board?

It would do this:

1. Access all pins on the S-100 bus (OK, segregate the voltage lines)
2. Poll and buffer all signal levels continuously, then present to UART for RS232 interface as serial output (100 bits +/-)
3. Accept RS232 serial input, addressed to any pin, to change bus state.
4. Provide safe on-board test-points for clock and power.

With this capability, it should be fairly simple to perform all the Front Panel address and data display and control functions from software in a standard terminal on a PC or external emulator, plus keeping full display of the other bus lines.

It would be much easier to play around with software configurations than hard-wired componentry such as hex displays and switch banks. Once the bus data is in a software environment there is no limit to the customized display and customized analysis that can be done, or the customised program control as well - steps, breakpoints, addresses..

The Virtual Front Panel would be able to assert Temporary Master status and step through programs, addresses, vectors etc much more easily than flipping switches and possibly less prone to human error. Also write to memory, write to device, or do anything that the CPU would do.

My feeling is that all the elements of this exist already. Does the whole package exist somewhere, or are there obstacles to building it that I am not aware of?

Any comments, pointers or advice would be welcome.


September 21st, 2009, 07:48 AM
Hi Rick! Thanks! That certainly sounds like a neat project!

I am willing to help fabricate a PCB for the design along the lines of the XT-IDE and AT2XTKBD projects hosted here. I don't have a design like what you are referring to but I think a system similar to the Jade Bus Probe is possible.

For the N8VEM project, I made a ECB bus monitor PCB which is conceptually similar to the Jade Bus Probe. What you are suggesting is a more complex design though. However, it seems to me what you are suggesting could be accomplished with a modified Z80 CPU board with extra logic for halting the bus.

A VCF group project would be cool though. I have tried to start some interest in an S-100 project along those lines but so far not much interest.

Your thoughts on the matter appreciated. Thanks and have a nice day!

Andrew Lynch

September 21st, 2009, 09:02 PM
Thanks, Andrew, for your interest.

A PCB fab would be a dream! For the time being, I would be satisfied just with a working prototype! However, I propose the design principle that keeps hardware function to the bare minimum and leaves as much logic as possible to software, so that users can customise for different environments and applications, on any OS or hardware. That could make it useful to a wider range of potential users and maybe boost numbers for a PCB run.

I've looked at the Jade Bus Probe and the ECB bus probe. Jade Bus shows 96 lines but displays purely in binary LED (logically grouped). Same with classic Front Panels like Ithaca. To deal with cranky old S-100 systems, and finding non-standard or undocumented bus states applied by various system and card builders or generated by failing components, it's good to see what is happening right across the bus.

If those binary signals are made available to software instead of (or as well as) LEDs, they can be displayed on screen in hex, asci, or any custom graphical display users might find useful - while saving a lot of soldering and on-board componentry (especially if monitoring the full 96 lines).

ECB Bus Probe addresses a subset of the S-100 bus lines - the ones needed by N8VEM.

Andrew, I also looked at your design for a Passive In-Circuit Emulator (PICE) on your website http:\\n8vem-sbc.pbworks.com. It looked attractively simple for a novice like me - but I don't think a probe or emulator that connects via the Z80 socket will represent enough of the bus for s-100 hardware debug purposes.

But might your PICE design be the place to start? Extend connections to 96 of the 100 bus connector pins, and at the other end replace displays with serial out, replace switches and buttons with serial in? Or would the ECB Bus Monitor be a better place to start?

Are there reasons that one-shot program execution has to be implemented in hardware, or could it be driven by input signals more or less direct to the bus after translation from serial? The Z80 ICE gizmo seems to receive all control instructions via serial input, but executes using its on-board CPU. For debugging, execution speed should not really be an issue, but are there bus timing issues that have to be handled on the board?

I have been thinking that a few latches would be all that was needed to store the line states after input from bus and before output to bus, with simple addressing as with RAM. Is there more to it than that?

As you can see, I have more questions than answers to contribute, but am keen to discover what can be done and then do it!

all the best,


September 21st, 2009, 10:34 PM
Sounds like a 96-channel logic analyzer; I think you're going to have trouble squirting that out the serial port in real time...

September 28th, 2009, 07:50 PM
Mike- thanks for responding.

Can you please elaborate on the "real time" issue?

What are the situations where bus state cannot be paused, held in latched buffer, and written to serial out?

Offline, someone suggested that a device like a FDD controller might generate a rapid sequence of signals across a whole range of ports and bus lines in response to one command, and this could be too fast for output via serial.

But if a device is only getting its inputs, requests and ready signals etc across the bus via the serial input of the analyzer, instead of from BIOS via system CPU, won't the device have to respond only as fast as it receives instructions? Or do some devices insist on driving the bus at their own speed?

I hadn't thought of this monitor/analyzer operating in anything like normal program run-time - more like a software debug program but reading bus line states instead of CPU registers.