Yes, it was common. You have the trade-off between writing a bit more code or using more hardware IO pins.
You can get away with as little as one resistor per digit and nothing else - see e.g.
https://projects.drogon.net/wp-content/ ... 7/led2.jpg This is on a Raspberry Pi, but the principle is the same. In this scenario I'm only lighting up one segment at a time so I have to rely on the software loop to scan fast enough to get them bright enough for persistence of vision to work without flicker.
(Note that the Pi can sink the same amount of current as it can source - not all IO chips or microcontrollers can, so this might not apply)
This article shows using one resistor per segment and a transistor to drive each digit (actually a uln2803, but the same idea)
https://projects.drogon.net/raspberry-p ... t-drivers/ (see note below)
I prefer that way as it's lighting up one digit at a time rather than one segment which can reduce the flicker and make the software easier but it needs more hardware.
So 6 digits (which I presume you mean), I'd do it as follows: Use one 8-bit port for the segments. Put 8 resistors on the 8 outputs and connect to the segments which you've all wired in parallel - ie. segment A on digit 1 to segment A to digit 2 and so on. (Make sure the port can source enough current when all 8 are on!)
The common pin for each digit wired to a suitable transistor (or darlington) (and this will depend on you using common anode or common cathode digits). You may need a resistor to the base of the transistor, pick one to make sure the transistor is fully saturated when you turn it on. These 6 outputs go to 6 pins on the other VIA port.
Then:
Foreach digit
output the segments to make the actual number on the 8-bit port (use a 16-byte lookup table in ROM to map a 4-biy hex number to an 8-bit segment pattern)
enable common pin on that digit
delay (maybe just a millisecond or so)
disable common pin
repeat
If you had a regular interrupt routine then it could do one step of that loop every interrupt, picking up the data from 6 memory locations, then all you need do is update the memory locations from any code and it will "magically" appear on the display.
Simples
You can optimise the VIA ports by using external hardware, but you're then in the world of trading off software for more hardware and so on and only you'll know what's best - e.g. your counter idea. Use a single pin on the VIA (say one of the control lines) to clock the counter going to the transistor to enable each digit in turn. You either need to know the initial state, or have another line to act as reset for the counter. If I really had to optimise the VIA pins, then 3 pins would get me into 2 74x595 shift registers which would be enough to drive up to 8 digits - the software outputting a 16-bit value each cycle - 8 bits into the segments and 8 into the digit drivers. (Maybe even using the shift-register in the VIA to clock the data out)
I think the eeprom idea is nice, but overkill - you're using the eeprom as a 4 to 8 decoder (as I understand it). There are 74 series TTL that do it though - see 7446 through 7479 although that's optimising the bits on the VIA - using only 3 bits rather than 8 to drive each segment.
Cheers,
-Gordon
Note: That display is off an Elektor Junior Computer which I made many years ago then stupidly stupidly stupidly cannibalised for bits for another 6502 project. What a muppet. Every time I see that display I kick myself. Ah well. Hindsight and all that!
_________________
--
Gordon Henderson.
See my
Ruby 6502 and 65816 SBC projects here:
https://projects.drogon.net/ruby/