Cool, I'll try that.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Zenith 171 - New project - no boot
- Thread starter Scruit
- Start date
Cool, I'll try that.
I got an immediate message saying that there was an error at 0000:0000 bit 0, so that seems to work.
I put the memory board back inn place and gave it 30 seconds. The "Testing memory" message lasts about 10 seconds, then soon after the message disappears the traces stop showing activity. I'm not sure how much time passes between the message going away and the traces dying - I'll have to use the oscilloscope instead of the LA so I'll try that later today.
Twospruces
Veteran Member
sounds like you have a good ram board now.
you could try pulling the CMOS RAM (to reset contents).
I guess the CMOS RAM is one are of potential problem. what if you have a missing address line at the cmos ram?
Also, I would bet that even with a bad A13, you would pass ram testing. But you need a good A13 for accessing CMOS SRAM.
so, yeah, I think it would be good to look closely at A13 and see why it seems to be toggling when it should not be, during RAM test.
(at least it is possible A13 has a defect; can't imagine why it would not count up in sequence during RAM test).
you could try pulling the CMOS RAM (to reset contents).
I guess the CMOS RAM is one are of potential problem. what if you have a missing address line at the cmos ram?
Also, I would bet that even with a bad A13, you would pass ram testing. But you need a good A13 for accessing CMOS SRAM.
so, yeah, I think it would be good to look closely at A13 and see why it seems to be toggling when it should not be, during RAM test.
(at least it is possible A13 has a defect; can't imagine why it would not count up in sequence during RAM test).
Twospruces
Veteran Member
I appreciate you taking the time to scan that for me!
If you are scanning at 1Mhz you may be missing data or getting a harmonic/resonance effect. I have been scanning at 100mhz and I find that to be too fast because I get strange results where some pins change before other pins. The bet scan frequency is probably closer to 10 or 20 Mhz.
To clean up my data I'm going to tweak my csv-to-hex-address parser to only process addresses as the ROM output enable drops low.
But first, I'm going your character rom onto a 27c256 and see what that does.
If you are scanning at 1Mhz you may be missing data or getting a harmonic/resonance effect. I have been scanning at 100mhz and I find that to be too fast because I get strange results where some pins change before other pins. The bet scan frequency is probably closer to 10 or 20 Mhz.
To clean up my data I'm going to tweak my csv-to-hex-address parser to only process addresses as the ROM output enable drops low.
But first, I'm going your character rom onto a 27c256 and see what that does.
So, your character rom versus my character rom...
They are the same, except for one small detail...
(No change to the boot failure behavior, but it's cool to find it's just an inverted rom. I wonder - could we burn both onto a 27C512 (one rom in the lower half, the other rom in the upper half) and use a switch or jumper on pin 1 (A15) to choose between normal and inverted mode?
They are the same, except for one small detail...
(No change to the boot failure behavior, but it's cool to find it's just an inverted rom. I wonder - could we burn both onto a 27C512 (one rom in the lower half, the other rom in the upper half) and use a switch or jumper on pin 1 (A15) to choose between normal and inverted mode?
Attachments
Last edited:
Twospruces
Veteran Member
You must have a different hardware barnacle on there!
Twospruces
Veteran Member
No, little board changes that are fixes to problems get added in the factory after the pcb is built....those are barnacles. For your hardware to require reversed bits for video means you machine has inverted video as a default relative to mine. Very odd. But whatever works.. not the reason for boot failure.
Ah! I call them "factory bodges".
There are a couple, I'll have to compare the diagram with them to see if they affect the screen.
For now I'm trying to get a clear read of BIOS ROM addresses that are being read. I'm seeing addresses bring read that are in the copyright message, so that makes me think that those addresses are not intended for the bios rom.
I was trying to get away with only reading the output enable flag on the rom (skipping chip enable) but I think that is giving me results I shouldn't be getting. I only have 16 channels on the LA so I'll have to switch the input I was using for a14 back to /ChipEnable (so I would go back to reading a0-14 plus /ChipEnable and /OutputEnable)
I'm still focusing on the point where all address activite stops after the memory test completes. I'll also look for other signs of life while it's in that state.
Leading up to the point where address activity dies is a period where the rom just loops back to itself at 0x066d. It read 66d, 66e, and 66f. If I decompiled the bios correctly then that is a "JMP 0x66d" command, which looks like it comparies correctly. I'm trying to figure out what breaks it out of that dead loop, if anything. An interrupt? Something takes it from that loop to a burst of other activity for a few milliseconds, then all the address pins flatline.
There are a couple, I'll have to compare the diagram with them to see if they affect the screen.
For now I'm trying to get a clear read of BIOS ROM addresses that are being read. I'm seeing addresses bring read that are in the copyright message, so that makes me think that those addresses are not intended for the bios rom.
I was trying to get away with only reading the output enable flag on the rom (skipping chip enable) but I think that is giving me results I shouldn't be getting. I only have 16 channels on the LA so I'll have to switch the input I was using for a14 back to /ChipEnable (so I would go back to reading a0-14 plus /ChipEnable and /OutputEnable)
I'm still focusing on the point where all address activite stops after the memory test completes. I'll also look for other signs of life while it's in that state.
Leading up to the point where address activity dies is a period where the rom just loops back to itself at 0x066d. It read 66d, 66e, and 66f. If I decompiled the bios correctly then that is a "JMP 0x66d" command, which looks like it comparies correctly. I'm trying to figure out what breaks it out of that dead loop, if anything. An interrupt? Something takes it from that loop to a burst of other activity for a few milliseconds, then all the address pins flatline.
Continuing this diagnosis, I've found a couple of interesting things using the LA on the 8088 pins.
The 8088 is running in max mode, so I can use the state pins S0/S1/S2 to tell the difference between IO Write, Mem Read etc. One of those states is "Halt". That's where we get to right as all the address/data activity stops. Only the clock signal remains in an active state.
However, the cursor (which is a square rather than underline style cursor) still flashes. That tells me that the screen refresh still works.
By watching and decoding the data lines during the memory test I can tell that the test on screen is being refreshed with ascii values (not pixel values post-chararcter-rom). So the system is definitely still fully active while testing memory. Curiously the screen is drawn in reverse, so parsing the decoded lines shows ascii "<y> <r> <o> <m> <e> <m> < > <g> <i> <n> <t> <s> <e> <T>" being drawn do the screen repeatedly. An observation, not a significant finding for diagnosis.
I also reduced the memory from 640 to 256 by adjusting the jumpers, and the mem test now completes more quickly. It still halts immediately after with the same LA output, but it's a reassurance that the memory is actually being tested and is passing (removing a chip that is expects to be there causes it to display an error/address) . That also allows for easier timing of running the LA to capture the halt.
So my next step is to go in one of two directions:
- Try to improve my analysis of the LA CSV output to clean up the data and address signals. The 8088 shares A0-7 with D0-7 and uses the status pins and ALE (etc) to tell the difference. If I am to cleanly follow the cpu's position though bios rom then I have to pick those apart better.
- I could theorize that the CPU is stuck on trying to communicate with a device on the motherboard, and use my LA to watch the "chip select" pins of the most likely chips. (Combine that with verifying in the schematics which chip select lines are supposed to be connected...)
The 8088 is running in max mode, so I can use the state pins S0/S1/S2 to tell the difference between IO Write, Mem Read etc. One of those states is "Halt". That's where we get to right as all the address/data activity stops. Only the clock signal remains in an active state.
However, the cursor (which is a square rather than underline style cursor) still flashes. That tells me that the screen refresh still works.
By watching and decoding the data lines during the memory test I can tell that the test on screen is being refreshed with ascii values (not pixel values post-chararcter-rom). So the system is definitely still fully active while testing memory. Curiously the screen is drawn in reverse, so parsing the decoded lines shows ascii "<y> <r> <o> <m> <e> <m> < > <g> <i> <n> <t> <s> <e> <T>" being drawn do the screen repeatedly. An observation, not a significant finding for diagnosis.
I also reduced the memory from 640 to 256 by adjusting the jumpers, and the mem test now completes more quickly. It still halts immediately after with the same LA output, but it's a reassurance that the memory is actually being tested and is passing (removing a chip that is expects to be there causes it to display an error/address) . That also allows for easier timing of running the LA to capture the halt.
So my next step is to go in one of two directions:
- Try to improve my analysis of the LA CSV output to clean up the data and address signals. The 8088 shares A0-7 with D0-7 and uses the status pins and ALE (etc) to tell the difference. If I am to cleanly follow the cpu's position though bios rom then I have to pick those apart better.
- I could theorize that the CPU is stuck on trying to communicate with a device on the motherboard, and use my LA to watch the "chip select" pins of the most likely chips. (Combine that with verifying in the schematics which chip select lines are supposed to be connected...)
So, your character rom versus my character rom...
They are the same, except for one small detail...
(No change to the boot failure behavior, but it's cool to find it's just an inverted rom. I wonder - could we burn both onto a 27C512 (one rom in the lower half, the other rom in the upper half) and use a switch or jumper on pin 1 (A15) to choose between normal and inverted mode?
The earlier models had a green/ yellow lcd display, then around 1988 they switched to the blue-ish supertwist lcd. I wonder if the difference in roms was related to the display types?
I got the thing to sort of boot...
Long story short... Attaching my LA to the 8 data pins on the PPI resulted in a change to the bootup behavior.
Previously I would get a "Testing Memory" message for a few seconds, then the message would be replaced with a flashing black cursor and the CPU going into HALT (Per S0/S1/S2 status).
With the LA hooked up to the data pins on the 8255 and the ground on the CPU the behavior is now that I get a permanent beep after the "Testing Memory" message disappears, and I now get a new message to the effect of "Timer Interupt Failure", then after a few seconds the world maps shows up.
This worked in this status for a while as I tried to document the testing condition. It was intermittent, and after a few minutes it went back to the old behavior.
So now I'm going to be looking at the quality of the powers/grounds and data signals between the 8255 and the CPU. Got me wondering if something is maybe floating a data line, is not asserting it high/low strongly enough, or has a bad ground / poor input voltage and some part of the signal found a path through the LA instead.
Long story short... Attaching my LA to the 8 data pins on the PPI resulted in a change to the bootup behavior.
Previously I would get a "Testing Memory" message for a few seconds, then the message would be replaced with a flashing black cursor and the CPU going into HALT (Per S0/S1/S2 status).
With the LA hooked up to the data pins on the 8255 and the ground on the CPU the behavior is now that I get a permanent beep after the "Testing Memory" message disappears, and I now get a new message to the effect of "Timer Interupt Failure", then after a few seconds the world maps shows up.
This worked in this status for a while as I tried to document the testing condition. It was intermittent, and after a few minutes it went back to the old behavior.
So now I'm going to be looking at the quality of the powers/grounds and data signals between the 8255 and the CPU. Got me wondering if something is maybe floating a data line, is not asserting it high/low strongly enough, or has a bad ground / poor input voltage and some part of the signal found a path through the LA instead.
Last edited:
Quick question... On the 80c39 ("Keyboard Controller" in the schematics) the two XTAL pins go to either side of a crystal oscillator, then both pins go to ground through big capacitors. I don't read a clock signal there, and the two capacitors appear to be open don't go to ground. I'm guessing this is a problem, no? I assume that I should be able to pick up an sine wave (of whatever the crystal is rated for) between each of those pins and ground, correct?
I plan to pull the two caps and the oscillator off the board to test.
I plan to pull the two caps and the oscillator off the board to test.
modem7
10k Member
Normally, with an oscilloscope, yes. What you see will depend on the chip and the components connected to X1 and X2. An example is shown in posts #30 and #31 at [here].
You need to stop interchanging between "crystal" and "oscillator". It will lead to confusion. An "oscillator" is typically a self contained unit - 3 or more pins - feed it a DC voltage on one pin, and an oscillating signal (square, or sine, etc.) comes out another pin.
Last edited:
That is the chip. Y2 is an inductor? I thought it was a crystal oscillator...
In my mind the difference was that a "clock signal" is what I would call something that had more of a square wave, and the "crystal oscillator" was the silver component (usually with a frequency printed on it) that would generate a sine wave that would be interpreted as / converted to a clock signal.
I have some reading to do on the thread you referenced. Specifically in how the two capacitors should read, and what those two pins should look like. Thank you!
Attachments
Last edited:
You are correct, I need to look closer - the concept is clearly not as simple as I had thought.
modem7
10k Member
In the photo you posted, Y2 is a crystal. Hence my earlier statement of, "Maybe an inductor was fitted in some Z-171's and something else in others.'
If you can find the data sheet for the Oki M80C39, that informs the design engineer as to what options are available for the X1 and X2 pins.
At [here], there are photos showing inside a 'crystal'. It doesn't oscillate by itself. It is used as part of an oscillator circuit. It has no polarity.
Whereas for the unit shown in the example at [here], it has a dedicated pin that you put a DC supply voltage on, and a clock comes out another pin. It is a complete oscillator circuit 'in a can'. You can even get units that output a saw-tooth waveform.
They are capacitors. Remove them and see what the measured capacitance is compared to what is printed on them.
It is going to vary from circuit-to-circuit.
I appreciate your assistance!
So, given that the schematic and board don't match in this case, my confusion on inductor vs crystal was understandable, so I don't feel quite so silly. However this inductor/crystal is the first inconsistency I have noted in the schematic compared to my board (while working through my troubleshooting) so it's still the best place to start. I'm considering redrawing the schematics in a modern piece of software, unless anyone knows of a better quality version out there? Some of the text is too blurry to read and I have to rely on following the traces and reading chip datasheets to figure out a lot of it.
I have the 80C39 datasheet and will review it for XTALx pin function. Having talked this trough I'm even more sure that the lack of activity on those pins using the oscilloscope is definitely something I need to look into. Maybe the components or traces are bad, maybe I'm measuring it wrong. I know that different implementations of the timing for the 8039/48 etc peripheral controllers will have different waveforms depending on if they use a physical oscillator, the design of said oscillator, or are fed an external timing signal from another device, etc. Having said that, I've never seen one that has zero activity on BOTH of those pins (have seen implementations where one pin is tied to ground, but the other still gets a timing signal) We'll see.
Thank you again, your advice has been very helpful.
So, given that the schematic and board don't match in this case, my confusion on inductor vs crystal was understandable, so I don't feel quite so silly.
However this inductor/crystal is the first inconsistency I have noted in the schematic compared to my board (while working through my troubleshooting) so it's still the best place to start. I'm considering redrawing the schematics in a modern piece of software, unless anyone knows of a better quality version out there? Some of the text is too blurry to read and I have to rely on following the traces and reading chip datasheets to figure out a lot of it.I have the 80C39 datasheet and will review it for XTALx pin function. Having talked this trough I'm even more sure that the lack of activity on those pins using the oscilloscope is definitely something I need to look into. Maybe the components or traces are bad, maybe I'm measuring it wrong. I know that different implementations of the timing for the 8039/48 etc peripheral controllers will have different waveforms depending on if they use a physical oscillator, the design of said oscillator, or are fed an external timing signal from another device, etc. Having said that, I've never seen one that has zero activity on BOTH of those pins (have seen implementations where one pin is tied to ground, but the other still gets a timing signal) We'll see.
Thank you again, your advice has been very helpful.