Topics

Is my Tek 468 beyond repair?


John
 

Comparison with Tony’s “quick once around the processor”.

1 5Mhz Squarewave
Confirmed.

2 5Mhz Squarewave, half size from 5V down to ~2.5V
Confirmed.

3 Low, short high pulse on power up
Confirmed.

4, 5, 6 Low
Confirmed.

7 500Hz digital signal with 2ms positive pulse
Confirmed. 500Hz signal with 400μS pulse. Cycle width is 2ms.

8, 9 High
8 = LOW, 9 = HIGH

10 100Hz digital signal with 10ms positive pulse
Pin is high. No pulse.

11 High, occasional negative pulse
Pin at approximately 0.8V. No negative pulse observed.

12 to 19,k and 21 to 33 Address/data/control constant traffic
12 - 19 = HIGH
21 - 31 = LOW
32 = 1.5V approx.
33 = LOW

20 Gnd
Ground connection confirmed.

34, 35, 36 High
34 = LOW
35 = HIGH
36 = HIGH

37 132Hz squarewave
2.5MHz quare wave

38, 39 High
Both LOW

40 +5V VCC
Confirmed.


Roger Evans
 

I don't understand Tony's measurement of 38,39 HIGH, on my schematic pin 39 is connected directly to ground.

Tracing back the input for the RST5.5 pin, in the absence of the GPIB board there is precisely nothing connected to pin 14 of U472. Leaving a TTL input unconnected is normally not good practice, I am surprised if Tek would have done that, but unconnected TTL inputs float high and the conclusion must be that in normal operation the CPU would check for the presence of the GPIB board and if not found it would leave the RST5.5 interrupt masked off.

John, when you said you had looked for a burst of activity on the cpu pins immediately after reset were you using a normal analogue scope or a scope with single shot storage? The processor activitiy could only be for 10s of microseconds and easy to miss on a normal scope.

I noticed the RAM on the 8085 board is made up of 2114s, I seem to remember a thread on one of the UK forums where these were regarded as failure prone but I have no personal experience with these.

The two programmed 28C64s are in the first class post (don't hold your breath). I hope making the adapter boards is not too much hassle, a lot depends on the room available.

Roger


John
 

Roget thanks.

Yes, I was using an analogue scope and watching for any flicker no matter how slight. Might be time to break out the Rigol and try single shot mode. On the other hand without any boot code to read from the ROM the processor would just simply halt so which would presumably happen very quickly. It have been trying to find a description of the exact sequence of events the processor follows at power up, i.e. the boot-up sequence if you like, but have yet to find something on that subject. I am wondering whether your book contains such information?

I tracked the GPIB interrupt input to a connector on the memory board, but couldn't fathom where it went from there. I agree with your conclusion. BTW, I realized later that the buffer in non-inverting. Pins 1 and 19 were low so the buffer should be operating. I didn't expect that 1.5V on the input would be sufficient to cause a HIGH on the output side, but as you say, leaving it open is not good practice. Perhaps there needs to be a pull-down resistor to GND, but it might work as you suggest, that is the detection fails (as the GPIB board is not present) and the interrupt is masked off.

I just tried the procedure on page 28 bearing in mind the comment by "Tom" posted by Daveolla. The scope powers up without the fan running but I do get a trace, however, only CH2 seems to be displaying regardless of the input switch position so there seems to be no chopping. CH1 does not appear and its position control does not seem to do anything. Only CH2 works. On the other hand this does at least demonstrate that the failure of the digital mode is preventing a trace from running in normal operation and that in principle at least the analogue side does work. It is not entirely unexpected that there may be problems to resolve once the digital side is fixed. I have restored it back to normal operation for now.

Thank you for getting the ROMs in the post. I should be able to sort out some adapters.

Really appreciate the comments from everyone as well.


Harvey White
 

The processor goes to location 0 and starts executing code on a power on reset.  Typically, the only instruction that should be at that location should be a jump to a routine that performs power on reset functions.  While the processor *could* continue executing other instructions immediately after location 0, the lowest locations are used for other interrupt conditions, and you lose the ability to use those interrupts.

A well populated 8085 system should have a series of jump instructions starting at 0.

If the processor sees nothing from the ROMS during power on startup, and reads all 0xFF, then you'll be executing an RST 7 instruction, which puts the current address (0), on the stack, and transfers execution to location 0x38.  You'll read 0xFF from that, so you'll have a continuing series of repeats of RST 7 if you can read nothing.

Data from your memory should be valid at the rising edge of the RD pulse (active low).

You should get ALE (address latch enable) pulses as well.

Harvey

On 9/18/2020 11:11 AM, John wrote:
Roget thanks.

Yes, I was using an analogue scope and watching for any flicker no matter how slight. Might be time to break out the Rigol and try single shot mode. On the other hand without any boot code to read from the ROM the processor would just simply halt so which would presumably happen very quickly. It have been trying to find a description of the exact sequence of events the processor follows at power up, i.e. the boot-up sequence if you like, but have yet to find something on that subject. I am wondering whether your book contains such information?

I tracked the GPIB interrupt input to a connector on the memory board, but couldn't fathom where it went from there. I agree with your conclusion. BTW, I realized later that the buffer in non-inverting. Pins 1 and 19 were low so the buffer should be operating. I didn't expect that 1.5V on the input would be sufficient to cause a HIGH on the output side, but as you say, leaving it open is not good practice. Perhaps there needs to be a pull-down resistor to GND, but it might work as you suggest, that is the detection fails (as the GPIB board is not present) and the interrupt is masked off.

I just tried the procedure on page 28 bearing in mind the comment by "Tom" posted by Daveolla. The scope powers up without the fan running but I do get a trace, however, only CH2 seems to be displaying regardless of the input switch position so there seems to be no chopping. CH1 does not appear and its position control does not seem to do anything. Only CH2 works. On the other hand this does at least demonstrate that the failure of the digital mode is preventing a trace from running in normal operation and that in principle at least the analogue side does work. It is not entirely unexpected that there may be problems to resolve once the digital side is fixed. I have restored it back to normal operation for now.

Thank you for getting the ROMs in the post. I should be able to sort out some adapters.

Really appreciate the comments from everyone as well.





Chuck Harris
 

The 8085 doesn't halt unless it executes a 166 octal instruction.
000 octal is one of the many NOP instructions, and 377 is a RST7
instruction, which calls the 7th interrupt vector location,
and starts executing... so typically, it will just maraud through
memory forever, never finding a HLT instruction.

Those of us that hoped for better behavior learned to salt unused
EPROM and RAM space with 166's. We also typically stuck a HLT
instruction in the 7th interrupt vector location, so executing a
RST7 would stop the marauding processor cold in its tracks..

Note, the 8080 is an octal machine. Its structure makes sense
in octal, and nonsense in hex.

The boot sequence is pretty simple, it loads the program counter
with zero, and starts to execute whatever it finds there.

-Chuck Harris

John wrote:

Roget thanks.

Yes, I was using an analogue scope and watching for any flicker no matter how slight. Might be time to break out the Rigol and try single shot mode. On the other hand without any boot code to read from the ROM the processor would just simply halt so which would presumably happen very quickly. It have been trying to find a description of the exact sequence of events the processor follows at power up, i.e. the boot-up sequence if you like, but have yet to find something on that subject. I am wondering whether your book contains such information?

I tracked the GPIB interrupt input to a connector on the memory board, but couldn't fathom where it went from there. I agree with your conclusion. BTW, I realized later that the buffer in non-inverting. Pins 1 and 19 were low so the buffer should be operating. I didn't expect that 1.5V on the input would be sufficient to cause a HIGH on the output side, but as you say, leaving it open is not good practice. Perhaps there needs to be a pull-down resistor to GND, but it might work as you suggest, that is the detection fails (as the GPIB board is not present) and the interrupt is masked off.

I just tried the procedure on page 28 bearing in mind the comment by "Tom" posted by Daveolla. The scope powers up without the fan running but I do get a trace, however, only CH2 seems to be displaying regardless of the input switch position so there seems to be no chopping. CH1 does not appear and its position control does not seem to do anything. Only CH2 works. On the other hand this does at least demonstrate that the failure of the digital mode is preventing a trace from running in normal operation and that in principle at least the analogue side does work. It is not entirely unexpected that there may be problems to resolve once the digital side is fixed. I have restored it back to normal operation for now.

Thank you for getting the ROMs in the post. I should be able to sort out some adapters.

Really appreciate the comments from everyone as well.






tgerbic
 

Roger, you are correct.

Looking at my notepad, I penciled in L and L for 38 and 39. Not sure how this turned into both High. Must have got distracted. Pin 37 should be 2.5Mhz as it is one half the 5Mhz clock.
Pins 37, 38 and 39 are ok on John's 468.

Regards


John
 

tgerbic, thank you for the confirmation on those 3 pins.

So do I understand from the replies below that the processor shouldn't halt even with a corrupt Mostek ROM and I should still see pulses on ALE regardless? I found a book online that discusses the 8085 in detail and I got the same impression but this level of diagnosis is something rather new to me.

If I have the time tomorrow I will hook up the LA to some of the pins. Maybe that will reveal something. I need to prepare my laptop though with some software.


Chuck Harris
 

There is one command that halts, 0166 octal, and 255 commands
that don't.

As I mentioned earlier, a wise programmer salts the unused
memory with halts, and makes the 7th interrupt vector contain
a halt, so executing 0377's (RST7) will go to that table, and
stop.

Then, if your logic analyzer is set to trip on the HALT state,
the LA will have a fairly good recording of how you got into
the weeds.

-Chuck Harris

John wrote:

tgerbic, thank you for the confirmation on those 3 pins.

So do I understand from the replies below that the processor shouldn't halt even with a corrupt Mostek ROM and I should still see pulses on ALE regardless? I found a book online that discusses the 8085 in detail and I got the same impression but this level of diagnosis is something rather new to me.

If I have the time tomorrow I will hook up the LA to some of the pins. Maybe that will reveal something. I need to prepare my laptop though with some software.






tgerbic
 

Does anyone know of a link for the download of the Tek468.zip file, which contains the service ROM bin file?

Thanks
Tony


Roger Evans
 

Chuck, John,

The insight into 8085 programming wisdom is very illuminating. I am guessing that the 160-0459 ROM is mapped to $0000 and there are many HALT instructions (hex $76) scattered through the first 100 bytes of code that look as if they are intended to catch a corrupted jump instruction that then falls through to the HALTs. The 8085 still has to execute a small number of instructions before hitting the HALT. I think the minimum would be five memory references and so five ALEs and five RDs before the HALT. It should be fairly straightforward to capture that on John's DSO.

Roger


John
 

Hmm, stuck the LA on it today but I see no processor cycles whatsoever.

The LA has 16 channels but I have only 8 clips, so I connected the control lines only:

RESET
S0
S1
ALE
RD
WR
TRAP
INTR
and
GND

The scan was run at 10MHz (2 x 5MHz - Nyquist).
The capture was run for 10 seconds.

The jumper was set to RST to pull the RESET line down. I hit Run in Pulseview and at the same time pulled the jumper. The RESET line goes up but nothing else happens. No change in S0/S1 states, no ALE.

Incidentally, I discovered that the clock signal was fading out. It seems that with everything open and fan not blowing the crystal gets a bit hot and stops oscillating and the signal fades. I set up an old PC fan to blow
on the board with the 5MHz crystal and monitored on the scope and repeated the test a handful of times, but even with the clock definitely running I saw no activity other than the reset line going up.


Chuck Harris
 

The scope should have no problem running 24-7 with
the case off and no fan.

You have just found a problem to fix.

Crystals that get hot have defective drivers that are hitting
them with too much power. There should be no measurable Trise
on the crystal.

Once the halt instruction happens, there will be no activity
from the processor because it will have .... halted. The only
way out of a halt is to reset the processor.

-Chuck Harris

John wrote:

Hmm, stuck the LA on it today but I see no processor cycles whatsoever.

The LA has 16 channels but I have only 8 clips, so I connected the control lines only:

RESET
S0
S1
ALE
RD
WR
TRAP
INTR
and
GND

The scan was run at 10MHz (2 x 5MHz - Nyquist).
The capture was run for 10 seconds.

The jumper was set to RST to pull the RESET line down. I hit Run in Pulseview and at the same time pulled the jumper. The RESET line goes up but nothing else happens. No change in S0/S1 states, no ALE.

Incidentally, I discovered that the clock signal was fading out. It seems that with everything open and fan not blowing the crystal gets a bit hot and stops oscillating and the signal fades. I set up an old PC fan to blow
on the board with the 5MHz crystal and monitored on the scope and repeated the test a handful of times, but even with the clock definitely running I saw no activity other than the reset line going up.






John
 

Chuck, thanks. I will have a look at the crystal driver. Will need to remove that board.

Regarding the processor, I get what you are saying. I put the jumper in reset mode which holds the RESET line down to ground. Processor should be halted. When I pull the jumper, it brings the RESET line back up and I am expecting the processor to start and do something, but all I get on the LA trace is RESET going up and no other activity. Even though I don't have the address lines connected to the LA, I expected to see the status of S0 and S1 change in response to a read operation and at least some ALE pulses before the processor halted again, but my understanding here is admittedly limited. I am learning as I go along.


Harvey White
 

One technique to "trap" a bad microprocessor is to have a series of jump or branch instructions surrounding a halt instruction.  If the mandatory jump or branch failed, then the processor would halt, or would do a jump to the current location and freeze operation.  The supposition is that some instructions may fail but the halt instruction won't.

Tektronix did that, IIRC, in the 468 and some other systems.  The practice may still be alive in some military equipment, but modern microprocessors are reliable enough that such measures are not likely to be needed

Harvey

On 9/19/2020 4:06 AM, Roger Evans via groups.io wrote:
Chuck, John,

The insight into 8085 programming wisdom is very illuminating. I am guessing that the 160-0459 ROM is mapped to $0000 and there are many HALT instructions (hex $76) scattered through the first 100 bytes of code that look as if they are intended to catch a corrupted jump instruction that then falls through to the HALTs. The 8085 still has to execute a small number of instructions before hitting the HALT. I think the minimum would be five memory references and so five ALEs and five RDs before the HALT. It should be fairly straightforward to capture that on John's DSO.

Roger





Roger Evans
 

John,

I think suspicions may be moving from ROM rot to a bad CPU or at least a need to clean the CPU pins. Before condemning the CPU check that the voltage swing on the clock input, pin 1, comfortably exceeds the TTL thresholds, < 0.4V for Low and > 2.4V for HIGH. With the 1k pull up resistor on U272 the clock signal should be more like 4V at the high level but frequently does not have a flat top. It switches very fast to the TTL high level then more gradually as the resistor pulls it higher. Check also that pin 2 isn't doing anything, it should sit close to +5V. You could also put a couple of logic analyser clips on HOLD and READY just to be sure they don't do anything strange in the startup phase. I have built several single board computers over the last couple of years and when they fail to do _anything_ coming out of reset it is either forgetting to get all the control inputs in the right states or a duff processor (the peril of buying parts from China!).

Regards,

Roger


John
 

Indeed, my suspicions were also heading in that direction, but its good to have another view.

HOLD is connected directly to GND and I confirmed a ground connection there. READY is connected to 5V via a 1k resistor. I did check that 5V was present, but didn't monitor it during start-up. Will have a look at that and pin 2 on U272 once I've sorted the clock and put everything back together. It seems that the diagra,s do not provide the power arrangements for the oscillator, just showing pin 8 as the output from the 50MHz oscillator box. I'm going to have to remove the board from the chassis and visually determine how its wired up and what is going on.

I did find an OKI branded 8085 on eBay for a fiver. I guess it is probable NOS although since he has more than 10 available I'm not sure. The china ones seem to be stamped "Infineon". Someone has a nice "rare ceramic" one with gold top but rather pricey!


Bert Haskins
 

On 9/19/2020 10:15 AM, John wrote:
Chuck, thanks. I will have a look at the crystal driver. Will need to remove that board.

Regarding the processor, I get what you are saying. I put the jumper in reset mode which holds the RESET line down to ground. Processor should be halted. When I pull the jumper, it brings the RESET line back up and I am expecting the processor to start and do something, but all I get on the LA trace is RESET going up and no other activity. Even though I don't have the address lines connected to the LA, I expected to see the status of S0 and S1 change in response to a read operation and at least some ALE pulses before the processor halted again, but my understanding here is admittedly limited. I am learning as I go along.
If you are not getting a TTL level pulse(s) on the ALE pin after reset, I would not bother going any further.

Is the 8085 sitting in one of those POS TI sockets?

Try rocking the core chips in their sockets several times.

FWIW I still have working development boards for most of the early procs, I've been doing this since the 74181 was the leading edge.

-- Bert




John
 

I was not getting anything at all on ALE. I removed and re-seated the 8085. Unlike the TTL logic chips, the pins on the processor were shiny and clean. However, since I have disconnected the A19 board (timing and power supply) I will not know the effect of this re-seating until I reconnect everything together again.

In the meantime, the oscillator crystall is a weird problem. I checked the power supplies on the A19 board and found there were all good. I was a little concerned about the 5V line because it had somewhat short of 100mVpp ripple on the CRT display, but the service manual shows a nominal 80mmVpp, so this is probably OK as well. I checked the output from the oscillator crystal (pin 8) and found that it started at about 3V and sank to about 1V after a few seconds. The result was that the output from the 74LS112 was OK at first, but destabilized after a few seconds, faded (the trace got blurred) and then flat-lined as the signal dropped below the TTL threshold. This is exactly what I was seeing at U272 and pin 1 of the 8085 on the microprocessor board. I therefore surmise that the 74LS112 is probably OK, and the problem is the crystal itself.

I am curious as to why you suggest that I should not bother going any further? Do you mean with the logic analyser or repair of the oscilloscope in general? If the latter, then no worries. The scope only cost me a trip to pick it up and although it was a bit daunting at first, delving into the computer side of things has been interesting and I have learned something. Cost wise, so far I am looking at a replacement crystal and possibly a 8085 processor which I think I can pick up for around £12. On the other hand the RAM board, storage board, display board are untested at present and I know that repair of the analogue side will incur some additional cost so I appreciate that at some point one has to ask whether it is worthwhile. I am not sure I have reached that point yet, but am happy to entertain other viewpoints?


 

On Sat, Sep 19, 2020 at 11:45 PM, John wrote:


Cost wise, so far I am looking at a replacement crystal and possibly a 8085
processor which I think I can pick up for around £12
In case you or someone else needs one or more: I've got hundreds of NOS 8085's (OKI) in their original rails at a few €/$/£'s each. Shipment from NL.

Raymond


Chuck Harris
 

He was trying to tell you that until you have a working CPU,
all of your other tests are wasted.

The clock has to work, and the processor has to be latching
addresses.

If it doesn't, it doesn't matter what your RAM and EPROM are
doing, or how good they are.

I would be more inclined to suspect the oscillator than the
crystal.

-Chuck Harris

John wrote:

I was not getting anything at all on ALE. I removed and re-seated the 8085. Unlike the TTL logic chips, the pins on the processor were shiny and clean. However, since I have disconnected the A19 board (timing and power supply) I will not know the effect of this re-seating until I reconnect everything together again.

In the meantime, the oscillator crystall is a weird problem. I checked the power supplies on the A19 board and found there were all good. I was a little concerned about the 5V line because it had somewhat short of 100mVpp ripple on the CRT display, but the service manual shows a nominal 80mmVpp, so this is probably OK as well. I checked the output from the oscillator crystal (pin 8) and found that it started at about 3V and sank to about 1V after a few seconds. The result was that the output from the 74LS112 was OK at first, but destabilized after a few seconds, faded (the trace got blurred) and then flat-lined as the signal dropped below the TTL threshold. This is exactly what I was seeing at U272 and pin 1 of the 8085 on the microprocessor board. I therefore surmise that the 74LS112 is probably OK, and the problem is the crystal itself.

I am curious as to why you suggest that I should not bother going any further? Do you mean with the logic analyser or repair of the oscilloscope in general? If the latter, then no worries. The scope only cost me a trip to pick it up and although it was a bit daunting at first, delving into the computer side of things has been interesting and I have learned something. Cost wise, so far I am looking at a replacement crystal and possibly a 8085 processor which I think I can pick up for around £12. On the other hand the RAM board, storage board, display board are untested at present and I know that repair of the analogue side will incur some additional cost so I appreciate that at some point one has to ask whether it is worthwhile. I am not sure I have reached that point yet, but am happy to entertain other viewpoints?