26 Oct
2010
26 Oct
'10
3:59 p.m.
Was there ever such a thing as a 74x00 series LED driver that did proper hex
decoding and not simply BCD? I can't seem to find that there was.
The topic of why split octal was used on some early micro-computers came up
on a list. After doing a search for a TTL LED driver that does hex, the
answer is probably that there were no single chip option for hex displays.
Split octal was just easier.
This kind of joins in with the TIL311 discussion. It was a TTL compatible
hex display, but expensive at the time.
-chuck
26 Oct
26 Oct
4:47 p.m.
On 26 Oct 2010 at 18:59, Charles Dickman wrote:
Was there ever such a thing as a 74x00 series LED
driver that did
proper hex decoding and not simply BCD? I can't seem to find that
there was.
Sure, the Fairchild 9370, 9368 and 9374. All include a latch (a nice
feature).
--Chuck
4:51 p.m.
Were they very common? Fairchild was pretty early in LEDs too I think?
-chuck
On Tue, Oct 26, 2010 at 7:47 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 26 Oct 2010 at 18:59, Charles Dickman wrote:
Was there ever such a thing as a 74x00 series LED
driver that did
proper hex decoding and not simply BCD? I can't seem to find that
there was.
Sure, the Fairchild 9370, 9368 and 9374. All include a latch (a nice
feature).
--Chuck
5:07 p.m.
On 26 Oct 2010 at 19:51, Charles Dickman wrote:
Were they very common? Fairchild was pretty early in
LEDs too I
think?
Montsanto (they of Roundup fame) were the early birds in LEDs. I
remember ordering a 4-LED sample pack from them.
National was a second source for the Fairchild ICs (i.e. look for
parts with a DM93xx part number). I don't know that they were
particularly uncommon.
--Chuck
5:03 p.m.
On 26 Oct 2010 at 18:59, Charles Dickman wrote:
> Was there ever such a thing as a 74x00 series LED driver that did
> proper hex decoding and not simply BCD? I can't seem to find that
> there was.
Also, any of the bipolar PROMs of at least 32 bits (8x4) would do,
e.g. 74S188/288, 82S23/123, etc.
You could even roll your own with a diode matrix and a 4-to-16 demux.
Myself, I've always wondered about a BCD-to-Roman numeral decoder IC.
--Chuck
5:13 p.m.
On 26/10/2010 6:03 PM, Chuck Guzis wrote:
You could even roll your own with a diode matrix and a
4-to-16 demux.
Myself, I've always wondered about a BCD-to-Roman numeral decoder IC.
Remember
Intercal does have a C compiler for it. I think it outputs
Roman Numerals.
Ben.
--Chuck
Check language doc's ... yep Roman numerals output,
standard written English digits for input like FOUR SEVEN ZERO.
http://www.catb.org/esr/intercal/stross.html
27 Oct
27 Oct
4:01 p.m.
Sure, the Fairchild 9370, 9368 and 9374. All include a latch (a nice
feature).
--Chuck
Heh heh.
This reminded me of a project I did in a hardware interfacing class a
very long time ago.
The project was to interface two 7 segment displays to a single 8 bit
I/O port - The design specs required that the displays should be able to
show hex characters, and be turned off - It was clear that the *intent*
of the assignment was that we were supposed to be learning about
scanning displays.
My lecturer was very surprised when I turned in a PCB with two 7 segment
displays, and two 9374 chips. I tied the data lines together, and
brought the individual latch and Ripple Blanking lines out - two port
writes were all that was required to display anything - and there was
none of that messy scanning required to keep the display updated. Using
the ripple blanking inputs, allowed me to turn off each display
individually.
I got an A, and the assignment sheet was updated to prevent the solution
in the future!!
Doug Jackson
26 Oct
26 Oct
5:13 p.m.
Charles Dickman wrote:
The topic of why split octal was used on some early
micro-computers came up
on a list. After doing a search for a TTL LED driver that does hex, the
answer is probably that there were no single chip option for hex displays.
Split octal was just easier.
The 8080 instruction encoding is based on 3 bit fields
for register
selection, so octal is natural. Split octal for 16-bit addresses
resulted from the way 16-bit addresses were stored in memory as two
consecutive bytes. If a JMP instruction was stored in memory in octal
as 303 222 111, it was more natural to consider the address to be 111
222 in split octal rather than 044622 in 16-bit octal.
Note that the Z80 uses a superset of the instruction encodings of the
8080, so the same argument would apply, but Zilog pushed the use of
hexadecimal.
Eric
5:40 p.m.
On 26 Oct 2010 at 17:13, Eric Smith wrote:
The 8080 instruction encoding is based on 3 bit fields
for register
selection, so octal is natural. Split octal for 16-bit addresses
resulted from the way 16-bit addresses were stored in memory as two
consecutive bytes. If a JMP instruction was stored in memory in octal
as 303 222 111, it was more natural to consider the address to be 111
222 in split octal rather than 044622 in 16-bit octal.
When I wrote a cross-assembler for the 8008, I used octal. When I
went to the 8080, I used hex. The only difference was the projects I
worked with at the day job--one mainframe used octal; the other used
hex. Both from the same manufacturer.
I liked the IMSAI scheme of color-coding the front panel toggles, so
you could group them by 3 or 4 as your preference demanded.
I found that octal on the PDP-11 with 16-bit words and 8 bit bytes
was unnecessarily confusing.
The GI CP1600 16-bit micro also used octal. A waste of ink.
So, what's best (octal or hex) for a system with 33 bit words and 11
bit characters?
--Chuck
9:49 p.m.
On 26 Oct 2010 at 21:36, Fred Cisin wrote:
Howzbout using base eleven
0 1 2 3 4 5 6 7 8 9 A
Heh. It has long seemed to me that 10 bits is the perfect length for
a byte. It gives you 1024 binary combinations and can also be used
to represent decimal numbers (0-999) with high efficiency. 1023
character possiblities would seem to be sufficient for all but the
logographic writing systems (e.g. Kanji).
I seem to recall an article in the HP Journal during the 80's that
discussed doing decimal arithmetic by using words consisting of
"digits" of 10 bits. Does anyone else remember this?
--Chuck
27 Oct
27 Oct
7:11 a.m.
On 10/26/10 8:40 PM, Chuck Guzis wrote:
The IMSAI 8080 also has both octal and hexadecimal groupings above
the first row of LEDs, printed on the sheet that sits between the two
parts of the plexiglas bezel.
-Dave
--
Dave McGuire
Port Charlotte, FL
The 8080
instruction encoding is based on 3 bit fields for register
selection, so octal is natural. Split octal for 16-bit addresses
resulted from the way 16-bit addresses were stored in memory as two
consecutive bytes. If a JMP instruction was stored in memory in octal
as 303 222 111, it was more natural to consider the address to be 111
222 in split octal rather than 044622 in 16-bit octal.
When I wrote a cross-assembler for the 8008, I used octal. When I
went to the 8080, I used hex. The only difference was the projects I
worked with at the day job--one mainframe used octal; the other used
hex. Both from the same manufacturer.
I liked the IMSAI scheme of color-coding the front panel toggles, so
you could group them by 3 or 4 as your preference demanded. 
1:12 p.m.
I found that octal on the PDP-11 with 16-bit words and
8 bit bytes
was unnecessarily confusing.
Except that the many of the PDP11 instructions are easy to decode if
written in octal (4 bit opcode, 3 bit addressing mde, 3 bit register
select, 3 bit addressing mode, 3 bit register select). I would hate to
have to work with PDP11 machine code in hex...
-tony
2:56 p.m.
On 27 Oct 2010 at 21:12, Tony Duell wrote:
Except that the many of the PDP11 instructions are
easy to decode if
written in octal (4 bit opcode, 3 bit addressing mde, 3 bit register
select, 3 bit addressing mode, 3 bit register select). I would hate to
have to work with PDP11 machine code in hex...
...and octal makes it so easy to read packed BCD.
I think the opcode subfield length determining the display radix of a
system is a red herring. Because the Atmel AVR microcontrollers have
32 8-bit registers, should base-32 be used as the display radix?
--Chuck
28 Oct
28 Oct
noon
I think the opcode subfield length determining the
display radix of a
system is a red herring. Because the Atmel AVR microcontrollers have
32 8-bit registers, should base-32 be used as the display radix?
What is wrong with base 32 :-)
Mroe seriously, there are undoubtedly many instruction sets that are no
easier to decode whether written in hex or octal. And for those it makes
no difference which you use. But there are soem that are a lot easier to
understnad in one number system than in the other, and for those it makes
sense, at least to me, to use said number ssytem. The PDP11 is one such.
It's easy to hand-assemble/disassemble when written in octal, a lot
harder when written in hex.
-tony
26 Oct
26 Oct
5:59 p.m.
It was thus said that the Great Eric Smith once stated:
Charles Dickman wrote:
The 8086 instruction set makes more sense viewed as octal than as
hexidecimal. The 6809 (which I learned before the 8086) makes sense viewed
as hexidecimal.
-spc (Really loved the Motorola chips ... )
The topic of why split octal was used on some
early micro-computers came up
on a list. After doing a search for a TTL LED driver that does hex, the
answer is probably that there were no single chip option for hex displays.
Split octal was just easier.
The 8080 instruction encoding is based on 3 bit fields
for register
selection, so octal is natural. Split octal for 16-bit addresses
resulted from the way 16-bit addresses were stored in memory as two
consecutive bytes. If a JMP instruction was stored in memory in octal
as 303 222 111, it was more natural to consider the address to be 111
222 in split octal rather than 044622 in 16-bit octal.
27 Oct
27 Oct
1:07 p.m.
The 8080 instruction encoding is based on 3 bit fields
for register
selection, so octal is natural. Split octal for 16-bit addresses
resulted from the way 16-bit addresses were stored in memory as two
consecutive bytes. If a JMP instruction was stored in memory in octal
as 303 222 111, it was more natural to consider the address to be 111
222 in split octal rather than 044622 in 16-bit octal.
As an aside. I've worked on a machine with an 8-bit microcode address
that was normally written as 4 octal digits. The address was split into 2
nybbles (this makes a lot of sense based ont he procressor design) and
each nyble was writen as as octal number from 00 to 17. So the highest
address was written as 1717.
[It's the HP9800 CPU if anyone's curious...]
-tony
2:26 p.m.
________________________________
From: Tony Duell <ard at p850ug1.demon.co.uk>
As an aside. I've worked on a machine with an 8-bit microcode address that was
normally written as 4 octal digits. The address was split into 2 nybbles (this
makes a lot of sense based ont he procressor design) and each nyble was writen
as as octal number from 00 to 17. So the highest address was written as 1717.
[It's the HP9800 CPU if anyone's curious...]
I'm interested. Those are great little machines. I think it would be really
interesting to put that CPU in an FPGA. Are there some documents describing the
architecture and the microcode?
Dave
28 Oct
28 Oct
11:35 a.m.
[It's the HP9800 CPU if anyone's curious...]
I'm interested. Those are great little machines. I think it would be really
interesting to put that CPU in an FPGA. Are there some documents describing the
architecture and the microcode?
Personally I'd rather have the original processor in 80 (or so) simple
logic chips and ROMs, but anyway...
There are many sources of information on these machines, there's probably
enough infroamtion out there to recreate them.
THe patents for these machines (separate ones for the 9810, 9820 and
9830) are very informative and include schematics and firmware listings
for the prototypes and some their options. Th production machines do
differ in some details, so be caareful if you use this information to
repair one. I can't rememebr the patent numbers, but I think they're on
Eric Smith's site (http://www.brouhaha.com/), or I can see if I can dig
them out.
There's a lot of information (user manuals, HP service manuals
(boardswapper guides) and schematics) on http://www.hpmuseum.net/
There's an hp9800 emulator (I can't rememebnr what it runs on...) which
includes dumps of the firmware ROMs. I think it's linked from sourceforge.
I have dumps of the CPU micorocde and ALU roms. I also have an annotated
CPU microcode source listing. I'll be happy to make thes available.
For reference, here's the CPU microcode word format :
HP98x0 microcode word bits
---------------------------
0 : Toggle uA4 )
1 : Toggle uA5 ) Select condition (Qualifier)
2 : Toggle uA6 )
3 : Toggle uA7 )
4 : Toggle uA1
5 : Toggle uA2
6 : Toggle uA3
7 : Toggle uA0
8 : )
9 : ) Number of shift clocks - 1
10 : )
11 : )
12 : Rd A/B (If R=0, QmuJMP, if R=1, I/O operation)
13 : ALU(1)
14 : ALU(0)
15 : IQN (Inhibit shift clock by condition)
16 : R(2)
17 : R(1)
18 : R(0)
19 : Enable condition
20 : ALU(2)
21 : X(1)
22 : X(2)
23 : X(0)
24 : ALU S input control SC(1)
25 : ALU S input control SC(0)
26 : ALU -> T register
27 : ALU -> M register
SC(1) SC(0)
0 0 0 -> S_ALU
0 1 M -> S_ALU
1 0 T -> S_ALU
1 1 1 -> S_ALU
R(2) R(1) R(0)
0 0 0 1 -> R_ALU
0 0 1 P -> R_ALU
0 1 0 T -> E, E -> R_ALU
0 1 1 Memory Write (Treg -> memory)
1 0 0 ALU -> Q(6)
1 0 1 Q -> R_ALU
1 1 0 Memroy Read (memory -> Treg)
1 1 1 0 -> R_ALU
X(2) X(1) X(0)
0 0 0 ALU -> Q
0 0 1 Q(11) -> A/B select Flip-Flop, clear BCD carry
0 1 0 ALU BCD mode
0 1 1 ALU -> E, E -> R_ALU
1 0 0 Invert A/B select Flip-Flop
1 0 1 ALU -> P
1 1 0 ALU -> A/B
1 1 1 None of the above
If X=3 and R=2, then ALU -> A/B (not E), E->R_ALU, and 0->E
ALU(2) ALU(1) ALU(0)
0 0 0 XOR
0 0 1 AND
0 1 0 IOR
0 1 1 Zero
1 0 0 Zero, clear carry
1 0 1 IOR, clear carry
1 1 0 IOR, set carry
1 1 1 Add
Conditions
0 : Q(0)
1 : Q(1)
2 : Q(2)
3 : Q(3)
4 : Q(4)
5 : Q(5)
6 : Q(6)
7 : Carry
8 : P bit 0
9 : Q(15)
10 : Memory reference instruction
11 : Q(10)
12 : I/O flag
13 : Q(8)
14 : BCD Carry
15 : I/O running
And the CPU machine code instruction set :
Memory Reference
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADA IND 0 0 0 0 Z/C | Address |
ADB IND 0 0 0 1 Z/C | Address |
CPA IND 0 0 1 0 Z/C | Address |
CPB IND 0 0 1 1 Z/C | Address |
LDA IND 0 1 0 0 Z/C | Address |
LDB IND 0 1 0 1 Z/C | Address |
STA IND 0 1 1 0 Z/C | Address |
STB IND 0 1 1 1 Z/C | Address |
IOR IND 1 0 0 0 Z/C | Address |
ISZ IND 1 0 0 1 Z/C | Address |
AND IND 1 0 1 0 Z/C | Address |
DSZ IND 1 0 1 1 Z/C | Address |
JSM IND 1 1 0 0 Z/C | Address |
JMP IND 1 1 0 1 Z/C | Address |
Shift
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
AAR 0 1 1 1 0 X X | Shift | X 0 0 0 0
ABR 0 1 1 1 1 X X | Shift | X 0 0 0 0
SAR 0 1 1 1 0 X X | Shift | X 0 0 1 0
SBR 0 1 1 1 1 X X | Shift | X 0 0 1 0
SAL 0 1 1 1 0 X X | Shift | X 0 1 0 0
SBL 0 1 1 1 1 X X | Shift | X 0 1 0 0
RAR 0 1 1 1 0 X X | Shift | X 0 1 1 0
RBR 0 1 1 1 1 X X | Shift | X 0 1 1 0
Skip/Alter
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
SZA 0 1 1 1 0 0 | Skip Offset | 0 1 0 0 0
SZB 0 1 1 1 1 0 | Skip Offset | 0 1 0 0 0
RZA 0 1 1 1 0 1 | Skip Offset | 0 1 0 0 0
RZB 0 1 1 1 1 1 | Skip Offset | 0 1 0 0 0
SIA 0 1 1 1 0 0 | Skip Offset | 1 1 0 0 0
SIB 0 1 1 1 1 0 | Skip Offset | 1 1 0 0 0
RIA 0 1 1 1 0 1 | Skip Offset | 1 1 0 0 0
RIB 0 1 1 1 1 1 | Skip Offset | 1 1 0 0 0
SLA 0 1 1 1 0 S | Skip Offset | C 1 0 0 1
SLB 0 1 1 1 1 S | Skip Offset | C 1 0 0 1
SAM 0 1 1 1 0 S | Skip Offset | C 1 0 1 0
SBM 0 1 1 1 1 S | Skip Offset | C 1 0 1 0
SAP 0 1 1 1 0 S | Skip Offset | C 1 0 1 1
SBP 0 1 1 1 1 S | Skip Offset | C 1 0 1 1
SES 0 1 1 1 0 S | Skip Offset | C 1 1 0 0
SEC 0 1 1 1 1 S | Skip Offset | C 1 1 0 1
Register Reference
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
ADA 0 1 1 1 A/B X X IND 0 0 0 0 1 1 1 1
ADB 0 1 1 1 A/B X X IND 0 0 0 1 1 1 1 1
CPA 0 1 1 1 A/B X X IND 0 0 1 0 1 1 1 1
CPB 0 1 1 1 A/B X X IND 0 0 1 1 1 1 1 1
LDA 0 1 1 1 A/B X X IND 0 1 0 0 1 1 1 1
LDB 0 1 1 1 A/B X X IND 0 1 0 1 1 1 1 1
STA 0 1 1 1 A/B X X 1 0 1 1 0 1 1 1 1
STB 0 1 1 1 A/B X X 1 0 1 1 1 1 1 1 1
IOR 0 1 1 1 A/B X X IND 1 0 0 0 1 1 1 1
ISZ 0 1 1 1 A/B X X 1 1 0 0 1 1 1 1 1
AND 0 1 1 1 A/B X X IND 1 0 1 0 1 1 1 1
DSZ 0 1 1 1 A/B X X 1 1 0 1 1 1 1 1 1
JSM 0 1 1 1 A/B X X 1 1 1 0 0 1 1 1 1
JMP 0 1 1 1 A/B X X IND 1 1 0 1 1 1 1 1
DMA/extras
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
CMA 0 1 1 1 0 X X X X X 1 0 1 1 1 0
CMB 0 1 1 1 1 X X X X X 1 0 1 1 1 0
TCA 0 1 1 1 0 X X X X X 1 1 1 1 1 0
TCB 0 1 1 1 1 X X X X X 1 1 1 1 1 0
EXA 0 1 1 1 0 X X X X X 0 0 1 1 1 0
EXB 0 1 1 1 1 X X X X X 0 0 1 1 1 0
CMA 0 1 1 1 0 X X X X X 0 1 1 1 1 0
I/O group
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
STF 1 1 1 1 X 1 0 1 1 1 1 | Select Code |
CLF 1 1 1 1 X 1 1 1 1 1 1 | Select Code |
SFC 1 1 1 1 X 1 H/C 1 1 1 0 | Select Code |
SFS 1 1 1 1 X 1 H/C 1 0 1 0 | Select Code |
CLC 1 1 1 1 X 1 H/C 1 0 1 1 | Select Code |
STC 1 1 1 1 X 1 H/C 1 1 0 0 | Select Code |
OT* 1 1 1 1 A/B 1 H/C 0 0 1 1 | Select Code |
LI* 1 1 1 1 A/B 1 H/C 0 1 0 1 | Select Code |
MI* 1 1 1 1 A/B 1 H/C 0 0 0 1 | Select Code |
Macro Group
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
RET 1 1 1 1 0 0 0 1 0 0 0 0 0 0 1 0
MOV 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 0
CLR 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
XFR 1 1 1 1 0 0 0 0 0 0 0 0 0 1 0 0
MRX 1 1 1 1 1 0 0 1 0 0 0 1 1 0 0 0
MRY 1 1 1 1 1 0 0 1 0 0 1 1 1 0 0 0
MLS 1 1 1 1 0 0 1 1 0 0 0 0 0 0 0 0
DRS 1 1 1 1 0 0 0 1 0 0 0 0 1 0 0 0
DLS 1 1 1 1 1 0 1 1 0 0 0 0 0 0 0 0
FXA 1 1 1 1 0 0 0 1 0 1 1 1 0 0 0 0
FMP 1 1 1 1 0 0 1 1 0 0 1 1 0 0 0 0
FDV 1 1 1 1 0 0 0 1 0 0 0 1 0 0 0 0
CMX 1 1 1 1 1 0 0 1 0 0 0 0 0 0 0 0
CMY 1 1 1 1 0 0 0 1 0 0 0 0 0 0 0 0
MDI 1 1 1 1 0 0 0 1 0 1 1 0 0 0 0 0
NRM 1 1 1 1 0 0 1 1 0 0 1 0 1 0 0 0
I am happy to chat about these fine amchines (I have a 9810, 9820 and
9830, all fo which I've reparied...) as much as you like :-)
-tony
27 Oct
27 Oct
4:26 p.m.
On the subject of binary to hex 7-segment decoders, has anyone
ever seen a DM9368? ISTR that it's a pre-programmed PROM of
some kind, taking in four bits of binary (plus some ripple
blanking pins) and outputting 7-segment drive signals for
0-9 and A-F.
A copy of the data sheet for the chip:
http://socrates.berkeley.edu/~phylabs/bsc/PDFFiles/DM9368.pdf
--
John Honniball
coredump at gifford.co.uk
5:07 p.m.
On 28 Oct 2010 at 0:26, John Honniball wrote:
On the subject of binary to hex 7-segment decoders, has anyone
ever seen a DM9368? ISTR that it's a pre-programmed PROM of
some kind, taking in four bits of binary (plus some ripple
blanking pins) and outputting 7-segment drive signals for
0-9 and A-F.
No, there's a latch in there also. As I mentioned yesterday, it's
part of the Fairchild 9368/9370/9374 series.
As a pure ROM, you may be thinking of the MC4039, which, by
Motorola's admission, was nothing but a preprogrammed version of the
XC170 128-bit mask ROM. Circa 1969.
The same ROM was used as the MC4001 BCD-to-Binary/Binary-to-BCD
encoder.
--Chuck
9:13 p.m.
On 2010 Oct 27, at 5:07 PM, Chuck Guzis wrote:
On 28 Oct 2010 at 0:26, John Honniball wrote:
.. they also differ from straight ROMS in their drive capabilities of
course.
The 68 and 74 have constant-current drivers for LEDs.
Then there was National's oddball inverse-function IC: 7-segment input
converted to BCD out.
On the subject of binary to hex 7-segment
decoders, has anyone
ever seen a DM9368? ISTR that it's a pre-programmed PROM of
some kind, taking in four bits of binary (plus some ripple
blanking pins) and outputting 7-segment drive signals for
0-9 and A-F.
No, there's a latch in there also. As I mentioned yesterday, it's
part of the Fairchild 9368/9370/9374 series As a pure ROM, you may be thinking of the MC4039,
which, by
Motorola's admission, was nothing but a preprogrammed version of the
XC170 128-bit mask ROM. Circa 1969.
The same ROM was used as the MC4001 BCD-to-Binary/Binary-to-BCD
encoder.
28 Oct
28 Oct
7:47 a.m.
On Thu, Oct 28, 2010 at 12:13 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Then there was National's oddball inverse-function
IC: 7-segment input
converted to BCD out.
I have one of those in a binary clock kit. The clock chip is one of
the standard National Semiconductor 1970s-era alarm clock IC, meant to
directly drive a multiplexed multi-digit 7-segment module. The clock
itself is more-or-less the reference design with that 7-segment-to-BCD
between the clock IC and a grid of 12mm LEDs.
I bought mine in 1994. Once the supply of those decoder chips dried
up, the kit manufacturer switched the design to a PIC-based design.
The clock I bought as a gift ten years later was the newer design.
-ethan
12:07 p.m.
As a pure ROM, you may be thinking of the MC4039,
which, by
Motorola's admission, was nothing but a preprogrammed version of the
XC170 128-bit mask ROM. Circa 1969.
If you ingnroe 'progammable' devices (PROMs, PALs, FPGAs, etc), what's
the simplest solution for getting 0-9,A-F from 4 bits of binary using
only 74xxx devices (and preferably common ones). I can trivially do it
in 7 such chips, but alas they're all 24 pin devices. Anything simpler?
The same ROM was used as the MC4001 BCD-to-Binary/Binary-to-BCD
encoder.
I beleive the 74184/74185 BCD<->binary converters were programmed
ROM/PROMs too. And as an aside, there were some MMI logic chips, things
like counters with extra facilities, which were clearly programmed PALs/HALs.
-tony
2:14 p.m.
On 28 Oct 2010 at 20:07, Tony Duell wrote:
If you ingnroe 'progammable' devices (PROMs,
PALs, FPGAs, etc), what's
the simplest solution for getting 0-9,A-F from 4 bits of binary using
only 74xxx devices (and preferably common ones). I can trivially do it
in 7 such chips, but alas they're all 24 pin devices. Anything
simpler?
Interesting challenge, Tony. I'll work on it before bed tonight if
no one else does. It should put me right to sleep...
--Chuck
3:55 p.m.
On 2010 Oct 28, at 2:14 PM, Chuck Guzis wrote:
On 28 Oct 2010 at 20:07, Tony Duell wrote:
OK, I claim three solutions:
a) - 7 packages (all 14/16-pin)
- 6.666 utilisation
- (and 7 pull-up resistors, to be pedantic)
- regular TTL active-high outputs
b) - 8 packages (all 14/16-pin)
- 6.9 utilisation
- high-drive active-low outputs for direct-drive of LEDs
c) - 7 packages (1 20-pin, 6 14/16-pin)
- 6.75 utilisation
- high-drive active-low outputs for direct-drive of LEDs
Is there a prize if I win?
If you ingnroe 'progammable' devices
(PROMs, PALs, FPGAs, etc), what's
the simplest solution for getting 0-9,A-F from 4 bits of binary using
only 74xxx devices (and preferably common ones). I can trivially do it
in 7 such chips, but alas they're all 24 pin devices. Anything
simpler?
Interesting challenge, Tony. I'll work on it before bed tonight if
no one else does. It should put me right to sleep... 
30 Oct
30 Oct
12:52 a.m.
From: "Brent Hilpert": Thursday, October 28, 2010 3:55 PM
OK, I claim three solutions:
Assuming I haven't muffed the thing somewhere, I have a
solution using a 74154, a 7410, a 7411, and two 7420. That's
a total of 5 chips; no pull-ups or anything but straight TTL.
The only thing tricky about it is to calculate 1\3\7\ using one
of the 7411 gates, then use that as an input to widen both
the NAND gates for both upper left and lower left vertical
segments.
All 3 sections of the 7411 are used to widen (as needed) the NAND
gates being used to drive the actual segments. Segments default
"on" (low) unless their NAND gate is turned "off" (high) by some
active low output from the 74154.
Vince
5:02 a.m.
On Sat, Oct 30, 2010 at 3:52 AM, Vincent Slyngstad <v.slyngstad at frontier.com
wrote:
From: "Brent Hilpert": Thursday, October 28,
2010 3:55 PM
OK, I claim three solutions:
only 4 chips ;)
74138
74247
7407
7403
and 4 pullups
=Dan
--http://www.vintagecomputer.net/ragooman/
5:17 a.m.
On Sat, Oct 30, 2010 at 8:02 AM, Dan Roganti <ragooman at gmail.com> wrote:
On Sat, Oct 30, 2010 at 3:52 AM, Vincent Slyngstad <
v.slyngstad at frontier.com> wrote:
little typo - early in the morning you know
7403 should be 7409 -- gotta love that Negative Logic ;)
=Dan
--http://www.vintagecomputer.net/ragooman/
From: "Brent Hilpert": Thursday,
October 28, 2010 3:55 PM
OK, I claim three solutions:
only 4 chips ;)
74138
74247
7407
7403
and 4 pullups
31 Oct
31 Oct
8:48 p.m.
On Sat, Oct 30, 2010 at 8:17 AM, Dan Roganti <ragooman at gmail.com> wrote:
On Sat, Oct 30, 2010 at 8:02 AM, Dan Roganti <ragooman at gmail.com> wrote:
4 chip solution, 74247, 74138, 7407, 4066
No rule against using diodes ;)
http://www.vintagecomputer.net/ragooman/files/schematics/hexdec/hexdecoder1…
You have to take the ol' "ouside the box" approach.
I call it the Kobayashi Maru hack ;)
Since the '247 already provides 15 decodes already, I just tweak the ouputs
for A-F
I use the lowercase 'c' since it saves a chip versus a uppercase 'C'
eh-hem, and don't let programmers design hardware :D
=Dan
--http://www.vintagecomputer.net/ragooman/
On Sat, Oct 30, 2010 at 3:52 AM, Vincent Slyngstad <
v.slyngstad at frontier.com> wrote:
little typo - early in the morning you know
7403 should be 7409 -- gotta love that Negative Logic ;)
On Sat, Oct 30, 2010 at 2:31 PM, Vincent Slyngstad <vrs at msn.com> wrote:
From: "Brent Hilpert": Thursday,
October 28, 2010 3:55 PM
OK, I claim three solutions:
only 4 chips ;)
74138
74247
7407
7403
and 4 pullups
only 4 chips ;)
74138
74247
7407
7403
and 4 pullups
OK, I admit that I'm not seeing it.
Are you using the funky 247 outputs for 10-15? Or are you disabling the
247 somehow (wouldn't that require an inverter from somewhere)?
Vince
(I have attached my schematic, in case you are interested.)
9:31 p.m.
On 31 Oct 2010 at 23:48, Dan Roganti wrote:
4 chip solution, 74247, 74138, 7407, 4066
No rule against using diodes ;)
http://www.vintagecomputer.net/ragooman/files/schematics/hexdec/hexdec
oder1a.jpg
If there's no rule against diodes, then there's a 1-chip solution--a
74154 feeding a diode matrix. Indeed, as I mentioned, there are even
diode arrays with 74xxx part numbers.
--Chuck
9:40 p.m.
On Mon, Nov 1, 2010 at 12:31 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 31 Oct 2010 at 23:48, Dan Roganti wrote:
that's too obvious ;)
rube goldberg would not be proud
4 chip solution, 74247, 74138, 7407, 4066
No rule against using diodes ;)
http://www.vintagecomputer.net/ragooman/files/schematics/hexdec/hexdec
oder1a.jpg
If there's no rule against diodes, then there's a 1-chip solution--a
74154 feeding a diode matrix. Indeed, as I mentioned, there are even
diode arrays with 74xxx part numbers.
but that's going over 16pins :)
=Dan
1 Nov
1 Nov
10:11 a.m.
On Mon, Nov 1, 2010 at 1:28 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 1 Nov 2010 at 0:40, Dan Roganti wrote:
That part is wired internally as a Diode Terminator, not much left over for
a matrix, little flexibility there, it'll take more than 4 chips - and since
the diodes are in a DIP, that counts as a chip ;)
Didn't they make a straight Diode Pack w/o the common anode or cathode
--which you commonly see - for wiring into a matrix for situations like this
?
=Dan
but that's going over 16pins :)
No--the 74S1051 is a 12-diode 16-pin PDIP. If you don't want to use
the 154, just use two 74138s--it has both positive and negative
enables.
10:31 a.m.
On Mon, Nov 1, 2010 at 1:11 PM, Dan Roganti <ragooman at gmail.com> wrote:
On Mon, Nov 1, 2010 at 1:28 AM, Chuck Guzis <cclist at sydex.com> wrote:
answered my own question
1N6510, 14pin DIP
1N6101, 16pin DIP
http://sites.google.com/site/interfacebus/Home/diode-arrays
=Dan
On 1 Nov 2010 at 0:40, Dan Roganti wrote:
That part is wired internally as a Diode Terminator, not much left over for
a matrix, little flexibility there, it'll take more than 4 chips - and since
the diodes are in a DIP, that counts as a chip ;)
Didn't they make a straight Diode Pack w/o the common anode or cathode
--which you commonly see - for wiring into a matrix for situations like this
?
but that's going over 16pins :)
No--the 74S1051 is a 12-diode 16-pin PDIP. If you don't want to use
the 154, just use two 74138s--it has both positive and negative
enables.
10:45 a.m.
On 1 Nov 2010 at 13:11, Dan Roganti wrote:
That
part is wired internally as a Diode Terminator, not much left
over for a matrix, little flexibility there, it'll take more than 4
chips - and since the diodes are in a DIP, that counts as a chip ;)
Sure, all you need is 7 of these critters; each common-anode line is
an output, with the cathodes connected to the appropriate demux
output from the 154.
Didn't they make a straight Diode Pack w/o the
common anode or cathode
--which you commonly see - for wiring into a matrix for situations
like this ?
Yes, but not with an SN74xxx part number, which was my way of staying
within the ground rules of using only 74xx series logic.
--Chuck
11:06 a.m.
On 01/11/2010 11:45 AM, Chuck Guzis wrote:
Yes, but not with an SN74xxx part number, which was my
way of staying
within the ground rules of using only 74xx series logic.
scratches out TTL ... writes RTL in pencil.
runs like hell ...
--Chuck
Ben.
PS.. And stick to the RTL cookbook hiding as a PDF on
the web.
12:10 p.m.
On 2010 Oct 31, at 7:48 PM, Dan Roganti wrote:
4 chip solution, 74247, 74138, 7407, 4066
No rule against using diodes ;)
http://www.vintagecomputer.net/ragooman/files/schematics/hexdec/
hexdecoder1a.jpg
You have to take the ol' "ouside the box" approach.
I call it the Kobayashi Maru hack ;)
Since the '247 already provides 15 decodes already, I just tweak the
ouputs
for A-F
I use the lowercase 'c' since it saves a chip versus a uppercase 'C'
eh-hem, and don't let programmers design hardware :D
Neat suggestion to modify the existing A-F displays, but once you have
the '138 and a bunch of diodes you could just revert to the technique
of generating 8-F, and get by with 2 chips (247,138), 1 inverter (to
disable the 247 for >=8), and diodes.
The use of the 4066 does present a problem for direct drive of the
LEDs: ON resistance of the transmission gates is on the order of
hundreds of ohms (with considerable variability over devices and temp).
11:23 a.m.
On Mon, Nov 1, 2010 at 3:10 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2010 Oct 31, at 7:48 PM, Dan Roganti wrote:
oh yea, that would make it only 3chips - we have a winner !
Although the utliz.of the inverter chip is very low.
You could always just use a transistor.
I just didn't want to leave the '247 abandoned ;)
The on resistance of the 4066 (~80ohm) is way less than the 4016(~200ohm) -
which is why I chose that one - but marginally higher when operating a the
lower 5volts. But you could still compensate by lowering the LED resister to
keep it just as bright.
I never rule out CMOS :)
=Dan
--http://www.vintagecomputer.net/ragooman/
4 chip solution, 74247, 74138, 7407, 4066
No rule against using diodes ;)
http://www.vintagecomputer.net/ragooman/files/schematics/hexdec/hexdecoder1…
You have to take the ol' "ouside the box" approach.
I call it the Kobayashi Maru hack ;)
Since the '247 already provides 15 decodes already, I just tweak the
ouputs
for A-F
I use the lowercase 'c' since it saves a chip versus a uppercase 'C'
eh-hem, and don't let programmers design hardware :D
Neat suggestion to modify the existing A-F displays, but once you have the
'138 and a bunch of diodes you could just revert to the technique of
generating 8-F, and get by with 2 chips (247,138), 1 inverter (to disable
the 247 for >=8), and diodes.
The use of the 4066 does present a problem for direct drive of the LEDs: ON
resistance of the transmission gates is on the order of hundreds of ohms
(with considerable variability over devices and temp).
1:02 p.m.
On 2010 Nov 1, at 10:23 AM, Dan Roganti wrote:
On Mon, Nov 1, 2010 at 3:10 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
We must have different specs at hand (different manufacturers perhaps):
Fairchild'76 says 270 ohms typ, 1000 max at 5V/25C, Harris'92 says
470-1050. Even if you account for the R in the LED drop R, part of the
problem is the variability between devices, even though intra-device
variability is low. Based on the specs I have power dissipation may
also be an issue once you're pushing current through that internal R
(100mW max per switch).
Neat suggestion to modify the existing A-F displays, but once you
have the
'138 and a bunch of diodes you could just revert to the technique of
generating 8-F, and get by with 2 chips (247,138), 1 inverter (to
disable
the 247 for >=8), and diodes.
The use of the 4066 does present a problem for direct drive of the
LEDs: ON
resistance of the transmission gates is on the order of hundreds of
ohms
(with considerable variability over devices and temp).
oh yea, that would make it only 3chips - we have a winner !
Although the utliz.of the inverter chip is very low.
You could always just use a transistor.
I just didn't want to leave the '247 abandoned ;)
The on resistance of the 4066 (~80ohm) is way less than the
4016(~200ohm) -
which is why I chose that one - but marginally higher when operating a
the
lower 5volts. But you could still compensate by lowering the LED
resister to
keep it just as bright. I never rule out CMOS :)
4:28 p.m.
On Mon, Nov 1, 2010 at 1:02 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2010 Nov 1, at 10:23 AM, Dan Roganti wrote:
My experience with quad bi-lateral transmission gates is the typical on
resistance is more likely around 1000 Ohms.
I must admit I have not read thru all the posts so if somebody else
suggested this my apologies. Why not a one chip solution; use a 74S188 and
program whatever you want the character set to be (i.e. hook or no hook on
6s, etc. )?
Best regards, Steven
On Mon, Nov 1, 2010 at 3:10 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
We must have different specs at hand (different manufacturers perhaps):
Fairchild'76 says 270 ohms typ, 1000 max at 5V/25C, Harris'92 says 470-1050.
Even if you account for the R in the LED drop R, part of the problem is the
variability between devices, even though intra-device variability is low.
Based on the specs I have power dissipation may also be an issue once you're
pushing current through that internal R (100mW max per switch).
I never rule out CMOS :)
Neat suggestion to modify the existing A-F displays, but once you have
the
'138 and a bunch of diodes you could just revert to the technique of
generating 8-F, and get by with 2 chips (247,138), 1 inverter (to disable
the 247 for >=8), and diodes.
The use of the 4066 does present a problem for direct drive of the LEDs:
ON
resistance of the transmission gates is on the order of hundreds of ohms
(with considerable variability over devices and temp).
oh yea, that would make it only 3chips - we have a winner !
Although the utliz.of
the inverter chip is very low.
You could always just use a transistor.
I just didn't want to leave the '247 abandoned ;)
The on resistance of the 4066 (~80ohm) is way less than the 4016(~200ohm)
-
which is why I chose that one - but marginally higher when operating a the
lower 5volts. But you could still compensate by lowering the LED resister
to
keep it just as bright.
5 p.m.
On 1 Nov 2010 at 16:28, alan canning wrote:
I must admit I have not read thru all the posts so if
somebody else
suggested this my apologies. Why not a one chip solution; use a 74S188
and program whatever you want the character set to be (i.e. hook or no
hook on 6s, etc. )?
That's where we started. Tony wanted to see what the minimum in
combinatorial logic would be. To date, I've not seen a solution that
doesn't use decoders or demuxes, just AND OR and NOT elements.
Anyone care to give that a crack and see what the optimal case is
using SSI TTL--say, nothing more complex than a 7486?
--Chuck
6:41 p.m.
On 2010 Nov 1, at 4:00 PM, Chuck Guzis wrote:
Tony wanted to see what the minimum in
combinatorial logic would be. To date, I've not seen a solution that
doesn't use decoders or demuxes, just AND OR and NOT elements.
Anyone care to give that a crack and see what the optimal case is
using SSI TTL--say, nothing more complex than a 7486?
Well, a starting point could be to replace the 74154 in the 1-of-16
decoder solution with 4 inverters and 16 4-in nands (9 packages),
plus the 4 packages remaining of that solution to do the segment
selection, gives 13 packages. Optimisation anyone?
6:35 p.m.
On 1 Nov 2010 at 17:41, Brent Hilpert wrote:
Well, a starting point could be to replace the 74154
in the 1-of-16
decoder solution with 4 inverters and 16 4-in nands (9 packages), plus
the 4 packages remaining of that solution to do the segment selection,
gives 13 packages. Optimisation anyone?
I'll eliminate some of the grunt work for folks and offer the
following document, which contains all of the Karnaugh maps and a
simple logic diagram.
http://www.strivingafterwind.com/EE/EE112/ee112formal.pdf
I'd probably start by using a 7404 and distribute the binary input
and its complement... :)
--Chuck
7:11 p.m.
On Mon, Nov 1, 2010 at 6:35 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 1 Nov 2010 at 17:41, Brent Hilpert wrote:
In college I designed a BCD to 7 segment driver using fewer chips than the
convention used by looking at the problem from the other direction. For most
of the digits more of the segments are on than off, so I designed a circuit
to turn segments OFF instead of ON. Try it !! Might get the parts count down
for this one also. I'll give it a shot when I get a few spare minutes. Just
started a new job after being OFF for two years.
Best regards, Steven
Well, a starting point could be to replace the
74154 in the 1-of-16
decoder solution with 4 inverters and 16 4-in nands (9 packages), plus
the 4 packages remaining of that solution to do the segment selection,
gives 13 packages. Optimisation anyone?
I'll eliminate some of the grunt work for folks and offer the
following document, which contains all of the Karnaugh maps and a
simple logic diagram.
http://www.strivingafterwind.com/EE/EE112/ee112formal.pdf
I'd probably start by using a 7404 and distribute the binary input
and its complement... :)
--Chuck
2 Nov
2 Nov
12:19 p.m.
On 2010 Nov 1, at 5:35 PM, Chuck Guzis wrote:
On 1 Nov 2010 at 17:41, Brent Hilpert wrote:
I'll eliminate some of the grunt work for folks and offer the
following document, which contains all of the Karnaugh maps and a
simple logic diagram.
http://www.strivingafterwind.com/EE/EE112/ee112formal.pdf
I'd probably start by using a 7404 and distribute the binary input
and its complement... :)
Starting with those karnaugh maps (there's an error in the schematic),
there is a solution with 10 packages:
1 7404
2 7408
7 74LS54
4 inverters to complement the inputs, 7 AOI for the segments, and 6 or
7 2-in AND to optimise and widen some of the AOI ANDs; utilisation of 9
& 1/6.
Based on the solutions and suggestions from the list, I drew up some
diagrams for the earlier problem:
http://www3.telus.net/~bhilpert/tmp/7seg.gif
A: 247,138 solution, suggested by several,
optimised down to 5 14/16-pin packages
B: 1-of-16 decoder with some optimisation, 5 packages (1 24-pin),
suggested by James and Vincent, IIRC
C: 247,253 data selectors solution suggested by Tony,
5 14/16-pin packages.
11:41 a.m.
On Tue, Nov 2, 2010 at 3:19 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Starting with those karnaugh maps (there's an error in the schematic), there
is a solution with 10 packages:
? 1 ?7404
? 2 ?7408
? 7 ?74LS54
4 inverters to complement the inputs, 7 AOI for the segments, and 6 or 7
2-in AND to optimise and widen some of the AOI ANDs; utilisation of 9 & 1/6.
Based on the solutions and suggestions from the list, I drew up some
diagrams for the earlier problem:
? ? http://www3.telus.net/~bhilpert/tmp/7seg.gif
?A: 247,138 solution, suggested by several,
? ? optimised down to 5 14/16-pin packages
?B: 1-of-16 decoder with some optimisation, 5 packages (1 24-pin),
? ? suggested by James and Vincent, IIRC
?C: 247,253 data selectors solution suggested by Tony,
? ? 5 14/16-pin packages.
habl? SSI ?
12:57 p.m.
On 2010 Nov 2, at 10:41 AM, Dan Roganti wrote:
On Tue, Nov 2, 2010 at 3:19 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
I'm not following you .. A,B,C are solutions for the earlier problem
(any 74xx), the 04,08,54 solution is for the second problem
(<=7486/SSI). The AOIs qualify as SSI in my books.
Starting with those karnaugh maps (there's an error in the
schematic), there
is a solution with 10 packages:
? 1 ?7404
? 2 ?7408
? 7 ?74LS54
4 inverters to complement the inputs, 7 AOI for the segments, and 6
or 7
2-in AND to optimise and widen some of the AOI ANDs; utilisation of 9
& 1/6.
Based on the solutions and suggestions from the list, I drew up some
diagrams for the earlier problem:
? ? http://www3.telus.net/~bhilpert/tmp/7seg.gif
?A: 247,138 solution, suggested by several,
? ? optimised down to 5 14/16-pin packages
?B: 1-of-16 decoder with some optimisation, 5 packages (1 24-pin),
? ? suggested by James and Vincent, IIRC
?C: 247,253 data selectors solution suggested by Tony,
? ? 5 14/16-pin packages.
habl? SSI ?
12:01 p.m.
On Tue, Nov 2, 2010 at 3:57 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2010 Nov 2, at 10:41 AM, Dan Roganti wrote:
yes I agree
On Tue, Nov 2, 2010 at 3:19 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
I'm not following you .. A,B,C are solutions for the earlier problem (any
74xx), the 04,08,54 solution is for the second problem (<=7486/SSI). The
AOIs qualify as SSI in my books.
Starting with those karnaugh maps (there's an error in the schematic),
there
is a solution with 10 packages:
? 1 ?7404
? 2 ?7408
? 7 ?74LS54
4 inverters to complement the inputs, 7 AOI for the segments, and 6 or 7
2-in AND to optimise and widen some of the AOI ANDs; utilisation of 9 &
1/6.
Based on the solutions and suggestions from the list, I drew up some
diagrams for the earlier problem:
? ? http://www3.telus.net/~bhilpert/tmp/7seg.gif
?A: 247,138 solution, suggested by several,
? ? optimised down to 5 14/16-pin packages
?B: 1-of-16 decoder with some optimisation, 5 packages (1 24-pin),
? ? suggested by James and Vincent, IIRC
?C: 247,253 data selectors solution suggested by Tony,
? ? 5 14/16-pin packages.
habl? SSI ?
10:09 a.m.
On Mon, Nov 1, 2010 at 8:00 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 1 Nov 2010 at 16:28, alan canning wrote:
I bet you enjoy changing the rules :)
Ok, but you didn't say >only< --- or no diodes ;)
I must admit I have not read thru all the posts
so if somebody else
suggested this my apologies. Why not a one chip solution; use a 74S188
and program whatever you want the character set to be (i.e. hook or no
hook on 6s, etc. )?
That's where we started. ?Tony wanted to see what the minimum in
combinatorial logic would be. ?To date, I've not seen a solution that
doesn't use decoders or demuxes, just AND OR and NOT elements.
Anyone care to give that a crack and see what the optimal case is
using SSI TTL--say, nothing more complex than a 7486?
I'll eliminate some of the grunt work for folks and offer the
following document, which contains all of the Karnaugh maps and a
simple logic diagram.
http://www.strivingafterwind.com/EE/EE112/ee112formal.pdf
I'd probably start by using a 7404 and distribute the binary input
and its complement... :)
oh gee, thanks :)
try this
http://tinyurl.com/2fjfnm5
excuse google for using a rather obtuse url for linking simple files
=Dan
--http://www.vintagecomputer.net/ragooman/
11:53 a.m.
On Tue, Nov 2, 2010 at 2:04 PM, Chuck Guzis <cclist at sydex.com> wrote:
On 2 Nov 2010 at 13:09, Dan Roganti wrote:
but where would this world be if we didn't use diodes ;)
we would have no...no.....
=Dan
I bet you enjoy changing the rules :)
Ok, but you didn't say >only< --- or no diodes ;)
Hey, do want a challenge or not? ?And NO DIODES!
--
12:38 p.m.
On 1 Nov 2010 at 16:28, alan canning wrote:
Strictly a PROM is combinatorial logic :-).
My origianl puzzle (which I don't know the best answer for...) was to
make a full hxadecimal 7 segment driver using 74xx TTL parts ('and
preferably common ones) and no programmable devices (no PROMS, PALs, etc).
I didn;t forbit sequential logic, although it's hard to see why it would
be useful.
-tony
I must admit I have not read thru all the posts
so if somebody else
suggested this my apologies. Why not a one chip solution; use a 74S188
and program whatever you want the character set to be (i.e. hook or no
hook on 6s, etc. )?
That's where we started. Tony wanted to see what the minimum in
combinatorial logic would be. To date, I've not seen a solution that
2:14 p.m.
On 2 Nov 2010 at 19:38, Tony Duell wrote:
My origianl puzzle (which I don't know the best
answer for...) was to
make a full hxadecimal 7 segment driver using 74xx TTL parts ('and
preferably common ones) and no programmable devices (no PROMS, PALs,
etc).
We could restrict the solution to HTL parts. That might be
interesting as they didn't reach any high level of integration.
--Chuck
3 Nov
3 Nov
10:22 p.m.
On Tue, Nov 2, 2010 at 7:03 PM, William Donzelli <wdonzelli at gmail.com>wrote:
I can do it with one 16 pin non-programmable TTL device ; National DM9368 (
sorry if somebody already pointed this one out as I don't have time to go
thru 75 posts right now....
In combinational logic I'm looking at turning 34 segments OFF instead of
turning 78 segments ON. No discrete parts. I'm a purist.
Best regards, Steven
We could
restrict the solution to HTL parts. That might be
interesting as they didn't reach any high level of integration.
...and if you need HTL, I've got it.
--
Will
10:50 p.m.
On 03/11/2010 11:22 PM, alan canning wrote:
I can do it with one 16 pin non-programmable TTL
device ; National DM9368 (
sorry if somebody already pointed this one out as I don't have time to go
thru 75 posts right now....
In combinational logic I'm looking at turning 34 segments OFF instead of
turning 78 segments ON. No discrete parts. I'm a purist.
I wonder what the logic would be for using 16 segment displays?
You have more segments, but less terms.
Best regards, Steven
Ben.
11:34 p.m.
On 2010 Nov 3, at 9:22 PM, alan canning wrote:
I can do it with one 16 pin non-programmable TTL
device ; National
DM9368 (
sorry if somebody already pointed this one out as I don't have time to
go
thru 75 posts right now....
Yes, that's exactly where the discussion started, somebody asked if
there was a single-chip hex 7-seg decoder, the 9368 (and other 93xx)
were pointed out.
In combinational logic I'm looking at turning 34
segments OFF instead
of
turning 78 segments ON. No discrete parts. I'm a purist.
I'm still looking at permutations to see if I can eliminate a couple
more AND gates and get it down to 9 packages from 10 (for the SSI
solution).
11:25 p.m.
On 3 Nov 2010 at 22:34, Brent Hilpert wrote:
Yes, that's exactly where the discussion started,
somebody asked if
there was a single-chip hex 7-seg decoder, the 9368 (and other 93xx)
were pointed out.
And it probably should be pointed out that the part probably
originated with Fairchild as part of its 9300 MSI TTL family.
Interestingly, the earliest 7-segment TTL decoder (1960s), the 9307,
had the horizontal segments on the "6" and "9". Was it contemporary
taste that caused later versions to drop the segment?
--Chuck
2 Nov
2 Nov
6:03 a.m.
On Mon, Nov 1, 2010 at 4:02 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2010 Nov 1, at 10:23 AM, Dan Roganti wrote:
oh yes, I was preoccupied with the diode matrix, I neglected good ol' ohm's
law on the 4066. There is another digital switch around - the 4066 was an
ol' favorite - with enough power that would replace this , I've seen them in
the mouser catalog.
On Mon, Nov 1, 2010 at 3:10 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
We must have different specs at hand (different manufacturers perhaps):
Fairchild'76 says 270 ohms typ, 1000 max at 5V/25C, Harris'92 says 470-1050.
Neat suggestion to modify the existing A-F displays, but once you have
the
'138 and a bunch of diodes you could just revert to the technique of
generating 8-F, and get by with 2 chips (247,138), 1 inverter (to disable
the 247 for >=8), and diodes.
The use of the 4066 does present a problem for direct drive of the LEDs:
ON
resistance of the transmission gates is on the order of hundreds of ohms
(with considerable variability over devices and temp).
oh yea, that would make it only 3chips - we have a winner !
Although the utliz.of
the inverter chip is very low.
You could always just use a transistor.
I just didn't want to leave the '247 abandoned ;)
The on resistance of the 4066 (~80ohm) is way less than the 4016(~200ohm)
-
which is why I chose that one - but marginally higher when operating a the
lower 5volts. But you could still compensate by lowering the LED resister
to
keep it just as bright.
Even if you account for the R in the LED drop R, part
of the problem is the
variability between devices, even though intra-device variability is low.
Based on the specs I have power dissipation may also be an issue once you're
pushing current through that internal R (100mW max per switch).
But I like the last solution even more, 2 chips, 74247, 74138, transistor
inverter, a few diodes, viola !
Rube Goldberg would be proud ;)
You can't rule out discretes !
=Dan
--http://www.vintagecomputer.net/ragooman/
30 Oct
30 Oct
10:21 a.m.
On the same topic here, can anyone interpret the "state table" on the
second page of the National DM74LS447 7-segment decoder datasheet?
http://pdf1.alldatasheet.com/datasheet-
pdf/view/149198/NSC/DM74LS447N.html
I tend to think of state diagrams as belonging to things such as
counters and don't have a clue as to what to make of the one
furnished.
--Chuck
1:23 p.m.
On 2010 Oct 30, at 10:21 AM, Chuck Guzis wrote:
On the same topic here, can anyone interpret the
"state table" on the
second page of the National DM74LS447 7-segment decoder datasheet?
http://pdf1.alldatasheet.com/datasheet-
pdf/view/149198/NSC/DM74LS447N.html
I tend to think of state diagrams as belonging to things such as
counters and don't have a clue as to what to make of the one
furnished.
It's obviously a state diagram for a decade counter, my guess is
someone just screwed up making the datasheet and included the state
diagram from some other device.
1:36 p.m.
New subject: Fall cleaning, some small machines for free
Fall cleaning!
I have a bunch of old computers and some peripherals. Most are not tested and I expect
they may need some work to become operational, though some may work correctly as-is.
Anyway, I'm hoping to find people interested in restoring these systems.
There are three Burroughs B25 systems, each has a processor box, disk box, monitor,
keyboard, and power supply. There is one box of docs and diskettes and one, very dirty,
printer.
http://www.anifur.com/clist/misc-b1.jpg
http://www.anifur.com/clist/misc-b2.jpg
http://www.anifur.com/clist/misc-b3.jpg
http://www.anifur.com/clist/misc-b4.jpg
IBM convertible, an early laptop type system.
A Computer Products portable, thermal, serial terminal.
http://www.anifur.com/clist/misc-ptr.jpg
A Radio Shack TRS-80 model I with expansion chassis and monitor. I believe this has a bad
power supply.
http://www.anifur.com/clist/misc-rs.jpg
A NEC Spinwriter terminal. This is like a Diablo daisywheel terminal except the print
element is a cylinder. I know this one needs work but does power up.
http://www.anifur.com/clist/misc-spin.jpg
Some kind of cartridge tape system. I think it's SCSI interfaced. I don't believe
this has ever been used.
http://www.anifur.com/clist/misc-tape.jpg
A large flatbed scanner that I also believe is unused. It's SCSI interfaced. UMAX
3000.
http://www.anifur.com/clist/misc-scanner.jpg
Digitech RS-232 analyzer with manuals. This runs CP/M 86 but I don't have the boot
disc for it. Does power up.
http://www.anifur.com/clist/misc-anal.jpg
Kaypro 2, powers up and ask for a system disk.
http://www.anifur.com/clist/kaypro1.jpg
Hitachi pen plotter. This has a parallel interface. It powers up and works from the front
panel. Light weight.
http://www.anifur.com/clist/hitachi1.jpg
Panasonic NV-A960 VCR editing unit.
http://www.anifur.com/clist/a960-1.jpg
Nicolet Zeta 8A pen plotter. 8 pens. Also powers up and works from the front panel. Serial
interface.
All of these are located in the Santa Cruz, CA mountains, near the Bonny Doon airport. I
can possibly bring something into Santa Clara where I work. Best to come visit and check
them out here. I really don't want to
ship anything as I just don't have the time or energy.
Please rescue these before I scrap them, I really need the space and these are now
outside, but covered under a Quonset hut.
Bob
2:09 p.m.
New subject: Fall cleaning, some small machines for free
On 2010 Oct 30, at 1:36 PM, Bob Rosenbloom wrote:
Panasonic NV-A960 VCR editing unit.
http://www.anifur.com/clist/a960-1.jpg
I dismantled one of these a few years ago, it contained an
(NEC-branded) 8080, a whack of NEC 8255's (PIO), half-a dozen ceramic
Fujitsu MB8516's (2K*8 EPROMS, 2716-like), all socketed, for anyone
that might take an interest in such stuff.
All of these are located in the Santa Cruz, CA
mountains, near the
Bonny Doon airport. I can possibly bring something into Santa Clara
where I work. Best to come visit and check them out here. I really
don't want to
ship anything as I just don't have the time or energy.
Please rescue these before I scrap them, I really need the space and
these are now outside, but covered under a Quonset hut.
Bob
2:21 p.m.
New subject: Fall cleaning, some small machines for free
----- Original Message -----
From: "Bob Rosenbloom" <bobalan at sbcglobal.net>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Saturday, October 30, 2010 4:36 PM
Subject: Fall cleaning, some small machines for free
Fall cleaning!
I have a bunch of old computers and some peripherals. Most are not tested
and I expect they may need some work to become operational, though some
may work correctly as-is. Anyway, I'm hoping to find people interested in
restoring these systems.
A large flatbed scanner that I also believe is unused. It's SCSI
interfaced. UMAX 3000.
http://www.anifur.com/clist/misc-scanner.jpg
Thats seems like a nice vintage high end scanner scanner (hope somebody
grabs it):
PowerLook 3000 Technical Specifications
Type Color Flatbed
Method Moving Flatbed, Single-pass, color
Element 10,500 elements, Tri-linear coated color CCD
Light Source Cold Cathode Lamp
Hardware Resolution Lens 1: 1220 dpi x 3048 dpi
Lens 2: 3048 dpi x 3048 dpi
Maximum Interpolated Resolution 12,192 dpi x 12,192 dpi
Scanning Resolution 1 dpi to 12,192 dpi
Maximum Scan Size Lens 1: 8.5" x 11.7"
Lens 2: 3.4" x 11.7"
Speed Color: 14.4ms/line
I/O Buffer 2MB
Maximum Density 3.6Dmax
Scan Modes 24/42-bit color
8/14-bit gray scale
1-bit halftone
1-bit line art
Scaling Lens 1: 1% to 400%
Lens 2: 1% to 1000%
Highlight/Shadow 256 steps
Contrast/Brightness +/-100%
Gamma Curve Downloadable Curves
Data Output 14-bit extendible
Hardware Interface SCSI-2
Operating Noise Under 60 db
Operating Temperature 25? - 104? F
Humidity 25% to 85%
Power Consumption 60 Watts
Voltage 100-240VAC
Frequency 47-63Hz
Dimensions 21.6" x 16.8" x 8.6"
Net Weight 41.46 lbs.
System Support Mac OS 8.0 to 9.1|Windows 98SE/ME/2000/XP|UNIX drivers
are available through third-party.
9:17 p.m.
New subject: Fall cleaning, Burroughs, TRS-80, IBM Convertable & Kaypro spoken for
The Burroughs, TRS-80, Kaypro, and IBM Convertable are spoken for.
The other, really nice stuff, is still available!
Thanks
Bob
28 Oct
28 Oct
4:17 p.m.
On Thu, 2010-10-28 at 14:14 -0700, Chuck Guzis wrote:
Interesting challenge, Tony. I'll work on it
before bed tonight if
no one else does. It should put me right to sleep...
If you want something to put you to sleep, try ISO 13818 (the MPEG
Transport Stream spec) will do a damn good job. One of my work
colleagues called it "the finest cure for insomnia known to man, even
better than Nytol." :)
--
Phil.
philpem at philpem.me.uk
http://www.philpem.me.uk/
29 Oct
29 Oct
8:39 a.m.
On 29 Oct 2010 at 0:17, Philip Pemberton wrote:
On Thu, 2010-10-28 at 14:14 -0700, Chuck Guzis wrote:
You should try working your way through ANSI programming language
specifications.
I've got my solution, that uses at most 16-pin packages and 6 of
them, but (a) I also need a few pullup resistors, and (b) I employ a
cheat. After making Karnaugh maps of the entire 0-F decoder and
simplifying terms, I realized that I was making the job too difficult
than the rules demanded. A common 74LS247 decoder provides the "6"
with the correct "tail"; the problem boils down to creating the
letters A-F (which, interestingly, is much less complex than making 0-
9) and wire-ANDing the outputs with that of the 247.
Not what Tony had in mind, I suspect.
I wonder what the smallest combinatorial implemenation is using at
most 4-input NAND and NOR gates and inverters. That's for another
time when I feel bored...
--Chuck
Interesting challenge, Tony. I'll work on it
before bed tonight if
no one else does. It should put me right to sleep...
If you want something to put you to sleep, try ISO 13818 (the MPEG
Transport Stream spec) will do a damn good job. One of my work
colleagues called it "the finest cure for insomnia known to man, even
better than Nytol." :)
10:51 a.m.
On 2010 Oct 29, at 8:39 AM, Chuck Guzis wrote:
On 29 Oct 2010 at 0:17, Philip Pemberton wrote:
I did the same thing, a '247, along with a '138 1-of-8 decoder to
decode the high values, feeding a bunch of NAND gates. Use the blanking
input on the 247 to disable it when A-F is being displayed. Did you
avoid the use of the 1-of-8 decoder?
I expect Tony's solution was 7 16-to-1 muxes, essentially a hardwired
ROM.
There would be another solution with a 1-of-16 decoder feeding 7 NAND
gates, doable in 8 packages (1 24-pin).
On Thu, 2010-10-28 at 14:14 -0700, Chuck Guzis
wrote:
You should try working your way through ANSI programming language
specifications.
I've got my solution, that uses at most 16-pin packages and 6 of
them, but (a) I also need a few pullup resistors, and (b) I employ a
cheat. After making Karnaugh maps of the entire 0-F decoder and
simplifying terms, I realized that I was making the job too difficult
than the rules demanded. A common 74LS247 decoder provides the "6"
with the correct "tail"; the problem boils down to creating the
letters A-F (which, interestingly, is much less complex than making 0-
9) and wire-ANDing the outputs with that of the 247. Interesting challenge, Tony. I'll work on it
before bed tonight if
no one else does. It should put me right to sleep...
If you want something to put you to sleep, try ISO 13818 (the MPEG
Transport Stream spec) will do a damn good job. One of my work
colleagues called it "the finest cure for insomnia known to man, even
better than Nytol." :) Not what Tony had in mind, I suspect.
I wonder what the smallest combinatorial implemenation is using at
most 4-input NAND and NOR gates and inverters. That's for another
time when I feel bored...
12:22 p.m.
On 29 Oct 2010 at 10:51, Brent Hilpert wrote:
I did the same thing, a '247, along with a
'138 1-of-8 decoder to
decode the high values, feeding a bunch of NAND gates. Use the
blanking input on the 247 to disable it when A-F is being displayed.
Did you avoid the use of the 1-of-8 decoder?
No I used one, though I considered not doing so, given the simplicity
of forming alpha letters (in comparison to forming numbers).
--Chuck
2:38 p.m.
I did the same thing, a '247, along with a
'138 1-of-8 decoder to
decode the high values, feeding a bunch of NAND gates. Use the blanking
input on the 247 to disable it when A-F is being displayed. Did you
avoid the use of the 1-of-8 decoder?
I expect Tony's solution was 7 16-to-1 muxes, essentially a hardwired
ROM.
Indeed it was... That's always a brute-force solution.
Anoyther idea. A '247 to get the 0-9 patterns. 3 off '253 dual 4-input
mexes. These decode the low 3 bits (and may need an extra inverter) to
get the segment aptters of the a,b,c,d,f segmetns of the A-F patterns (e
and g are always on in those states. And a little bit of logic to disable
the '247, enable the muxes and turn on e,g for the appropriat input
states. Probably only a couple more chips.
There would be another solution with a 1-of-16 decoder feeding 7 NAND
gates, doable in 8 packages (1 24-pin).
Yep.
-tony
2:27 p.m.
I've got my solution, that uses at most 16-pin
packages and 6 of
them, but (a) I also need a few pullup resistors, and (b) I employ a
cheat. After making Karnaugh maps of the entire 0-F decoder and
simplifying terms, I realized that I was making the job too difficult
than the rules demanded. A common 74LS247 decoder provides the "6"
with the correct "tail"; the problem boils down to creating the
letters A-F (which, interestingly, is much less complex than making 0-
9) and wire-ANDing the outputs with that of the 247.
Not what Tony had in mind, I suspect.
I don't see why not :-). As I mentioned in my earlier reply tonight, I
wasn't sure if using the normal 7-segemtn decoder helped or not (and
whether it's better to use it for 0-7 or 0-9). Thinking about it, aren't
the 'e' and 'g' segments always on for A-F? That simplifies things...
I wonder what the smallest combinatorial implemenation is using at
most 4-input NAND and NOR gates and inverters. That's for another
time when I feel bored...
Indeed...
-tony
3:37 p.m.
On 29 Oct 2010 at 22:27, Tony Duell wrote:
I don't see why not :-). As I mentioned in my
earlier reply tonight, I
wasn't sure if using the normal 7-segemtn decoder helped or not (and
whether it's better to use it for 0-7 or 0-9). Thinking about it,
aren't the 'e' and 'g' segments always on for A-F? That simplifies
things...
Actually, looking at the sequence A-F in the negative sense, many
simplifications come to mind, depending on how the letters are
displayed. I chose "AbCdEF", but there's no reason that "abcdeF"
couldn't be chosen.
Using "AbCdEF", "d" is the only letter where segment "f"
isn't
illuminated. "C" is the only letter that doesn't include "g",
unless
you make the "c" lowercase, in which case, it's always on (as you
observed). "b" and "d" are the only letters that omit the top
segment...and so on.
--Chuck
2:10 p.m.
On 28 Oct 2010 at 20:07, Tony Duell wrote:
I see...
For those who are wondeirng, the 'trivial' solution I mentioned uses 7
off 74150 16-input multiplexers, one for each segment. You tie the inputs
high low to determine if that segment is on or off for a given set fo 4
input bits.
After posing that, I thought of other solutions that make no assumptions
about the segment patterns -- they always work. For example 7 off 74151 8
input muxes and a single inverter (1/6 of a 7404) That has the advantage
of automatically providing actrive high and active low outputs.
Or use a 74154 to decode the input bits and then logically OR the active
low outputs together with 7430 8-input NANDs. The thing is that a given
segment is either on in 8 or fewer patterns or it's off in 8 or fewer
patterns (it must be one or the other since there are only 16 patterns).
So you can get away with 8 input NAND gates, maybe you need to invert the
outputs (7404s again) [1]. So that's 9 packages (74154, 24 pin, 7 off
7430, 14 pin and a 7404, also 14 pin. If you need to invert all 7 putputs,
and thus need more than the contents of a 7404, then I would simply
redefine the problem to use the other type of display :-). Actually, in
all cases you probably want some kind of driver on the outputs, so you
can pck a normal or inverting onme.
I've not writtne down the turth table so I don't know if you can use
smaller NAND gates for some of the outputs, and thus get away with fewer
packages.
Anyother thought I had is to use a 7447 for the lower 8 or 10 patterns
(as it's designed to do!) and add logic for the higher ones. I don't know
if that saves chips.
[1] I beleive you need this sort of trick to build such a decoder in a
stnadard PAL or GAL device.
-tony
If you ingnroe 'progammable' devices
(PROMs, PALs, FPGAs, etc), what's
the simplest solution for getting 0-9,A-F from 4 bits of binary using
only 74xxx devices (and preferably common ones). I can trivially do it
in 7 such chips, but alas they're all 24 pin devices. Anything
simpler?
Interesting challenge, Tony. I'll work on it before bed tonight if
no one else does. It should put me right to sleep...
3:28 p.m.
On 29 Oct 2010 at 22:10, Tony Duell wrote:
Anyother thought I had is to use a 7447 for the lower
8 or 10
patterns (as it's designed to do!) and add logic for the higher ones.
I don't know if that saves chips.
The 7447 has a problem in that the "6" doesn't have the top crossbar,
so that it's indistinguishable from a "b". The '247 does include the
top segment when displaying '6', which is why I mentioned the 247 and
not 47.
This brings to mind an ancient "fix" for the 47 "6" display--a
pulldown diode connected between segment "e" and segment "a"--in the
display of 0-9 there is no time when segment "e" is active that
segment "a" isn't also active. The converse, however isn't true--and
this "fix" will mess up your display of "b" if you use the method
described previously to display 0-F.
But if you allow diodes, then there's no reason not to use a 4-to-16
demux and a mess of diodes to do the decoding for 0-F, is there?
--Chuck
4:13 p.m.
On 2010 Oct 29, at 3:28 PM, Chuck Guzis wrote:
The 7447 has a problem in that the "6"
doesn't have the top crossbar,
so that it's indistinguishable from a "b". The '247 does include the
top segment when displaying '6', which is why I mentioned the 247 and
not 47.
I too realised that halfway thru the exercise and went scrambling back
to the databook to check on the 247.
5:46 p.m.
On 29 Oct 2010 at 16:13, Brent Hilpert wrote:
I too realised that halfway thru the exercise and went
scrambling back
to the databook to check on the 247.
Another reason to lament the passing of the hardcopy databook. I
used to sit and read them cover-to-cover. Not really possible in
today's world. The data's out there, but not in any form that you
could really curl up with and browse. The app notes were
particularly fun.
Sigh.
--Chuck
30 Oct
30 Oct
1:44 p.m.
On 29 Oct 2010 at 16:13, Brent Hilpert wrote:
Absolutely. Of cousre I've kept all my old paper databooks, and still
read them from time to tieme.
Yes, it's very useful being able to get data on just about any standard
IC over the internet. But it's useful in a different way being able to
flip through a data book, see what's available, etc. I've yet to find a
manufacturer's site that lets me browse in the same way.
-tony
I too realised that halfway thru the exercise and
went scrambling back
to the databook to check on the 247.
Another reason to lament the passing of the hardcopy databook. I
used to sit and read them cover-to-cover. Not really possible in
1:23 p.m.
On 29 Oct 2010 at 22:10, Tony Duell wrote:
Yes, I should have remembered that...
Anyother thought I had is to use a 7447 for the
lower 8 or 10
patterns (as it's designed to do!) and add logic for the higher ones.
I don't know if that saves chips.
The 7447 has a problem in that the "6" doesn't have the top crossbar,
so that it's indistinguishable from a "b". The '247 does include the
top segment when displaying '6', which is why I mentioned the 247 and
not 47.
This brings to mind an ancient "fix" for the 47 "6" display--a
pulldown diode connected between segment "e" and segment "a"--in the
Been there, done that :-)
display of 0-9 there is no time when segment
"e" is active that
segment "a" isn't also active. The converse, however isn't true--and
this "fix" will mess up your display of "b" if you use the method
described previously to display 0-F.
Of course. For 'b' you mmed the 'e' segment without the 'a'
segment.
That's what distinguishes it from '6'
But if you allow diodes, then there's no reason not to use a 4-to-16
demux and a mess of diodes to do the decoding for 0-F, is there?
while my original question didn't preclude the use of discrete
components, and while I happly ageee that the odd diodes, pull-up
resisotrs, etc can lead to interesting solutions, I do feel that such a
diode matrix is outisde the spirit of the problem. After all, you could
say it can be solved with no ICs at all, just lots of discrete
transistors, etc. :-)
-tony
29 Oct
29 Oct
4:06 p.m.
On 2010 Oct 29, at 2:10 PM, Tony Duell wrote:
For those who are wondeirng, the 'trivial' solution I mentioned uses 7
off 74150 16-input multiplexers, one for each segment. You tie the
inputs
high low to determine if that segment is on or off for a given set fo 4
input bits.
After posing that, I thought of other solutions that make no
assumptions
about the segment patterns -- they always work. For example 7 off
74151 8
input muxes and a single inverter (1/6 of a 7404) That has the
advantage
of automatically providing actrive high and active low outputs.
That only gives you 8 patterns, not 16 .. ?
Or use a 74154 to decode the input bits and then
logically OR the
active
low outputs together with 7430 8-input NANDs. The thing is that a given
segment is either on in 8 or fewer patterns or it's off in 8 or fewer
patterns (it must be one or the other since there are only 16
patterns).
So you can get away with 8 input NAND gates, maybe you need to invert
the
outputs (7404s again) [1]. So that's 9 packages (74154, 24 pin, 7 off
7430, 14 pin and a 7404, also 14 pin. If you need to invert all 7
putputs,
and thus need more than the contents of a 7404, then I would simply
redefine the problem to use the other type of display :-). Actually, in
all cases you probably want some kind of driver on the outputs, so you
can pck a normal or inverting onme.
I've not writtne down the turth table so I don't know if you can use
smaller NAND gates for some of the outputs, and thus get away with
fewer
packages.
You can get by with 4-in for 2 or 3 of the segs, depending on c or C.
Anoyther idea. A '247 to get the 0-9 patterns. 3
off '253 dual 4-input
mexes. These decode the low 3 bits (and may need an extra inverter) to
Each one of those 5 or 6 muxes (for 5 segs) only gives you 4
states/patterns, there are 6 (A-F) patterns needed (?).
get the segment aptters of the a,b,c,d,f segmetns of
the A-F patterns
(e
and g are always on in those states. And a little bit of logic to
disable
the '247, enable the muxes and turn on e,g for the appropriat input
states. Probably only a couple more chips.
30 Oct
30 Oct
1:41 p.m.
On 2010 Oct 29, at 2:10 PM, Tony Duell wrote:
Err, no. That's what the extra inverter is for.
You know hos to use a 2^n input mux to make an arbitrary combinartorial
function of n signals. Feed the n signals to the select inputs of the
multiplexer and wire the 'data' inputs high or low as the truth table
requires.
But you can also yuse a 2^(n-1) input mux and maybe a single inverte, you
connect n-1 of the input lines to the select inputs of the mux. And then
for each of those combinations you consider the 2 truth table lines that
apply (the last input, the one you've not used yet, of course
distinguishes between the 2 lines in each pair). There are 4 possibilites
:
a) The output of the function is 0 in both cases (it doesn't depend on
the last input at all) --> wire that input of thr mux to ground
b) It's 1 in both cases -> wire the input to Vcc
c) It's 0, 1 , it follows the last input in this case -> Wire that last
input signal to the appropraite input of the multiplexer
d) It's 1,0, it's the opposite of the last input. This is when you need
that inverter. Invert the last input signal and wire the appropriate
multiplexer input to the ouptu of the inverter.
If oyu requre several functions of the same inputs (as here), you only
need 1 ivnerter (assumeing there are no fan-out problems), since it's
always thge same singal (say the 2^0 data input) you need to invert.
Son yes, you can use 8 input multiplexers here (and 4 input ones if you
only want to generate 6 or 8 patterns).
Now, another silly aside...
If you want to use a 2^(n-2) mux, you may need any or all of the 16
possible functions of the last 2 inputs (you split up the truth table
into sets of 4 lines, and see which function of the last 2 inputs gives
the right paattern, of course). This makes it less useful :-). But it's
made me think pof a chip that AFAIK never existed... If you think of those
16 possible functions of 2 inputs, then 4 of them are 'trivial' in the
sense that you can produce them with no logic at all. Namely 'always 0',
'always 1', 'equal to the A input' and 'equal to the B input'.
Which
leaves 12 non-rtrivial ones/ Now that means there could have been a 16
pin IC with 2 power pins, 2 inputs and 12 outputs, the 12 non-trivial
functions of the 2 inputs. Use that witha 74150 for an arbitrary fucntion
of 6 inputs...
-tony
For those who are wondeirng, the 'trivial' solution I mentioned uses 7
off 74150 16-input multiplexers, one for each segment. You tie the
inputs
high low to determine if that segment is on or off for a given set fo 4
input bits.
After posing that, I thought of other solutions that make no
assumptions
about the segment patterns -- they always work. For example 7 off
74151 8
input muxes and a single inverter (1/6 of a 7404) That has the
advantage
of automatically providing actrive high and active low outputs.
That only gives you 8 patterns, not 16 .. ?
4944
days inactive
4953
days old
82 comments
20 participants
participants (20)
-
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
bobalan＠sbcglobal.net -
cclist＠sydex.com -
chd＠chdickman.com -
cisin＠xenosoft.com -
coredump＠gifford.co.uk -
dfnr2＠yahoo.com -
doug＠stillhq.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
hilpert＠cs.ubc.ca -
mcguire＠neurotica.com -
philpem＠philpem.me.uk -
ragooman＠gmail.com -
scanning.cc＠gmail.com -
spc＠conman.org -
teoz＠neo.rr.com -
v.slyngstad＠frontier.com -
wdonzelli＠gmail.com