[vcf-midatlantic] Altair cant jump
Herb Johnson
hjohnson at retrotechnology.info
Mon Jun 22 11:25:06 EDT 2020
NOtes to Jeff G:
0) add "[vcf-midatlantic]" to your subject line. It's email list etiquette.
1)
> Thanks Herb, its actually my intention that since I have the real deal, to
> get the experience of messing with it as someone may have back in the day.
> For the most part, I haven't used almost any test equipment other than a
> logic probe and multimeter so far.
If someone told me in 1978 they were using a meter and an LED to debug
their Altair, I'd tell them what I'm telling you now.
Time to break out the oscilloscope. How can you monitor real-time
execution of instructions and operation of digital logic *without an
oscilloscope*? You said you have a logic analyzer but "it's too heavy".
OK by me. Use an oscilloscope, to
monitor IC chip enables (so you know the chip is being addressed)
logic states of lines and IC pins
general operation of address and data lines.
In the course of doing so, you'll find all kinds of faults; as witness
your later reportage.
2) "if you want to look at the code, it's here..."
Use a cross assembler! Spare yourself some pain.
http://www.retrotechnology.com/restore/a85.html
http://www.retrotechnology.com/restore/uart_dump.txt
I disassembled your code so I could read it comfortably. The code looks
plausible. As you have said, you can read the UART data sheets and other
coding sources. I don't guarantee your code.
3) > This thing has certainly given me an honorary
> computer science degree, as every little error and attempt to cut a corner
> was thrown back at me.
This is, simply, how front panel binary programming and IC logic
debugging was done in the 1970's. It's not "computer science". You are
making a point this is tough mental work. Yeah. Go figure, when you have
to toggle in every byte of code and follow how it works. If this were a
C or BASIC program, you'd have to type every line and know how each line
works. Except you don't have to know ASCII codes when you type.
4)
> Hardware wise, on the serial board...
... you found many fatal problems, which you fixed. Right. This is not a
computer from Sears. Anything could have been done to it, in four
decades. So one has to inspect and test and repair to the COMPONENT
level. As for "jumpers and mods". The UART may or may not have
logic-inputs that need to be high or low, so see if those pins have
plausible logic levels or states.
At this point for you, the UART is king. Do everything you can, to be
assured the UART gets what it needs and can produce what it has to.
5)
> As of today, I eliminated the ram board being culprit with an DeRamp FDC+
> board doing ram duties.
Right. Swap boards and see if the problem follows the board or not. Swap
chips to see what that does - but beware that just messing with chips
and sockets finds and creates problems. And beware: some memory boards
are more tolerant than others of bus issues, or just speed of access.
YOu may need to test memory at some point. It's annoying when memory is
a problem.
6) Interrupts. Disable them. Keep them disabled.
7) coding errors. Glad you've caught them.
8)
> NOW, what did change, is that I've sat here and single stepped the entire
> thing, and found it works perfectly in doing so. A character I enter is
> being replied back no problem, which tells me serially everything's fine
> Yet if I run it, I'm just getting a solid stream of garbage, although
> interestingly, repetitive garbage.
Good! Good. you are narrowing down the conditions of failure and what
causes those conditions to change. Not "computer science", just
practical science. Hypothesis, test, review results, evaluate. Repeat
tests to verify conditions under test.
An oscilloscope, by the way, may tell you what your UART is producing.
Sweep slow enough to see a whole character on the sweep. Maybe that will
be informative.
Vary your programs. That may be informative.
init
loop check status of write
load A with "A" or "Z" or whatever
write that char
jump loop
init
loop check status of read
read a char
display on front panel (know how?)
loop
*Maybe*, you need to add delays in accessing your UART? Or wait states?
Hard to believe an 8080 may be too fast. But this is 1970's logic and
chips.
9)
> So my next thoughts are that the bus is ringing/noisy, or perhaps there's
> bad buffers on either the serial board or the CPU board, as it seems that
> reading ports 0/1 is flaky or having a timing issue, or the serial board
> itself has other issues.
9a) Good guess. Could be a bus termination problem. Might not.
http://www.retrotechnology.com/herbs_stuff/s_term.html
Oh - and use that oscilloscope? to look at your bus lines. see if they
*are* ringing or look funny.
Suggestion. Put a board at the FAR END of whatever backplane you have.
Memory or UART, may not be important. But put something there to keep
the backplane from acting like a ringing bell. There are of course,
S-100 terminator boards. But don't go nuts on that, yet.
By the way: bus lines WILL look odd, because sometimes they aren't being
"driven" and they may just look like TTL inputs and float around some
value between very low and very high (fractions of a volt and four volts
or so).
You'll learn a lot about tristate logic and TTL voltage levels in and
out, when you are done. That's not "computer science" but it is
"electrical engineering", 1970's style. It's a 1970's computer, whatdda
expect?
also: the MITS Altair design is less than bullet-proof. A 1970's company
that sold audio-oscillator kits, built their first computer, with
microprocessors only a few years old.
9b) Or... could be some "bad buffers" as you say. Chips go bad, sockets
go bad, pins get rusty. Did you look hard at the chips on the board?
http://www.retrotechnology.com/restore/ith_feb16_repairs.html#rust
Texas Instrument (TI) chips of the 70's and 80's, have a terrible
problem with "black rust". It would appear to be a TARNISH problem, the
pins turn black, sometimes brittle. This is not likely your problem, but
it might BECOME your problem later.
----------------------------
Seems to me, you are learning how to repair and diagnose and USE your
Altair. Taking notes, considering conditions, checking out problems.
Good work, good descriptions.
And to anyone else reading this: if you find this tedious, boring, or
just too OCD for you. Sorry, enjoy playing with your Raspberry Pi's.
regards, Herb Johnson
--
Herbert R. Johnson, New Jersey in the USA
http://www.retrotechnology.com OR .net
preserve, recover, restore 1970's computing
email: hjohnson AT retrotechnology DOT com
or try later herbjohnson AT retrotechnology DOT info
More information about the vcf-midatlantic
mailing list