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