[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