6502 Front Panels

[johnx993]

I would hardly consider 1975 to be late. It had a 2 year window before the appliance computer took hold. Even then, CGRS Microtech didn't get the memo and produced a machine in '78 with one.
Meanwhile, the RCA 1802 came out in 1976, and some of its most famous examples are all centered around inexpensive front panels.

By 'late' I wasn't referring to the 1977 appliance computers. I meant 'arrived late' compared to the 8080 and 6800 that arrived a year earlier in 1974.
And the 1802 was really more of a controller than a general purpose CPU. But still suited for the 'trainer board' class of machines. I still have my Elf II.

 

[jplr]

Also, I'm pretty sure Usagi's machine is a PDP-11/44 and has an 8085 for the task y'all are describing.

The 11/44 /EK-11044-UG-003 user guide agrees with you (see page 1-12)

 

[Eudimorphodon]

#3 David Brader's Kompuutar (1977): a homebrew machine described in Byte Magazine from November of 1977. As far as I can tell, a one-off since no evidence indicates that anyone besides David built one to his instructions. If someone did, I would love to hear about it. The only other piece of information about it is an addendum in a later issue, but no other historical references to this machine appear to have been recorded within the scope of the modern internet. I contacted him last year, but he wasn't interested in talking about the project's history. Can't say I didn't try...
Byte Magazine Volume 02 Number 11

This is a really impressive piece of work... but it's also technically *not* really a "front panel" in the Altair sense? It actually appears to be pretty much fully software driven. (IE, it's basically a binary-entry equivalent of something like the KIM-1's hex keypad.)

I guess what's kind of ironic is by 1977 you could build a simple TV interface terminal with a similar number (if not fewer) parts.

 

[bsd64]

This is a very interesting historical discussion. I don't know of a comprehensive exploration focusing specifically on this aspect of computer history. So, it would be very interesting if someone were to compile this information - not only about the early 6502 front panel computers, but on the evolution of the computer 'front panel interface'. What was interesting to me as I explored this - and you guys have pointed out in the comments above - is that panels on the surface may appear quite similar, but are actually implemented very differently on the back end.

You have this whole evolution from when panels were at first tightly integrated into the CPU and perhaps had an addressable 'switch' register, to where they might be 'partially integrated' where the CPU, to where they resided completely outside the CPU and operated on it or the bus directly. You also have this co-evolution with the gradual integration with ROMS - from no integration where the panel was required to bootstrap and debug, to partial integration where you might have a 'load program' switch on the panel, to full reliance on ROMs for the front panel operation, to finally the front panel disappears completely; a very interesting topic really.

The comments above were reflecting that in the timeline of front panels, their use with the 6502 came about towards the tail end. I would suggest that cost was specifically an important additional factor with front panel integration with the 6502. One thing that set the 6502 apart was its incredibly low cost. When you consider the large (in comparison) expense of wiring up a complex front panel, and its lowered usefulness at the time, it was probably seen as cost-prohibitive - especially for commercial 6502 computers - and why there are so few examples.

 

[MiaM]

As has already been hinted at in this thread, a 6502 kind of works against having a front panel. In particular there is no wait/halt input to cause some sort of infinite wait state, it's not static so it loses it's state if the clock runs too slow (the program counter when forcing the data bus to a "NOP" seems to give up at about 7½Hz with the anecdotal sample of one chip a friend tried this on 3+ decades ago, while IIRC the spec says at least 100kHz. Also the address lines are always driven by the 6502.

Thus you would need to restart the 6502 each time you use a frond panel, or add some tricks in the form of feeding the CPU NOPs for each cycle while the front panel stores where the CPU was about to execute code from when switching to front panel mode, and add a way to go back to where you were. A way of doing this is just to let the 6502 continue executing NOPs until it's at the desired address and then "release" it. (Side track: This is also a way of starting a Z80 computer with ROM only at the top of memory, suitable for CP/M. Instead of switching in a mirror of the ROM at the start of memory, just push a NOP to the bus instead of RAM reads until the actual ROM space is reached).

The only real use case I can see for a 6502 front panel would be for a DIY/kit computer where you would want to start out with being able to read/write RAM before even installing the CPU, and also being able to build a computer without having access to pre programmed ROMs.

I also think we can look at things the other way around, I.E. not ask why so few 6502 computers had front panels, but rather why 8080 and earlier computers had front panel and to me the clear answer is that Intel and others didn't provide a mask programmed monitor ROM to go with the CPU. Or to put it on other words, Motorolas monitor ROM for the 6800 is indirectly why there were so few 6502 systems with a front panel.

Btw, re OSI, they made various CPU cards, IIRC including one that used a 12-bit data bus with a CPU compatible with some PDP (can't remember which). This might had been a reason for having a front panel, i.e. at leats in theory there would had been many combinations of CPU and I/O and they would had had to have ROM versions for each supported combination. (In practice I would think that all systems used a 6502 and any combination of additional processors, but rarely if ever being without a 6502, so this might not had been a big issue, but still).

 

[jlang]

@Bruce Tomlin "Yeah, EPROM killed the front panel."

I agree. Even with the cost of a ROM monitor it was way cheaper than a couple dozen switches. (even in the 70's)
My favorite minicomputer (PDP-11) abandoned the blinken lights with the LSI-11.
The monitor was built into the CPU (ODT) the front panel was reduced to power, run/halt and reset.

 

[cjs]

It is an 11/03 and they use firmware in prom on the console interface board

I'm glad we're in agreement on that!

The misinformation people are pulling out of their butts about DEC systems here is annoying

It was a joke....

On the IMSAI, was the front panel a static device? That is, was it raw electronics? How did the IMSAI panel specify a starting run address to the CPU? In contrast to the KIM-1 keypad, which was driven by software.

Yes, the front panel was straight LSI electronics. It worked by "jamming" JMP and NOP instructions on to the bus and making the CPU execute those, among other things. It's very illuminating to examine the schematics for the front panel board (this one may be easier to read, though less complete) and read §Display/Control Board Operation (p.5) in the Theory of Operation, which doesn't do too bad a job of explaining how it works.

I don't know about early 8080, but early 6502, pre-CMOS, it was not a static device, so it had to always be "running", it always needed a clock. You can't just HALT it.

This is correct, but....

a 6502 kind of works against having a front panel. In particular there is no wait/halt input to cause some sort of infinite wait state

This is wrong. From the original datasheet:

Ready (RDY)​

This input signal allows the user to single cycle the microprocessor on all cycles except write cycles. A​

negative transition to the low state during or coincident with phase one (Φ₁) will halt the microprocessor​

with the output address lines reflecting the current address being fetched. This condition will remain​

through a subsequent phase two (Φ₂) in which the Ready signal is low . This feature allows microprocessor interfacing with low speed PROMS as well as fast (max. 2 cycle) Direct Memory Access (DMA). If Ready is low during a write cycle, it is ignored until the following read operation.​

The MCS6500 Family Hardware Manual gives circuits for doing this reliably, IIRC.

When you consider the large (in comparison) expense of wiring up a complex front panel, and its lowered usefulness at the time, it was probably seen as cost-prohibitive - especially for commercial 6502 computers - and why there are so few examples.

Well, as I mentioned earlier, whether or not it was cost-prohibitive depends on the cost of your other options, in particular, EPROM and ROM.

I believe that even in 1974, mask ROM was cheaper than a front panel. However, the setup costs for mask ROM were quite high, so if you didn't anticipate selling a large enough quantity to cover the up-front costs, that fell off your list of alternatives. But some vendors (such as Motorola) did their own mask ROM with a monitor in it that you could buy fairly cheaply, so if that happened to be available and you could design your machine to work with it, it was an option again.

EPROMs were pretty expensive at the start of 1974, but got quite a bit cheaper over the next couple of years. At one point I actually went through magazines from 1974 through about 1978 to noted the prices, but I think I have lost those notes, sadly. But at the start of 1974 I am pretty sure that you could build a front panel board for less than a board with an EPROM and a serial interface. (And who had a terminal at the start of 1974, anyway?)

 

[MiaM]

Oh, good point, I forgot about RDY.

Either way, you'd need to have separate logic to be able to drive the address bus from the front panel, and the 6502 would repeat the same bus cycle over and over, so if you happen to pause it in a write cycle you might need buffers to tri state the data bus too.

Re ROMs: The main thing is that the CPU manufacturer could afford the cost of creating a ROM. Motorola did that for general consumption, MOS only did it in small quantities (their own KIM-1 and before that the JOLT). I assume that the introduction of the PET and other 6502 based computers without front panels killed off any market and incentives for selling the KIM-1 style RRIOT 6530 chips with the monitor ROM.

Going off on a tangent: There were a MCS-650 or whatever it was called, development system, for the 6502, that seems to have been lost. I.E. there are photos and IIRC stories that confirm that it did actually exist and people used it, but no known one seems to survive and IIRC also no known ROM dumps, schematics or whatnot seems to survive. This seems to be the one major lost item in the history of the 6502 and for that same the company MOS and the company Commodore, kind of sort of.

 

[cjs]

...so if you happen to pause it in a write cycle you might need buffers to tri state the data bus too.

Hm. I read, "on all cycles except write cycles" and, "If Ready is low during a write cycle, it is ignored until the following read operation" to mean that the CPU would never pause during write cycles, so that this wouldn't be an issue.

 

[MiaM]

Good, that reduces the chip count a bit. Still the address bus and obviously the read/write signal would need to have additional chips to tri state / mux them between the CPU or the front panel driving the signals.

 

[cjs]

Still the address bus and obviously the read/write signal would need to have additional chips to tri state / mux them between the CPU or the front panel driving the signals.

Can you remind me why the Altair technique (with the CPU, instead of the front panel, driving the address lines) won't work?

 

[Bruce Tomlin]

Can you remind me why the Altair technique (with the CPU, instead of the front panel, driving the address lines) won't work?

It probably could work, but it would still be easier to get the CPU to do it with a monitor program. An interesting difference is the reset behavior that fetches the initial PC. That could also make things easier since you don't need to jam a JMP instruction, just hit reset and the next two clocks pull it in for you. It's easier to make a state machine for two cycles than for three.

There's also that interrupts on the 8080 were done by jamming RST instructions, so an opcode jamming circuit would already be needed anyhow.

 

[Al Kossow]

are there any hobby microprocessor systems being built with an LCD front panel that can display the uP's entire machine state as either blinkenlights or hex/octal digits?
that would be cool to see

 

[cjs]

It probably could work, but it would still be easier to get the CPU to do it with a monitor program.

Yes, but that's no different from the 8080.

My question was not really about should you build a front panel in any particular situation, but if you did, can you do it in the same way as the Altair 8080 front panel?

An interesting difference is the reset behavior that fetches the initial PC. That could also make things easier since you don't need to jam a JMP instruction, just hit reset and the next two clocks pull it in for you. It's easier to make a state machine for two cycles than for three.

Oh, nice point! I'd not thought of doing it that way.

There's also that interrupts on the 8080 were done by jamming RST instructions, so an opcode jamming circuit would already be needed anyhow.

I don't recall if the original Altair CPU board supported interrupts, but if it did, that would have been a completely different set of circuitry from the front panel system unless I'm missing something really clever in the schematics.