23 Aug
2014
23 Aug
'14
2:56 p.m.
Working away on the Altair 8800 restoration..
So the display/control board ("d/c") is now installed, and I'm running into
my first roadblock. I ask your understanding in advance, as my familiarity
with digital logic is pretty weak.
This machine has a Processor Tech. MB-1 mainboard in it. Full-width, 16
slots, and some mods I don't understand.
First, there's an LM309 (TO-3 case) mounted to the board, apparently
providing reg'd 5VCD to the normally 8V (un-reg'd) line. Why would that be
there? Every plug-in board I've seen - which isn't all that many,
admittedly - has its own regulator for 5V on-board.
Secondly, on the far left side of the board, there are several columns of
resistors that seem to be doing a couple different things - some are
pulling-up various groups of lines to what seems like 1/2 of VCC, others
are either there for termination or some other unknown function.
All together, close to 100 resistors installed there.. and it's clearly a
mod (at least partly) as a line of 50 new holes was drilled to accommodate
them.
Anyone know what's up with this stuff? Why it's there? At this point, my
sense is that I need to remove all of it, as they don't exist in the
original build - and I may even cut the main board in two - totally lop-off
the leftmost 12 sockets along with the resitors & reg.
23 Aug
23 Aug
4:53 p.m.
On 2014-Aug-23, at 11:56 AM, drlegendre . wrote:
Working away on the Altair 8800 restoration..
So the display/control board ("d/c") is now installed, and I'm running
into
my first roadblock. I ask your understanding in advance, as my familiarity
with digital logic is pretty weak.
This machine has a Processor Tech. MB-1 mainboard in it. Full-width, 16
slots, and some mods I don't understand.
First, there's an LM309 (TO-3 case) mounted to the board, apparently
providing reg'd 5VCD to the normally 8V (un-reg'd) line. Why would that be
there? Every plug-in board I've seen - which isn't all that many,
admittedly - has its own regulator for 5V on-board.
Secondly, on the far left side of the board, there are several columns of
resistors that seem to be doing a couple different things - some are
pulling-up various groups of lines to what seems like 1/2 of VCC, others
are either there for termination or some other unknown function.
All together, close to 100 resistors installed there.. and it's clearly a
mod (at least partly) as a line of 50 new holes was drilled to accommodate
them.
Anyone know what's up with this stuff? Why it's there? At this point, my
sense is that I need to remove all of it, as they don't exist in the
original build - and I may even cut the main board in two - totally lop-off
the leftmost 12 sockets along with the resitors & reg.
I'd suggest double-checking the 309 regulator and the +8 lines on the bus sockets, the
309 might be just providing +5 for the termination network.
It's conceivable the bus and (some) boards were modified for +5 on the bus edge
connectors but it would make for a limited and incompatible system.
The S100 bus is a mixture of OC (open-collector) and tri-state signals:
- OC signals are supposed to have a pull-up resistor somewhere in the system, usually
on the processor board.
- Tri-state signals *may* (optionally) have termination resistor (networks) somewhere
in the system.
- One way to provide such termination is an R per signal to a common supply
regulated to ~ 1/2 Vcc;
- Another way is two Rs per signal: one to ground, one to +5, calculated to
give the target AC impedance for the line assuming negligible
AC impedance between +5 & GND while DC biasing the line to ~ 1/2 Vcc.
See the IEEE-696 spec:
http://www.pestingers.net/PDFs/Other_computers/IEEE%20696%20S-100%20Bus%20S…
page 34, Sec 3.4.1 Driver Types
Sec 3.7.1 Bus Termination
page 15, Table 6
I'd think you should be able to get the sys working before taking the irreversible
step of cutting the Processor Tech bus board. No, the termination isn't strictly
necessary, at least for 'low-speed' (i.e. early) systems (I've seen several
16-slot systems with no termination), but some reading suggests the PT bus may have been a
common upgrade for the Altair bus-boards.
4:55 p.m.
On Sat, Aug 23, 2014 at 12:56 PM, drlegendre . <drlegendre at gmail.com> wrote:
This machine has a Processor Tech. MB-1 mainboard in
it. Full-width, 16
slots, and some mods I don't understand.
First, there's an LM309 (TO-3 case) mounted to the board, apparently
providing reg'd 5VCD to the normally 8V (un-reg'd) line. Why would that be
there? Every plug-in board I've seen - which isn't all that many,
admittedly - has its own regulator for 5V on-board.
Secondly, on the far left side of the board, there are several columns of
resistors that seem to be doing a couple different things - some are
pulling-up various groups of lines to what seems like 1/2 of VCC, others
are either there for termination or some other unknown function.
Are you sure the LM309 doesn't have its input tied to the 8V supply,
and its output to those termination resistors?
7:51 p.m.
I'll take another look (pulled the boards out of the case) but I'm pretty
sure the LM309 is serving the entire +8 / +5 supply. Good point, though.
I began asking this, as when I powered-up the boards for first smoke test,
I noticed that all of the Data LEDs are on.. +except+ for D2. Investigation
found that all data lines (except D2) are sitting at 1/2 Vcc causing the
connected 7404 inverter outputs to go low, which turns on the LEDs (as the
other leg of the LEDs is tied to Vcc). So when the inverter output remains
high, both sides of the LED see Vcc and hence no current - inverters go
low, and they sink current and turn-on the LEDs.
It was that D2 being off that drew my attention. And upon further reading,
I don't think +any+ of those data LEDs should be on, when no other boards
are installed.
Will report back in just a few mins.
On Sat, Aug 23, 2014 at 3:55 PM, Eric Smith <spacewar at gmail.com> wrote:
On Sat, Aug 23, 2014 at 12:56 PM, drlegendre .
<drlegendre at gmail.com>
wrote:
This machine has a Processor Tech. MB-1 mainboard
in it. Full-width, 16
slots, and some mods I don't understand.
First, there's an LM309 (TO-3 case) mounted to the board, apparently
providing reg'd 5VCD to the normally 8V (un-reg'd) line. Why would that
be
there? Every plug-in board I've seen - which
isn't all that many,
admittedly - has its own regulator for 5V on-board.
Secondly, on the far left side of the board, there are several columns
of
resistors that seem to be doing a couple
different things - some are
pulling-up various groups of lines to what seems like 1/2 of VCC, others
are either there for termination or some other unknown function.
Are you sure the LM309 doesn't have its input tied to the 8V supply,
and its output to those termination resistors?
8:20 p.m.
Ok good call gents, thanks for pointing this out.. yes, the LM309 only
provides power for the termination network (marked VT+). Here's what I see
in the network:
- Some lines have no connection to the network at all
- Most lines have a 330R pull-up connected to the VT+
- A number of lines are biased at +roughly+ 1/2 VT+ by being placed at the
junction of a 330R and 470R -> Gnd resistor.
And for some reason, all of the data lines - with the exception of D2 - are
in the latter category. They're biased at the 330 / 470 junctions. So my
current questions are..
Why did they skip D2 of all things?
Will any of this have any effect on the operation of the machine, once I
plug in an original CPU board & static RAM board?
And lastly...
Does anyone have a 1K or 4K static RAM board for this, that I can beg, buy,
barter or steal off them? Howzabout an original mainboard, so I don't have
to whack this one to pieces.. which seems to throw up huge red flags in my
mind, as I'm loath to modify or damage any kind of vintage parts!
On Sat, Aug 23, 2014 at 6:51 PM, drlegendre . <drlegendre at gmail.com> wrote:
I'll take another look (pulled the boards out of
the case) but I'm pretty
sure the LM309 is serving the entire +8 / +5 supply. Good point, though.
I began asking this, as when I powered-up the boards for first smoke test,
I noticed that all of the Data LEDs are on.. +except+ for D2. Investigation
found that all data lines (except D2) are sitting at 1/2 Vcc causing the
connected 7404 inverter outputs to go low, which turns on the LEDs (as the
other leg of the LEDs is tied to Vcc). So when the inverter output remains
high, both sides of the LED see Vcc and hence no current - inverters go
low, and they sink current and turn-on the LEDs.
It was that D2 being off that drew my attention. And upon further reading,
I don't think +any+ of those data LEDs should be on, when no other boards
are installed.
Will report back in just a few mins.
On Sat, Aug 23, 2014 at 3:55 PM, Eric Smith <spacewar at gmail.com> wrote:
On Sat, Aug 23, 2014 at 12:56 PM, drlegendre .
<drlegendre at gmail.com>
wrote:
This machine has a Processor Tech. MB-1 mainboard
in it. Full-width, 16
slots, and some mods I don't understand.
First, there's an LM309 (TO-3 case) mounted to the board, apparently
providing reg'd 5VCD to the normally 8V (un-reg'd) line. Why would that
be
there? Every plug-in board I've seen - which
isn't all that many,
admittedly - has its own regulator for 5V on-board.
Secondly, on the far left side of the board, there are several columns
of
resistors that seem to be doing a couple
different things - some are
pulling-up various groups of lines to what seems like 1/2 of VCC, others
are either there for termination or some other unknown function.
Are you sure the LM309 doesn't have its input tied to the 8V supply,
and its output to those termination resistors?
9:44 p.m.
On 2014-Aug-23, at 5:20 PM, drlegendre . wrote:
Ok good call gents, thanks for pointing this out..
yes, the LM309 only
provides power for the termination network (marked VT+). Here's what I see
in the network:
- Some lines have no connection to the network at all
- Most lines have a 330R pull-up connected to the VT+
- A number of lines are biased at +roughly+ 1/2 VT+ by being placed at the
junction of a 330R and 470R -> Gnd resistor.
And for some reason, all of the data lines - with the exception of D2 - are
in the latter category. They're biased at the 330 / 470 junctions. So my
current questions are..
Why did they skip D2 of all things?
Will any of this have any effect on the operation of the machine, once I
plug in an original CPU board & static RAM board?
> I began asking this, as when I powered-up the
boards for first smoke test,
> I noticed that all of the Data LEDs are on.. +except+ for D2. Investigation
> found that all data lines (except D2) are sitting at 1/2 Vcc causing the
> connected 7404 inverter outputs to go low, which turns on the LEDs (as the
> other leg of the LEDs is tied to Vcc). So when the inverter output remains
> high, both sides of the LED see Vcc and hence no current - inverters go
> low, and they sink current and turn-on the LEDs.
>
> It was that D2 being off that drew my attention. And upon further reading,
> I don't think +any+ of those data LEDs should be on, when no other boards
> are installed.
The absence of termination resistors on D2 just sounds like a mistake.
The open-circuit state for a TTL input is high and the S100 data lines are active-high, so
with no boards on the bus one could expect all the Data LEDs to be on, with or without
termination resistors. With the D2 LED off it suggests something is pulling the line low.
(Are all the data/address front panel switches in the same position?)
You might try pulling the appropriate D2 line (DI2) high, through a 220 to 330 ohm
resistor for a little safety, to see if the D2 LED will come on.
10:40 p.m.
The absence of termination resistors on D2 just sounds like a mistake.
The open-circuit state for a TTL input is high and the S100 data lines are
active-high, so with no boards on the bus one could expect all the Data
LEDs to be on, with or without termination resistors. With the D2 LED off
it suggests something is pulling the line low. (Are all the data/address
front panel switches in the same position?)
You might try pulling the appropriate D2 line (DI2) high, through a 220 to
330 ohm resistor for a little safety, to see if the D2 LED will come on.
Yeah, there aren't any resistors connected to it, which is why it's sitting
low. I checked that out.
So what's the verdict on this, guys? Is this board - which was modded with
all the termination stuff for a Z-80 based system - going to be OK when I
try to get the old 8080A hardware working in it? Or is it going to screw
things up, like having the Data LEDs on at all (or at least spurious) times?
This is all new to me.
10:55 p.m.
On 2014-Aug-23, at 7:40 PM, drlegendre . wrote:
Without any termination resistors, an undriven bus line should nonetheless be interpreted
(by the 7404) as high, so the D2 LED should be on.
It would appear something else is pulling it low (or something is wrong with the
7404/LED).
The absence of
termination resistors on D2 just sounds like a mistake.
The open-circuit state for a TTL input is high and the S100 data lines are
active-high, so with no boards on the bus one could expect all the Data
LEDs to be on, with or without termination resistors. With the D2 LED off
it suggests something is pulling the line low. (Are all the data/address
front panel switches in the same position?)
You might try pulling the appropriate D2 line (DI2) high, through a 220 to
330 ohm resistor for a little safety, to see if the D2 LED will come on.
Yeah, there aren't any resistors connected to it, which is why it's sitting
low. I checked that out. So what's the verdict on this, guys? Is this board
- which was modded with
all the termination stuff for a Z-80 based system - going to be OK when I
try to get the old 8080A hardware working in it? Or is it going to screw
things up, like having the Data LEDs on at all (or at least spurious) times?
This is all new to me.
11:32 p.m.
On Sat, Aug 23, 2014 at 9:55 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Without any termination resistors, an undriven bus line should nonetheless
be interpreted (by the 7404) as high, so the D2 LED should be on.
It would appear something else is pulling it low (or something is wrong
with the 7404/LED).
Not in this case.. and I mentioned why a few posts back, but I don't blame
you for missing it.
The non-gate side of the LEDs are connected to Vcc (5V), rather than Gnd.
So if the 7404 input is L, the output is H and the LED is +off+ (5V on both
LED terminals, no current). If the 7404 input goes H, the output is L and
current sinks from the Vcc line through the LED to the (low) gate of the
7404.
24 Aug
24 Aug
12:57 a.m.
On 2014-Aug-23, at 8:32 PM, drlegendre . wrote:
On Sat, Aug 23, 2014 at 9:55 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
No, you're missing the point.
You said the D2 LED is OFF, which by your logic implies the 7404 input is LOW.
But, as I've stated twice now, an undriven TTL input (which should be the state of the
line without termination resistors) should be interpreted by the inverter as HIGH. Thence
(as per your desc) the output of the inverter would be LOW and the D2 LED ON.
This input behaviour is a characteristic of TTL logic at the electrical level. It may seem
counter-intuitive but an open or unconnected input in a physical logic implementation is
not inherently a logical low. Pulling TTL inputs high with resistors is not done for the
sake of setting the input to a logic high, it's done for noise margin and speed
issues.
There is other stuff in the front panel connected to the DIn lines, but I don't think
any of it would be driving the lines in the idle state, so all the data LEDs should be on
with no boards plugged in. You might confirm the data switches are all in the same
position and toggling them has no immediate effect on the LEDs.
Without any termination resistors, an undriven
bus line should nonetheless
be interpreted (by the 7404) as high, so the D2 LED should be on.
It would appear something else is pulling it low (or something is wrong
with the 7404/LED).
Not in this case.. and I mentioned why a few posts back, but I don't blame
you for missing it.
The non-gate side of the LEDs are connected to Vcc (5V), rather than Gnd.
So if the 7404 input is L, the output is H and the LED is +off+ (5V on both
LED terminals, no current). If the 7404 input goes H, the output is L and
current sinks from the Vcc line through the LED to the (low) gate of the
7404.
2:12 a.m.
On Sat, Aug 23, 2014 at 11:57 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
No, you're missing the point.
You said the D2 LED is OFF, which by your logic implies the 7404 input is
LOW.
But, as I've stated twice now, an undriven TTL input (which should be the
state of the line without termination resistors) should be interpreted by
the inverter as HIGH. Thence (as per your desc) the output of the inverter
would be LOW and the D2 LED ON.
This input behaviour is a characteristic of TTL logic at the electrical
level. It may seem counter-intuitive but an open or unconnected input in a
physical logic implementation is not inherently a logical low. Pulling TTL
inputs high with resistors is not done for the sake of setting the input to
a logic high, it's done for noise margin and speed issues.
There is other stuff in the front panel connected to the DIn lines, but I
don't think any of it would be driving the lines in the idle state, so all
the data LEDs should be on with no boards plugged in. You might confirm the
data switches are all in the same position and toggling them has no
immediate effect on the LEDs.
Then I'm not sure what to say, because when I fixed the bunk connection in
the term. network (for pin 41 / D2) the LED came on just like the rest of
them.. shrug.
4:52 a.m.
On 2014-Aug-23, at 11:12 PM, drlegendre . wrote:
On Sat, Aug 23, 2014 at 11:57 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
Well, that's good. If the 470-ohm R to ground was intact and the 330 R to +5 had a
bad connection that would explain the symptoms. Your earlier messages left the impression
the D2 Rs were missing.
No, you're missing the point.
You said the D2 LED is OFF, which by your logic implies the 7404 input is
LOW.
But, as I've stated twice now, an undriven TTL input (which should be the
state of the line without termination resistors) should be interpreted by
the inverter as HIGH. Thence (as per your desc) the output of the inverter
would be LOW and the D2 LED ON.
This input behaviour is a characteristic of TTL logic at the electrical
level. It may seem counter-intuitive but an open or unconnected input in a
physical logic implementation is not inherently a logical low. Pulling TTL
inputs high with resistors is not done for the sake of setting the input to
a logic high, it's done for noise margin and speed issues.
There is other stuff in the front panel connected to the DIn lines, but I
don't think any of it would be driving the lines in the idle state, so all
the data LEDs should be on with no boards plugged in. You might confirm the
data switches are all in the same position and toggling them has no
immediate effect on the LEDs.
Then I'm not sure what to say, because when I fixed the bunk connection in
the term. network (for pin 41 / D2) the LED came on just like the rest of
them.. shrug.
11:48 a.m.
Well, they were /functionally missing/. So many little parts all crammed
together, all alike, and no clear pin numbering in sight - I couldn't tell
whether or not the 330 was present until I pulled the board back out,
flipped it over and started counting. Then I found the bunk joint where #41
should be soldered..
As things moved along, I was able to measure the 470 to gnd, tho, so I knew
that much was there.
Now back to your original point, the one you felt I was missing..
Pin #41 had the 470 to gnd, but no 330 to VT+, so it was at a true logic
low, pulled down by the 470. This causes the 7404 output to go high,
turning off the LED. When I connected the 330 part, Pin 41 came up to
2.8VDC (about 1/2 of VT+) which I guess the 7404 sees as a high (?)
switching off the 7404 output and turning on the LED.
All good so far?
if so, then I don't understand why you were stressing that a typical TTL
chip would see a floating input ("undetermined") as a logic hi. Since all
of the bus pins in the D0-D7 series connected to the 7404s had either 2.8V
or 470 to gnd, none were just floating, were they? Or were you speaking of
some other lines left floating that I should be concerned about?
See what I mean?
On Sun, Aug 24, 2014 at 3:52 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-23, at 11:12 PM, drlegendre . wrote:
in
On Sat, Aug 23, 2014 at 11:57 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
> No, you're missing the point.
>
> You said the D2 LED is OFF, which by your logic implies the 7404 input
is
> LOW.
>
> But, as I've stated twice now, an undriven TTL input (which should be
the
> state of the line without termination
resistors) should be interpreted
by
> the inverter as HIGH. Thence (as per your
desc) the output of the
inverter
> would be LOW and the D2 LED ON.
>
> This input behaviour is a characteristic of TTL logic at the electrical
> level. It may seem counter-intuitive but an open or unconnected input
in a
> physical logic implementation is not
inherently a logical low. Pulling
TTL
> inputs high with resistors is not done for
the sake of setting the
input to
> a logic high, it's done for noise margin
and speed issues.
>
> There is other stuff in the front panel connected to the DIn lines, but
I
> don't think any of it would be driving
the lines in the idle state, so
all
> the data LEDs should be on with no boards
plugged in. You might confirm
the
data
switches are all in the same position and toggling them has no
immediate effect on the LEDs.
Then I'm not sure what to say, because when I fixed the bunk connection the term. network (for pin 41 / D2) the LED came
on just like the rest of
them.. shrug.
Well, that's good. If the 470-ohm R to ground was intact and the 330 R to
+5 had a bad connection that would explain the symptoms. Your earlier
messages left the impression the D2 Rs were missing.
11:56 a.m.
In any event, once the data LEDs were acting "normal", I went ahead and
plugged-in the CPU board and tried it out. It was running at about 100V of
line when I noticed that something in there was now pulling about 350mA..
almost 35W! Without the CPU board, current was almost nil..
Then I caught a slight whiff of "that" smell, and switched-off, to hunt
down the hot component.. which seems to be on the D/C board, not the CPU
board. The D/C had a fire in the past, but I did replace the associated
chip & damaged components. Maybe I missed a shorted cap or something, but
how would the insertion of the CPU board create a new, high-current path to
the D/C board?
And that's when I packed it in for the day. If you had seen the state of
this thing when I got it, it's almost like a miracle that it's doing
anything at all right, lol. A genuine basket case, it was.
On Sun, Aug 24, 2014 at 10:48 AM, drlegendre . <drlegendre at gmail.com> wrote:
Well, they were /functionally missing/. So many little
parts all crammed
together, all alike, and no clear pin numbering in sight - I couldn't tell
whether or not the 330 was present until I pulled the board back out,
flipped it over and started counting. Then I found the bunk joint where #41
should be soldered..
As things moved along, I was able to measure the 470 to gnd, tho, so I
knew that much was there.
Now back to your original point, the one you felt I was missing..
Pin #41 had the 470 to gnd, but no 330 to VT+, so it was at a true logic
low, pulled down by the 470. This causes the 7404 output to go high,
turning off the LED. When I connected the 330 part, Pin 41 came up to
2.8VDC (about 1/2 of VT+) which I guess the 7404 sees as a high (?)
switching off the 7404 output and turning on the LED.
All good so far?
if so, then I don't understand why you were stressing that a typical TTL
chip would see a floating input ("undetermined") as a logic hi. Since all
of the bus pins in the D0-D7 series connected to the 7404s had either 2.8V
or 470 to gnd, none were just floating, were they? Or were you speaking of
some other lines left floating that I should be concerned about?
See what I mean?
On Sun, Aug 24, 2014 at 3:52 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-23, at 11:12 PM, drlegendre . wrote:
in
On Sat, Aug 23, 2014 at 11:57 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
> No, you're missing the point.
>
> You said the D2 LED is OFF, which by your logic implies the 7404 input
is
> LOW.
>
> But, as I've stated twice now, an undriven TTL input (which should be
the
> state of the line without termination
resistors) should be interpreted
by
> the inverter as HIGH. Thence (as per your
desc) the output of the
inverter
> would be LOW and the D2 LED ON.
>
> This input behaviour is a characteristic of TTL logic at the electrical
> level. It may seem counter-intuitive but an open or unconnected input
in a
> physical logic implementation is not
inherently a logical low. Pulling
TTL
> inputs high with resistors is not done for
the sake of setting the
input to
> a logic high, it's done for noise margin
and speed issues.
>
> There is other stuff in the front panel connected to the DIn lines,
but I
> don't think any of it would be driving
the lines in the idle state, so
all
> the data LEDs should be on with no boards
plugged in. You might
confirm the
data
switches are all in the same position and toggling them has no
immediate effect on the LEDs.
Then I'm not sure what to say, because when I fixed the bunk connection the term. network (for pin 41 / D2) the LED came
on just like the rest
of
them.. shrug.
Well, that's good. If the 470-ohm R to ground was intact and the 330 R
to +5 had a bad connection that would explain the symptoms. Your earlier
messages left the impression the D2 Rs were missing.
3:02 p.m.
On 2014-Aug-24, at 8:56 AM, drlegendre . wrote:
In any event, once the data LEDs were acting
"normal", I went ahead and
plugged-in the CPU board and tried it out. It was running at about 100V of
line when I noticed that something in there was now pulling about 350mA..
almost 35W! Without the CPU board, current was almost nil..
Then I caught a slight whiff of "that" smell, and switched-off, to hunt
down the hot component.. which seems to be on the D/C board, not the CPU
board. The D/C had a fire in the past, but I did replace the associated
chip & damaged components. Maybe I missed a shorted cap or something, but
how would the insertion of the CPU board create a new, high-current path to
the D/C board?
And that's when I packed it in for the day. If you had seen the state of
this thing when I got it, it's almost like a miracle that it's doing
anything at all right, lol. A genuine basket case, it was.
You're going to have to get more specific (and more accurate).
What burned up before (pic perhaps)?
What is getting hot now? (and how hot as noted by finger?)
Confirm that +5 looks good on both the CPU board and D/C board.
5:50 p.m.
On Sun, Aug 24, 2014 at 2:02 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
You're going to have to get more specific (and more accurate).
Heh, I wasn't requesting help with it, Brent.. ;-) I was just supplying a
little narrative to keep those who are reading on the same page... you
really think I'd expect anyone to supply useful comment on "something got
hot and I'm not really sure where or why"? Really?
That's just general electrical stuff, which I tend to have a good handle on
- again, it's the world of digital electronics that's mostly very new to
me.
Anyway, it was getting very late, and I'd been at it for over eight hours.
I'd accidentally swapped the +18 & -18 lines, and that was causing the
excessive current & heat. When you're dealing with juggling a +lot+ of new
info it's easy (at least for me) to slip-up and confuse yourself, draw
unfounded conclusions, etc. My accuracy will improve dramatically once I
have a handle on this stuff.
SO THEN.. After finding & fixing a couple other issues (bad connections)
and adjusting the brightness of the new LEDs to match the old ones (wow,
from 220R to 3K9 for the dropping resistance!), this
old thing is actually
showing some signs of life! I have the CPU board plugged in,
but no RAM
board, as all I have is a 64K dynamic card. Here's what I'm seeing:
MEMR, STACK and WO are lit. D0-D7 remain lit. A15-A0 are another matter..
A15 is flashing about 2Hz, A14 at about 4Hz, A13 at about 8Hz and after
that on down the line to A0 I assume all others are flashing as well, but
persistence of vision makes them appear to be steadily lit. Oh, on power-up
the A LEDs were off, but hitting RESET puts them in the flashing modes I
described.
So is this how it's supposed to act with no memory installed? I'm at the
point where I pretty much must have a SRAM board for it.. I may have to
resort to eBay, and hope I get one that's actually working. I really need a
known-good part for this stage.
25 Aug
25 Aug
2:14 a.m.
I just realized something, about the flashing LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
displaying the position on the A15-A0 LEDs. Since A15 is the MSB, it
changes the least often, with A14 changing twice as often as A15, and A13
changing twice as often as A14 and so on down the line. Any bits below A13
or so are changing so quickly that vision can't perceive it.
So that is what I +think+ it's doing. As to why, I'd have little idea..
time to read more docs.
On Sun, Aug 24, 2014 at 4:50 PM, drlegendre . <drlegendre at gmail.com> wrote:
On Sun, Aug 24, 2014 at 2:02 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
You're going to have to get more specific (and more accurate).
Heh, I wasn't requesting help with it, Brent.. ;-) I was just supplying a
little narrative to keep those who are reading on the same page... you
really think I'd expect anyone to supply useful comment on "something got
hot and I'm not really sure where or why"? Really?
That's just general electrical stuff, which I tend to have a good handle
on - again, it's the world of digital electronics that's mostly very new to
me.
Anyway, it was getting very late, and I'd been at it for over eight hours.
I'd accidentally swapped the +18 & -18 lines, and that was causing the
excessive current & heat. When you're dealing with juggling a +lot+ of new
info it's easy (at least for me) to slip-up and confuse yourself, draw
unfounded conclusions, etc. My accuracy will improve dramatically once I
have a handle on this stuff.
SO THEN.. After finding & fixing a couple other issues (bad connections)
and adjusting the brightness of the new LEDs to match the old ones (wow,
from 220R to 3K9 for the dropping resistance!), this old thing is actually
showing some signs of life! I have the CPU board plugged in, but no RAM
board, as all I have is a 64K dynamic card. Here's what I'm seeing:
MEMR, STACK and WO are lit. D0-D7 remain lit. A15-A0 are another matter..
A15 is flashing about 2Hz, A14 at about 4Hz, A13 at about 8Hz and after
that on down the line to A0 I assume all others are flashing as well, but
persistence of vision makes them appear to be steadily lit. Oh, on power-up
the A LEDs were off, but hitting RESET puts them in the flashing modes I
described.
So is this how it's supposed to act with no memory installed? I'm at the
point where I pretty much must have a SRAM board for it.. I may have to
resort to eBay, and hope I get one that's actually working. I really need a
known-good part for this stage.
3:14 a.m.
On Mon, Aug 25, 2014 at 12:14 AM, drlegendre . <drlegendre at gmail.com> wrote:
I just realized something, about the flashing LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
If you're going to do much hardware work, I'd strongly recommend getting
an oscilliscope. You want at least three times the bandwidth of the highest
frequency digital signal you are going to look at, so for old 8-bitters, I'd
recommend having at least 30 MHz bandwidth, but you can probably find
a used 100 MHz analog scope (e.g., Tek 465) pretty inexpensively. You
don't need the scope to be well-calibrated, but it does need to work, since
you don't want the scope to also be a repair project, especially for something
as complicated as a Tek 465. I paid about $100 for a working Tek 465 last year.
If you can afford it, a modern digital scope such as a Rigol might be a good
investment. A digital scope can catch single-shot events which a normal analog
scope cannot. A Rigol DS1102E two-channel 100 MHz scope costs $399 new.
Note that older digital scopes are actually *less* useful than an analog
scope for anything other than single-shot capture, because the older ones
(up through the mid-1990s) didn't behave much like an analog scope. The
newer ones are specifically design to give a similar experience to an analog
scope.
For really heavy-duty debugging, a logic analyzer is quite useful, but there's
an intermediate step known as a "mixed signal oscilliscope", which is
an oscilliscope with an extra 16 channels that are digital only, and
with simple logic analyzer capabilities. For instance, a Rigol DS1102D
100 MHz 2 analaog 16 digital channel scope is $800 new.
If you want test equipment suitable to work on modern computers (anything from
the mid-1990s and later), you're talking Really Big Bucks (tm). IMNSHO,
it's not even worth wasting time trying to do any hardware repair on newer
stuff, since they aren't designed to be serviced. The manufacturer intends
the whole computer to be a single FRU (Field Replaceable Unit), i.e., when
it breaks, throw it away and buy a new one. :-(
OK, so I exaggerate slightly. Usually the power supply, disk drive, keyboard,
mouse, and monitor are still separate FRUs.
4:01 p.m.
On Mon, Aug 25, 2014 at 12:14 AM, drlegendre . <drlegendre at gmail.com> wrote:
I don't use a 'scope all that much, actually.
Obivously the insturment I use most is a multimeter, since checking PSU
voltages and finding broken conenctions is a common task. But after that,
I wopuld use a logic analuyser much more than a 'scope. I find the
ability ot be able to see 16 signals at a time (albiet as only 0's and
1's to be a lot e more use than seeing 2 or 4 signals as votlage waveforms.
It does depend on what you are doing, though,and there are times wien I
need a 'scope (jsut as there are times when oyu _ened_ a logic analyser
[1]).
[1] Depugging microdeed CPUs is one such, things like the HP9800 family.
Being able to feed the 8 bit microcode address into an LA and thus trace
the microcode really speeds up debugging.
If you can find one, the HP LogicDart is a very hand yhadnhedl thing. A
combined voltmeter, continuity tester, frequency meter and 3 channel LA.
It does not replace a larger logic analyser with more channels. but ti is
small enoguh to throw in the toolbox and take to the job.
I just realized something, about the flashing
LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
If you're going to do much hardware work, I'd strongly recommend getting
an oscilliscope. You want at least three times the bandwidth of the highest frequency digital signal you are going to look at, so
for old 8-bitters, I'd
recommend having at least 30 MHz bandwidth, but you can probably find
a used 100 MHz analog scope (e.g., Tek 465) pretty inexpensively. You
don't need the scope to be well-calibrated, but it does need to work, since
you don't want the scope to also be a repair project, especially for something
as complicated as a Tek 465. I paid about $100 for a working Tek 465 last year.
Oh I don't know. Fixing old Tek 'scopes is fun. For sutiable values of fun...
If you want test equipment suitable to work on modern
computers (anything from
the mid-1990s and later), you're talking Really Big Bucks (tm). IMNSHO,
One reason why I will not depend on such machiens if IO ahve ot maintain
them...
it's not even worth wasting time trying to do any
hardware repair on newer
stuff, since they aren't designed to be serviced. The manufacturer intends
And even if you ahve ythetest gear and can fidn the faulty compoent,
99.9% of the time you can't get it other than as part of the FRU.
For classic machines it can be useful to be able ot find fault ASICs even
if tehy were never avaialbel as spares, since it may well mean you can
get oen workign board otu of 2 fautly ones. But for modern stuff it's not
really worth it -- yet.
I find the service manual for my digital TV set very amusing. There re 2
PCBs in there. A PSU (sonventioanl SMPSU) and the signal processing board
complete with BGA packaged ICs, etc. The service manaul regards the PSU as
a single FRU, no schematics, but you are expexcted to repair the signal
proccessing panel to component level armed only with the schematic. Go
figure...
-tony
27 Aug
27 Aug
10:54 a.m.
On Aug 25, 2014, at 12:14 AM, Eric Smith <spacewar at gmail.com> wrote:
On Mon, Aug 25, 2014 at 12:14 AM, drlegendre .
<drlegendre at gmail.com> wrote:
To amplify Eric's point about big bucks for modern equipment.
At a previous employer where we were doing *bringup* of new processors on
new hardware (Intel Core2 stuff...before the memory controller was integrated
in with the CPU) we had a "front side bus analyzer". It was "double
pumped"
and running at 800MHz (so logically it's running at 1.6GHz). As I recall that
analyzer was in the high $100,000s (ie pushing $1,000,000). We had several
in order to do the analysis/debug. How the thing actually worked with signaling
that fast still amazes me. The analyzer itself sat about 4' away from the system
being diagnosed. I still can't figure out how you manage the signaling. ;-)
In current modern systems, the high speeds are at the memory interface DDR3/4,
PCIe, SATA. All of these are running at giga-tranfers per second. We won't even
get into the proprietary interconnects between the north (CPU, graphics, memory
controller) and the south (everything else) chips.
TTFN - Guy
I just realized something, about the flashing
LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
If you want test equipment suitable to work on modern computers (anything from
the mid-1990s and later), you're talking Really Big Bucks (tm). IMNSHO,
it's not even worth wasting time trying to do any hardware repair on newer
stuff, since they aren't designed to be serviced. The manufacturer intends
the whole computer to be a single FRU (Field Replaceable Unit), i.e., when
it breaks, throw it away and buy a new one. :-(
OK, so I exaggerate slightly. Usually the power supply, disk drive, keyboard,
mouse, and monitor are still separate FRUs. 
11:20 a.m.
At a previous employer where we were doing *bringup*
of new processors on
new hardware (Intel Core2 stuff...before the memory controller was integrated
in with the CPU) we had a "front side bus analyzer". It was "double
pumped"
and running at 800MHz (so logically it's running at 1.6GHz). As I recall that
analyzer was in the high $100,000s (ie pushing $1,000,000).
And in 20 years, that same item will be a $100 hamfest special.
--
Will
11:59 a.m.
On 8/27/2014 8:20 AM, William Donzelli wrote:
Intel used the Deathstar, which was a semicircle of HP 16700 frames
loaded with 4m deep capable cards. I don't know how many channels they
had, but I know they instrumented the FSB and graphics.
This was in the time of the Timna, which was to be a single SOC with
graphics just after the P3 Coppermine turn.
The Coppermine was about the last S1 form factor product before they
transitioned back into the original pin type packaging away from BGA's
on circuit boards for reference.
The Timna was killed off, not sure why.
The 16700's are already sometimes in the $100 range with the newer logic
analyzers out in the field now.
We at Arium had a trace product up to the S2 and S1 days which used an
Arium ML4400 analyzer with special cards built by another company to
capture the bus traffic. That was the last trace product for Intel that
we did. We transitioned to run control only like everyone else and left
the tracing to others.
I think the monster that HP made for the Itanium was the last trace they
did for intel. There is a preprocessor module that shows up on the
market w/o the adapter to go under the processor all the time. Useless
w/o the adapter, but people look at the original cost from HP for it and
price the things at ridiculous amounts. They are almost always for sale
At a previous
employer where we were doing *bringup* of new processors on
new hardware (Intel Core2 stuff...before the memory controller was integrated
in with the CPU) we had a "front side bus analyzer". It was "double
pumped"
and running at 800MHz (so logically it's running at 1.6GHz). As I recall that
analyzer was in the high $100,000s (ie pushing $1,000,000).
And in 20 years, that
same item will be a $100 hamfest special.
--
Will from "asset recovery" operations and they
base their attempted sale on a
percentage of the original balance sheet value. HP
made so few of these
that they were just incredibly expensive.
We at Arium did the run control for Itanium for HP and interacted with
their logic analyzers to do triggering and also could read the trace
into our debugger for annotated instruction level trace.
Jim
12:03 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of William Donzelli
Sent: Wednesday, August 27, 2014 11:20 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Some Altair questions, if I may..
With the pods and data cables missing. Where the h*** do they go?
At a previous employer where we were doing
*bringup* of new
processors on
new hardware (Intel Core2 stuff...before the
memory controller was
integrated
in with the CPU) we had a "front side bus
analyzer". It was "double
pumped"
and running at 800MHz (so logically it's
running at 1.6GHz). As I
recall that
analyzer was in the high $100,000s (ie pushing
$1,000,000).
And in 20 years, that same item will be a $100 hamfest special.
3:20 p.m.
On Mon, Aug 25, 2014 at 2:14 AM, Eric Smith <spacewar at gmail.com> wrote:
On Mon, Aug 25, 2014 at 12:14 AM, drlegendre .
<drlegendre at gmail.com>
wrote:
There have been a few comments & questions about scopes and so forth in
this thread, so I thought it worth mentioning what I've got on-hand so you
know what I've got to work with.
There are three scopes here, all older. Two Telequipment 10MHz models, both
rebuilt, and a B&K 30Mhz model that seems to work OK but I've not been
through it. All single-ended stuff, no differential probes.
Additionally, there's a Racal/Dana 8-place freq. counter, two logic probes,
two logic pulsers, a Wavetek signal gen, half a dozen DMMs including a
matched pair of cal'd Fluke 8050As. Beyond that, it's the typical workbench
stuff - power supplies, variacs, sub. boxes, etc.
So that's is about it, for applicable instruments.
I just realized something, about the flashing
LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
If you're going to do much hardware work, I'd strongly recommend getting
an oscilliscope. (...)
25 Aug
25 Aug
3:48 p.m.
I just realized something, about the flashing LEDs..
They're not just flashing, I think the thing is +running+ or at least
counting. It's counting up through the entire 16-bit address space, and
displaying the position on the A15-A0 LEDs. Since A15 is the MSB, it
changes the least often, with A14 changing twice as often as A15, and A13
changing twice as often as A14 and so on down the line. Any bits below A13
or so are changing so quickly that vision can't perceive it.
So that is what I +think+ it's doing. As to why, I'd have little idea..
time to read more docs.
Are you sure it's counting up and not down?
AS I understnad it you have no memeory boards in the machine. The CPU (if
it's runnign at all) will be fetch instructions from a floating data bus.
I am assuming that it's an *080 or Z80 CPU/.
IF that floating bus is all 0's, then ti wil lbe fethcin NOPs and will be
counting up through memory, incrementign the pC after each NOP and
fetchign the next intruction form the next location.
But it's more likely (espeically grom what you have said) that it is
fetching FF's (all data lines are 1's). That's a RST 38h instruction.
Effectively iy dfoes a clal to lcation 0038 hex. Of course when it gts
there it will fetch another RST 38h from location 0038h, and carry on
doing the same thing. But it will also push the return address (when it is
fetcvhing a RST 38h from 0038h, this will mean it will write 39 00 to
memory) onto the stack. The stack builds downwards, so the address bus will
effectively alternate between 0038h (to fetch the isntruction) and a
downwards count (as it pushes the return address onto the stack). This
was actually a test ofn the TRS80 M1. You pulled the BASIC ROMs (causign
the CPU to read FF's from the data bus) and of course all memeory,
including the video RAM was fileld with 39 00 patters. Thad displayed as
'9 at 9@9 at ...' If you get that on the display it meant that the CPU was
running, the video circuitry was doing soemthing ,and so on.
-tony
6:49 p.m.
On 2014-Aug-24, at 8:56 AM, drlegendre . wrote:
Then I caught a slight whiff of "that"
smell, and switched-off, to hunt
On 2014-Aug-24, at 2:50 PM, drlegendre . wrote:
Anyway, it was getting very late, and I'd been at
it for over eight hours.
I'd accidentally swapped the +18 & -18 lines, and that was causing the
excessive current & heat.
The 8080 uses +12 & -5, both of which are derived from the +/-18 lines through
discrete zener-diode-&-series-resistor regulators.
Those regulator components may have been the source of the burning smell.
Hopefully the forward-biased zeners clamped the bad voltages and saved the 8080, but you
should ensure that those regulator components are within spec and still functioning
properly. If the regulator components got as far as burning enough to smell them, it may
be a good idea to replace them.
7:58 p.m.
On 08/25/2014 03:49 PM, Brent Hilpert wrote:
Hopefully the forward-biased zeners clamped the bad
voltages and
saved the 8080, but you should ensure that those regulator components
are within spec and still functioning properly. If the regulator
components got as far as burning enough to smell them, it may be a
good idea to replace them.
I'd replace all of the linear regulators anyway. The 8800 run some of
them very hot--it particular, the 4K DRAM boards had to have shunt
resistors across the 7805s too keep them at some sort of sane
temperature. Heat+age+semiconductors can make for a bitter cocktail.
--Chuck
8:57 p.m.
See this one I knew, so yes, I did check the zener regs, and yes, they are
just fine.. as is the 7805.
Nods on the 7805s running hot on this machine. Might be a nice place to
install a modern part with higher current handling, and a bit more heat
sink as well.
Whatever was getting po'd by my little polarity 'oops' was on the D/C
board.. and so far, I can't find anything that obviously went wrong. I did
note that the 7490 counter was running +uncomfortably+ hot in general, so I
dropped-in another NOS part.
FWIW, all of this is done on a variac.. so nothing runs at full AC line
unless needed, and nothing needs to fail in a spectacular way. I hate
electronic fires, they reek and they're unnecessary.
On Mon, Aug 25, 2014 at 5:49 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-24, at 8:56 AM, drlegendre . wrote:
Then I caught a slight whiff of "that"
smell, and switched-off, to hunt
On 2014-Aug-24, at 2:50 PM, drlegendre . wrote:
Anyway, it was getting very late, and I'd
been at it for over eight
hours.
I'd accidentally swapped the +18 & -18
lines, and that was causing the
excessive current & heat.
The 8080 uses +12 & -5, both of which are derived from the +/-18 lines
through discrete zener-diode-&-series-resistor regulators.
Those regulator components may have been the source of the burning smell.
Hopefully the forward-biased zeners clamped the bad voltages and saved the
8080, but you should ensure that those regulator components are within spec
and still functioning properly. If the regulator components got as far as
burning enough to smell them, it may be a good idea to replace them.
9:44 p.m.
On 08/25/2014 05:57 PM, drlegendre . wrote:
See this one I knew, so yes, I did check the zener
regs, and yes, they are
just fine.. as is the 7805.
Nods on the 7805s running hot on this machine. Might be a nice place to
install a modern part with higher current handling, and a bit more heat
sink as well.
You can't beat a switching regulator for this kind of thing--only
requires a couple of (small) external components--and I believe that you
can get pre-assembled modules that are a pin-for-pin substitute for a
78xx. Why heat things up?
--Chuck
12:55 a.m.
On 8/25/14, Chuck Guzis <cclist at sydex.com> wrote:
Sometimes, you don't even need additional components. For example,
Traco's TSR-1 is a completely standalone unit (I think Recom is
another common brand, these are probably familiar to most here), and
as you say, intended as a dropin replacement for linear regs. Albeit
at a significant multiple of the cost...
Nods on the
7805s running hot on this machine. Might be a nice place to
install a modern part with higher current handling, and a bit more heat
sink as well.
You can't beat a switching regulator for this kind of thing--only
requires a couple of (small) external components--and I believe that you
can get pre-assembled modules that are a pin-for-pin substitute for a
78xx. Why heat things up?
11:33 a.m.
So get this.. something didn't ring right when I replaced that 7490 chip -
I didn't recall that number from the BOM. Turns out I was right - some Mc
Bozo had put a 7490 in the hole where a 7473 should have been.
Not only does it no longer heat up, but the machine suddenly began showing
hints of genuine sanity! I was able to step up & down through memory, stop
/ start the CPU, etc. But there are still big issues, the machine is quite
erratic - and for some reason, it's sanity is sensitive to the position of
the A0-A15 switches. Set just one or two many 'on' and things go totally
wacko.. bunch of blinking lights, no control response, etc.
And the D0-D7 LEDs are still permanently 'on'. It's certainly a result of
the previously-discussed power termination scheme, which I will stress
appears NOWHERE in the original drawings or BOMs. It's almost certain that
it's interfering, at least with the Data LEDs. What good is a data readout
that always says "FF"? (Yeah, maybe it's right twice a day or something,
heh).
Termination has to go. I'll start by disconnecting the power. But if that
doesn't do it, then it's bye-bye for all of it.
On Mon, Aug 25, 2014 at 11:55 PM, Andrew Hoerter <amh at pobox.com> wrote:
On 8/25/14, Chuck Guzis <cclist at sydex.com>
wrote:
Sometimes, you don't even need additional components. For example,
Traco's TSR-1 is a completely standalone unit (I think Recom is
another common brand, these are probably familiar to most here), and
as you say, intended as a dropin replacement for linear regs. Albeit
at a significant multiple of the cost...
Nods on
the 7805s running hot on this machine. Might be a nice place to
install a modern part with higher current handling, and a bit more heat
sink as well.
You can't beat a switching regulator for this kind of thing--only
requires a couple of (small) external components--and I believe that you
can get pre-assembled modules that are a pin-for-pin substitute for a
78xx. Why heat things up?
2 p.m.
On Tue, Aug 26, 2014 at 9:33 AM, drlegendre . <drlegendre at gmail.com> wrote:
Termination has to go. I'll start by disconnecting
the power. But if that
doesn't do it, then it's bye-bye for all of it.
In private email I advised against, but I think it is worth trying
just disconnecting the termination power, and if that isn't enough,
perhaps try disconnecting the termination from just one of the data
lines to see if that results in different behavior for the
corresponding LED.
Maybe someone more familiar with the actual Altair boards can comment
as to whether they have inadequate drivers for bus termination? It
seems unlikely to me since the intended the user to be able to chain a
bunch of their four-slot backplanes and have a fair number of cards,
but it's possible that they cut corners or didn't think it through.
3:15 p.m.
On 2014-Aug-26, at 11:00 AM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 9:33 AM, drlegendre .
<drlegendre at gmail.com> wrote:
I've been looking at (a bad copy) of the Altair schematics over the course of this
thread.
A few points:
- The front panel data LEDS monitor the DI bus lines (not the DO bus), with no
latches involved.
- The Altair CPU card has 1K pull-ups on the DI bus.
- The Altair front panel does not manipulate memory or the DI or DO bus directly.
Instead, the memory examination facility functions by force-feeding the 8080 JMP
instructions to set the PC address for examine,
and NOP instructions to increment the PC address for examine-next.
It circumvents the DI bus by going directly to a 'sub-bus' around the data pins
of the 8080 to to do this force-feed.
The 8080 then sets the address onto the bus and memory is expected to respond
with data on the DI bus.
- It appears the system worked by leaving MEMR asserted when idle, so an
addressed memory board would be enabled when idle and putting data on the DI bus
to be observed via the LEDs.
Prior to this point in the thread dr indicated he did not have a memory board installed,
hence my question as to whether he now does.
If there is no memory board present, or if the memory board is not responding or
addressed, I (don't see) any reason to expect the data LEDs to be anything other than
ON. There still would be nothing to drive the DI lines low.
If the DI lines are sitting at ~ 1/2 Vcc as dr earlier indicated then I don't see the
termination as being a problem at this point, based on what has been said in the thread so
far.
If all dr has at this time is a 64K mem board(correct me if I'm not recalling that
correctly), then it could be (nearly) time to sort out the bank addressing on that board
(it probably has such) to ensure it will be addressed as the first bank and install it.
It might be preferable, however, to sort out the flakiness which dr referred to and ensure
the rest of the front panel operations are correct first.
Another point to note is the STOP/RUN switch is center-off/momentary-up/momentary-down
(not set-position up/down) controlling a RUN/STOP flip-flop. The reset switch does not
reset the run-stop flip-flop, nor is it reset on power-up, so it appears to be always
necessary to explicitly halt the processor by pressing the RUN/STOP switch to STOP
(momentarily).
Performing front panel memory operations without the processor halted may result in (the
appearance of) flaky behaviour on the LEDs.
Termination has to go. I'll start by
disconnecting the power. But if that
doesn't do it, then it's bye-bye for all of it.
In private email I advised against, but I think it is worth trying
just disconnecting the termination power, and if that isn't enough,
perhaps try disconnecting the termination from just one of the data
lines to see if that results in different behavior for the
corresponding LED.
Maybe someone more familiar with the actual Altair boards can comment
as to whether they have inadequate drivers for bus termination? It
seems unlikely to me since the intended the user to be able to chain a
bunch of their four-slot backplanes and have a fair number of cards,
but it's possible that they cut corners or didn't think it through.
2:10 p.m.
On 2014-Aug-26, at 8:33 AM, drlegendre . wrote:
So get this.. something didn't ring right when I
replaced that 7490 chip -
I didn't recall that number from the BOM. Turns out I was right - some Mc
Bozo had put a 7490 in the hole where a 7473 should have been.
Not only does it no longer heat up, but the machine suddenly began showing
hints of genuine sanity! I was able to step up & down through memory,
Do you mean to say you have a memory board installed, or just that the address lights are
at times stable and will increment-by-one when examine-next is pressed?
stop / start the CPU, etc. But there are still big
issues, the machine is quite
erratic - and for some reason, it's sanity is sensitive to the position of
the A0-A15 switches. Set just one or two many 'on' and things go totally
wacko.. bunch of blinking lights, no control response, etc.
And the D0-D7 LEDs are still permanently 'on'. It's certainly a result of
the previously-discussed power termination scheme, which I will stress
appears NOWHERE in the original drawings or BOMs. It's almost certain that
it's interfering, at least with the Data LEDs. What good is a data readout
that always says "FF"? (Yeah, maybe it's right twice a day or something,
heh).
Termination has to go. I'll start by disconnecting the power. But if that
doesn't do it, then it's bye-bye for all of it.
2:59 p.m.
On Tue, Aug 26, 2014 at 1:10 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
Do you mean to say you have a memory board installed, or just that the
address lights are at times stable and will increment-by-one when
examine-next is pressed?
Both, actually. All I have for memory is this 64K DRAM card, and I've been
experimenting with it both in and out of the system. But since the data
LEDs are always solid on, I have no way of telling whether or not I can
actually deposit or examine a location.
Next I'll pull the power for the term. stuff and see how it acts. It's a
tough spot to be in, too many variables and unknowns.. not sure what I can
or can't trust. So I just have to keep pecking away one bit at a time.
3:43 p.m.
On 2014-Aug-26, at 11:59 AM, drlegendre . wrote:
On Tue, Aug 26, 2014 at 1:10 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
.. this crossed over with a message I just sent which addresses some of this.
OK, what is the manufacturer/model of the DRAM board? Need to sort out the bank addressing
and the phantom function for the board, as well as the following issue.
A niggling question I have in the back of my head, is whether or not some/many memory
boards will work with the Altair front panel.
As stated in my previous message the front panel expects a memory board to be putting data
onto the DI bus to be observable on the LEDs when idle, the front panel does not latch the
data from a last memory cycle.
I suspect many memory boards don't do this, they may only put (strobe) data onto the
bus during the active portion of a memory cycle. The bus lines would then revert to the
high state and all you would see is ON LEDs.
Yes, arguably it's too bad you don't have a small static-RAM board as they tend to
be electronically simpler.
On the other hand such boards are also earlier and may be less reliable than a late model
DRAM board.
Do you mean to say you have a memory board
installed, or just that the
address lights are at times stable and will increment-by-one when
examine-next is pressed?
Both, actually. All I have for memory is this 64K DRAM card, and I've been
experimenting with it both in and out of the system. But since the data
LEDs are always solid on, I have no way of telling whether or not I can
actually deposit or examine a location.
Next I'll pull the power for the term. stuff and see how it acts. It's a
tough spot to be in, too many variables and unknowns.. not sure what I can
or can't trust. So I just have to keep pecking away one bit at a time.
4:12 p.m.
On Tue, Aug 26, 2014 at 1:43 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
A niggling question I have in the back of my head, is
whether or not some/many memory boards will work with the Altair front panel.
As stated in my previous message the front panel expects a memory board to be putting
data onto the DI bus to be observable on the LEDs when idle, the front panel does not
latch the data from a last memory cycle.
I suspect many memory boards don't do this, they may only put (strobe) data onto the
bus during the active portion of a memory cycle. The bus lines would then revert to the
high state and all you would see is ON LEDs.
I'm not terribly familiar with the details of the S-100 bus, and not
at all with the Altair, so please excuse my ignorance, but surely even
a static RAM board won't drive the bus for any significant length of
time after the bus read cycle is over. This suggests that for the
front panel without data latches to be able to examine memory, the
front panel (or something related to it) would have to keep the bus
read cycle active indefinitely, perhaps by driving a ready line false.
I would think that even a DRAM board would have to hold the read data
on the bus as long as the bus read cycle hasn't terminated, because it
has no other way to know when the bus master has actually accepted the
data.
5:38 p.m.
On 2014-Aug-26, at 1:12 PM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 1:43 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
I'm just in the process of examining docs and several mem board schematics in relation
to this issue and the Altair.
I've worked on a few S100 machines and some variety of S100 boards for hardware level
repairs.
We have to keep in mind that the first Altair was something of a seat-of-the-pants design,
so things don't always work as one might expect or hope
(witness the forced-instruction mem-examine technique).
For purposes at this point, there are 3 primary control signals involved with a mem read:
- address lines of course.
- MEMR or SMEMR: an indication from the bus master (processor board) of a memory read
cycle.
MEMR is a *latched* status sig from the 8080.
- DBIN or PDBIN: a strobe from the bus master to a bus slave (e.g. mem board) to
put data on the data input bus.
DBIN is a buffered sig right out of the 8080.
The Altair 4K mem board schematic indicates it puts data on the bus when the board is
addressed and MEMR asserted. It appears to ignore DBIN.
A niggling question I have in the back of my
head, is whether or not some/many memory boards will work with the Altair front panel.
As stated in my previous message the front panel expects a memory board to be putting
data onto the DI bus to be observable on the LEDs when idle, the front panel does not
latch the data from a last memory cycle.
I suspect many memory boards don't do this, they may only put (strobe) data onto the
bus during the active portion of a memory cycle. The bus lines would then revert to the
high state and all you would see is ON LEDs.
I'm not terribly familiar with the details of the S-100 bus, and not
at all with the Altair, so please excuse my ignorance, but surely even
a static RAM board won't drive the bus for any significant length of
time after the bus read cycle is over. This suggests that for the
front panel without data latches to be able to examine memory, the
front panel (or something related to it) would have to keep the bus
read cycle active indefinitely, perhaps by driving a ready line false.
I would think that even a DRAM board would have to hold the read data
on the bus as long as the bus read cycle hasn't terminated, because it
has no other way to know when the bus master has actually accepted the
data. From what I've been able to discern so far from the
8080 datasheet, DBIN is a pulsed signal, I haven't seen anywhere that the proc would
leave it asserted.
The front panel seems to rely on:
- the proc board leaving the address asserted on the bus,
- AND the MEMR latch on the proc board to have left MEMR asserted on the bus (dr
indicated the MEMR LED was ON on the front panel)
- AND the mem board to be ignoring DBIN
Depending on the semantics one wishes to apply, rather than having something extend the
mem cycle as you suggest, it appears the front panel is relying on a 'degenerate'
mem board design that ignores DBIN. From one perspective ignoring it doesn't matter,
as MEMR will be de-asserted when the proc starts another type of cycle.
(Of course calling it degenerate is hindsight, as it was was the earliest S100 design.)
Other mem board schematics that I've examined so far show the data from the boards to
be additionally mediated by DBIN, even a simple 70's 8K Godbout SRAM board, suggesting
they wouldn't work with the Altair front panel.
Or my understanding of DBIN is off or I've missed something in perusing the docs.
dr could measure the state of DBIN to see if it's asserted when idle, as opposed to
being just pulsed.
DBIN doesn't seem to have a state LED on the front panel (with does suggest it is just
pulsed).
It would be interesting to hear from someone else with an original-rev Altair and what mem
boards they use.
6:14 p.m.
On Tue, Aug 26, 2014 at 3:38 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
The Altair 4K mem board schematic indicates it puts
data on the bus when the board is addressed and MEMR asserted. It appears to ignore DBIN.
Is that schematic online? My cursory search turned up only a copy of
the manual without schematic.
Depending on the semantics one wishes to apply, rather
than having something extend the mem cycle as you suggest, it appears the front panel is
relying on a 'degenerate' mem board design that ignores DBIN.
Interesting.
(Of course calling it degenerate is hindsight, as it
was was the earliest S100 design.)
[stated earlier:]
We have to keep in mind that the first Altair was
something of a seat-of-the-pants design,
Of course. Having something that worked at all was quite an
accomplishment at that time. It's not surprising that it wasn't as
elegant as we might hope for with the benefit of hindsight. It also
had to be as inexpensive as possible, so if there was a kludge to get
the data bus for the front panel stable without adding a latch (and
perhaps even by *omitting* a gate that one might otherwise design in),
that would undoubtedly have been viewed quite favorably by the
designers.
Thanks for posting your analysis.
7:52 p.m.
On 2014-Aug-26, at 3:14 PM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 3:38 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
I've been using the "Schematics accompanying Theory Of Operation Manual"
from Dunfield's site:
http://www.classiccmp.org/dunfield/altair/altair6.htm
http://www.classiccmp.org/dunfield/altair/d/88schema.pdf
The CPU / 1K mem / front panel / power supply are all in there.
(I was mistaken, it's the 1K board not 4K.)
While the title suggests it might be simplified schematics, it doesn't appear to be
so, they seem to be complete and as fully detailed as could be expected, perhaps just
presented in some different manner or order than whatever the 'masters' may have
been.
It appears we may be rediscovering what was probably a commonly known issue amongst Altair
owners in 1977.
If this pans out as it appears, one possibility for dr may be to modify a mem board to
ignore DBIN, but I'm getting a little ahead of things.
The Altair 4K mem board schematic indicates it
puts data on the bus when the board is addressed and MEMR asserted. It appears to ignore
DBIN.
Is that schematic online? My cursory search turned up only a copy of
the manual without schematic.
8:43 p.m.
On 2014-Aug-26, at 3:14 PM, Eric Smith wrote:
Is that schematic online? My cursory search turned up
only a copy of
the manual without schematic.
Grant Stockly's version provides some degree of improvement:
http://www.altairkit.com/manuals.html
http://www.altairkit.com/manuals/MITS/Schematics-03-Beta%201.pdf
10:43 p.m.
Sorry, wasn't following this especially closely. I have clean
schematics of the Altair 4K brd.
Who would like them?
Steve
On 8/26/2014 3:14 PM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 3:38 PM, Brent
Hilpert<hilpert at cs.ubc.ca> wrote:
The Altair 4K mem board schematic indicates it
puts data on the bus when the board is addressed and MEMR asserted. It appears to ignore
DBIN.
Is that schematic online? My cursory search turned up only a copy of
the manual without schematic.
Depending on the semantics one wishes to apply,
rather than having something extend the mem cycle as you suggest, it appears the front
panel is relying on a 'degenerate' mem board design that ignores DBIN.
Interesting.
(Of course calling it degenerate is hindsight, as
it was was the earliest S100 design.)
[stated earlier:]
We have to keep in mind that the first Altair was
something of a seat-of-the-pants design,
Of course. Having something that worked at all was quite an
accomplishment at that time. It's not surprising that it wasn't as
elegant as we might hope for with the benefit of hindsight. It also
had to be as inexpensive as possible, so if there was a kludge to get
the data bus for the front panel stable without adding a latch (and
perhaps even by *omitting* a gate that one might otherwise design in),
that would undoubtedly have been viewed quite favorably by the
designers.
Thanks for posting your analysis.
11:22 p.m.
I'm just catching up on all of the new info.. thank you all very much for
the support!
I will accept ANY and ALL relevant data that I don't already have on the
Altair 8800. I have uploaded my entire cache of Altair 8800 data to my
shell, and it can be viewed / downloaded here:
http://nerp.net/~legendre/altair/
If anything new shows up, I'll add it. TYIA - now back to the machinery..
I'm going to pull the power for the term. network and see if that yields.
But one question for those who might know - how the HECK should the front
panel behave when NO cards are installed? Should it be able to walk the
(empty) memory space, and read it out to the D0-D7 display (which would be
all zeros).
I don't know enough about this to understand how much and or what role(s)
the CPU/RAM cards play in the front panel operations - other than the
blatantly obvious, such as r or w actual memory locations, and so on.
On Tue, Aug 26, 2014 at 9:43 PM, steve shumaker <shumaker at att.net> wrote:
Sorry, wasn't following this especially closely.
I have clean schematics
of the Altair 4K brd.
Who would like them?
Steve
On 8/26/2014 3:14 PM, Eric Smith wrote:
On Tue, Aug 26, 2014 at 3:38 PM, Brent
Hilpert<hilpert at cs.ubc.ca> wrote:
The Altair 4K mem board schematic indicates it
puts data on the bus when
the board is addressed and MEMR asserted. It appears to ignore DBIN.
Is that schematic online? My cursory search turned up only a copy of
the manual without schematic.
Depending on the semantics one wishes to apply,
rather than having
something extend the mem cycle as you suggest, it appears the front panel
is relying on a 'degenerate' mem board design that ignores DBIN.
Interesting.
(Of course calling it degenerate is hindsight, as
it was was the
earliest S100 design.)
[stated earlier:]
We have to keep in mind that the first Altair was
something of a
seat-of-the-pants design,
Of course. Having something that worked at all was quite an
accomplishment at that time. It's not surprising that it wasn't as
elegant as we might hope for with the benefit of hindsight. It also
had to be as inexpensive as possible, so if there was a kludge to get
the data bus for the front panel stable without adding a latch (and
perhaps even by *omitting* a gate that one might otherwise design in),
that would undoubtedly have been viewed quite favorably by the
designers.
Thanks for posting your analysis.
27 Aug
27 Aug
12:58 a.m.
On 2014-Aug-26, at 8:22 PM, drlegendre . wrote:
I'm just catching up on all of the new info..
thank you all very much for
the support!
I will accept ANY and ALL relevant data that I don't already have on the
Altair 8800. I have uploaded my entire cache of Altair 8800 data to my
shell, and it can be viewed / downloaded here:
http://nerp.net/~legendre/altair/
I'm getting refusal on permissions there.
If anything new shows up, I'll add it. TYIA - now
back to the machinery..
I'm going to pull the power for the term. network and see if that yields.
But one question for those who might know - how the HECK should the front
panel behave when NO cards are installed? Should it be able to walk the
(empty) memory space, and read it out to the D0-D7 display (which would be
all zeros).
I don't know enough about this to understand how
much and or what role(s)
the CPU/RAM cards play in the front panel operations - other than the
blatantly obvious, such as r or w actual memory locations, and so on.
This is all addressed in the previous messages, but in short:
- the CPU card is required to be able to 'set' the address LEDs,
- with no memory board you can expect the D0-D7 LEDS to be all 1s (on), not 0s.
1:58 p.m.
On Tue, Aug 26, 2014 at 11:58 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
This is all addressed in the previous messages, but in short:
- the CPU card is required to be able to 'set' the address LEDs,
- with no memory board you can expect the D0-D7 LEDS to be all 1s
(on), not 0s.
Thanks for condensing that info, very helpful.
So in that case, the DRAM card is clearly not doing what one would expect -
the data LEDs are perma-lit irrespective of DRAM presence.
I have also nailed-down some of the crazy behavior wrt the address
switches.. it all seems to be related to A5. If A5 is on, I can stop/start
the cpu and perform semi-sane stepping operations with ex/ex next. But set
A5 off, and the machine goes out of control.. and so far, it seems that A5
and only A5 has this odd control effect. This smells like a good hint, so
next step is to check my address line wiring work, and A5 in specific, as
well as whatever ICs / components play a role in that signal chain,
FYI, I have tried two different CPUs (well, actually three) and also a
second 8212 on the CPU board. These changes had no effect on behavior that
I could notice.
Another possible clue - the prot/unprot function is totally dead. I don't
know how the prot scheme / circuit works, but it does seem to signal a lack
of communication & control between the DRAM and the CPU/front panel. Any
info on how that circuit works would be helpful - meantime, I'll see what I
can figure out on my own from the schematic.
Thanks again for the assistance, I'm learning this stuff as we go along.
4:45 p.m.
On 2014-Aug-27, at 10:58 AM, drlegendre . wrote:
On Tue, Aug 26, 2014 at 11:58 PM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
--- DBIN:
(eric:) Scratch all my conjecturing about DBIN and inadequate memory boards.
Found a more complete 8080 processor manual with better timing diagrams (at bitsavers of
course), and going through the machine cycle in more detail it seems the front panel is
halting the processor part way into the first machine cycle of an instruction, at which
point DBIN should be asserted, and should remain asserted through the idle / front panel
display period. This makes more sense inasmuch as the alternative would have left very few
memory boards to work with the front panel. Was led down a wrong path by the distinction
in use/nonuse of DBIN by different memory boards.
dr: you might measure the state of the bus PDBIN line while in the halt/stop state and
let us know.
--- Memory board :
So back to your memory board, the configuration of that board should be confirmed for
operation as required in your system.
It could be helpful to know which board you have there.
In addition to the typical address-range enable, S100 memory boards could commonly have
two additional enabling schemes:
- Bank enable/disable - allowed memory sizes greater than 64K by allowing memory boards
to be enabled/disabled by writing to a dedicated I/O port.
Your board/bank needs to be enabled as bank 0 or bank operation disabled.
- Phantom disable - allowed a memory board to be disabled at reset and later enabled
under program control,
to allow initial overlaying by boot ROMs.
The phantom function should be disabled (the board should ignore phantom, so its always
enabled)
--- Mem protect :
Most of the mem protect facility is an optional function of memory board(s). The front
panel just buffers the state of the prot/unprot switch out onto the bus.
--- A5 :
It makes sense that the problem occurs when A5 is off, if by off you mean down. When it
is up, the switch is open and shouldn't affect the bus, when down it connects a 7405
output to the proc data line. It sounds like it could be a bad 7405 on the front panel.
This is all addressed in the previous messages,
but in short:
- the CPU card is required to be able to 'set' the address LEDs,
- with no memory board you can expect the D0-D7 LEDS to be all 1s
(on), not 0s.
Thanks for condensing that info, very helpful.
So in that case, the DRAM card is clearly not doing what one would expect -
the data LEDs are perma-lit irrespective of DRAM presence.
I have also nailed-down some of the crazy behavior wrt the address
switches.. it all seems to be related to A5. If A5 is on, I can stop/start
the cpu and perform semi-sane stepping operations with ex/ex next. But set
A5 off, and the machine goes out of control.. and so far, it seems that A5
and only A5 has this odd control effect. This smells like a good hint, so
next step is to check my address line wiring work, and A5 in specific, as
well as whatever ICs / components play a role in that signal chain,
FYI, I have tried two different CPUs (well, actually three) and also a
second 8212 on the CPU board. These changes had no effect on behavior that
I could notice.
Another possible clue - the prot/unprot function is totally dead. I don't
know how the prot scheme / circuit works, but it does seem to signal a lack
of communication & control between the DRAM and the CPU/front panel. Any
info on how that circuit works would be helpful - meantime, I'll see what I
can figure out on my own from the schematic.
Thanks again for the assistance, I'm learning this stuff as we go along.
6:49 p.m.
That's what I was thinking.. so I set up a test for 7405's on my little
proto-trainer that I found & rebuilt some time ago.
Guess what? Every 7405 on the panel is screwed.. 2 functional gates out of
30.. I'm getting very close to shotgunning the entire IC complement on the
panel.
It's all socketed already, so it's not that tedious of a task - but a large
portion of my stock is used/pulls and not necessarily known good. And
naturally, I have ZERO 7405s in my stocks. Despite not really being 'into'
digital stuff, I did plan for the day, so have assembled a small collection
of ICs and related parts. Out of the hundred or two ICs, not a single 7405.
So, who's got an excess of 7405s? I need 5 to fix this board, and I'd like
another several for spares. Call it 8-10 pcs for a nice round number.
For swaps, I have quite a few: 7400, 02, 08, 47, 73, 90, 93, 123 and 165 to
trade, as well as smaller quantities of about a dozen other 74XX/X series.
Also a number of Sprague UHP 481 & 495 HV drivers, and a couple of MM5314N
display drivers, as used in Nixie tube clocks - the latter sell for
$20-25/ea, IIRC.
Please let me know, I'd love to do a trade/trade-cash deal with a member in
preference to eBay! But either way, I gotta get some on the way ASAP.
Thanks!
On Wed, Aug 27, 2014 at 3:45 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-27, at 10:58 AM, drlegendre . wrote:
expect -
On Tue, Aug 26, 2014 at 11:58 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
This is
all addressed in the previous messages, but in short:
- the CPU card is required to be able to 'set' the address LEDs,
- with no memory board you can expect the D0-D7 LEDS to be all 1s
(on), not 0s.
Thanks for condensing that info, very helpful.
So in that case, the DRAM card is clearly not doing what one would the data LEDs are perma-lit irrespective of DRAM
presence.
I have also nailed-down some of the crazy behavior wrt the address
switches.. it all seems to be related to A5. If A5 is on, I can
stop/start
the cpu and perform semi-sane stepping operations
with ex/ex next. But
set
A5 off, and the machine goes out of control.. and
so far, it seems that
A5
and only A5 has this odd control effect. This
smells like a good hint, so
next step is to check my address line wiring work, and A5 in specific, as
well as whatever ICs / components play a role in that signal chain,
FYI, I have tried two different CPUs (well, actually three) and also a
second 8212 on the CPU board. These changes had no effect on behavior
that
I could notice.
Another possible clue - the prot/unprot function is totally dead. I don't
know how the prot scheme / circuit works, but it does seem to signal a
lack
of communication & control between the DRAM
and the CPU/front panel. Any
info on how that circuit works would be helpful - meantime, I'll see
what I
can figure out on my own from the schematic.
Thanks again for the assistance, I'm learning this stuff as we go along.
--- DBIN:
(eric:) Scratch all my conjecturing about DBIN and inadequate memory
boards.
Found a more complete 8080 processor manual with better timing diagrams
(at bitsavers of course), and going through the machine cycle in more
detail it seems the front panel is halting the processor part way into the
first machine cycle of an instruction, at which point DBIN should be
asserted, and should remain asserted through the idle / front panel display
period. This makes more sense inasmuch as the alternative would have left
very few memory boards to work with the front panel. Was led down a wrong
path by the distinction in use/nonuse of DBIN by different memory boards.
dr: you might measure the state of the bus PDBIN line while in the
halt/stop state and let us know.
--- Memory board :
So back to your memory board, the configuration of that board should be
confirmed for operation as required in your system.
It could be helpful to know which board you have there.
In addition to the typical address-range enable, S100 memory boards could
commonly have two additional enabling schemes:
- Bank enable/disable - allowed memory sizes greater than 64K by
allowing memory boards to be enabled/disabled by writing to a dedicated I/O
port.
Your board/bank needs to be enabled as bank 0 or bank operation
disabled.
- Phantom disable - allowed a memory board to be disabled at reset
and later enabled under program control,
to allow initial overlaying by boot ROMs.
The phantom function should be disabled (the board should ignore
phantom, so its always enabled)
--- Mem protect :
Most of the mem protect facility is an optional function of memory
board(s). The front panel just buffers the state of the prot/unprot switch
out onto the bus.
--- A5 :
It makes sense that the problem occurs when A5 is off, if by off you mean
down. When it is up, the switch is open and shouldn't affect the bus, when
down it connects a 7405 output to the proc data line. It sounds like it
could be a bad 7405 on the front panel.
7:06 p.m.
Regarding trade deals, I should really clarify a previous comment. When I
stated that many of my chips may be used, or potential pulls, I was mainly
considering the wisdom of shotguning the board with them and expecting it
to insta-cure all IC issues.
In fact, many parts in the stock are obviously +new+ and well cared for,
few if any at all are solder-pulls, and I have no overt reason to suspect
that they are a bad group. I've sold & traded a number over the last year
or two, without any comebacks - except on 5314s - which were _not_ properly
stored. The rest came to me in tubes or on foam in drawers, but they are of
unknown provenance. Most all are well-known brands - TI, NS, Motorboata,
Sprague, etc.
And moreover, I need to stress that I stand behind +everything+ that passes
through my hands, and have the eBay and ar15.com feedback to back that up.
Speaking of ar15.com, it is a superb place to buy & sell items, and not
just gun-related stuff.
They have a truly excellent feedback policy: If you get one un-resolved
negative feedback, you're BANNED for LIFE.. PERIOD - and they do it to
slacking newbs all the time.. no muss, no fuss. Talk about
confidence-inspiring, heh!
On Wed, Aug 27, 2014 at 5:49 PM, drlegendre . <drlegendre at gmail.com> wrote:
That's what I was thinking.. so I set up a test
for 7405's on my little
proto-trainer that I found & rebuilt some time ago.
Guess what? Every 7405 on the panel is screwed.. 2 functional gates out of
30.. I'm getting very close to shotgunning the entire IC complement on the
panel.
It's all socketed already, so it's not that tedious of a task - but a
large portion of my stock is used/pulls and not necessarily known good. And
naturally, I have ZERO 7405s in my stocks. Despite not really being 'into'
digital stuff, I did plan for the day, so have assembled a small collection
of ICs and related parts. Out of the hundred or two ICs, not a single 7405.
So, who's got an excess of 7405s? I need 5 to fix this board, and I'd like
another several for spares. Call it 8-10 pcs for a nice round number.
For swaps, I have quite a few: 7400, 02, 08, 47, 73, 90, 93, 123 and 165
to trade, as well as smaller quantities of about a dozen other 74XX/X
series. Also a number of Sprague UHP 481 & 495 HV drivers, and a couple of
MM5314N display drivers, as used in Nixie tube clocks - the latter sell for
$20-25/ea, IIRC.
Please let me know, I'd love to do a trade/trade-cash deal with a member
in preference to eBay! But either way, I gotta get some on the way ASAP.
Thanks!
On Wed, Aug 27, 2014 at 3:45 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Aug-27, at 10:58 AM, drlegendre . wrote:
expect -
On Tue, Aug 26, 2014 at 11:58 PM, Brent Hilpert
<hilpert at cs.ubc.ca>
wrote:
> This is all addressed in the previous
messages, but in short:
> - the CPU card is required to be able to 'set' the address LEDs,
> - with no memory board you can expect the D0-D7 LEDS to be all
1s
(on), not
0s.
Thanks for condensing that info, very helpful.
So in that case, the DRAM card is clearly not doing what one would the data LEDs are perma-lit irrespective of DRAM
presence.
I have also nailed-down some of the crazy behavior wrt the address
switches.. it all seems to be related to A5. If A5 is on, I can
stop/start
the cpu and perform semi-sane stepping operations
with ex/ex next. But
set
A5 off, and the machine goes out of control.. and
so far, it seems that
A5
and only A5 has this odd control effect. This
smells like a good hint,
so
next step is to check my address line wiring
work, and A5 in specific,
as
well as whatever ICs / components play a role in
that signal chain,
FYI, I have tried two different CPUs (well, actually three) and also a
second 8212 on the CPU board. These changes had no effect on behavior
that
I could notice.
Another possible clue - the prot/unprot function is totally dead. I
don't
know how the prot scheme / circuit works, but it
does seem to signal a
lack
of communication & control between the DRAM
and the CPU/front panel. Any
info on how that circuit works would be helpful - meantime, I'll see
what I
can figure out on my own from the schematic.
Thanks again for the assistance, I'm learning this stuff as we go along.
--- DBIN:
(eric:) Scratch all my conjecturing about DBIN and inadequate memory
boards.
Found a more complete 8080 processor manual with better timing diagrams
(at bitsavers of course), and going through the machine cycle in more
detail it seems the front panel is halting the processor part way into the
first machine cycle of an instruction, at which point DBIN should be
asserted, and should remain asserted through the idle / front panel display
period. This makes more sense inasmuch as the alternative would have left
very few memory boards to work with the front panel. Was led down a wrong
path by the distinction in use/nonuse of DBIN by different memory boards.
dr: you might measure the state of the bus PDBIN line while in the
halt/stop state and let us know.
--- Memory board :
So back to your memory board, the configuration of that board should be
confirmed for operation as required in your system.
It could be helpful to know which board you have there.
In addition to the typical address-range enable, S100 memory boards could
commonly have two additional enabling schemes:
- Bank enable/disable - allowed memory sizes greater than 64K by
allowing memory boards to be enabled/disabled by writing to a dedicated I/O
port.
Your board/bank needs to be enabled as bank 0 or bank operation
disabled.
- Phantom disable - allowed a memory board to be disabled at
reset and later enabled under program control,
to allow initial overlaying by boot ROMs.
The phantom function should be disabled (the board should
ignore phantom, so its always enabled)
--- Mem protect :
Most of the mem protect facility is an optional function of memory
board(s). The front panel just buffers the state of the prot/unprot switch
out onto the bus.
--- A5 :
It makes sense that the problem occurs when A5 is off, if by off you
mean down. When it is up, the switch is open and shouldn't affect the bus,
when down it connects a 7405 output to the proc data line. It sounds like
it could be a bad 7405 on the front panel.
7:42 p.m.
On Wed, Aug 27, 2014 at 4:49 PM, drlegendre . <drlegendre at gmail.com> wrote:
So, who's got an excess of 7405s? I need 5 to fix
this board, and I'd like
another several for spares. Call it 8-10 pcs for a nice round number.
The 74LS06 would be a good substitute, and is much easier to find.
8:29 p.m.
On 08/27/2014 03:49 PM, drlegendre . wrote:
That's what I was thinking.. so I set up a test
for 7405's on my little
proto-trainer that I found & rebuilt some time ago.
Guess what? Every 7405 on the panel is screwed.. 2 functional gates out of
30.. I'm getting very close to shotgunning the entire IC complement on the
panel.
You might be better off using 7406s instead of 7405--better output
current rating.
As far as the 8800 front panel, be wary of the 74Lxx ICs--I seem to
recall that I once tried a straight 74LSxx substitution and it didn't
work. I don't recall why.
--Chuck
12:39 a.m.
On 2014-Aug-26, at 7:43 PM, steve shumaker wrote:
Sorry, wasn't following this especially closely.
I have clean schematics of the Altair 4K brd.
Who would like them?
There are reasonable schematics of the 1K board on the web, if you have the 4K board
schematics I would be interesting in seeing them to compare the aspects at issue with the
1K.
24 Aug
24 Aug
2:02 p.m.
On 2014-Aug-24, at 8:48 AM, drlegendre . wrote:
Well, they were /functionally missing/. So many little
parts all crammed
together, all alike, and no clear pin numbering in sight - I couldn't tell
whether or not the 330 was present until I pulled the board back out,
flipped it over and started counting. Then I found the bunk joint where #41
should be soldered..
As things moved along, I was able to measure the 470 to gnd, tho, so I knew
that much was there.
Now back to your original point, the one you felt I was missing..
Pin #41 had the 470 to gnd, but no 330 to VT+, so it was at a true logic
low, pulled down by the 470. This causes the 7404 output to go high,
turning off the LED. When I connected the 330 part, Pin 41 came up to
2.8VDC (about 1/2 of VT+) which I guess the 7404 sees as a high (?)
switching off the 7404 output and turning on the LED.
All good so far?
Sure
if so, then I don't understand why you were stressing that a typical TTL
chip would see a floating input ("undetermined") as a logic hi. Since all
of the bus pins in the D0-D7 series connected to the 7404s had either 2.8V
or 470 to gnd, none were just floating, were they? Or were you speaking of
some other lines left floating that I should be concerned about?
See what I mean?
In your earlier message you wrote:
>> - A number of lines are biased at +roughly+
1/2 VT+ by being placed at the
>> junction of a 330R and 470R -> Gnd resistor.
>>
>> And for some reason, all of the data lines - with the exception of D2 - are
>> in the latter category. They're biased at the 330 / 470 junctions. So my
>> current questions are..
>>
>> Why did they skip D2 of all things?
Apparently they didn't skip D2 and only one of the two resistors was 'functionally
missing'.
If they had skipped D2 then the observed behaviour (LED off) was at odds with what would
be expected (on).
The behaviour of the D2 line was at odds with the others, and with what would be expected
based on the description you provided.
The point was to focus on the D2 line and figure out why that was, which seems to have
been a good thing, as you found and fixed a fault there.
On Sun, Aug 24, 2014 at 3:52 AM, Brent Hilpert
<hilpert at cs.ubc.ca> wrote:
> On 2014-Aug-23, at 11:12 PM, drlegendre . wrote:
>> On Sat, Aug 23, 2014 at 11:57 PM, Brent Hilpert <hilpert at cs.ubc.ca>
> wrote:
>>
>>> No, you're missing the point.
>>>
>>> You said the D2 LED is OFF, which by your logic implies the 7404 input
> is
>>> LOW.
>>>
>>> But, as I've stated twice now, an undriven TTL input (which should be
> the
>>> state of the line without termination resistors) should be interpreted
> by
>>> the inverter as HIGH. Thence (as per your desc) the output of the
> inverter
>>> would be LOW and the D2 LED ON.
>>>
>>> This input behaviour is a characteristic of TTL logic at the electrical
>>> level. It may seem counter-intuitive but an open or unconnected input
> in a
>>> physical logic implementation is not inherently a logical low. Pulling
> TTL
>>> inputs high with resistors is not done for the sake of setting the
> input to
>>> a logic high, it's done for noise margin and speed issues.
>>>
>>> There is other stuff in the front panel connected to the DIn lines, but
> I
>>> don't think any of it would be driving the lines in the idle state, so
> all
>>> the data LEDs should be on with no boards plugged in. You might confirm
> the
>>> data switches are all in the same position and toggling them has no
>>> immediate effect on the LEDs.
>>>
>>>
>> Then I'm not sure what to say, because when I fixed the bunk connection
> in
>> the term. network (for pin 41 / D2) the LED came on just like the rest of
>> them.. shrug.
>
>
> Well, that's good. If the 470-ohm R to ground was intact and the 330 R to
> +5 had a bad connection that would explain the symptoms. Your earlier
> messages left the impression the D2 Rs were missing.
1:10 p.m.
If it were me (and it's not, so FWIW) I'd continue to work on this since
you seem to be making good progress, but I'd pick up some boards from
the N8VEM-S100 group instead of modifying (as opposed to repairing)
vintage gear.
Boards available and contact information is at:
http://n8vem-sbc.pbworks.com/w/page/35044530/PCB%20Inventory
Of course you have to source components and build them yourself but
that's a lot of fun.
Todd
* drlegendre . <drlegendre at gmail.com> [140823 20:20]:
Ok good call gents, thanks for pointing this out..
yes, the LM309 only
provides power for the termination network (marked VT+). Here's what I see
in the network:
- Some lines have no connection to the network at all
- Most lines have a 330R pull-up connected to the VT+
- A number of lines are biased at +roughly+ 1/2 VT+ by being placed at the
junction of a 330R and 470R -> Gnd resistor.
And for some reason, all of the data lines - with the exception of D2 - are
in the latter category. They're biased at the 330 / 470 junctions. So my
current questions are..
Why did they skip D2 of all things?
Will any of this have any effect on the operation of the machine, once I
plug in an original CPU board & static RAM board?
And lastly...
Does anyone have a 1K or 4K static RAM board for this, that I can beg, buy,
barter or steal off them? Howzabout an original mainboard, so I don't have
to whack this one to pieces.. which seems to throw up huge red flags in my
mind, as I'm loath to modify or damage any kind of vintage parts!
2:25 p.m.
I don't know if it's been mentioned before, but Herb Johnson has a nice
retrospective on S-100 bus termination here:
http://www.retrotechnology.com/herbs_stuff/s_term.html
Some may find this useful.
--Chuck
4:06 p.m.
I began asking this, as when I powered-up the boards
for first smoke test,
I noticed that all of the Data LEDs are on.. +except+ for D2. Investigation
found that all data lines (except D2) are sitting at 1/2 Vcc causing the
connected 7404 inverter outputs to go low, which turns on the LEDs (as the
other leg of the LEDs is tied to Vcc). So when the inverter output remains
high, both sides of the LED see Vcc and hence no current - inverters go
low, and they sink current and turn-on the LEDs.
This is quite a nroaml way to do it. A TTL output can sink a larger
current tahn it can source, so when driving LEDs it is noraml to lin kthe
LED from the otuput to Vcc so that the output has to sink current to turn
it on.
It was that D2 being off that drew my attention. And upon further reading,
I don't think +any+ of those data LEDs should be on, when no other boards
are installed.
I am not so sure. Since a TTL output can sink better than it can source
it is noraml to have termination which pulls the input to a logic 1
state. In which case all the LEDs should be on if there are not other
boards in the machine (and thus the only thing 'driving' the data lines
are the termiation resistors.
-tony
3616
days inactive
3621
days old
55 comments
13 participants
participants (13)
-
amh＠POBOX.COM -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
dkelvey＠hotmail.com -
drlegendre＠gmail.com -
ggs＠shiresoft.com -
hilpert＠cs.ubc.ca -
jws＠jwsss.com -
shumaker＠att.net -
spacewar＠gmail.com -
tsg＠bonedaddy.net -
wdonzelli＠gmail.com -
wh.sudbrink＠verizon.net