A colleague of mine mentioned that in college he wrote a slot machine program on an Intel 8080 using an LCD display. What kind of display communication protocol existed on the Intel 8080? How was information sent from the chip to the display?
The display in question was some sort of three 7-segmented LCDs.
The 8080 is not a microcontroller, but a microprocessor, so it had no special provision for LCD displays, as modern microcontroller may have, except maybe for the ability to use packed BCD numbers. It had no in-built host peripherals that would support protocols like RS232 or SPI.
You don't mention what kind of LCD display your college used, so this is only an assumption (and your question may be put on hold precisely due to the lack of information about this) but for the most basic LCD display, a 7-segment display, the software may have used BCD for storing numbers. That way, a number could be easily output from the data bus (8-bit parallel) to a latch "listening" in a I/O port. The output of that latch could be feed a BCD-to-7 segment converter/driver, with in turn would be connected to the display.
So, the protocol would have been 8-bit parallel (the 8080 data bus) with strobe (the signal generated by the address and bus cycle decoding , that is used to open the latch). This would have been work like this:
First, the current machine cycle must be decoded in order to know whether it is a I/O operation, memory operation, stack, instruction fetch, etc. The 8080 didn't have special pins, like the Z80A, to inform the system about the nature of the machine cycle. Instead of that, the 8080 used the SYNC pin to signal the beginning of a machine cycle, whose type would be encoded in the data bus during the time SYNC is active. The 8080 chipset included a machine cycle decoder, the 8212 controller, that was connected to the 8080 as this:
Now the hardware designer would have to use a 8-bit latch whose enable input would be triggered by certain value present in the lower part of the address bus (or most frequenctly, triggered by having a certain value in some bit of the lower address bus), and the WR signal and the OUT signal from the 8212. This 8 bit value, if packed BCD coded, can feed two 7-segment displays to show two digits.
A passive, non multiplexed 7 segment LCD display doesn't need a real "protocol" - but neither can you just apply voltage to segments from some I/O pin. LCD displays at their core need an AC drive waveform, otherwise the LC material will be quickly damaged. Multiplexed displays tend to need more than two voltage levels per drive pin, and a more involved drive waveform - they are not like multiplexed LED displays that can take advantage of the rectifier behaviour of individual display elements.
All this COULD be generated in software, if coupled with a symmetric driver circuit and/or primitive DAC (resistor networks) driven by an I/O port device (or just an address decoder + latch) or even directly off the bus. This would need CONSTANT and prioritized attention by the software, though: If your timing slips, your AC waveforms effectively get a DC bias and your LC display suffers.
A possible compromise would be using an IO port followed by clocked XOR gates (and symmetric drivers, again...).
Alternatively, either a dedicated LC driver chip, or a display with a builtin driver chip was used: In which case, these will have behaved just like any other parallel, Data+Address+Chipselect I/O device.
If you are driving a non-multiplexed LCD display, there will typically be one wire per segment, plus one common wire. The common wire needs to be driven alternately high and low, with the other wires being driven in phase with the common wires when they should be "off", and out of phase when they should be "on". A display with three digits and two decimal points could be wired to three 8-bit latches, provided that code flips the states of the wires as appropriate. One hazard of this approach is that if the latches are left in a state other than "all on" or "all off" for an extended period of time, it could damage the LCD.
An alternative approach would be to use two sets of three latches that have output enables fed by the CPU, and have three inverting latches that also have output enables connected with their outputs tied to their inputs, and have the output enables and latching control for the second latches generated by an oscillator or cycle-counter circuit which runs independently of the CPU.
