• Please review our updated Terms and Rules here

Zenith 171 - New project - no boot

S

Scruit

Experienced Member
Joined
Apr 9, 2022
Messages
105
Just got a new project, a Zenith 171. Seller described it as failing memory test.

I did my usual intake/evaluation and the first two obvious problems I found were:

- The PSU sometimes would put out some very low voltages. I traced this to the close proximity of C17 and R44/R45 - any moisture in that area (even 91% ipa) would cause it to confuse the opamp and pull the voltgaes very low. Even humidity seems to cause it. The fix was to coat the legs of those three components with a thin layer of uv-cure solder mask.

- Memory test was failing, so I took all the socketed ram (three rows of 41256 and one row of 4264) and run them through the Retro Chip Tester. Found two of them failing. One in row E and one in row B. I replaced the bad 41256 in row E with a known good chip, and removed all the chips from row B. I reconfigured the jumpers for 576k (5 up / 6 open / 7 rt / 8 rt / 9 rt) while I waited for a replacement 4264.

Current status is:

On power up I get message; "Testing Memory" for a few seconds.
Then the screen clears and I get a flashing cursor (the whole character is the cursor, not just a line at the bottom).
No beep or disk seek. System wait here indefinitely.


Comparing with this video of a 171 bootup from LGR:

Mine gets past the memory test and then stops just before the beep wit the flashing block cursor.

Couple of questions:

- In the manual I see that the memory shows the first two rows can have "256" chips and the second two rows have "64". Could the fact that I have 256s in the 3rd row cause a problem? (I'm going to remove all but the first two rows and configure it for 512, see if that helps)

- Does the memory test say something specific if it finds bad memory? I don't recall it saying anything other than "Testing memory" on my first bootup attempt.

- Does it seek the A drive before or after bringing up the world map?

Thanks!
 
If you get the world map you need to press the boot key.

The service guide at minus zero degrees has the error messages.
 
I'll check it out. I can also disassemble the bios and see what tests are next after the memory test.
 
The two bad memory chips have been replaced, so all memory chips test good now in the RCT. No change.

Something I noticed during early testing is that during the "Testing memory" phase (and after it gets stuck right after those words disappear) the FD power connector does not get 12v and 5v, it gets like 4.5v and 2.5v instead.

Looking through the schematic from minuszerodegrees I can see that pin 1 (12v) of the dual FD power connector on the PSU board is controlled by the Q7/Q6 (transistor/mosfet etc) combination. There is 12v to the emitter of the big Q7, the collector goes to pin 1, and the base goes to Q6. The base of Q6 goes to pin 3 of the smaller ribbon cable connector that goes to the motherboard. The two 82ohm resistors test as expected.

On the motherboard it seems that pin3 of J5 goes to a 74/00 and then to a 74/02. All of those show no activity on the pins on that path. However, before I get too deep looking for a physical fault on that side I was thinking that maybe this is just how the motherboard controls whether to turn on the power to the FDDs, and maybe the POST is stopping short of that power up step.

Dopes anyone have a list of the expected voltages of the power cable that goes from the PSU to the motherboard? Ideally both during steady-state but also during the POST memory test? I have the values for the FDD power connector, and I'll worry about the FDD data cable later.

If the voltages are expected to be low until the FDD is needed then I can avoid that rabbit hole.



(p.s) Now that I think of it, if the base of Q6 is low then Q7 should not allow anything through, right? The voltage at pin 1 should be zero, not some halfway voltage. I will have to check again - the PSU is currently out of the computer and on the bench, so maybe if the base of Q6 is disconnected/floating the output is unreliable. I should be able to verify the Q6/Q7 interaction by giving it either 5v or shorting it to ground? IF that works as expected (5v on Q6 base results in 12v at Q7 output to FDD 12v, and gnd on q6 base = 0v to FDD) then my observation of 4.5v while in the computer would suggest that the motherboard's control input to the Q6 is base is floating at that time, rather than 5v or 0v...
 
Last edited:
Looking through the schematics, the FDD 12v and 5v appears to be simply turned on and off by 16M (R6765 P - FDD Controller) via 15L (74/174 flip flop) via 11L (Two-input NOR) and 10M (two-input NAND).

I can verify that path with the logic analyzer, however now I understand why the voltage is low when the disk is not being commanded on.

Quick question: Does the drive seek prior to the beep/world map? Or does it wait until you press the boot button?
 
Watching the address lines on the rom bios with a logic analyzer, along with the /chip enable and /output enable, I can see the bios start to kick in with a first read from FFF0 (7FF0 in the 32k rom image) then to the next instructions after the JMP that it finds there. This proves that my address capture methodology is correct. (have used it on a 16bit data bus machine / 286, not an 8088)

I can then see it doing what looks like a memory check (address lines counting up in a sequential pattern.

After that the bios goes into a loop that appears to be retrying some operation. The bad news is the thing won't start up, but the good news is that is is stuck in the BIOS code, so if I can disassemble this BIOS ROM I can follow the path it takes through the code and find where it is looping (what what condition is required to exit that loop)

BTW, what 8088 disassembler are folks using?
- I was hoping to use objdump in centos8 but it's giving me what is obviously incorrect interpretations whe useinf machine i8086, addr16 and data16. It doesn't have a data8 option on centos8.
- I tried DASM.COM and the instructions there say "This is based on DASM 1.5, that manual is public domain, go find it"
- IDA 7+ free says "I only work on PE filed, please buy the full version"
- IDA 5 free says; "This is a Z80 file, but the full version" (If I try to trick it into loading anyway then it says it can't detect the entrypoint. Selecting 7FF0) results in an error.
 
I got a copy of nasm 2.10 and ran this command:

ndisasm -b16 -s7ff0h -pintel bios.com > bios.asm

That seems to have worked at least for the starting point of 0x7FF0 (Which is the standard BIOS 0xFFF0 entrypoint, but on a 32k rom)

Code: 
00007FED  0000              add [bx+si],al
00007FEF  00                db 0x00
00007FF0  EA228000F0        jmp word 0xf000:0x8022
00007FF5  0000              add [bx+si],al
00007FF7  0000              add [bx+si],al
00007FF9  0000              add [bx+si],al
00007FFB  008FCDFE          add [bx-0x133],cl
00007FFF  00                db 0x00

That JMP to 0x8022 actually winds up being 0x0022. as confirmed by logic analyzer trace (the address that it reads from rom after reading all the bytes of the JMP instruction is 0x0022). This tells me 2 things:

- The address is absolute, not relative to the beginning of the next command.
- This ROM is only 32K, so the addresses in this disassembled version are 0x0000-0x7FFF, however this code actually appears in memory at 0x8000-0xFFFF when the computer is running it. So I need to subtract 0x8000 from any absolute addresses that refer to locations inside the ROM.


The code at 0x022 there looks very familiar as a beginning of a BIOS:


Code: 
00000022  B84000            mov ax,0x40
00000025  8ED8              mov ds,ax
00000027  C70672000000      mov word [0x72],0x0
0000002D  FA                cli
0000002E  FC                cld
0000002F  B099              mov al,0x99
00000031  E663              out 0x63,al

I don't immediately recognize what it is doing for the first 3 lines. It's loading 0x40 in D segment register via the A register, then putting 0 at memory address 0x0072 (0x 0040:0072 ?)

After that is the typical clear of interrupt and direction flags. Then it sends 0x99 to port 0x63 (PPI / "keyboard controller")

So I think I can stumble through this. I'll convert the logic analyzer exports to rom addresses and try to find which addresses it is looping around.
 
Last edited:
Scruit said:
I don't immediately recognize what it is doing for the first 3 lines. It's loading 0x40 in D segment register via the A register, then putting 0 at memory address 0x0072 (0x 0040:0072 ?)
Click to expand...
0040:0072 = 00472

00400
00072 +
--------
00472

The significance of the 400h is that it is the starting address of the 'BIOS Data Area' (BDA).
See "40:72" in the list at [here], but to be considered when referring to that list, is that in the 171, Zenith may be using some addresses in the BDA for purposes other than shown in the list.

Scruit said:
Then it sends 0x99 to port 0x63 (PPI / "keyboard controller")
Click to expand...
The control port of the 8255 PPI.

What the 99h is doing is initialising the 8255, specifically, setting port B of the 8255 to outputs, and setting ports A and C of the 8255 to inputs. That is the same configuration used in the IBM PC and XT.

The 8255 is not a keyboard controller, although, in the IBM PC and XT, it is involved in keyboard operations, amongst other things. How the IBM PC and XT use the 8255 is shown at [here], For hardware compatibility reasons, the 171's use of the 8255 may be similar.
 
The address tracing shows that the system appears to be performing multiple different kinds of memory tests even several seconds after the 'Testing Memory" message goes away.

Maybe I'm just giving up too soon? How long do other people's 171s take to test memory, and how much memory do you have?

Mine is configured for 640k, and I've been giving up about 10 seconds after the 'Testing memory' message goes away.

The LA trace that I have shows that at the beginning it performs a rapid test where it accesses all memory addresses sequentially. lasting about a second, then it goes into a longer cycle of testing that seems to still be under way 5 seconds after the message goes away. The trace shows both BIOS ROM addresses and memory addresses so I can see that a few different parts of BIOS code perform different aspects of the memory test. I'm currently working on identifying the parts of BIOS code that performs the different tests and the memory ranges that are tested by each. Hopefully that call tell me if the memory test is progressing and just being slow, or stuck.

Example of apparent memory test attached (although the a13 line looks wrong, I'll have to verify the connection to the pin and test again)
 

Attachments

  • hangloog.jpg
    hangloog.jpg
    296 KB · Views: 2
Last edited:
My machine takes maybe 10sec to complete memory trst and move on.
I'm your case it is surely moving on to the world map screen. BOOT key should enable boot from floppy.

Yes a13 looks suspicious. Might want to spend some time with that.

Didn't we conclude separately that your roms had some differences?
 
There were some minor differences I believe. I'll disassemble your rom and see what the differences are.
 
In the othrr thread, i said your roms were the same except the character rom. I suggest burning a character rom and dropping it in. You never know, maybe someone with a Pivot was messing around and swapped roms. Pivot had a different lcd.
 
Sure, good idea, that should be easy enough. I'll see what blank eproms I have.
 
If you pull the memory card altogether and try to boot up, you should get an error at 0000 message. Try that, to see if at least that part of boot up is the same as others.
 
Interesting....

Your character rom and mine are actually fundamentally the same, but there's something funky going on. A quick glance gave me the impression that my rom has many of the bits inverted.

Example of first 6 bytes:
Code: 
Mine:    FF 81 81 FF FF C7:      11111111 10000001 10000001 11111111 11111111 11000111
Yours:   00 7E 7E 00 00 38:      00000000 01111000 01111000 00000000 00000000 00111000


Looking more closely now, because more of the overall landmarks appear to otherwise match.
 
Twospruces said:
If you pull the memory card altogether and try to boot up, you should get an error at 0000 message. Try that, to see if at least that part of boot up is the same as others.
Click to expand...
Will try, stand by.

Also I'm looking to see if I can use a 27/256 eprom in place of the 57/256 character rom.
 
You must log in or register to reply here.
Back
Top