• Please review our updated Terms and Rules here

Zenith Z-171 hardware debug

T

Twospruces

Veteran Member
Joined
Dec 9, 2009
Messages
787
Location
Canada
Well out of nowhere my trusty Z-171 XT 99% compatible is completely broken. It went from working to not working in one power cycle.

Normally when the Z-171 boots from a power on, it does a memory check first. Now, when I power on, I get rando garbage on the display, and the screen flashes bright/dim on a 1 sec cadence. Sometimes, a beep too.

Preliminary findings:
* voltages all look good, with both DVM and scope.
* databus signals look normal at first glance, at CPU.
* A1-A6 have some low voltage pulses, with Vh at about 4V, rather than 5V. This is strange but I can't identify a reason why some pulses have low voltage. I feel like this is a problem. The lower address bus is multiplexed with data.... maybe the bus is being driven when it should not, and a conflict is resulting in odd voltage levels.

That's where I am right now.
Thinking about trying out a 5160 diagnostic ROM from minuszerodegrees to see if that helps me isolate an issue.

Ideas or suggestions welcome.
 
I think it is the DMA controller - uPD8237AC - which is trying to drive the address lines when it should not be. If I pull that chip (it is socketed), the address bus voltage levels look normal.

It is also noticeably warm.
From my read of the schematic, the DMA controller is the only other thing that can drive the address bus other than the CPU and related buffers.

In addition, my XT-CF card is showing a solid "Drive activity" LED all the time. This is an interesting clue that I have not yet investigated. The XT-CF card is not the source of the problem as the machine malfunctions regardless of this card being installed or not.
 
The Landmark diagnostic ROM beeps 5 Hl/LO and 9 short, meaning can't initialize the video.
But I think this also means that the ROM is readable and possibly RAM is read-writeable. So that seems like a bit of info.

Actually if I let the Landmark ROM run, I get many more and varied beeps. Seems to be more than the manual describes.

Ruud's diagnostic appears to do absolutely nothing. I have a printer connected... no characters at all. no beeps. no video.
the lack of video is expected, I think it is non-standard.
 
Twospruces said:
Ruud's diagnostic appears to do absolutely nothing. I have a printer connected... no characters at all.
Click to expand...
Rudd's diagnostic ROM is not designed to output to a printer.
For example, when it sends the checkpoint code of 1, it is outputting the byte of 01h, not 31h (ASCII equivalent of '1').
Perhaps your printer has a 'hex' mode, an example following:
1672361586589.png
 
Thanks for pointing information that out.

Funny because printers are a lot more common that io hex code readers.

80h and increasing are characters. Maybe I can. Let it run and thr printer will buffer up. Then connect to another pc and send cr lf to trigger the code character print out.
 
modem7 said:
The first beep that Rudd's diagnostic ROM does is the one at step 25 at [here].
Therefore a possibility is that one of the earlier steps is erroring then halting the CPU.
Click to expand...
Yes thanks! This method of throwing a code on error means that a completely dead machine will never throw a code. Might have been better to be more verbose! Maybe I'm just a special case with a non compatible display...
 
So I have set up my printer to accept codes like 80h and print characters. I let Ruuds rom run, a d assuming an error code is thrown, I wait for a while, then connect a separate computer and send 13d 10d carriage return lf to stimulate a buffer print on the printer.

No characters sent from Ruud. At least so far. Not sure how long to let it run before I try to see if a code is thrown.

Additional info:

Measured 63 msec of databus activity until HALT.
 
Last edited:
I'm gonna guess that in my case the rom is failing at the checksum. 63 msec is probably enough time to do 16k reads of 16bits and add them up. If it were the case then I might see an address line that is not toggling at the eprom.
 
If you can program in 8088/8086 assembly, then you could modify the 'Rudd's diagnostic ROM' code to create for yourself a custom version that does print to your printer.

- Version 2022-12-12 is the latest version (earlier versions do not output to 3BC, the parallel port on most MDA cards).
- Compile using NASM (version 2.11 or higher).
- After successful compilation, adjust the final byte of the 8 KB sized binary to get an 8-bit checksum of 00.
- Then, quadruple the 8 KB sized binary to get a 32 KB sized binary.

Subroutine 'sOutDebug' (sends the passed byte to the parallel ports) is an appropriate place for a modification.
 
Ahar!
Well thanks for pushing me a bit to do some assembly; what was interesting is that I could NOT ever get the parallel port to work. I spent a few hours asking myself what I was doing wrong in my code.
Turns out it was not that at all. The fault that was bringing down the system was also bringing down the parallel port.

The issue was in fact a blown 74HC08 DIP14 chip. Of all things. In the process of finding out why the parallel port did not work, I was able to find some strange non-logic logic signals that should have been driving an enable line on a buffer. Without said buffer enabled, no data to several key sections of the board.
 
You must log in or register to reply here.
Back
Top