2 Mar
2012
2 Mar
'12
9:08 p.m.
I wonder if anyone has experience with Cosmac Elf. I've been trying to
build one on breadboard but have troubles with the input section. Please
let me know if you have built one! Thanks
Greg Lorincz
4 Mar
4 Mar
10:03 p.m.
On Fri, Mar 2, 2012 at 9:08 PM, Gergely L?rincz <alkopop79 at gmail.com> wrote:
I wonder if anyone has experience with Cosmac Elf.
I've been trying to
build one on breadboard but have troubles with the input section. Please
let me know if you have built one! Thanks
I built one from the original Popular Electronics magazine plans
(including the CDP1861 interface). What's the problem?
In my own case, when I first built it, I had a wiring fault that
caused odd input behavior. I simply miscounted pins and miswired D5
or D6 somewhere. The fix was to move the join.
To guess, I know of one common issue with hand-made 1802 designs - the
4016 and 4066 are not 100% interchangable. They have different switch
response characteristics. ISTR the older designs used 4016 switches
which are harder to find now than 4066 switches.
If not that, then the other issue to investigate is to ensure that the
input button is debounced and generating proper DMA-IN requests (and
that the CPU is in LOAD mode).
-ethan
5 Mar
5 Mar
3:41 p.m.
Ethan Dicks wrote about the COSMAC Elf:
To guess, I know of one common issue with hand-made
1802 designs - the
4016 and 4066 are not 100% interchangable. They have different switch
response characteristics. ISTR the older designs used 4016 switches
which are harder to find now than 4066 switches.
It's certainly true that the
4016 and 4066 have differences in their
characteristics. However, in the simple way in which it is used in the
Elf, I can't see how it would make any difference. I can't say that
I've actually tried it, though.
If not that, then the other issue to investigate is to
ensure that the
input button is debounced
Yes, that is quite important.
4:15 p.m.
On 03/05/2012 03:41 PM, Eric Smith wrote:
that and also making sure all the wires go where they are supposed to.
I've built many of the COSMAC ELFs over the years and still have my wire
wrapped original, a
QUEST PCB version and a few more wire wrapped variants. I made a version
of the ELF on S100.
I also have the EELF and ELF2000. It was a simple and very
non-critical CPU to build up and make work.
Of the old CPUs I still play with and use the Z80 (Z180, Z280) are most
used, 8085 the next, 8048/51,
1802, and the 6100(pdp8). Of all the 1802 is the most interesting as
it's not unlike the PDP-8 in that its
simple to the extreme yet still useful.
Allison
Ethan Dicks wrote about the COSMAC Elf:
I have no difference.
To guess, I know of one common issue with
hand-made 1802 designs -
the 4016 and 4066 are not 100% interchangable. They have different
switch response characteristics. ISTR the older designs used 4016
switches which are harder to find now than 4066 switches.
It's certainly true
that the 4016 and 4066 have differences in their
characteristics. However, in the simple way in which it is used in
the Elf, I can't see how it would make any difference. I can't say
that I've actually tried it, though.
If not that,
then the other issue to investigate is to ensure that
the input button is debounced
Yes, that is quite important.
4:48 p.m.
On Mon, Mar 5, 2012 at 4:15 PM, allison <ajp166 at verizon.net> wrote:
I was told by the engineer who made the Quest SuperElf that he had a
problem subbing 4066s for 4016s. He was rather insistent there was a
problem. I have not tried it myself, either. My breadboard Elf and
my Quest Elf have 4016 switches.
Ethan Dicks
wrote about the COSMAC Elf:
It's certainly true that the 4016 and 4066 have differences in their
characteristics. ?However, in the simple way in which it is used in the Elf,
I can't see how it would make any difference. ?I can't say that I've
actually tried it, though.
I have no difference. that and also making sure all the wires go where they
are supposed to.
Indeed. That was my problem on my Popular Electronics Elf.
I've built many of the COSMAC ELFs over the years
and still have my wire
wrapped original, a
QUEST PCB version and a few more wire wrapped variants. I made a version of
the ELF on S100.
Nice.
I also have the EELF and ELF2000. ? It was a simple
and very non-critical
CPU to build up and make work.
Yep. I've built those, too. I just pulled out my Elf2K this weekend.
I need to re-do the switch plate label - somehow a drop of oil got
onto the paper and left a stain.
?Of all the 1802 is the most interesting as it's
not unlike the PDP-8 in that its
simple to the extreme yet still useful.
Agreed.
There's one thing I can do on my Elf2000 that I still can't do on a
PDP-8... play Zork.
-ethan
7:50 p.m.
Thanks! Every answer has been very useful! I spent days trying to figure
out what went wrong. I rebuilt and rewired the entire input and output
section, tested every IC on a separate breadboard, check voltages with
multimeter on vcc and ground pins, measured signal with an oscilloscope and
it still doesn't work. These are the symptoms:
- the 4016 work when the ENABLE pins are high (tied to a voltage source)
yet they don't let anything go through when wired to the control circuit
- the HP hex displays work perfectly except the control circuit never sends
logic low signal. When the LATCH ENABLE pin is low, the display shows
whatever comes from the bus. When wired to the ground, the display happily
updates its content when I poke random bus wires. I tested the hex displays
(four actually) separately, they work fine.
Therefor the trouble is somewhere in the control circuit. The 4013 and the
4023 seem to be the culprits.
On 5 March 2012 21:48, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On Mon, Mar 5, 2012 at 4:15 PM, allison <ajp166 at
verizon.net> wrote:
I was told by the engineer who made the Quest SuperElf that he had a
problem subbing 4066s for 4016s. He was rather insistent there was a
problem. I have not tried it myself, either. My breadboard Elf and
my Quest Elf have 4016 switches.
> Ethan Dicks wrote about the COSMAC Elf:
> It's certainly true that the 4016 and 4066 have differences in their
> characteristics. However, in the simple way in which it is used in the
Elf,
I
can't see how it would make any difference. I can't say that I've
actually tried it, though.
I have no difference. that and also making sure all the wires go where
they are supposed to.
Indeed. That was my problem on my Popular Electronics Elf.
I've built many of the COSMAC ELFs over the
years and still have my wire
wrapped original, a
QUEST PCB version and a few more wire wrapped variants. I made a version
of
the ELF on S100.
Nice.
I also have the EELF and ELF2000. It was a
simple and very non-critical
CPU to build up and make work.
Yep. I've built those, too. I just pulled out my Elf2K this weekend.
I need to re-do the switch plate label - somehow a drop of oil got
onto the paper and left a stain.
Of all the 1802 is the most interesting as
it's
not unlike the PDP-8 in that its
simple to the extreme yet still useful.
Agreed.
There's one thing I can do on my Elf2000 that I still can't do on a
PDP-8... play Zork.
-ethan
9:14 p.m.
On 03/05/2012 04:48 PM, Ethan Dicks wrote:
Wire wrap has always looked like a bowl of pasta to me. Even my own work.
It's one of those CPUs that can be almost called an attractive nusance. ;)
One thing I've not done yet is build a software compatible TTL or CMOS SSI
version of the 1802 from the ground up. I think a 4 2901s could do th bulk
of the registers and D nicely.
I like my EELF as it's the whole stack with 8x24 video board. It ended
up in
an old Atlantic Research RS232 line monitor box with a nice 5" monitor. So
the whole result with a PS2 keyboard is very portable though for AC power
only. I need to build a power supply so it can run on a 12V source as there
is room for 7AH battery inside..
But consider this it was lunar lander and a few other games on PDP8
( or PDP12) that got the games thing going. Having played lunar lander
with analog inputs on a vector monitor, I can say it's fun.
Allison
On Mon, Mar 5, 2012 at 4:15 PM, allison<ajp166 at
verizon.net> wrote:
I was told by the engineer
who made the Quest SuperElf that he had a
problem subbing 4066s for 4016s. He was rather insistent there was a
problem. I have not tried it myself, either. My breadboard Elf and
my Quest Elf have 4016 switches.
That may be the super elf. There is one oddity of the 1802, if run at
higher speeds
the timing of the control signals tend to skew badly. Also like all
CMOS voltages
at the pins are critical. I found the 4066 to be better, it's the same
as the 4016
but the series resistance of each switch is lower and the rate is can switch
on or off is a bit faster. I've used both with no issue but I'm fussy
about the
timing and clock rates.
Like any CMOS system get the ground and power well bussed and clean.
It's tolerant but some parts can throw spikes when they switch that are
nasty.
Ethan
Dicks wrote about the COSMAC Elf:
It's certainly true that the 4016 and 4066 have differences in their
characteristics. However, in the simple way in which it is used in the Elf,
I can't see how it would make any difference. I can't say that I've
actually tried it, though.
I have no difference. that and also
making sure all the wires go where they are supposed to.
Indeed. That was my
problem on my Popular Electronics Elf.
I've built
many of the COSMAC ELFs over the years and still have my wire
wrapped original, a
QUEST PCB version and a few more wire wrapped variants. I made a version of
the ELF on S100.
Nice.
I also have
the EELF and ELF2000. It was a simple and very non-critical
CPU to build up and make work.
Yep. I've built those, too. I just pulled out
my Elf2K this weekend.
I need to re-do the switch plate label - somehow a drop of oil got
onto the paper and left a stain.
Of all the
1802 is the most interesting as it's
not unlike the PDP-8 in that its
simple to the extreme yet still useful.
Agreed.
There's one thing I can do on my Elf2000 that I still can't do on a
PDP-8... play Zork.
10:04 p.m.
New subject: Wire-wrap (was Re: Cosmac Elf on breadboard)
allison wrote:
Wire wrap has always looked like a bowl of pasta to
me. Even my own
work.
In my experience, if a wire-wrapped board looks neat, it probably won't
work. Neat wire-wrapped board tend to have lots of parallel wires,
which can cause problems. Rat's-nest style generally works well.
6 Mar
6 Mar
4:35 a.m.
I wonder, which one is more reliable, wire-wrapping or soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
On 6 March 2012 02:14, allison <ajp166 at verizon.net> wrote:
On 03/05/2012 04:48 PM, Ethan Dicks wrote:
Indeed. That was my problem on my Popular Electronics Elf.
Wire wrap has always looked like a bowl of pasta to me. Even my own work.
I've built many of the COSMAC ELFs over the years and still have my wire
;)
One thing I've not done yet is build a software compatible TTL or CMOS SSI
version of the 1802 from the ground up. I think a 4 2901s could do th bulk
of the registers and D nicely.
I also have the EELF and ELF2000. It was a simple and very non-critical
up
in
an old Atlantic Research RS232 line monitor box with a nice 5" monitor. So
the whole result with a PS2 keyboard is very portable though for AC power
only. I need to build a power supply so it can run on a 12V source as
there
is room for 7AH battery inside..
Of all the 1802 is the most interesting as it's
But consider this it was lunar lander and a few other games on PDP8
( or PDP12) that got the games thing going. Having played lunar lander
with analog inputs on a vector monitor, I can say it's fun.
Allison
On Mon, Mar 5, 2012 at 4:15 PM, allison<ajp166
at verizon.net> wrote:
higher
speeds
the timing of the control signals tend to skew badly. Also like all CMOS
voltages
at the pins are critical. I found the 4066 to be better, it's the same as
the 4016
but the series resistance of each switch is lower and the rate is can
switch
on or off is a bit faster. I've used both with no issue but I'm fussy
about the
timing and clock rates.
Like any CMOS system get the ground and power well bussed and clean.
It's tolerant but some parts can throw spikes when they switch that are
nasty.
that and also making sure all the wires go where they are supposed to.
Ethan Dicks wrote about the COSMAC Elf:
I was told by the engineer who made the Quest SuperElf that he had a
problem subbing 4066s for 4016s. He was rather insistent there was a
problem. I have not tried it myself, either. My breadboard Elf and
my Quest Elf have 4016 switches.
That may be the super elf. There is one oddity of the 1802, if run at It's certainly true that the 4016 and 4066
have differences in their
characteristics. However, in the simple way in which it is used in the
Elf,
I can't see how it would make any difference. I can't say that I've
actually tried it, though.
I have no difference.
wrapped
original, a
QUEST PCB version and a few more wire wrapped variants. I made a version
of
the ELF on S100.
Nice.
It's one of those CPUs that can be almost called an attractive nusance. CPU to
build up and make work.
Yep. I've built those, too. I just pulled out my Elf2K this weekend.
I need to re-do the switch plate label - somehow a drop of oil got
onto the paper and left a stain.
I like my EELF as it's the whole stack with 8x24 video board. It ended not
unlike the PDP-8 in that its
simple to the extreme yet still useful.
Agreed.
There's one thing I can do on my Elf2000 that I still can't do on a
PDP-8... play Zork.
1:45 p.m.
On Tue, Mar 6, 2012 at 4:35 AM, Gergely L?rincz <alkopop79 at gmail.com> wrote:
I wonder, which one is more reliable, wire-wrapping or
soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
Veroboard is not common in the States (I bought some from Dick Smith's
the last time I was in NZ), so my choices have been wire-wrapping or
point-to-point wiring occasionally using multi-pad prototyping board
(some have a few bus lines, others have 2-4 adjacent holes connected).
I've had no reliability problems with point-to-point using
machined-pin sockets.
Wire-wrap with good sockets and good wraps is quite reliable, I just
prefer using less expensive sockets and having a shorter/thinner
design that's often easier to pack into a project case. Wire-wrap
with a "Just Wrap" tool is probably faster.
I did dabble with wire-wrap as a kid in the 1970s, but any failures
there were due to my inexperience not the reliability of the
technology. I got good at soldering, so I switched to point-to-point
and have built many successful projects that way.
My Popular Electronics Elf (built in 2004) was done with
point-to-point soldering, not wire-wrap, BTW. I had no joint or
socket problems, and it was perfectly reliable once I identified and
moved the lone wiring error.
-ethan
1:45 p.m.
On 6 Mar 2012 at 9:35, Gergely L"orincz wrote:
I wonder, which one is more reliable, wire-wrapping or
soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
Done well, they're probably about the same. You're limited by the
PCB in using vero, but wire-wrap is 3-dimensional; it can be very
dense indeed and lends itself to some interesting techniques, such as
using twisted pair for ECL.
--Chuck
3:46 p.m.
I can make PCBs at home, probably I should design a semi-point-to-point
board.
On 6 March 2012 18:45, Chuck Guzis <cclist at sydex.com> wrote:
On 6 Mar 2012 at 9:35, Gergely L"orincz wrote:
I wonder, which one is more reliable,
wire-wrapping or soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
Done well, they're probably about the same. You're limited by the
PCB in using vero, but wire-wrap is 3-dimensional; it can be very
dense indeed and lends itself to some interesting techniques, such as
using twisted pair for ECL.
--Chuck
3:30 p.m.
I wonder, which one is more reliable, wire-wrapping or soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
Wire-wrapping is certainly very reliable.
But practically, for something like this, I don;t think you'd have any
problems using wire=-weapping, stripboard, roadrunner tool, or any
reasonable construcitonal method. If you do any of them properly it'll
work.
-tony
4:40 p.m.
On 03/06/2012 04:35 AM, Gergely L?rincz wrote:
I wonder, which one is more reliable, wire-wrapping or
soldering on a
vero/stripboard? I fancy learning wire wrapping but it's expensive.
I use spool
wire, a few colors, hand stripper of the automatic type,
and a OKtool manual (you squeeze to spin the bit) and good gold tail
sockets.
Even now it's less expensive to equip to do that than buy the soldering
gear and
all.
Reliability, I have panels I made up back in the 70s still running
(including an ELF).
Its easier to train an operator to do wirewrap and recognoze a good wrap
than
soldering. No power needed to make up a board so the kit to do it is
portable.
Oh, there are no RoHS issues with wirewrap (no lead, no fluxes).
The largest system done with wirewrap by me was about 200 pcs TTL and
bit slice. It was a complete custom processor with ram and IO.
Allison
On 6 March 2012 02:14, allison<ajp166 at
verizon.net> wrote:
> On 03/05/2012 04:48 PM, Ethan Dicks wrote:
>
>> On Mon, Mar 5, 2012 at 4:15 PM, allison<ajp166 at verizon.net> wrote:
>>
>>> Ethan Dicks wrote about the COSMAC Elf:
>>>> It's certainly true that the 4016 and 4066 have differences in their
>>>> characteristics. However, in the simple way in which it is used in the
>>>> Elf,
>>>> I can't see how it would make any difference. I can't say that
I've
>>>> actually tried it, though.
>>>>
>>> I have no difference.
>>>
>> I was told by the engineer who made the Quest SuperElf that he had a
>> problem subbing 4066s for 4016s. He was rather insistent there was a
>> problem. I have not tried it myself, either. My breadboard Elf and
>> my Quest Elf have 4016 switches.
>>
>> That may be the super elf. There is one oddity of the 1802, if run at
> higher speeds
> the timing of the control signals tend to skew badly. Also like all CMOS
> voltages
> at the pins are critical. I found the 4066 to be better, it's the same as
> the 4016
> but the series resistance of each switch is lower and the rate is can
> switch
> on or off is a bit faster. I've used both with no issue but I'm fussy
> about the
> timing and clock rates.
>
> Like any CMOS system get the ground and power well bussed and clean.
> It's tolerant but some parts can throw spikes when they switch that are
> nasty.
>
>
> that and also making sure all the wires go where they are supposed to.
>> Indeed. That was my problem on my Popular Electronics Elf.
>>
>> Wire wrap has always looked like a bowl of pasta to me. Even my own
> work.
>
>
> I've built many of the COSMAC ELFs over the years and still have my wire
>>> wrapped original, a
>>> QUEST PCB version and a few more wire wrapped variants. I made a version
>>> of
>>> the ELF on S100.
>>>
>> Nice.
>>
>> It's one of those CPUs that can be almost called an attractive nusance.
> ;)
>
> One thing I've not done yet is build a software compatible TTL or CMOS SSI
> version of the 1802 from the ground up. I think a 4 2901s could do th bulk
> of the registers and D nicely.
>
>
>
> I also have the EELF and ELF2000. It was a simple and very non-critical
>>> CPU to build up and make work.
>>>
>> Yep. I've built those, too. I just pulled out my Elf2K this weekend.
>> I need to re-do the switch plate label - somehow a drop of oil got
>> onto the paper and left a stain.
>>
>> I like my EELF as it's the whole stack with 8x24 video board. It ended
> up in
> an old Atlantic Research RS232 line monitor box with a nice 5" monitor. So
> the whole result with a PS2 keyboard is very portable though for AC power
> only. I need to build a power supply so it can run on a 12V source as
> there
> is room for 7AH battery inside..
>
>
> Of all the 1802 is the most interesting as it's
>>> not unlike the PDP-8 in that its
>>> simple to the extreme yet still useful.
>>>
>> Agreed.
>>
>> There's one thing I can do on my Elf2000 that I still can't do on a
>> PDP-8... play Zork.
>>
>>
> But consider this it was lunar lander and a few other games on PDP8
> ( or PDP12) that got the games thing going. Having played lunar lander
> with analog inputs on a vector monitor, I can say it's fun.
>
> Allison
>
6:58 p.m.
New subject: CIn defense of wire-wrap; was: osmac Elf on breadboard
On 6 Mar 2012 at 16:40, allison wrote:
I use spool wire, a few colors, hand stripper of the
automatic type,
and a OKtool manual (you squeeze to spin the bit) and good gold tail
sockets. Even now it's less expensive to equip to do that than buy the
soldering gear and all.
Sometimes for prototypes, I use socket pins and single-sided blank
FR4 PCB stock. Drill holes for the pins with a #49 drill--releive
the holes slightly on the copper side with a quick twist of a larger
bit, shove the pins in, use the copper as a ground plane. The result
looks very nice.
But you can get good results with an $8 Radio Shack wire wrap tool
that includes a stripper.
The nice thing about wire wrap is that you can use different colors
for different signals. Makes debugging a little easier.
Repairs/modifications are easy--no soldering involved.
(I use a G-D electric gun and an Augat stripper). I've got boards
that I assembled more than 20 years ago still working fine.
--Chuck
8:15 p.m.
New subject: CIn defense of wire-wrap; was: osmac Elf on breadboard
On Mar 6, 2012, at 6:58 PM, Chuck Guzis wrote:
(I use a G-D electric gun and an Augat stripper).
I've got boards
that I assembled more than 20 years ago still working fine.
I don't see why they wouldn't; the wire-wrapping process actually
cold-welds the wire to the corners of the pin and makes a fairly
gas-tight seal. If you're providing the correct amount of relief
with unstripped wire at the end of the wrap, there's no reason your
connections shouldn't last longer than a soldered one; it's actually
less stress on the joint.
Of course, the outside of the wrap starts to look pretty ugly pretty
quickly, so perhaps people just assume they'll go bad quickly if
they've never used wire-wrap.
I should also point out that all of the original Macintosh
prototypes were wire-wrapped, which should probably indicate that
it's a pretty sound methodology for assembling microcomputers.
It worked well enough in '83, anyway.
- Dave
8:58 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On 6 Mar 2012 at 20:15, David Riley wrote:
I should also point out that all of the original
Macintosh
prototypes were wire-wrapped, which should probably indicate that it's
a pretty sound methodology for assembling microcomputers. It worked
well enough in '83, anyway.
Unless my memory has completely failed me, some microprocessor
prototypes were first done up in wirewrap before going to silicon.
And there were plenty of wirewrapped backplanes.
Wasn't it WECo who pioneered wire-wrap in the 1950s?
There was also a sort of "stitched wire" fabrication method. I can't
for the life of me remember the name of it, however.
--Chuck
5:07 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
In article <4F565053.21950.1E295BF at cclist.sydex.com>,
"Chuck Guzis" <cclist at sydex.com> writes:
On 6 Mar 2012 at 20:15, David Riley wrote:
The Nuclear Data ND812 CPU is all wire-wrapped SSI/MSI 7400 series logic.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 version available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
I should also point out that all of the original
Macintosh
prototypes were wire-wrapped, which should probably indicate that it's
a pretty sound methodology for assembling microcomputers. It worked
well enough in '83, anyway.
Unless my memory has completely failed me, some microprocessor
prototypes were first done up in wirewrap before going to silicon.
And there were plenty of wirewrapped backplanes. 
5:16 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
The Nuclear Data ND812 CPU is all wire-wrapped SSI/MSI
7400 series logic.
Another production unit that shipped with lots of wire-wrap on board was
the IBM 3803 tape controller. E.g. from Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open-small.jpg
De
5:33 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On 03/07/2012 05:16 PM, Dennis Boone wrote:
Many (most?) DEC backplanes, like the PDP-11/70:
http://www.neurotica.com/albums/pdp1170/DSCN1161.JPG
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
The Nuclear
Data ND812 CPU is all wire-wrapped SSI/MSI 7400 series logic.
Another production unit that shipped with lots of wire-wrap on board was
the IBM 3803 tape controller. E.g. from Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open-small.jpg 
9:42 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Mar 7, 2012, at 5:33 PM, Dave McGuire wrote:
On 03/07/2012 05:16 PM, Dennis Boone wrote:
Many (most?) DEC backplanes, like the PDP-11/70:
http://www.neurotica.com/albums/pdp1170/DSCN1161.JPG
Also all of the PDP-10 backplanes, unless I heard wrong.
My '11 backplane (whose number I keep forgetting) is a PCB, but
they kindly left wire wrap stakes on the back so I could convert
it to 22-bit.
- Dave
The
Nuclear Data ND812 CPU is all wire-wrapped SSI/MSI 7400 series logic.
Another production unit that shipped with lots of wire-wrap on board was
the IBM 3803 tape controller. E.g. from Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open-small.jpg
11:51 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
David Riley wrote:
Also all of the PDP-10 backplanes, unless I heard
wrong. My '11
backplane (whose number I keep forgetting) is a PCB, but they kindly
left wire wrap stakes on the back so I could convert it to 22-bit.
The KL10 CPU
backplane is a PCB, with some of the wiring etched, and
some wire-wrapped. Since it's ECL, some of the wire-wrapped signals are
differential pairs, using twisted pair.
8 Mar
8 Mar
2:41 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
From: David Riley
Sent: Wednesday, March 07, 2012 6:43 PM
On Mar 7, 2012, at 5:33 PM, Dave McGuire wrote:
> On 03/07/2012 05:16 PM, Dennis Boone wrote:
>>> The Nuclear Data ND812 CPU is all wire-wrapped SSI/MSI 7400 series logic.
>> Another production unit that shipped with lots
of wire-wrap on board was
>> the IBM 3803 tape controller. E.g. from Pat's collection:
> Many (most?) DEC backplanes, like the PDP-11/70:
>
> http://www.neurotica.com/albums/pdp1170/DSCN1161.JPG
Also all of the PDP-10 backplanes, unless I heard
wrong.
My '11 backplane (whose number I keep forgetting)
is a PCB, but
they kindly left wire wrap stakes on the back so I could convert
it to 22-bit.
DEC began using Gardner-Denver wirewrap machines with the advent of the
PDP-7 and FlipChip(TM) circuit boards. Prior to the -7, every computer
built by DEC was hand soldered by teams of engineers and technicians.
(One piece of the PDP-7, the DECtape controller, is shared with the PDP-4,
and is constructed of System Modules(TM) connected by a soldered backplane.)
NB: Those (TM) may be (R). I'm not going to bother to check right now. ;-)
Rich Alderson
Vintage Computing Sr. Systems Engineer
Vulcan, Inc.
505 5th Avenue S, Suite 900
Seattle, WA 98104
mailto:RichA at vulcan.com
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
3:18 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On 8 Mar 2012 at 19:41, Rich Alderson wrote:
NB: Those (TM) may be (R). I'm not going to
bother to check right
now. ;-)
Actually "Wire-wrap" is (TM) Cooper Industries...
http://www.cooperhandtools.com.au/PDFs/Wire-Wrap%2009.pdf
I can't imagine wrapping with 18AWG wire, but there it is...
--Chuck
7 Mar
7 Mar
5:51 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Wed, 7 Mar 2012, Dennis Boone wrote:
Another production unit that shipped with lots of
wire-wrap on board was
the IBM 3803 tape controller. E.g. from Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open-small.jpg
The central computer (Hughes H5118ME) of the AN/FYQ-93 air defense
system had a slightly larger backplane, all wire-wrapped. It didn't
generally cause problems, unless someone was fooling around in the back.
It took us 5 days to track down a connection problem on the backplane
once, eventually doing point-to-point continuity checks.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
6:54 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of Mike Loewen
Sent: 07 March 2012 22:51
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Wed, 7 Mar 2012, Dennis Boone wrote:
Machine produced wire wrap is extremely reliable. The wire forms a cold weld
round the sharp corners of the post. I think the most common problem was a
wire being strung too tight and an extra contact being created when a post
rubbed through the insulation.
Most mainframes of the 60's had large quantities of wire wrap. We had a
Honeywell L66 (basically an slightly upragde GE600//6000). It had I guess
about 100 12" square boards which were wire wrapped on the back. The back
plane these fitted into was also wire wrapped. Some was produced completely
automatically on cnc driven machines
Another production unit that shipped with lots of
wire-wrap
on board was
the IBM 3803 tape controller. E.g. from
Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open
-small.jpg
The central computer (Hughes H5118ME) of the AN/FYQ-93
air defense
system had a slightly larger backplane, all wire-wrapped. It didn't
generally cause problems, unless someone was fooling around
in the back.
It took us 5 days to track down a connection problem on the backplane
once, eventually doing point-to-point continuity checks.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology
http://sturgeon.css.psu.edu/~mloewen/Oldtech/
8 Mar
8 Mar
1:55 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
In 1981 I was invited to watch a Burroughs technician apply a patch to
the university's B6700 mainframe. The machine was entirely wire-wrapped.
He came in and pulled out the affected board and opened a sealed package
that included some drawings and text, two pieces of wire precut to the
correct length and with the ends stripped plus a manual wire-wrap tool.
I was surprised to see the latter for two reasons: we used powered
wire-wrap tools on our own boards (based on the 6800 processor and which
interfaced to the B6700 by emulating a terminal) and the idea that each
patch should pack a separate tool seemed silly since this isn't exactly
medical supply or something.
Having done a lot of wire-wrapping with both powered tools and manually,
I can do it either way without much trouble. Powered tools are faster
and more consistent, but most of the improved results I got with them
were due to using a much better wire stripper than the one built into
the manual tool.
In 1986 I had finished a 68000 computer done entirely in wire-wrap and
the number one problem had been finding a low cost board that was large
enough. The solution was to buy two boards and mount them in a wooden
picture frame, as seen on the right side of these two pictures:
http://www.smalltalk.org.br/fotos/inova6.jpg
http://www.smalltalk.org.br/fotos/inova7.jpg
Since the 68000 would take up a significant board area, I arranged it so
each row of pins was on a separate board and below the chip was the gap
between the boards. The boards had wide copper tracks which would make a
nice power distribution system, but I ended up having to do the power in
wire-wrap too and that turned out to be a significant part of the
construction effort.
One month before the big computer show in Brazil, my partner decided
that this black and white Mac-like machine was too pathetic and asked me
to design a more powerful version with color. This is the machine on the
left in those pictures. We didn't have time for a normal wire-wrap
prototype and my partner wanted something that looked closer to a
finished product. We had just bought a PCB CAD program (I think it was
called SmartWorks) but a quick test showed that though it helped with
regular designs like the memory banks, the random parts of the design
would take more time than wire-wrap.
So my friend, Ruy Cesar Pinto Neto, came up with the idea of doing the
memory as a normal PCB with the CAD (you had to print it twice with the
dot matrix to get it dark enough at four times the normal size and then
photographically reduce it to get the PCB masks) and to do the random
part as a single sided PCB with just the power distribution and normal
IC sockets (costing a fraction of what the equivalent wire-wrap sockets
cost) with each pin connected with a very short track to a wire-wrap
post on the component side. It was amazing how much faster it was to
wire-wrap without constantly flipping over the board. The wires had to
be a little longer since they had to snake around the components instead
of being point to point but that didn't prove to be a problem. We
actually were able to build three who prototypes (of which two were
working) by the start of the computer show. With the two boards
connected to each other, the wire-wrap was completely hidden and the
result looked like something that was reasonably close to shipping.
http://www.smalltalk.org.br/fotos/inova3.jpg
Though the two projects I did after this one used traditional wire-wrap,
my experience with this hybrid technique was very positive and I
recommend it. My big mistake was not designing in some spare 14 and 16
pins sockets - you can see a 14 pin wire-wrap socket glued on its side
on the top right of the bottom board in the second picture as the result
of this.
-- Jecel
7 Mar
7 Mar
7:24 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On 2012 Mar 7, at 2:51 PM, Mike Loewen wrote:
On Wed, 7 Mar 2012, Dennis Boone wrote:
There was another backplane wiring technique in the mid-60s using
crimps. Could be mistaken for wire-wrap from a distance, but the wire
is crimped to the pin with a folded metal crimp, not wrapped.
The early HP 21xx machines used it, some photos of a 2116C backplane:
http://www3.telus.net/~bhilpert/tmp/2116Cbp/crimps.jpg
http://www3.telus.net/~bhilpert/tmp/2116Cbp/backplane.jpg
I've never heard a distinct name for it.
What's the earliest instance of wire-wrap anyone knows of?
Another production unit that shipped with lots of
wire-wrap on
board was
the IBM 3803 tape controller. E.g. from Pat's collection:
http://computer-refuge.org/compcollect/ibm/3420/3803-back-open-
small.jpg
The central computer (Hughes H5118ME) of the AN/FYQ-93 air
defense system had a slightly larger backplane, all wire-wrapped.
It didn't generally cause problems, unless someone was fooling
around in the back. It took us 5 days to track down a connection
problem on the backplane once, eventually doing point-to-point
continuity checks. 
9:19 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On 7 Mar 2012 at 20:31, William Donzelli wrote:
Yup, you'll see crossbar switches full of it. Of course, not using
30AWG Kynar-insulated wire, more like 26AWG. It may still be used;
I'm not up to date on the latest switching gear.
Generally speaking, if Ma Bell adopted a technology, it was probably
pretty durable. Modular plugs excepted.
--Chuck
What's the
earliest instance of wire-wrap anyone knows of?
Chuck mentioned WECo. Certainly it was in common use in the mid-1950s
in COs. 
9:31 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
Generally speaking, if Ma Bell adopted a technology,
it was probably
pretty durable. ?Modular plugs excepted.
Real Western Electric modular plugs are actually very good and can
withstand a zillion insert cycles.
But there hasn't been a real WE modular plug made in a very long time...
--
Will
8 Mar
8 Mar
4:06 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
Generally speaking, if Ma Bell adopted a
technology, it was probably
pretty durable. =A0Modular plugs excepted.
Real Western Electric modular plugs are actually very good and can
withstand a zillion insert cycles.
But there hasn't been a real WE modular plug made in a very long time...
7 Mar
7 Mar
9:47 p.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Mar 7, 2012, at 9:19 PM, Chuck Guzis wrote:
On 7 Mar 2012 at 20:31, William Donzelli wrote:
Yup, you'll see crossbar switches full of it. Of course, not using
30AWG Kynar-insulated wire, more like 26AWG. It may still be used;
I'm not up to date on the latest switching gear.
I certainly see it on a T1/E1 plugboard at Hughes Network Systems when
I'm there (large-gauge wire, probably 26AWG, and bigger posts than what
I'm used to). It's probably used when a punchdown cross-connect is
undesirable, since those usually aren't good for much more than 1 shot.
What's the earliest instance of wire-wrap anyone knows of?
Chuck mentioned WECo. Certainly it was in common use in the mid-1950s
in COs. Generally speaking, if Ma Bell adopted a technology,
it was probably
pretty durable. Modular plugs excepted.
Modular plugs are plenty durable. It's the retention clips that break
off if you look at them wrong.
- Dave
8 Mar
8 Mar
12:02 a.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Wed, 7 Mar 2012, David Riley wrote:
It's probably used when a punchdown cross-connect
is
undesirable, since those usually aren't good for much more than 1 shot.
[citation needed]
I used to work for a small telco equipment manufacturer, and both we and
our customers (including national telcos in smaller countries) re-wired 66
and 110 blocks constantly.
Alexey
12:18 a.m.
New subject: In defense of wire-wrap; was: Cosmac Elf on breadboard
On Mar 8, 2012, at 12:02 AM, Alexey Toptygin wrote:
On Wed, 7 Mar 2012, David Riley wrote:
Well, I don't use them often. It's what I heard from a
local wiring tech; perhaps he was used to cheaper stuff?
- Dave
It's probably used when a punchdown
cross-connect is
undesirable, since those usually aren't good for much more than 1 shot.
[citation needed]
I used to work for a small telco equipment manufacturer, and both we and our customers
(including national telcos in smaller countries) re-wired 66 and 110 blocks constantly.
5 Mar
5 Mar
4:22 p.m.
On 2012 Mar 5, at 12:41 PM, Eric Smith wrote:
Ethan Dicks wrote about the COSMAC Elf:
The basic design does provide debouncing, as I'm sure you are aware
(although how it is achieved might be considered either cute or
questionable, depending upon one's attitude to design).
I wondered why they bothered to debounce the nCLEAR and nWAIT lines
when they are level-sensing rather than edge-triggerred, but I
haven't really examined the details of the 1802 functioning in depth.
To guess, I know of one common issue with
hand-made 1802 designs -
the 4016 and 4066 are not 100% interchangable. They have different
switch response characteristics. ISTR the older designs used 4016
switches which are harder to find now than 4066 switches.
It's certainly true
that the 4016 and 4066 have differences in
their characteristics. However, in the simple way in which it is
used in the Elf, I can't see how it would make any difference. I
can't say that I've actually tried it, though.
If not that, then the other issue to investigate
is to ensure that
the input button is debounced
Yes, that is quite important. 
5:29 p.m.
Eric Smith wrote:
Ethan Dicks wrote about the COSMAC Elf:
According to Don Lancaster's CMOS Cookbook the 4066
"This is an improved version of the 4016, having a lower on resistance.
However, the 4016 remains a better choice for ultralow-leakage
applications such as sample-held circuits."
John :-#)#
To guess, I know of one common issue with
hand-made 1802 designs -
the 4016 and 4066 are not 100% interchangable. They have different
switch response characteristics. ISTR the older designs used 4016
switches which are harder to find now than 4066 switches.
It's certainly true
that the 4016 and 4066 have differences in their
characteristics. However, in the simple way in which it is used in
the Elf, I can't see how it would make any difference. I can't say
that I've actually tried it, though.
If not that,
then the other issue to investigate is to ensure that
the input button is debounced
Yes, that is quite important.
4:09 a.m.
On 2012 Mar 2, at 6:08 PM, Gergely L?rincz wrote:
I wonder if anyone has experience with Cosmac Elf.
I've been trying to
build one on breadboard but have troubles with the input section.
Please
let me know if you have built one! Thanks
I was refurbishing a school-project implementation from the 70's (not
mine originally) just last summer.
http://www.cs.ubc.ca/~hilpert/e/cosmacElf/index.html
There's a re-organised version of the schematic there.
I wasn't familiar with it in depth before this, although I remember
it from the Pop Electronics article in the 70's. Kinda cute for its
simplicity.
7:55 p.m.
Thanks for the schematics, amazing!
On 5 March 2012 09:09, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2012 Mar 2, at 6:08 PM, Gergely L?rincz wrote:
I wonder if anyone has experience with Cosmac Elf. I've been trying to
build one on breadboard but have troubles with
the input section. Please
let me know if you have built one! Thanks
I was refurbishing a school-project implementation from the 70's (not mine
originally) just last summer.
http://www.cs.ubc.ca/~hilpert/**e/cosmacElf/index.html<http://www.cs.ubc…
There's a re-organised version of the schematic there.
I wasn't familiar with it in depth before this, although I remember it
from the Pop Electronics article in the 70's. Kinda cute for its simplicity.
7 Mar
7 Mar
11:21 a.m.
I finally had time to have a look at the schematics. I realised that this
schematics replaced the two 4050's with 4049s. Can you confirm that it
works? Will purchase a couple of 4049 this week, wish I wasn't under my
overdraft...
On 6 March 2012 00:55, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Thanks for the schematics, amazing!
On 5 March 2012 09:09, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2012 Mar 2, at 6:08 PM, Gergely L?rincz
wrote:
I wonder if anyone has experience with Cosmac Elf. I've been trying to
build one on breadboard but have troubles with
the input section. Please
let me know if you have built one! Thanks
I was refurbishing a school-project implementation from the 70's (not
mine originally) just last summer.
http://www.cs.ubc.ca/~hilpert/**e/cosmacElf/index.html<http://www.cs.ubc…
There's a re-organised version of the schematic there.
I wasn't familiar with it in depth before this, although I remember it
from the Pop Electronics article in the 70's. Kinda cute for its simplicity.
8 Mar
8 Mar
3:23 a.m.
On 2012 Mar 7, at 8:21 AM, Gergely L?rincz wrote:
I finally had time to have a look at the schematics. I
realised
that this
schematics replaced the two 4050's with 4049s. Can you confirm that it
works? Will purchase a couple of 4049 this week, wish I wasn't
under my
overdraft...
Inverting or non-inverting: it depends on other aspects of the
implementation.
Comparing with the schematic here:
http://incolor.inetnebr.com/bill_r/elf/html/elf-1-35.htm
http://incolor.inetnebr.com/bill_r/elf/html/elf-1-36.htm
(There is an error on page 36: IC5 at the RUN switch is labelled as
4050 (non-inverting and correct) but shown as an inverter.)
If you are following the original design strictly it looks like there
should be a 4049 and two 4050s.
The implementation I happen to have uses three 4049s because:
- simple LEDs are used for the display and so required inverters,
- the display latch is inverted as it is a different latch type,
- replaced the RUN-switch single-element non-inverting debounce
circuit
with a two-inverter circuit like the other debounce circuits.
I mentioned my schematic because it shows things on one page and the
control flow is clearer, I hope the implementation differences aren't
confusing things too much.
You mentioned checking a few things, but I don't think you actually
told use what the problem symptoms are.
Is the 1802 oscillator running?
One suggestion would be to check that the levels at the mode inputs
of the 1802 are correct for given switch settings.
On 6 March 2012 00:55, Gergely L?rincz <alkopop79
at gmail.com> wrote:
> Thanks for the schematics, amazing!
>
> On 5 March 2012 09:09, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>
>> On 2012 Mar 2, at 6:08 PM, Gergely L?rincz wrote:
>>
>> I wonder if anyone has experience with Cosmac Elf. I've been
>> trying to
>>> build one on breadboard but have troubles with the input
>>> section. Please
>>> let me know if you have built one! Thanks
>>>
>>
>> I was refurbishing a school-project implementation from the 70's
>> (not
>> mine originally) just last summer.
>>
>> http://www.cs.ubc.ca/~hilpert/**e/cosmacElf/index.html<http://
>> www.cs.ubc.ca/~hilpert/e/cosmacElf/index.html>
>>
>> There's a re-organised version of the schematic there.
>>
>> I wasn't familiar with it in depth before this, although I
>> remember it
>> from the Pop Electronics article in the 70's. Kinda cute for its
>> simplicity.
>>
>
>
9 Mar
9 Mar
8:29 a.m.
Brent, I checked the 1802 (both of them) and they seem to work fine. When
the CLEAR and WAIT pin are set high or low accordingly, TPA and TPB sends
timing pulses (checked with the scope), the status pins SC1 and SC0 show
the state of the processor (checked it against the truth table, works
fine). I think they work fine. If you have any ideas how to test the 1802s
further, let me know!
Greg
On 8 March 2012 08:23, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2012 Mar 7, at 8:21 AM, Gergely L?rincz wrote:
I finally had time to have a look at the schematics. I realised that this
schematics replaced the two 4050's with
4049s. Can you confirm that it
works? Will purchase a couple of 4049 this week, wish I wasn't under my
overdraft...
Inverting or non-inverting: it depends on other aspects of the
implementation.
Comparing with the schematic here:
http://incolor.inetnebr.com/**bill_r/elf/html/elf-1-35.htm<http://incolo…
http://incolor.inetnebr.com/**bill_r/elf/html/elf-1-36.htm<http://incolo…
(There is an error on page 36: IC5 at the RUN switch is labelled as 4050
(non-inverting and correct) but shown as an inverter.)
If you are following the original design strictly it looks like there
should be a 4049 and two 4050s.
The implementation I happen to have uses three 4049s because:
- simple LEDs are used for the display and so required inverters,
- the display latch is inverted as it is a different latch type,
- replaced the RUN-switch single-element non-inverting debounce circuit
with a two-inverter circuit like the other debounce circuits.
I mentioned my schematic because it shows things on one page and the
control flow is clearer, I hope the implementation differences aren't
confusing things too much.
You mentioned checking a few things, but I don't think you actually told
use what the problem symptoms are.
Is the 1802 oscillator running?
One suggestion would be to check that the levels at the mode inputs of the
1802 are correct for given switch settings.
On 6 March 2012 00:55, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Thanks for the schematics, amazing!
>
> On 5 March 2012 09:09, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>
> On 2012 Mar 2, at 6:08 PM, Gergely L?rincz wrote:
>>
>> I wonder if anyone has experience with Cosmac Elf. I've been trying to
>>
>>> build one on breadboard but have troubles with the input section.
>>> Please
>>> let me know if you have built one! Thanks
>>>
>>>
>> I was refurbishing a school-project implementation from the 70's (not
>> mine originally) just last summer.
>>
>>
http://www.cs.ubc.ca/~hilpert/****e/cosmacElf/index.html<http://www.cs.u…
>>
<http:**//www.cs.ubc.ca/~hilpert/e/**cosmacElf/index.html<http://www.cs.ubc.ca/~hilpert/e/cosmacElf/index.html>
>> >
>>
>>
>> There's a re-organised version of the schematic there.
>>
>> I wasn't familiar with it in depth before this, although I remember it
>> from the Pop Electronics article in the 70's. Kinda cute for its
>> simplicity.
>>
>>
>
>
6:48 p.m.
I just powered up my unit and played with it for a moment to
reacquaint myself.
I'm still not clear what your unit is or is not doing.
Starting from scratch though, a possible debugging sequence:
- assuming the power supply is correct and clean,
- you did put pull-up resistors on the 1802 inputs such as nDMAOUT
and nINTR, didn't you?
- confirm the clock frequency is not too high for the 1802 chip type
being used
(not a good idea to measure at pins 1/39 as it may affect F).
Another possibility for debugging is to feed a low frequency clock
to the chip
or set up a single-step clock circuit.
- check the Examine mode.
The idea is each push of the INPUT switch should result in a
presentation of the memory contents.
Assuming the memory contents is somewhat random at this point, the
display should present random values.
Set the 3 mode switches for PROGRAM-EXAMINE.
Confirm:
1802-3 / nCLEAR =0V
1802-2 / nWAIT =0V
2101-20 / RAM-R/W =5V
1802-21 / nEF4 =5V, goes to 0V with INPUT switch depressed
Confirm the DMAIN cycle is working:
1802-31 / nDMAIN =5V, pulses to 0V with each push of INPUT
switch (will be difficult to observe at high clock F)
2101-18 / nMREAD pulses to 0V with each push of INPUT switch
display-latch pulses active (whichever is active for your
display type) with each push of INPUT switch
Observing the one time pulses may be difficult depending on what type
of scope / test equipment you have, one option is to turn off auto-
trigger on the scope and set the trigger slope and level to trigger
on the desired pulse edge.
I'm suggesting all this from just looking at the schematic and 1802
datasheet, errors are possible and sanity checks will be a good idea.
On 2012 Mar 9, at 5:29 AM, Gergely L?rincz wrote:
Brent, I checked the 1802 (both of them) and they seem
to work
fine. When
the CLEAR and WAIT pin are set high or low accordingly, TPA and TPB
sends
timing pulses (checked with the scope), the status pins SC1 and SC0
show
the state of the processor (checked it against the truth table, works
fine). I think they work fine. If you have any ideas how to test
the 1802s
further, let me know!
Greg
On 8 March 2012 08:23, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
> On 2012 Mar 7, at 8:21 AM, Gergely L?rincz wrote:
>
> I finally had time to have a look at the schematics. I realised
> that this
>> schematics replaced the two 4050's with 4049s. Can you confirm
>> that it
>> works? Will purchase a couple of 4049 this week, wish I wasn't
>> under my
>> overdraft...
>>
>
> Inverting or non-inverting: it depends on other aspects of the
> implementation.
>
> Comparing with the schematic here:
> http://incolor.inetnebr.com/**bill_r/elf/html/elf-1-35.htm<http://
> incolor.inetnebr.com/bill_r/elf/html/elf-1-35.htm>
> http://incolor.inetnebr.com/**bill_r/elf/html/elf-1-36.htm<http://
> incolor.inetnebr.com/bill_r/elf/html/elf-1-36.htm>
> (There is an error on page 36: IC5 at the RUN switch is labelled
> as 4050
> (non-inverting and correct) but shown as an inverter.)
>
> If you are following the original design strictly it looks like there
> should be a 4049 and two 4050s.
>
> The implementation I happen to have uses three 4049s because:
> - simple LEDs are used for the display and so required inverters,
> - the display latch is inverted as it is a different latch type,
> - replaced the RUN-switch single-element non-inverting debounce
> circuit
> with a two-inverter circuit like the other debounce circuits.
>
> I mentioned my schematic because it shows things on one page and the
> control flow is clearer, I hope the implementation differences aren't
> confusing things too much.
>
> You mentioned checking a few things, but I don't think you
> actually told
> use what the problem symptoms are.
> Is the 1802 oscillator running?
> One suggestion would be to check that the levels at the mode
> inputs of the
> 1802 are correct for given switch settings.
>
12 Mar
12 Mar
12:07 a.m.
- assuming the power supply is correct and clean,
Checked.
- you did put pull-up resistors on the 1802 inputs such as nDMAOUT and
nINTR, didn't you?
Done.
- check the Examine mode.
The idea is each push of the INPUT switch should result in a presentation
of the memory contents.
Assuming the memory contents is somewhat random at this point, the
display should present random values.
That's one of the problems. Even if I push the input button, *Q* output of
the the flipflop (4013) doesn't change. Seems like the 4013 doesn't work
properly.
I'm suggesting all this from just looking at the
schematic and 1802
datasheet, errors are possible and sanity checks will be a good idea.
I checked both 1802s. They work fine. Also, the damn 4016s does not
anything let through. I tested them (for the third time) on a separate
breadboard and they work fine. When I place them back, they stop letting
anything through. When I set any of the output pins (bus wires), the
display changes accordingly (for instance setting pin 2 of the 4016 will
set the display's content to '2' from '0'). It seems to me that the
fault
must be somewhere in the input circuitry. Will remove the 4013 and test it.
On 2012 Mar 9, at 5:29 AM, Gergely L?rincz wrote:
Brent, I checked the 1802 (both of them) and they seem to work fine. When
the CLEAR and WAIT pin are set high or low
accordingly, TPA and TPB sends
timing pulses (checked with the scope), the status pins SC1 and SC0 show
the state of the processor (checked it against the truth table, works
fine). I think they work fine. If you have any ideas how to test the 1802s
further, let me know!
Greg
On 8 March 2012 08:23, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2012 Mar 7, at 8:21 AM, Gergely L?rincz wrote:
>
> I finally had time to have a look at the schematics. I realised that
> this
>
>> schematics replaced the two 4050's with 4049s. Can you confirm that it
>> works? Will purchase a couple of 4049 this week, wish I wasn't under my
>> overdraft...
>>
>>
> Inverting or non-inverting: it depends on other aspects of the
> implementation.
>
> Comparing with the schematic here:
>
http://incolor.inetnebr.com/****bill_r/elf/html/elf-1-35.htm<http://inco…
>
<h**ttp://incolor.inetnebr.com/**bill_r/elf/html/elf-1-35.htm<http://incolor.inetnebr.com/bill_r/elf/html/elf-1-35.htm>
> >
>
http://incolor.inetnebr.com/****bill_r/elf/html/elf-1-36.htm<http://inco…
>
<h**ttp://incolor.inetnebr.com/**bill_r/elf/html/elf-1-36.htm<http://incolor.inetnebr.com/bill_r/elf/html/elf-1-36.htm>
> >
>
> (There is an error on page 36: IC5 at the RUN switch is labelled as 4050
> (non-inverting and correct) but shown as an inverter.)
>
> If you are following the original design strictly it looks like there
> should be a 4049 and two 4050s.
>
> The implementation I happen to have uses three 4049s because:
> - simple LEDs are used for the display and so required inverters,
> - the display latch is inverted as it is a different latch type,
> - replaced the RUN-switch single-element non-inverting debounce circuit
> with a two-inverter circuit like the other debounce circuits.
>
> I mentioned my schematic because it shows things on one page and the
> control flow is clearer, I hope the implementation differences aren't
> confusing things too much.
>
> You mentioned checking a few things, but I don't think you actually told
> use what the problem symptoms are.
> Is the 1802 oscillator running?
> One suggestion would be to check that the levels at the mode inputs of
> the
> 1802 are correct for given switch settings.
>
>
9:17 a.m.
Created a diagram to log the faults: *http://tinyurl.com/6okrnnn*
*
*
The symptoms: the 4016's are not enabled by the control circuit (IC11 p2
<--> IC8/9 pin 5,6,12,13) and the displays' latch is often not enabled (IC4
pin15 --> IC6/7 pin5). Both are controlled by the NAND gate and the
flipflop (4023 and 4013). I guess I have to test the two thoroughly, both
the ICs and the wiring. Every other parts of the computer have been tested
and found working: 1802, buffer (inverting and non-inverting), the HP hex
displays, the power distribution, switches, bus, etc. I haven't tested the
RAMs yet but I have plenty of them and the bus works just fine. I also
measured the voltage and ground pins of each IC and they're fine. Would
love to see this thing working...
Greg
On 12 March 2012 04:07, Gergely L?rincz <alkopop79 at gmail.com> wrote:
- assuming the power supply is correct and
clean,
Checked.
- you did put pull-up resistors on the 1802 inputs such as nDMAOUT and
nINTR, didn't you?
Done.
- check the Examine mode.
The idea is each push of the INPUT switch should result in a
presentation of the memory contents.
Assuming the memory contents is somewhat random at this point, the
display should present random values.
That's one of the problems. Even if I push the input button, *Q* output
of the the flipflop (4013) doesn't change. Seems like the 4013 doesn't
work properly.
I'm suggesting all this from just looking at
the schematic and 1802
datasheet, errors are possible and sanity checks will be a good idea.
I checked both 1802s. They work fine. Also, the damn 4016s does not
anything let through. I tested them (for the third time) on a separate
breadboard and they work fine. When I place them back, they stop letting
anything through. When I set any of the output pins (bus wires), the
display changes accordingly (for instance setting pin 2 of the 4016 will
set the display's content to '2' from '0'). It seems to me that the
fault
must be somewhere in the input circuitry. Will remove the 4013 and test it.
On 2012 Mar 9, at 5:29 AM, Gergely L?rincz wrote:
Brent, I checked the 1802 (both of them) and they seem to work fine. When
the CLEAR and WAIT pin are set high or low
accordingly, TPA and TPB sends
timing pulses (checked with the scope), the status pins SC1 and SC0 show
the state of the processor (checked it against the truth table, works
fine). I think they work fine. If you have any ideas how to test the
1802s
further, let me know!
Greg
On 8 March 2012 08:23, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2012 Mar 7, at 8:21 AM, Gergely L?rincz wrote:
>
> I finally had time to have a look at the schematics. I realised that
> this
>
>> schematics replaced the two 4050's with 4049s. Can you confirm that it
>> works? Will purchase a couple of 4049 this week, wish I wasn't under my
>> overdraft...
>>
>>
> Inverting or non-inverting: it depends on other aspects of the
> implementation.
>
> Comparing with the schematic here:
>
http://incolor.inetnebr.com/****bill_r/elf/html/elf-1-35.htm<http://inco…
>
<h**ttp://incolor.inetnebr.com/**bill_r/elf/html/elf-1-35.htm<http://incolor.inetnebr.com/bill_r/elf/html/elf-1-35.htm>
> >
>
http://incolor.inetnebr.com/****bill_r/elf/html/elf-1-36.htm<http://inco…
>
<h**ttp://incolor.inetnebr.com/**bill_r/elf/html/elf-1-36.htm<http://incolor.inetnebr.com/bill_r/elf/html/elf-1-36.htm>
> >
>
> (There is an error on page 36: IC5 at the RUN switch is labelled as 4050
> (non-inverting and correct) but shown as an inverter.)
>
> If you are following the original design strictly it looks like there
> should be a 4049 and two 4050s.
>
> The implementation I happen to have uses three 4049s because:
> - simple LEDs are used for the display and so required inverters,
> - the display latch is inverted as it is a different latch type,
> - replaced the RUN-switch single-element non-inverting debounce circuit
> with a two-inverter circuit like the other debounce circuits.
>
> I mentioned my schematic because it shows things on one page and the
> control flow is clearer, I hope the implementation differences aren't
> confusing things too much.
>
> You mentioned checking a few things, but I don't think you actually told
> use what the problem symptoms are.
> Is the 1802 oscillator running?
> One suggestion would be to check that the levels at the mode inputs of
> the
> 1802 are correct for given switch settings.
>
>
3:14 p.m.
On 2012 Mar 11, at 9:07 PM, Gergely L?rincz wrote:
How about the input conditions for the 4013?
D/9 = 5V
C/11 = 5V, goes to 0V with push of INPUT switch
R/10 = 0V (pulses to 5V for uSecs via 1802 after release of INPUT
switch)
Keeping in mind the output (nQ) of the 4013 will only change (go to
0V) for a few microseconds.
- check the Examine mode.
The idea is each push of the INPUT switch should result in a
presentation
of the memory contents.
Assuming the memory contents is somewhat random at this point, the
display should present random values.
That's one of the problems. Even if I push the input button, *Q*
output of
the the flipflop (4013) doesn't change. Seems like the 4013
doesn't work
properly.
14 Mar
14 Mar
11:17 p.m.
15 Mar
15 Mar
12:06 p.m.
On Wed, Mar 14, 2012 at 11:17 PM, Gergely L?rincz <alkopop79 at gmail.com> wrote:
This bit helped a lot to understand what's going
on. Took out the 4013 and
tested it on a separate breadboard, worked fine. Put it back and still
cannot see anything on pin 12 (*Q*). Tested all the conditions over and
over and seems that SC1 does not change after the input button is pressed.
On the other hand, if I set the DMA IN pin low, SC1 goes high. Created a
somewhat amateurish
diagram<https://picasaweb.google.com/lh/photo/r9_0Sc3OKIxotL1IU5hk3dMTjN…nk>,
green means tested and working, red means doesn't work. I wonder what N2
does. It never seem to change from low state. Thank you for your help in
advance!
N2 is one of the "N lines" - they are used to select the correct
device for the 6X IN/OUT instructions.
One of the neat things about the Elf design is that most of the I/O
serves two purposes depending on what the processor is up to. If you
are in "LOAD" mode, the input button triggers /DMA_IN pulses that gate
in the state of the switches, and the TIL311s latch memory bus data.
In "RUN" mode, the toggle switches can be read with an INP 4
instruction and the displays can be written to with OUT 4, and the
input button can be sensed on /EF4 with a branch/skip instruction
Could you be having a problem with your RUN/LOAD switches so that the
processor is _not_ in LOAD state when you think it is?
-ethan
12:22 p.m.
*Could you be having a problem with your RUN/LOAD switches so that the
processor is _not_ in LOAD state when you think it is?*
Actually, I checked them millions of time by probing the WAIT and CLEAR
(pins 2&3 of 1802). In load mode, both of them are low, in run mode they're
high and TPA%TPB send timing pulses. Also, the SC0 pin goes high/low as you
flip the load and run switches. I cannot think of any other means of
testing the run and load switches but they seem to work and the 1802
behaves accordingly. However, the 4013 still doesn't work properly. I have
trouble understanding how it works. It seems to me that when the input
button is pressed (or released), the Q_ should send a pulse to DMA IN then
the SC1 should change its state (since DMA IN's state changed) and send a
short pulse back to 4013. In other words, once the Q- output sends a pulse
to DMA IN and SC1 sends a pulse in return, which resets the flipflop. Am I
right? At the moment SC1 doesn't do a damn thing (since DMA IN doesn't get
a pulse). Any ideas? I'm beginning to grow a beard, chain smoke and eat
cold leftover from the fridge. Wife's worried and complains. Any help would
be appreciated!
Greg
On 15 March 2012 16:06, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On Wed, Mar 14, 2012 at 11:17 PM, Gergely L?rincz
<alkopop79 at gmail.com>
wrote:
This bit helped a lot to understand what's
going on. Took out the 4013
and
tested it on a separate breadboard, worked fine.
Put it back and still
cannot see anything on pin 12 (*Q*). Tested all the conditions over and
over and seems that SC1 does not change after the input button is
pressed.
On the other hand, if I set the DMA IN pin low,
SC1 goes high. Created a
somewhat amateurish
diagram<
https://picasaweb.google.com/lh/photo/r9_0Sc3OKIxotL1IU5hk3dMTjNZETYmyPJy0l…
,
green means tested and working, red means doesn't work. I wonder what N2
does. It never seem to change from low state. Thank you for your help in
advance!
N2 is one of the "N lines" - they are used to select the correct
device for the 6X IN/OUT instructions.
One of the neat things about the Elf design is that most of the I/O
serves two purposes depending on what the processor is up to. If you
are in "LOAD" mode, the input button triggers /DMA_IN pulses that gate
in the state of the switches, and the TIL311s latch memory bus data.
In "RUN" mode, the toggle switches can be read with an INP 4
instruction and the displays can be written to with OUT 4, and the
input button can be sensed on /EF4 with a branch/skip instruction
Could you be having a problem with your RUN/LOAD switches so that the
processor is _not_ in LOAD state when you think it is?
-ethan
5:04 p.m.
On 2012 Mar 15, at 9:22 AM, Gergely L?rincz wrote:
*Could you be having a problem with your RUN/LOAD
switches so that the
processor is _not_ in LOAD state when you think it is?*
Actually, I checked them millions of time by probing the WAIT and
CLEAR
(pins 2&3 of 1802). In load mode, both of them are low, in run mode
they're
high and TPA%TPB send timing pulses. Also, the SC0 pin goes high/
low as you
flip the load and run switches. I cannot think of any other means of
testing the run and load switches but they seem to work and the 1802
behaves accordingly. However, the 4013 still doesn't work properly.
I have
trouble understanding how it works. It seems to me that when the input
button is pressed (or released), the Q_ should send a pulse to DMA
IN then
the SC1 should change its state (since DMA IN's state changed) and
send a
short pulse back to 4013. In other words, once the Q- output sends
a pulse
to DMA IN and SC1 sends a pulse in return, which resets the
flipflop. Am I
right? At the moment SC1 doesn't do a damn thing (since DMA IN
doesn't get
a pulse). Any ideas? I'm beginning to grow a beard, chain smoke and
eat
cold leftover from the fridge. Wife's worried and complains. Any
help would
be appreciated!
Yes, that's the idea:
- The release of the INPUT switch results in a +edge on the 4013
clock (11)
- The +edge sends the nQ output (12) low and hence nDMAIN low
- the 1802 enters DMA state, sending SC1 high
- SC1 high resets the 4013 through the diode OR gate, sending nQ &
nDMAIN back high
- the 1802 exits DMA state, sending SC1 back low, completing the DMA/
load/examine cycle
nQ & nDMAIN will only be low for a microsec or two, SC1 will only be
high for a microsec or two.
Debugging trial: remove the connection from SC1 to the diode at the
4013 reset (10).
Now, when the input switch is released, nQ & nDMAIN should go low and
STAY low as there is nothing to reset the 4013 (until you flip the
load mode switch).
It follows SC1 should go high and stay high or repeatedly pulse high
as the 1802 is being held in the DMA state (which I think you already
tested by forcing nDMAIN low).
8:51 p.m.
All of these test are done. Conclusion: if I remove the wire to SC1 and
reset the 4013, it works fine, just as you described. In fact, I spent a
few hours sending pulses from an Arduino (microsecond ones) to simulate
SC1. I even managed to see the pulse from *Q* on the oscilloscope. But once
the wire between the 4013 and the SC1 pin is used, nothing works. I even
tried two different 1802s and they work fine (when the DMA IN pin is set
low, SC1 instantly goes high). The only possible reason I can think of
(since both the 1802 and 4013 works perfectly) is that one of the diodes
are either broken or placed the wrong way around. An other thing is that I
use a SPST button (input) instead of the SPDT. It still works (for some
weird reason no SPDT buttons are rare and expensive in the UK). I'll check
this tomorrow. The other mystery is that why the 4023 never sets the HP
displays to enable mode. The displays are stuck (latched) and even though
they work perfectly, the NAND gate (4023) never sets the enable pins low. I
wonder if that has to anything with the previous problem? Anyway, at least
I know where the problem is, even though I don't know what it is. It's
certainly a good start! Thanks for all of your effort and indispensable
help!
Greg
Debugging trial: remove the connection from SC1 to the diode at the 4013
reset (10).
Now, when the input switch is released, nQ & nDMAIN should go low and STAY
low as there is nothing to reset the 4013 (until you flip the load mode
switch).
It follows SC1 should go high and stay high or repeatedly pulse high as
the 1802 is being held in the DMA state (which I think you already tested
by forcing nDMAIN low).
16 Mar
16 Mar
2:15 p.m.
Problem (partially) solved: the LOAD switch stops the fliflop letting
anything pass through until it's set on ( RESET mode). As if someone
mentioned it that particular bit is wrong on the schematics. I assume i
just have to rewire the thing.
On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com> wrote:
All of these test are done. Conclusion: if I remove
the wire to SC1 and
reset the 4013, it works fine, just as you described. In fact, I spent a
few hours sending pulses from an Arduino (microsecond ones) to simulate
SC1. I even managed to see the pulse from *Q* on the oscilloscope. But
once the wire between the 4013 and the SC1 pin is used, nothing works. I
even tried two different 1802s and they work fine (when the DMA IN pin is
set low, SC1 instantly goes high). The only possible reason I can think of
(since both the 1802 and 4013 works perfectly) is that one of the diodes
are either broken or placed the wrong way around. An other thing is that I
use a SPST button (input) instead of the SPDT. It still works (for some
weird reason no SPDT buttons are rare and expensive in the UK). I'll check
this tomorrow. The other mystery is that why the 4023 never sets the HP
displays to enable mode. The displays are stuck (latched) and even though
they work perfectly, the NAND gate (4023) never sets the enable pins low. I
wonder if that has to anything with the previous problem? Anyway, at least
I know where the problem is, even though I don't know what it is. It's
certainly a good start! Thanks for all of your effort and indispensable
help!
Greg
Debugging trial: remove the connection from SC1 to the diode at the 4013
reset (10).
Now, when the input switch is released, nQ & nDMAIN should go low and
STAY low as there is nothing to reset the 4013 (until you flip the load
mode switch).
It follows SC1 should go high and stay high or repeatedly pulse high as
the 1802 is being held in the DMA state (which I think you already tested
by forcing nDMAIN low).
17 Mar
17 Mar
11:48 a.m.
Getting there: finally I can see the hex result on the display after I
press the input button. Seems to me that the control circuit work fine.
However I tried to test the machine by entering 7b (SEQ) and pressed INPUT
and set to RUN mode, expecting the Q output change it's state. It didn't
happen:( The 1802the input and output section and the whole control circuit
seem to work fine so I checked the RAMs. It seems that the read/write
enable and output disable pins (18 and 20) show different logic state in
the two memory ICs. I assume this stops the instruction to be entered to
the memory. Can you guys tell me what should be the state of pins 18 and 20
(output disable and write enable) in run and load mode and when pressing
the input button? The datasheet doesn't have much info on this.
On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Problem (partially) solved: the LOAD switch stops the
fliflop letting
anything pass through until it's set on ( RESET mode). As if someone
mentioned it that particular bit is wrong on the schematics. I assume i
just have to rewire the thing.
On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com> wrote:
> All of these test are done. Conclusion: if I remove the wire to SC1 and
> reset the 4013, it works fine, just as you described. In fact, I spent a
> few hours sending pulses from an Arduino (microsecond ones) to simulate
> SC1. I even managed to see the pulse from *Q* on the oscilloscope. But
> once the wire between the 4013 and the SC1 pin is used, nothing works. I
> even tried two different 1802s and they work fine (when the DMA IN pin is
> set low, SC1 instantly goes high). The only possible reason I can think of
> (since both the 1802 and 4013 works perfectly) is that one of the diodes
> are either broken or placed the wrong way around. An other thing is that I
> use a SPST button (input) instead of the SPDT. It still works (for some
> weird reason no SPDT buttons are rare and expensive in the UK). I'll check
> this tomorrow. The other mystery is that why the 4023 never sets the HP
> displays to enable mode. The displays are stuck (latched) and even though
> they work perfectly, the NAND gate (4023) never sets the enable pins low. I
> wonder if that has to anything with the previous problem? Anyway, at least
> I know where the problem is, even though I don't know what it is. It's
> certainly a good start! Thanks for all of your effort and indispensable
> help!
>
> Greg
>
>
>
>>
>> Debugging trial: remove the connection from SC1 to the diode at the 4013
>> reset (10).
>> Now, when the input switch is released, nQ & nDMAIN should go low and
>> STAY low as there is nothing to reset the 4013 (until you flip the load
>> mode switch).
>> It follows SC1 should go high and stay high or repeatedly pulse high as
>> the 1802 is being held in the DMA state (which I think you already tested
>> by forcing nDMAIN low).
>>
>>
>>
>>
>>
>
8:38 p.m.
Idle state for RAM-R/W (20) should HIGH (read).
I expect idle state for RAM-OD (18) is also HIGH (RAM outputs disabled).
I would suggest before trying to run a program you confirm that you
are able to load and examine memory.
One of the subtle points here is that when loading/examining/running
you generally need to go 'through' the RESET state with the mode
switches to reset the internal address pointer to zero.
Here's a load/examine test sequence:
Load:
L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
L3 - set mode for PROGRAM (flip *LOAD up)
L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10 into
mem-0)
L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11 into
mem-1)
L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12 into
mem-2)
Examine:
E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
E3 - set mode for PROGRAM (flip *LOAD up)
E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
If you miss step L1, you won't know where you are actually loading
into memory. If you miss step E1, the examine steps (E4,E5,E6) will
display addresses 3,4,5 rather than displaying addresses 0,1,2. The
same issue applies when running a program, you normally have to reset
state with the mode switches so the program starts running at 0.
I don't like the switch labels of the original Elf, they can be
misleading, but that's history. I relabelled/disambiguated them in my
schematic and unit, the * labels above are the original switch
labels, others are mine.
On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
Getting there: finally I can see the hex result on the
display after I
press the input button. Seems to me that the control circuit work
fine.
However I tried to test the machine by entering 7b (SEQ) and
pressed INPUT
and set to RUN mode, expecting the Q output change it's state. It
didn't
happen:( The 1802the input and output section and the whole control
circuit
seem to work fine so I checked the RAMs. It seems that the read/write
enable and output disable pins (18 and 20) show different logic
state in
the two memory ICs. I assume this stops the instruction to be
entered to
the memory. Can you guys tell me what should be the state of pins
18 and 20
(output disable and write enable) in run and load mode and when
pressing
the input button? The datasheet doesn't have much info on this.
On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com> wrote:
> Problem (partially) solved: the LOAD switch stops the fliflop letting
> anything pass through until it's set on ( RESET mode). As if someone
> mentioned it that particular bit is wrong on the schematics. I
> assume i
> just have to rewire the thing.
>
> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com>
wrote:
>
>> All of these test are done. Conclusion: if I remove the wire to
>> SC1 and
>> reset the 4013, it works fine, just as you described. In fact, I
>> spent a
>> few hours sending pulses from an Arduino (microsecond ones) to
>> simulate
>> SC1. I even managed to see the pulse from *Q* on the
>> oscilloscope. But
>> once the wire between the 4013 and the SC1 pin is used, nothing
>> works. I
>> even tried two different 1802s and they work fine (when the DMA
>> IN pin is
>> set low, SC1 instantly goes high). The only possible reason I can
>> think of
>> (since both the 1802 and 4013 works perfectly) is that one of the
>> diodes
>> are either broken or placed the wrong way around. An other thing
>> is that I
>> use a SPST button (input) instead of the SPDT. It still works
>> (for some
>> weird reason no SPDT buttons are rare and expensive in the UK).
>> I'll check
>> this tomorrow. The other mystery is that why the 4023 never sets
>> the HP
>> displays to enable mode. The displays are stuck (latched) and
>> even though
>> they work perfectly, the NAND gate (4023) never sets the enable
>> pins low. I
>> wonder if that has to anything with the previous problem? Anyway,
>> at least
>> I know where the problem is, even though I don't know what it is.
>> It's
>> certainly a good start! Thanks for all of your effort and
>> indispensable
>> help!
>>
>> Greg
>>
>>
>>
>>>
>>> Debugging trial: remove the connection from SC1 to the diode at
>>> the 4013
>>> reset (10).
>>> Now, when the input switch is released, nQ & nDMAIN should go
>>> low and
>>> STAY low as there is nothing to reset the 4013 (until you flip
>>> the load
>>> mode switch).
>>> It follows SC1 should go high and stay high or repeatedly pulse
>>> high as
>>> the 1802 is being held in the DMA state (which I think you
>>> already tested
>>> by forcing nDMAIN low).
>>>
>>>
>>>
>>>
>>>
>>
18 Mar
18 Mar
6:19 a.m.
Yepp, it took me a goog few weeks to realise that the LOAD mode of the 1802
is in fact the reset mode, an the Cosmac Elf's LOAD mode is the DMA IN mode
of the microprocessor. I wish I knew that! Thank you for your kind help,
Brent!
Greg
On 18 March 2012 00:38, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Idle state for RAM-R/W (20) should HIGH (read).
I expect idle state for RAM-OD (18) is also HIGH (RAM outputs disabled).
I would suggest before trying to run a program you confirm that you are
able to load and examine memory.
One of the subtle points here is that when loading/examining/running you
generally need to go 'through' the RESET state with the mode switches to
reset the internal address pointer to zero.
Here's a load/examine test sequence:
Load:
L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
L3 - set mode for PROGRAM (flip *LOAD up)
L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10 into
mem-0)
L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11 into
mem-1)
L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12 into
mem-2)
Examine:
E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
E3 - set mode for PROGRAM (flip *LOAD up)
E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
If you miss step L1, you won't know where you are actually loading into
memory. If you miss step E1, the examine steps (E4,E5,E6) will display
addresses 3,4,5 rather than displaying addresses 0,1,2. The same issue
applies when running a program, you normally have to reset state with the
mode switches so the program starts running at 0.
I don't like the switch labels of the original Elf, they can be
misleading, but that's history. I relabelled/disambiguated them in my
schematic and unit, the * labels above are the original switch labels,
others are mine.
On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
Getting there: finally I can see the hex result on the display after I
press the input button. Seems to me that the
control circuit work fine.
However I tried to test the machine by entering 7b (SEQ) and pressed INPUT
and set to RUN mode, expecting the Q output change it's state. It didn't
happen:( The 1802the input and output section and the whole control
circuit
seem to work fine so I checked the RAMs. It seems that the read/write
enable and output disable pins (18 and 20) show different logic state in
the two memory ICs. I assume this stops the instruction to be entered to
the memory. Can you guys tell me what should be the state of pins 18 and
20
(output disable and write enable) in run and load mode and when pressing
the input button? The datasheet doesn't have much info on this.
On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Problem (partially) solved: the LOAD switch stops the fliflop letting
> anything pass through until it's set on ( RESET mode). As if someone
> mentioned it that particular bit is wrong on the schematics. I assume i
> just have to rewire the thing.
>
> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com>
wrote:
>
> All of these test are done. Conclusion: if I remove the wire to SC1 and
>> reset the 4013, it works fine, just as you described. In fact, I spent a
>> few hours sending pulses from an Arduino (microsecond ones) to simulate
>> SC1. I even managed to see the pulse from *Q* on the oscilloscope. But
>>
>> once the wire between the 4013 and the SC1 pin is used, nothing works. I
>> even tried two different 1802s and they work fine (when the DMA IN pin
>> is
>> set low, SC1 instantly goes high). The only possible reason I can think
>> of
>> (since both the 1802 and 4013 works perfectly) is that one of the diodes
>> are either broken or placed the wrong way around. An other thing is
>> that I
>> use a SPST button (input) instead of the SPDT. It still works (for some
>> weird reason no SPDT buttons are rare and expensive in the UK). I'll
>> check
>> this tomorrow. The other mystery is that why the 4023 never sets the HP
>> displays to enable mode. The displays are stuck (latched) and even
>> though
>> they work perfectly, the NAND gate (4023) never sets the enable pins
>> low. I
>> wonder if that has to anything with the previous problem? Anyway, at
>> least
>> I know where the problem is, even though I don't know what it is. It's
>> certainly a good start! Thanks for all of your effort and indispensable
>> help!
>>
>> Greg
>>
>>
>>
>>
>>> Debugging trial: remove the connection from SC1 to the diode at the
>>> 4013
>>> reset (10).
>>> Now, when the input switch is released, nQ & nDMAIN should go low and
>>> STAY low as there is nothing to reset the 4013 (until you flip the load
>>> mode switch).
>>> It follows SC1 should go high and stay high or repeatedly pulse high as
>>> the 1802 is being held in the DMA state (which I think you already
>>> tested
>>> by forcing nDMAIN low).
>>>
>>>
>>>
>>>
>>>
>>>
>>
3:57 p.m.
Gergely L?rincz wrote:
it took me a goog few weeks to realise that the LOAD
mode of the 1802
is in fact the reset mode, an the Cosmac Elf's LOAD mode is the DMA IN mode
of the microprocessor. I wish I knew that!
Not so fast. LOAD mode and RESET are two different things, and the LOAD
mode of the 1802 is NOT the same as RESET. LOAD mode is entered by
asserting WAIT (driving it low) during RESET, but just being in RESET is
not by itself LOAD mode. This is true whether it's an ELf or some other
1802 system.
In LOAD mode, whether an 1802 or otherwise, you are not in "DMA IN"
mode; there isn't even such a "mode". you have to be in actual LOAD
mode, as defined by the CLEAR and WAIT inputs both being low, then pulse
the DMA IN signal (pin 38) to strobe each byte.
If you try to just use DMA IN mode for loading, without being in LOAD
mode, you'll have problems.
From the datasheet (DIP pin numbers):
pin 3 pin 2
CLEAR WAIT Mode
----- ----- ----
low low LOAD
low high RESET
high low PAUSE
high high RUN
CLEAR, WAIT, and DMA IN are active low, shown with an overbar in the
datasheet. The "low" and "high" levels refer to the actual voltages,
low being near Vss (ground), and high being near Vdd (positive supply).
22 Mar
22 Mar
11:20 a.m.
The display only updates after the input button is pressed if in RESET mode
(RUN down, LOAD down). If RUN down, LOAD up, can't see the display
changing.
On 18 March 2012 00:38, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Idle state for RAM-R/W (20) should HIGH (read).
I expect idle state for RAM-OD (18) is also HIGH (RAM outputs disabled).
I would suggest before trying to run a program you confirm that you are
able to load and examine memory.
One of the subtle points here is that when loading/examining/running you
generally need to go 'through' the RESET state with the mode switches to
reset the internal address pointer to zero.
Here's a load/examine test sequence:
Load:
L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
L3 - set mode for PROGRAM (flip *LOAD up)
L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10 into
mem-0)
L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11 into
mem-1)
L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12 into
mem-2)
Examine:
E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
E3 - set mode for PROGRAM (flip *LOAD up)
E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
If you miss step L1, you won't know where you are actually loading into
memory. If you miss step E1, the examine steps (E4,E5,E6) will display
addresses 3,4,5 rather than displaying addresses 0,1,2. The same issue
applies when running a program, you normally have to reset state with the
mode switches so the program starts running at 0.
I don't like the switch labels of the original Elf, they can be
misleading, but that's history. I relabelled/disambiguated them in my
schematic and unit, the * labels above are the original switch labels,
others are mine.
On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
Getting there: finally I can see the hex result on the display after I
press the input button. Seems to me that the
control circuit work fine.
However I tried to test the machine by entering 7b (SEQ) and pressed INPUT
and set to RUN mode, expecting the Q output change it's state. It didn't
happen:( The 1802the input and output section and the whole control
circuit
seem to work fine so I checked the RAMs. It seems that the read/write
enable and output disable pins (18 and 20) show different logic state in
the two memory ICs. I assume this stops the instruction to be entered to
the memory. Can you guys tell me what should be the state of pins 18 and
20
(output disable and write enable) in run and load mode and when pressing
the input button? The datasheet doesn't have much info on this.
On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Problem (partially) solved: the LOAD switch stops the fliflop letting
> anything pass through until it's set on ( RESET mode). As if someone
> mentioned it that particular bit is wrong on the schematics. I assume i
> just have to rewire the thing.
>
> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com>
wrote:
>
> All of these test are done. Conclusion: if I remove the wire to SC1 and
>> reset the 4013, it works fine, just as you described. In fact, I spent a
>> few hours sending pulses from an Arduino (microsecond ones) to simulate
>> SC1. I even managed to see the pulse from *Q* on the oscilloscope. But
>>
>> once the wire between the 4013 and the SC1 pin is used, nothing works. I
>> even tried two different 1802s and they work fine (when the DMA IN pin
>> is
>> set low, SC1 instantly goes high). The only possible reason I can think
>> of
>> (since both the 1802 and 4013 works perfectly) is that one of the diodes
>> are either broken or placed the wrong way around. An other thing is
>> that I
>> use a SPST button (input) instead of the SPDT. It still works (for some
>> weird reason no SPDT buttons are rare and expensive in the UK). I'll
>> check
>> this tomorrow. The other mystery is that why the 4023 never sets the HP
>> displays to enable mode. The displays are stuck (latched) and even
>> though
>> they work perfectly, the NAND gate (4023) never sets the enable pins
>> low. I
>> wonder if that has to anything with the previous problem? Anyway, at
>> least
>> I know where the problem is, even though I don't know what it is. It's
>> certainly a good start! Thanks for all of your effort and indispensable
>> help!
>>
>> Greg
>>
>>
>>
>>
>>> Debugging trial: remove the connection from SC1 to the diode at the
>>> 4013
>>> reset (10).
>>> Now, when the input switch is released, nQ & nDMAIN should go low and
>>> STAY low as there is nothing to reset the 4013 (until you flip the load
>>> mode switch).
>>> It follows SC1 should go high and stay high or repeatedly pulse high as
>>> the 1802 is being held in the DMA state (which I think you already
>>> tested
>>> by forcing nDMAIN low).
>>>
>>>
>>>
>>>
>>>
>>>
>>
4:57 p.m.
Again, as opposed to what I expected the display changes only if in RESET
mode (both run and load low). When in LOAD mode (LOAD up, RUN down) nothing
seems to happen before/after flipping data switches and pushing the input
button. Isn't it supposed to be the other way?
On 22 March 2012 15:20, Gergely L?rincz <alkopop79 at gmail.com> wrote:
The display only updates after the input button is
pressed if in RESET
mode (RUN down, LOAD down). If RUN down, LOAD up, can't see the display
changing.
On 18 March 2012 00:38, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Idle state for RAM-R/W (20) should HIGH (read).
I expect idle state for RAM-OD (18) is also HIGH (RAM outputs disabled).
I would suggest before trying to run a program you confirm that you are
able to load and examine memory.
One of the subtle points here is that when loading/examining/running you
generally need to go 'through' the RESET state with the mode switches to
reset the internal address pointer to zero.
Here's a load/examine test sequence:
Load:
L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
L3 - set mode for PROGRAM (flip *LOAD up)
L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10 into
mem-0)
L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11 into
mem-1)
L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12 into
mem-2)
Examine:
E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
address pointer=0)
E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
E3 - set mode for PROGRAM (flip *LOAD up)
E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
If you miss step L1, you won't know where you are actually loading into
memory. If you miss step E1, the examine steps (E4,E5,E6) will display
addresses 3,4,5 rather than displaying addresses 0,1,2. The same issue
applies when running a program, you normally have to reset state with the
mode switches so the program starts running at 0.
I don't like the switch labels of the original Elf, they can be
misleading, but that's history. I relabelled/disambiguated them in my
schematic and unit, the * labels above are the original switch labels,
others are mine.
On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
Getting there: finally I can see the hex result on the display after I
press the input button. Seems to me that the
control circuit work fine.
However I tried to test the machine by entering 7b (SEQ) and pressed
INPUT
and set to RUN mode, expecting the Q output change it's state. It didn't
happen:( The 1802the input and output section and the whole control
circuit
seem to work fine so I checked the RAMs. It seems that the read/write
enable and output disable pins (18 and 20) show different logic state in
the two memory ICs. I assume this stops the instruction to be entered to
the memory. Can you guys tell me what should be the state of pins 18 and
20
(output disable and write enable) in run and load mode and when pressing
the input button? The datasheet doesn't have much info on this.
On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com> wrote:
Problem (partially) solved: the LOAD switch stops the fliflop letting
> anything pass through until it's set on ( RESET mode). As if someone
> mentioned it that particular bit is wrong on the schematics. I assume i
> just have to rewire the thing.
>
> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at gmail.com>
wrote:
>
> All of these test are done. Conclusion: if I remove the wire to SC1 and
>> reset the 4013, it works fine, just as you described. In fact, I spent
>> a
>> few hours sending pulses from an Arduino (microsecond ones) to simulate
>> SC1. I even managed to see the pulse from *Q* on the oscilloscope. But
>>
>> once the wire between the 4013 and the SC1 pin is used, nothing works.
>> I
>> even tried two different 1802s and they work fine (when the DMA IN pin
>> is
>> set low, SC1 instantly goes high). The only possible reason I can
>> think of
>> (since both the 1802 and 4013 works perfectly) is that one of the
>> diodes
>> are either broken or placed the wrong way around. An other thing is
>> that I
>> use a SPST button (input) instead of the SPDT. It still works (for some
>> weird reason no SPDT buttons are rare and expensive in the UK). I'll
>> check
>> this tomorrow. The other mystery is that why the 4023 never sets the HP
>> displays to enable mode. The displays are stuck (latched) and even
>> though
>> they work perfectly, the NAND gate (4023) never sets the enable pins
>> low. I
>> wonder if that has to anything with the previous problem? Anyway, at
>> least
>> I know where the problem is, even though I don't know what it is. It's
>> certainly a good start! Thanks for all of your effort and indispensable
>> help!
>>
>> Greg
>>
>>
>>
>>
>>> Debugging trial: remove the connection from SC1 to the diode at the
>>> 4013
>>> reset (10).
>>> Now, when the input switch is released, nQ & nDMAIN should go low and
>>> STAY low as there is nothing to reset the 4013 (until you flip the
>>> load
>>> mode switch).
>>> It follows SC1 should go high and stay high or repeatedly pulse high
>>> as
>>> the 1802 is being held in the DMA state (which I think you already
>>> tested
>>> by forcing nDMAIN low).
>>>
>>>
>>>
>>>
>>>
>>>
>>
23 Mar
23 Mar
5:25 a.m.
Sounds like one of the switches is wired (or positioned if one
prefers) the 'wrong way round'. Doublecheck the switch positions
against the measured state on the mode pins:
MODE RUN LOAD nCLEAR nWAIT
switch switch pin 3 pin 2
----- --------------------------------
RESET down down 0 +V
PROGRAM down up 0 0
RUN up down +V +V
PAUSE up up +V 0
The design is not the way one might expect it to be (RESET is not 0 &
0 at the 1802).
On 2012 Mar 22, at 1:57 PM, Gergely L?rincz wrote:
Again, as opposed to what I expected the display
changes only if in
RESET
mode (both run and load low). When in LOAD mode (LOAD up, RUN down)
nothing
seems to happen before/after flipping data switches and pushing the
input
button. Isn't it supposed to be the other way?
On 22 March 2012 15:20, Gergely L?rincz <alkopop79 at gmail.com> wrote:
> The display only updates after the input button is pressed if in
> RESET
> mode (RUN down, LOAD down). If RUN down, LOAD up, can't see the
> display
> changing.
>
> On 18 March 2012 00:38, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>
>> Idle state for RAM-R/W (20) should HIGH (read).
>> I expect idle state for RAM-OD (18) is also HIGH (RAM outputs
>> disabled).
>>
>> I would suggest before trying to run a program you confirm that
>> you are
>> able to load and examine memory.
>>
>> One of the subtle points here is that when loading/examining/
>> running you
>> generally need to go 'through' the RESET state with the mode
>> switches to
>> reset the internal address pointer to zero.
>>
>> Here's a load/examine test sequence:
>>
>> Load:
>> L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
>> address pointer=0)
>> L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
>> L3 - set mode for PROGRAM (flip *LOAD up)
>> L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10
>> into
>> mem-0)
>> L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11
>> into
>> mem-1)
>> L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12
>> into
>> mem-2)
>>
>> Examine:
>> E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
>> address pointer=0)
>> E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
>> E3 - set mode for PROGRAM (flip *LOAD up)
>> E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
>> E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
>> E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
>>
>> If you miss step L1, you won't know where you are actually
>> loading into
>> memory. If you miss step E1, the examine steps (E4,E5,E6) will
>> display
>> addresses 3,4,5 rather than displaying addresses 0,1,2. The same
>> issue
>> applies when running a program, you normally have to reset state
>> with the
>> mode switches so the program starts running at 0.
>>
>> I don't like the switch labels of the original Elf, they can be
>> misleading, but that's history. I relabelled/disambiguated them
>> in my
>> schematic and unit, the * labels above are the original switch
>> labels,
>> others are mine.
>>
>>
>>
>> On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
>>
>> Getting there: finally I can see the hex result on the display
>> after I
>>> press the input button. Seems to me that the control circuit
>>> work fine.
>>> However I tried to test the machine by entering 7b (SEQ) and
>>> pressed
>>> INPUT
>>> and set to RUN mode, expecting the Q output change it's state.
>>> It didn't
>>> happen:( The 1802the input and output section and the whole control
>>> circuit
>>> seem to work fine so I checked the RAMs. It seems that the read/
>>> write
>>> enable and output disable pins (18 and 20) show different logic
>>> state in
>>> the two memory ICs. I assume this stops the instruction to be
>>> entered to
>>> the memory. Can you guys tell me what should be the state of
>>> pins 18 and
>>> 20
>>> (output disable and write enable) in run and load mode and when
>>> pressing
>>> the input button? The datasheet doesn't have much info on this.
>>>
>>>
>>> On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com>
>>> wrote:
>>>
>>> Problem (partially) solved: the LOAD switch stops the fliflop
>>> letting
>>>> anything pass through until it's set on ( RESET mode). As if
>>>> someone
>>>> mentioned it that particular bit is wrong on the schematics. I
>>>> assume i
>>>> just have to rewire the thing.
>>>>
>>>> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at
gmail.com>
>>>> wrote:
>>>>
>>>> All of these test are done. Conclusion: if I remove the wire
>>>> to SC1 and
>>>>> reset the 4013, it works fine, just as you described. In fact,
>>>>> I spent
>>>>> a
>>>>> few hours sending pulses from an Arduino (microsecond ones) to
>>>>> simulate
>>>>> SC1. I even managed to see the pulse from *Q* on the
>>>>> oscilloscope. But
>>>>>
>>>>> once the wire between the 4013 and the SC1 pin is used,
>>>>> nothing works.
>>>>> I
>>>>> even tried two different 1802s and they work fine (when the
>>>>> DMA IN pin
>>>>> is
>>>>> set low, SC1 instantly goes high). The only possible reason I can
>>>>> think of
>>>>> (since both the 1802 and 4013 works perfectly) is that one of the
>>>>> diodes
>>>>> are either broken or placed the wrong way around. An other
>>>>> thing is
>>>>> that I
>>>>> use a SPST button (input) instead of the SPDT. It still works
>>>>> (for some
>>>>> weird reason no SPDT buttons are rare and expensive in the
>>>>> UK). I'll
>>>>> check
>>>>> this tomorrow. The other mystery is that why the 4023 never
>>>>> sets the HP
>>>>> displays to enable mode. The displays are stuck (latched) and
>>>>> even
>>>>> though
>>>>> they work perfectly, the NAND gate (4023) never sets the
>>>>> enable pins
>>>>> low. I
>>>>> wonder if that has to anything with the previous problem?
>>>>> Anyway, at
>>>>> least
>>>>> I know where the problem is, even though I don't know what it
>>>>> is. It's
>>>>> certainly a good start! Thanks for all of your effort and
>>>>> indispensable
>>>>> help!
>>>>>
>>>>> Greg
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Debugging trial: remove the connection from SC1 to the diode
>>>>>> at the
>>>>>> 4013
>>>>>> reset (10).
>>>>>> Now, when the input switch is released, nQ & nDMAIN should go
>>>>>> low and
>>>>>> STAY low as there is nothing to reset the 4013 (until you
>>>>>> flip the
>>>>>> load
>>>>>> mode switch).
>>>>>> It follows SC1 should go high and stay high or repeatedly
>>>>>> pulse high
>>>>>> as
>>>>>> the 1802 is being held in the DMA state (which I think you
>>>>>> already
>>>>>> tested
>>>>>> by forcing nDMAIN low).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>
10:21 a.m.
Thought so... thanks for all the help!
On 23 March 2012 09:25, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Sounds like one of the switches is wired (or
positioned if one prefers)
the 'wrong way round'. Doublecheck the switch positions against the
measured state on the mode pins:
MODE RUN LOAD nCLEAR nWAIT
switch switch pin 3 pin 2
----- ------------------------------**--
RESET down down 0 +V
PROGRAM down up 0 0
RUN up down +V +V
PAUSE up up +V 0
The design is not the way one might expect it to be (RESET is not 0 & 0 at
the 1802).
On 2012 Mar 22, at 1:57 PM, Gergely L?rincz wrote:
Again, as opposed to what I expected the display changes only if in RESET
mode (both run and load low). When in LOAD mode
(LOAD up, RUN down)
nothing
seems to happen before/after flipping data switches and pushing the input
button. Isn't it supposed to be the other way?
On 22 March 2012 15:20, Gergely L?rincz <alkopop79 at gmail.com> wrote:
The display only updates after the input button is pressed if in RESET
> mode (RUN down, LOAD down). If RUN down, LOAD up, can't see the display
> changing.
>
> On 18 March 2012 00:38, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>
> Idle state for RAM-R/W (20) should HIGH (read).
>> I expect idle state for RAM-OD (18) is also HIGH (RAM outputs disabled).
>>
>> I would suggest before trying to run a program you confirm that you are
>> able to load and examine memory.
>>
>> One of the subtle points here is that when loading/examining/running you
>> generally need to go 'through' the RESET state with the mode switches to
>> reset the internal address pointer to zero.
>>
>> Here's a load/examine test sequence:
>>
>> Load:
>> L1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
>> address pointer=0)
>> L2 - set MEM-RD/WR switch for WRITE/LOAD (*MP down)
>> L3 - set mode for PROGRAM (flip *LOAD up)
>> L4 - set data switches to 0001 0000, press STEP/*INPUT (load $10 into
>> mem-0)
>> L5 - set data switches to 0001 0001, press STEP/*INPUT (load $11 into
>> mem-1)
>> L6 - set data switches to 0001 0010, press STEP/*INPUT (load $12 into
>> mem-2)
>>
>> Examine:
>> E1 - set 2 mode switches for RESET (*RUN down, *LOAD down) (set 1802
>> address pointer=0)
>> E2 - set MEM-RD/WR switch for READ/EXAMINE (*MP up)
>> E3 - set mode for PROGRAM (flip *LOAD up)
>> E4 - press STEP/*INPUT, display should be 0001 0000 ($10)
>> E5 - press STEP/*INPUT, display should be 0001 0001 ($11)
>> E6 - press STEP/*INPUT, display should be 0001 0010 ($12)
>>
>> If you miss step L1, you won't know where you are actually loading into
>> memory. If you miss step E1, the examine steps (E4,E5,E6) will display
>> addresses 3,4,5 rather than displaying addresses 0,1,2. The same issue
>> applies when running a program, you normally have to reset state with
>> the
>> mode switches so the program starts running at 0.
>>
>> I don't like the switch labels of the original Elf, they can be
>> misleading, but that's history. I relabelled/disambiguated them in my
>> schematic and unit, the * labels above are the original switch labels,
>> others are mine.
>>
>>
>>
>> On 2012 Mar 17, at 8:48 AM, Gergely L?rincz wrote:
>>
>> Getting there: finally I can see the hex result on the display after I
>>
>>> press the input button. Seems to me that the control circuit work fine.
>>> However I tried to test the machine by entering 7b (SEQ) and pressed
>>> INPUT
>>> and set to RUN mode, expecting the Q output change it's state. It
>>> didn't
>>> happen:( The 1802the input and output section and the whole control
>>> circuit
>>> seem to work fine so I checked the RAMs. It seems that the read/write
>>> enable and output disable pins (18 and 20) show different logic state
>>> in
>>> the two memory ICs. I assume this stops the instruction to be entered
>>> to
>>> the memory. Can you guys tell me what should be the state of pins 18
>>> and
>>> 20
>>> (output disable and write enable) in run and load mode and when
>>> pressing
>>> the input button? The datasheet doesn't have much info on this.
>>>
>>>
>>> On 16 March 2012 18:15, Gergely L?rincz <alkopop79 at gmail.com>
wrote:
>>>
>>> Problem (partially) solved: the LOAD switch stops the fliflop letting
>>>
>>>> anything pass through until it's set on ( RESET mode). As if someone
>>>> mentioned it that particular bit is wrong on the schematics. I assume
>>>> i
>>>> just have to rewire the thing.
>>>>
>>>> On 16 Mar 2012 00:51, "Gergely L?rincz" <alkopop79 at
gmail.com> wrote:
>>>>
>>>> All of these test are done. Conclusion: if I remove the wire to SC1
>>>> and
>>>>
>>>>> reset the 4013, it works fine, just as you described. In fact, I
>>>>> spent
>>>>> a
>>>>> few hours sending pulses from an Arduino (microsecond ones) to
>>>>> simulate
>>>>> SC1. I even managed to see the pulse from *Q* on the oscilloscope.
>>>>> But
>>>>>
>>>>> once the wire between the 4013 and the SC1 pin is used, nothing
>>>>> works.
>>>>> I
>>>>> even tried two different 1802s and they work fine (when the DMA IN
>>>>> pin
>>>>> is
>>>>> set low, SC1 instantly goes high). The only possible reason I can
>>>>> think of
>>>>> (since both the 1802 and 4013 works perfectly) is that one of the
>>>>> diodes
>>>>> are either broken or placed the wrong way around. An other thing is
>>>>> that I
>>>>> use a SPST button (input) instead of the SPDT. It still works (for
>>>>> some
>>>>> weird reason no SPDT buttons are rare and expensive in the UK).
I'll
>>>>> check
>>>>> this tomorrow. The other mystery is that why the 4023 never sets the
>>>>> HP
>>>>> displays to enable mode. The displays are stuck (latched) and even
>>>>> though
>>>>> they work perfectly, the NAND gate (4023) never sets the enable pins
>>>>> low. I
>>>>> wonder if that has to anything with the previous problem? Anyway, at
>>>>> least
>>>>> I know where the problem is, even though I don't know what it
is.
>>>>> It's
>>>>> certainly a good start! Thanks for all of your effort and
>>>>> indispensable
>>>>> help!
>>>>>
>>>>> Greg
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Debugging trial: remove the connection from SC1 to the diode at the
>>>>>> 4013
>>>>>> reset (10).
>>>>>> Now, when the input switch is released, nQ & nDMAIN should go
low
>>>>>> and
>>>>>> STAY low as there is nothing to reset the 4013 (until you flip
the
>>>>>> load
>>>>>> mode switch).
>>>>>> It follows SC1 should go high and stay high or repeatedly pulse
high
>>>>>> as
>>>>>> the 1802 is being held in the DMA state (which I think you
already
>>>>>> tested
>>>>>> by forcing nDMAIN low).
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>
5:04 p.m.
Sounds like one of the switches is wired (or positioned if one =20
prefers) the 'wrong way round'. Doublecheck the switch positions =20
against the measured state on the mode pins:
One 'trap for the unwary' is that with most small toggle switches, if the
lever is pushed to one side, a connection is made between the centre tag
and the end tag _at the other side_.
--------
\ | |-o
\ | |
\| |-o *
| |
| |-o *
--------
With the toggle 'up' as shown here, the connection is made between the 2
tags I've marked with '*'s. It's fairly obvious if you know how the
mechanism works, but not everybody has had a mis-spent childhood taking
switches apart :-)
I always check with an ohmmeter though. It only tkes a couple of seconds
and it saves a lot of debugging time.
-tony
15 Mar
15 Mar
9:05 p.m.
There's a guy on Erik's Vintage forum who says he's got a new
Netronics Elf II kit in original packaging that he'd like to sell:
http://www.vintage-computer.com/vcforum/showthread.php?29771-
Netronics-Elf-II-sealed-in-box-unassembled
I thought that it might appeal to some here.
--Chuck
8 Mar
8 Mar
3:40 p.m.
I finally had time to have a look at the schematics. I realised that this
schematics replaced the two 4050's with 4049s. Can you confirm that it
I haev not looekd at these schematics, but the 4049 is a hex inverting
buffer, the 4050 is a hex non-inverting buffer. Unless 2 sections of them
are always cascaded, it's hard to see how replacing one with the other
won't make a difference.
works? Will purchase a couple of 4049 this week, wish
I wasn't under my
overdraft...
Ouch, things must be bad. Last time I looked, 4049s/4050s were under a
pound each...
-tony
5:44 p.m.
I know they're cheap but at the moment I have exactly 96 pence available:D
On 8 March 2012 20:40, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I finally had time to have a look at the schematics. I realised that this
schematics replaced the two 4050's with 4049s. Can you confirm that it
I haev not looekd at these schematics, but the 4049 is a hex inverting
buffer, the 4050 is a hex non-inverting buffer. Unless 2 sections of them
are always cascaded, it's hard to see how replacing one with the other
won't make a difference.
works? Will purchase a couple of 4049 this week,
wish I wasn't under my
overdraft...
Ouch, things must be bad. Last time I looked, 4049s/4050s were under a
pound each...
-tony
4509
days inactive
4529
days old
65 comments
18 participants
participants (18)
-
ajp166＠verizon.net -
alexeyt＠freeshell.org -
alkopop79＠gmail.com -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dave.g4ugm＠gmail.com -
drb＠msu.edu -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
hilpert＠cs.ubc.ca -
jecel＠merlintec.com -
legalize＠xmission.com -
mcguire＠neurotica.com -
mloewen＠cpumagic.scol.pa.us -
pinball＠telus.net -
RichA＠vulcan.com -
wdonzelli＠gmail.com