6502.org

Posted: **Mon Nov 19, 2018 10:26 am**

Just thinking out loud here, but going back to the beginning...

Might it be a worthwhile project (and I'm not volunteering right now!) to make something up that had 8 pins on a 0.1" spacing plus 2 flying leads (power & gnd) that had a suitable buffer chip and display on-board? Then, a board designer could create a row of holes on the same/standard 0.1" pitch and if needed, solder in a pin header socket - then for your 6502 system you plug it in and read the 8-bit result on the display.

So you then need 3 for a fully loaded 6502 (data bus + 16 bits of address) or 3 for the '816.

Then we're back to the decoder chips - for this scenario, a GAL might be my choice which may also allow for a different type of module that looked at bus status signals - BE/RDY/R~W, etc. and present different display patterns.

Just thoughts, but I claim the name MUD: Module for Universal Debugging

-Gordon

Posted: **Mon Nov 19, 2018 3:05 pm**

I think that's the premise of those expensive display modules with a built-in decoder and driver. Building two-digit modules by hand would be reasonable, though since I will need a 6-digit display, that means three decoders instead of just one.

There are GAL chips, both 16V8 and 22V10, which work down to 3V and are reasonably inexpensive. They don't have all that much current drive capability, so should probably be buffered for driving LEDs.

Since I don't currently have a GAL device programmer, I'm still interesting in knowing whether those MC14495 decoders will work at 3.3V, at least as far as correct decoding logic is concerned. If they have weak drive when working at low voltage, that can be addressed with a buffer just like with a GAL. It seems like something that can be tried on a breadboard by someone who already has one to hand…

Posted: **Mon Nov 19, 2018 3:27 pm**

Chromatix wrote:

Since I don't currently have a GAL device programmer, I'm still interesting in knowing whether those MC14495 decoders will work at 3.3V, at least as far as correct decoding logic is concerned. If they have weak drive when working at low voltage, that can be addressed with a buffer just like with a GAL. It seems like something that can be tried on a breadboard by someone who already has one to hand…

I have a few coming from China, but with ongoing rotating mail strikes in the Great White North for the last month and Christmas right around the corner, I expect the mail backlog to be significant.

Posted: **Mon Nov 19, 2018 3:36 pm**

Chromatix wrote:

I think that's the premise of those expensive display modules with a built-in decoder and driver. Building two-digit modules by hand would be reasonable, though since I will need a 6-digit display, that means three decoders instead of just one.

There are GAL chips, both 16V8 and 22V10, which work down to 3V and are reasonably inexpensive. They don't have all that much current drive capability, so should probably be buffered for driving LEDs.

Since I don't currently have a GAL device programmer, I'm still interesting in knowing whether those MC14495 decoders will work at 3.3V, at least as far as correct decoding logic is concerned. If they have weak drive when working at low voltage, that can be addressed with a buffer just like with a GAL. It seems like something that can be tried on a breadboard by someone who already has one to hand…

I am currently driving 4 LEDs directly off a Lattice 22v10 - that doesn't mean it's in-spec, but all I could find was a figure of about 10mA current sink capacity on the data sheet - that's good enough for an LED for a little hobby project. See https://unicorn.drogon.net/ruby-02.jpg the 4 LEDs on the right are directly driven off the 22v10 via 680Ω resistors.

However - the 3.3v thing. Do you have 5v available? If-so, then 6 years of playing with the Raspberry Pi's 3.3v GPIO pins has shown me that there is generally no issue driving (ttl and other) chips powered by 5v from the Pi 3.3v pins. (That's 3.3v Pi into 5v chip, not the other way round!) You'll also find many commercial Pi projects that to that too. 3.3v is above the TTL threshold, so it's within specification. The MC14495 seems to feature an open emitter driver via an internal 290Ω resistor - perfect for LED displays, so one chip, one 7-seg display (common cathode), but at the added requirement of needing a 5v supply for the IC. It's worth a test if you can get hold of them.

-Gordon

Posted: **Mon Nov 19, 2018 6:57 pm**

It's undoubtedly *possible* to get a 5V secondary supply in, but it would complicate the power supply, especially for allowing battery power. A local DC-DC boost converter might be the easiest option that doesn't permanently complicate the machine for a temporary peripheral device. And really, I'm a bit fed up of having to fall back on 5V TTL for random things when all the core logic will run happily (and efficiently) at 3.3V.

I suppose I always have the options of building a diode-logic ROM, or falling back on bargraph displays with 4-to-16 decoders.

Posted: **Mon Nov 19, 2018 7:03 pm**

I'm planning to handle 7-segment digit pairs with a PIC16 microcontroller that can run at either voltage. The LED current will be set by one resistor for each digit. I have kind of a lot of work to do this week though.

Posted: **Mon Nov 19, 2018 8:55 pm**

With one resistor per digit, you should implement 8-phase multiplexing with single segment per digit active at any time. Otherwise 1 will be much brighter than 8.

Posted: **Mon Nov 19, 2018 9:19 pm**

gbm wrote:

With one resistor per digit, you should implement 8-phase multiplexing with single segment per digit active at any time. Otherwise 1 will be much brighter than 8.

I suspect using a PIC that Garth can do that, however... Once upon a time I saw a project that didn't use any resistors - it was using an ATmega to drive a 4-digit display, their theory being that the duty cycle was low enough to not require resistors. It worked just fine - it was a watch, (if somewhat chunky) but I was never convinced. A program bug sticking an output on in the wrong state would have the potential to do some damage - although the whole thing was powered via a 3v lithium coin cell...

-Gordon

Posted: **Mon Nov 19, 2018 9:29 pm**

Yes, the PIC would feed one segment at a time, and the resistor would be in the common. The brightness could be controlled with duty cycle, but then the current jumps would be less friendly in terms of electrical noise.

Posted: **Tue Nov 20, 2018 10:31 am**

If it would be of help... I wrote a few different versions of code for a chap who was using the circuit below. I believe he used a '373/'573 latch driving the inputs.

Code: Select all

;
;  // PIC psuedo C code program example
;
;  char segdata [] = { 0b00111111,      // "0"   -|-|F|E|D|C|B|A
;                      0b00000110,      // "1"   -|-|-|-|-|C|B|-
;                      0b01011011,      // "2"   -|G|-|E|D|-|B|A
;                      0b01001111,      // "3"   -|G|-|-|D|C|B|A
;                      0b01100110,      // "4"   -|G|F|-|-|C|B|-
;                      0b01101101,      // "5"   -|G|F|-|D|C|-|A
;                      0b01111101,      // "6"   -|G|F|E|D|C|-|A
;                      0b00000111,      // "7"   -|-|-|-|-|C|B|A
;                      0b01111111,      // "8"   -|G|F|E|D|C|B|A
;                      0b01101111,      // "9"   -|G|F|-|D|C|B|A
;                      0b01110111,      // "A"   -|G|F|E|-|C|B|A
;                      0b01111100,      // "b"   -|G|F|E|D|C|-|-
;                      0b00111001,      // "C"   -|-|F|E|D|-|-|A
;                      0b01011110,      // "d"   -|G|-|E|D|C|B|-
;                      0b01111001,      // "E"   -|G|F|E|D|-|-|A
;                      0b01110001 };    // "F"   -|G|F|E|-|-|-|A
;
;  void Main()
;  { static unsigned char digsel = 0;   // digit select, 0 or 128
;    cmcon = 7;                         // turn comparator off
;    trisa = 255;                       // Port A all inputs
;    trisb = 0;                         // Port B all outputs
;    while(1)                           // loop forever
;    { unsigned char work = porta;      // sample inputs
;      if(digsel)                       // if left (hi) digit
;        work /= 16;                    // use hi nibble, 0..F
;      else                             // otherwise
;        work &= 15;                    // use lo nibble, 0..F
;      work = segdata[work];            // get segment data
;      work |= digsel;                  // pick up digit select bit
;      portb = work;                    // update display
;      DelayMS(8);                      // ~60 Hz refresh rate
;      digsel ^= 128;                   // toggle digit select bit
;    }                                  //
;  }                                    //
;

Some time ago I also experimented with eliminating segment current limiting resistors. That is, I drove one segment at a time (1/32nd duty cycle) while relying on the ~100-ohm Rds(on) resistance of the I/O pin MOSFET drivers for current limiting.

This scheme worked quite well driving modern hi-intensity LED displays (I was using Vcc = 5v).

It would be relatively easy to design a microcontroller based solution that could drive a 7-segment display, an HD44780 LCD, and an OLED display at the same time. Simply connect your display of choice.

I would be happy to help with PIC code and please note that it would be relatively simple to wrap the PIC firmware in an Arduino sketch and use a $2 Arduino Nano or $3 Arduino Uno and a solderless breadboard to program the PIC microcontroller via LVP (Low Voltage Programming).

Not sure why the original poster dis'ed my suggestion (he never elaborated) and I apologize if my suggestions are not in context for this thread...

Cheerful regards, Mike

Posted: **Tue Nov 20, 2018 10:40 am**

Quote:

Not sure why the original poster dis'ed my suggestion (he never elaborated) and I apologize if my suggestions are not in context for this thread...

I'm sure it, or something similar, would work and be appropriate in some projects, but it requires you to use and pre-program an MCU that's almost equal in capability to the entire rest of the project, just to light an LED display. The application I have in mind is for *bootstrapping* a project from the ground up, where the only permanently programmable storage attached is an EEPROM that's still blank. By using an MCU, that problem is reduced to that of bootstrapping the MCU, which is not really an improvement.

That's why I'm looking for solutions that can be built without using a programmable device, with a diode-logic ROM being the backstop if all else fails.

Posted: **Tue Nov 20, 2018 7:59 pm**

Chromatix wrote:

That's why I'm looking for solutions that can be built without using a programmable device, with a diode-logic ROM being the backstop if all else fails.

Dead-start definitely has its attractions. (I'm trying to remember if that's what we called it in a previous topic.) What if one of us provides pre-programmed microcontrollers to replace the no-longer-available 7-segment hex driver ICs? Then the user doesn't have to concern himself with programming it, or with any timing diagrams, or instruction protocols, etc..

Posted: **Tue Nov 20, 2018 8:01 pm**

Many microcontrollers can be programmed by USB - they need a host computer, but no extra equipment. I have mixed feelings as to whether we need two threads "dumb hex displays" and "intelligent hex displays" or if the two kinds of solutions should be able to happily co-exist. I'd like to say that we're not normally terribly protective about threads, but possibly in the past I've been (over-)protective, so I can't.

Posted: **Tue Nov 20, 2018 8:16 pm**

There certainly is a place for intelligent displays, or at least, displays that can rely on some intelligence from the host to make them work (possibly simplifying the hardware design). I was hoping specifically to find direct replacements for hex display decoders for this more basic application.

A term used in the power industry is "blackstart". It comes into play when some major power-grid anomaly knocks some or all of the grid offline, and it's necessary to bootstrap it from cold. Many large power stations actually rely on external power to get running, for auxiliary equipment like fuel conveyors, draught fans, pumps, and simply spinning the turbines up to mains frequency before taking power. Wind turbines are often of the inductive type which produce no power until an external AC potential is applied. So blackstart capability usually comes from hydropower facilities and/or large diesel generators, which are sufficient to start a gas-turbine station, which can then assist a big coal or nuke plant into working order.

Recent political events have me thinking, at least theoretically, about how to built voting machines that could actually be trustworthy. That means they have to be both robust against all sorts of casual misuse, and auditable from the hardware level upwards. A 6502-based system could be a good basis for that, since everything is big and crude enough to examine on an airport-grade X-ray machine and the source code would be small enough to examine by hand, but the number of programmable devices embedded in it would have to be strictly minimised. A GAL chip or a PIC stuck in the middle of the bootstrap process would be a giant red flag.

Posted: **Wed Nov 21, 2018 12:39 am**

Who says old school logic only runs at 5V?

A PIC16C84-04/P microcontroller supplying counting pulses to a SN74LS393 counter, which in turn is supplying binary data to a MC14495P display driver. This then is driving a red seven segment display. The whole lot is being powered from two AA cells, the current battery voltage is 2.93V as shown on the cheap multimeter

The MC14495P and the common cathode red seven segment display were obtained from China via eBay.