Final assembly...

Discuss construction, troubleshooting, and operation of the Altair 8800c computer

Re: Final assembly...

Postby BillO » February 8th, 2021, 10:17 pm

Okay, the opera continues.

I found a flaky socket on the CPU card. The machine was showing some intermittent behavior. It would work fine for a couple of hours then .. not .. for a few more hours. During the trouble shooting I grabbed the 8212 whilst putting a scope probe elsewhere, then it worked fine. However, as soon as I let go the 8212, it would play the fool. It took an iteration or two before I caught on but eventually realized there was an issue with the 8212. Pushing it one way, it worked .. the other way it did not. So I replaced the socket. Now it works more reliably.

I'm not going to claim it's fully functional yet. But it's closer.

Stay tuned ..

(Does this sort of thing only happen to people that live out in the woods where every little part needs to be shipped in and handled by local hillbillies for the final delivery [read - painful process], or has everyone had these troubleshooting experiences? It also seems the trouble index is proportional to the square of the cost.)

(Oh, BTW, I am actually enjoying this. Really.)
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

Re: Final assembly...

Postby BillO » February 11th, 2021, 6:43 pm

After replacing the socket it has not lost its mind and has been running AMON ever since.

However, there is still something odd. With it just sitting there, every now and then (from a few dozen seconds to a few minutes apart) it registers a <CR>. Just like if you hit enter. A new line appears and a new prompt. If I put it in EN mode and leave it for a little while, it will exit EN mode and go back to the '>' prompt so it is actually receiving a <CR>.

Anyone have any idea whet could be causing this?
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

Re: Final assembly...

Postby AltairClone » February 12th, 2021, 7:14 pm

My guess is that the input polling loop is occasionally seeing the data available bit asserted and then reads in whatever is in the UART data register. Most often CR was the last character typed/received, so that becomes the spurious character. Type the letter “A”and let it sit there. Is the spurious character now an “A”?

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Final assembly...

Postby BillO » February 14th, 2021, 12:01 pm

Good guess!

I'm assuming that AMON does polling and not relying on interrupts?

Is there an assembly listing of AMON?

Edit: Found it!

So it looks like there are spurious "1"s on D0(in) from time to time (and possibly other data lines). That would cause AMON to think there was a new character available. Hmm, have to get the 4 channel scope off the shelf for some quality time together.
Last edited by BillO on February 14th, 2021, 12:26 pm, edited 1 time in total.
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

Re: Final assembly...

Postby AltairClone » February 14th, 2021, 12:23 pm

If ‘A’ becomes the spurious character when an ‘A’ is the last character typed, then there is a hardware problem, not a software problem. Bit 0 is occasionally reading as 1 during an IN instruction instead of the 0 that it should be. Could be numerous things causing the problem.

1) Simplest first check is to cycle the 2SIOJP in and out of its bus socket numerous times in case that data bit connection to the bus is marginal.

2) If that doesn’t fix it, try another bus slot.

3) If that doesn’t fix it, swap the two 6850s on your 2SIOJP and see if the problem goes away.

4) If that doesn’t fix it, swap the 74LS367 on the 2SIOJP that drives the data bus.

5) If that doesn’t fix it, send me a picture of the two phase clock on your scope.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Final assembly...

Postby BillO » February 14th, 2021, 1:36 pm

I was assuming it was a hardware issue. Just wanted to have the AMON source code to see how it's accessing the hardware. I'm a 6502/6800 guy and am a bit unfamiliar with how things are done in the 8080 world. In any case it's usually a handy debugging tool to see how the software is supposed to manipulate the hardware.

I'll try your suggestions Mike.

The 2-phase clock image is attached.

td1 = 65ns
td2 = 74ns
td3 = 137ns

The pulse widths are on the image.

And my CPU is an 8080A-1

2-ph-clk.jpg
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

Re: Final assembly...

Postby AltairClone » February 14th, 2021, 3:26 pm

The timing spec that causes the most processor behavior problems is TD2. Yours is presently on the hairy edge. I’d tweak R42 a bit to shorten the phi2 high period by 20ns-30ns or so. This, in turn, increases TD2 by the same amount and leaves the phi2 pulse time well above the 220ns minimum.

I don’t recall the leading edge of the clock having such a slow rise time. I’ll have to set up a test configuration and see. The rise time is based on R29,30 and R32,33, and the capacitance they’re seeing from the output of IC-N and 8080 clock inputs. Doesn’t look quite right.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Final assembly...

Postby BillO » February 14th, 2021, 8:11 pm

AltairClone wrote:
1) Simplest first check is to cycle the 2SIOJP in and out of its bus socket numerous times in case that data bit connection to the bus is marginal.

2) If that doesn’t fix it, try another bus slot.

3) If that doesn’t fix it, swap the two 6850s on your 2SIOJP and see if the problem goes away.


1) and 3) did not make any difference (did 3 before 2), but after moving the card to a different bus slot it's been sitting for over 5 hours without a spurious character.

I agree about the clock, especially the rise time. I'll make some adjustments there and post the results. Since I'm using the -1 CPU, the rise time constraints are a little tighter. I'll also pull the MB and check out my soldering on that one connector. I used EDAC connectors so I doubt it's the connector's fault. I won't be able to get to all this until next weekend though.

Thanks Mike!
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

Re: Final assembly...

Postby AltairClone » February 15th, 2021, 9:16 am

Don’t go tearing apart your motherboard until you get the CPU clock looking a bit better. It’s not unusual to have different issues in different slots due solely to the timing issues caused by the shape of the ringing waveform at each slot. A CPU clock adjustment may make the bus cycle more tolerant and both slots could then work fine.

Mike
AltairClone
Site Admin
 
Posts: 632
Joined: April 5th, 2013, 10:55 am

Re: Final assembly...

Postby BillO » February 15th, 2021, 6:08 pm

Well, that's why I'm here. To tap into the experience available. I'm very grateful for your input Mike, and it seems you may be right on the money.

I had a few moments today to try different combinations of slots and it turns out the 88-2SIOJP board is only happy if it is closer to the CPU than the FDC+ card.

I'll get to fixing up that clock first thing next Saturday morning.
BillO
 
Posts: 136
Joined: November 11th, 2020, 6:29 am

PreviousNext

Return to Altair 8800c

Who is online

Users browsing this forum: No registered users and 7 guests

cron