VOGONS


Reply 20 of 33, by Deunan

User metadata
Rank Member
Rank
Member

After a cursory glance at the BIOS disassembly I can say forget the POST card - doesn't look like it does any port 80 writes so there won't be any meaningful codes. This mobo really is a kind of early XT to AT hybrid. Make sure the keyboard is connected - I've seen some early mobos behave odd when it wasn't present, or was disabled by the key lock.

Reply 21 of 33, by Jo22

User metadata
Rank l33t
Rank
l33t
Deunan wrote on 2020-03-26, 22:58:

After a cursory glance at the BIOS disassembly I can say forget the POST card - doesn't look like it does any port 80 writes so there won't be any meaningful codes. This mobo really is a kind of early XT to AT hybrid. Make sure the keyboard is connected - I've seen some early mobos behave odd when it wasn't present, or was disabled by the key lock.

Any chance an alternate BIOS could work then ?
- The IBM AT was compatible with the Quadtel BIOS for example, which was superior in certain fields.
If I think about it, XT and AT were not that different, after all. In essence, the AT was a superset with some of the core parts (IRQ, DMA) set up in a cascade configuration.
In fact, the only meaningful additions I can think of right now are AT-BIOS, CMOS Setup and the Real-Time Clock, which all work hand in hand.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 22 of 33, by Horun

User metadata
Rank Oldbie
Rank
Oldbie
Vegge wrote on 2020-03-25, 17:00:

Yeah, sad but true. but if it can be repaired I'll have a nice 286 machine to play with. I bought it as a package with the original keyboard and the monitor it was sold withwhen new, even got the box for the monitor.

I see some things in your original picture that may or may not be part of the issue, see my pic. Being it is nearly all TTL and not a true 286 chipset board (like Headland, etc) even a minor quirk in one could lead to a cascade of issues. Where is U20, U21 and U22 ? Are they under that paper sticker on the board ? Also cannot figure out what should be in the empty socket, to far and no traces to the cpu for a mathco from what I can see. Just curious...

Attachments

  • Image1.jpg
    Filename
    Image1.jpg
    File size
    33.31 KiB
    Views
    156 views
    File license
    Public domain

First computer was an IBM 3270 workstation with CGA monitor. 🤣

Reply 23 of 33, by Vegge

User metadata
Rank Member
Rank
Member
computerguy08 wrote on 2020-03-26, 21:19:
This is quoted from minuszerodegrees website: […]
Show full quote

This is quoted from minuszerodegrees website:

These diagnostics primarily require a CGA or MDA/MGA video card (although, strangely, an IBM MDA card does not work for the 517 […]
Show full quote

These diagnostics primarily require a CGA or MDA/MGA video card (although, strangely, an IBM MDA card does not work for the 5170 version of the ROM).
EGA cards will work, but poorly.
Only some VGA cards are expected to work (more information here).
If you do not have a suitable video card, you will be forced to rely on error beeps that the diagnostics send to the speaker. See 'Speaker' section below.

So, this ROM is mainly designed around CGA and monochrome cards. If I were you, I would eliminate all possible failure points (and use fully compatible cards with said ROM).

About the seal break, I admit it's a tough one. It's up to you if you want to use that card (unless you get another one). I would use that card (this is just my opinion ofc).

I think you already visited the Supersoft manual, but just in case you didn't, here it is.

Here is what you need for beep codes (from manual), in the video it corresponds to 6 HI/Lo 1 Short , which is unable to init video.

So yeah, hrm, I don't know how I read those beep codes. Thank you for clearing that up. I found another EGA card that actually produces an image with supersoft.

IMG_5152.JPG
Filename
IMG_5152.JPG
File size
1.72 MiB
Views
151 views
File license
Fair use/fair dealing exception

So protected mode cpu fails. So from what I can read it's toggled with the reset line from the kbc? I checked the reset line during the supersoft testing. Always low at cpu, and always hi at kbc.

Horun wrote on 2020-03-27, 03:59:
Vegge wrote on 2020-03-25, 17:00:

Yeah, sad but true. but if it can be repaired I'll have a nice 286 machine to play with. I bought it as a package with the original keyboard and the monitor it was sold withwhen new, even got the box for the monitor.

I see some things in your original picture that may or may not be part of the issue, see my pic. Being it is nearly all TTL and not a true 286 chipset board (like Headland, etc) even a minor quirk in one could lead to a cascade of issues. Where is U20, U21 and U22 ? Are they under that paper sticker on the board ? Also cannot figure out what should be in the empty socket, to far and no traces to the cpu for a mathco from what I can see. Just curious...

Yes that looks wierd. But it's just flux, when I took that photo I was in the process of reflowing points and then replacing the 287 socket.
Here's a current photo of the board. Yes they are under the now removed sticker. The socket is for the 287 mathco, lots of traces between them on the underside of the board 😀

IMG_5157.JPG
Filename
IMG_5157.JPG
File size
1.78 MiB
Views
151 views
File license
Fair use/fair dealing exception

Reply 24 of 33, by computerguy08

User metadata
Rank Newbie
Rank
Newbie
Vegge wrote on 2020-03-27, 05:24:

I found another EGA card that actually produces an image with supersoft

That looks very promising. You will only have to figure out how to solve that protected mode error and the board may come back to life.

Just out of curiosity, could you try the original BIOS with this exact hardware config ?

Attachments

  • Capture.PNG
    Filename
    Capture.PNG
    File size
    64.65 KiB
    Views
    126 views
    File license
    Public domain

Reply 25 of 33, by Deunan

User metadata
Rank Member
Rank
Member
Vegge wrote on 2020-03-27, 05:24:

So protected mode cpu fails. So from what I can read it's toggled with the reset line from the kbc? I checked the reset line during the supersoft testing. Always low at cpu, and always hi at kbc.

80286 can enter protected mode at any time, but cannot exit it. The only way to do so is to reset the CPU (same goes for the NPU). So the AT boards have a special feature in the keyboard controller chip - it can toggle the reset line so the code can do a soft-reset when required. This process also uses a flag in the CMOS data, and in the status of the keyboard controller, to tell the difference between a normal reset and a mode switch.

So if the test fails but we have no other info about what exactly went wrong, it can be a number of things:
- CPU being bad (that'd be the first one I've heard about but I suppose it can happen)
- 8042 keyboard controller being bad or wrong kind - these have internal internal ROM with program but since the mobo did work for a while I doubt it's the wrong chip
- CMOS data getting corrupted somehow (even with weak battery should not happen on PSU power, but might be a bad diode or solder?)

There seems to be some PAL devices near your 8042, not sure what for, possibly weak? These do go bad sometimes and good luck finding a replacement. Though it might be possible to read them out and use a GAL replacement, but then again if you can read them out then they still work and don't need replacing.

And then there's the 74612 memory expander/controller. First time I see one of those. It's probably used to address the HMA and/or provide EMS banks. See, there's one more aspect of 286 - it has more address lines than 8088/86 so the A20 line must be masked to provide 100% compatibility with XT machines. This is also the job of the 8042 keyboard controller and could be part of the protected mode test. Again, could be related to the PAL chips.

Since you now have something booting with display, I'd start with removing chips and seeing what that does. '612 first, then 8042, then the PALs.

Reply 26 of 33, by Vegge

User metadata
Rank Member
Rank
Member

Removing '612 does nothing except supersoft lists that chip as failed. Same with the 8042. With the U15 pal removed it still boots but fails 8254 Timer channel 2 and 8042 parity.
With either of the two pals at u14 and u19 removed I get no boot at all.

I've been amusing myself with checking connections between chips according to the schematic. All chips around the battery has all their connections. The resetline has all connections.
Just for the sake of checking I removed the din-connector to check underneath, all ok there.

With the original BIOS it's still as dead as a stuffed squirrel.

Reply 27 of 33, by computerguy08

User metadata
Rank Newbie
Rank
Newbie

Well, that's a bummer. There is a very small chance that one or more solder joints around the 80286 have cracked due to thermal expansion over the years. It could be worth taking that HS off and checking the area for any visual imperfections. I doubt the death of the CPU, since it works with the diagnostic ROM.

Reply 29 of 33, by computerguy08

User metadata
Rank Newbie
Rank
Newbie
Vegge wrote on 2020-03-25, 13:25:

J9 is to jumper between the original keyboard and ibm compatible keyboard.

I don't think this will affect very much, but you could install a jumper there. After all , it is related to the keyboard controller and it won't hurt.

Reply 30 of 33, by Deunan

User metadata
Rank Member
Rank
Member

Doh, the 74612 is DMA address extender. I should've looked at the schematics, this really is an early AT clone - basically upgraded XT guts with 16-bit wide data bus and some quirks to support that (and 286 in general).

Anyway, I did look at the schematics now - it seems this mobo is not 100% identical (but very close to it). Since you are not getting anything from the original BIOS and the test complains about protected mode, I'm going to assume it a reset problem related to keyboard controller. It's a start anyway.

On the schematic pin 34 of the '42 MCU goes into a '04 NOT gate, that in turn into a '32 OR gate, and that goes to reset line of the 82284 clock generator. Find that connection, verify it's intact and measure voltage on pin 34 when the system is running. Original schematic has this tied to the keyboard lock, connector J4, as well as J1. I don't quite get how that's supposed to work, unless J1 is meant to be closed by default. Also, the keyboard lock connector might need to be wired.

Then, while at it, check that pin 22 of the '42 MCU is connected to the 74s257 (U59 on schematic) - this is A20 line control. I think by default pin 1 of U59 should be at L level, and pin 15 as well (this one might be toggling). This will keep pin 4 at L as well, causing A20 line to be always masked.

Reply 31 of 33, by Vegge

User metadata
Rank Member
Rank
Member
Deunan wrote on 2020-03-29, 20:01:
Doh, the 74612 is DMA address extender. I should've looked at the schematics, this really is an early AT clone - basically upgra […]
Show full quote

Doh, the 74612 is DMA address extender. I should've looked at the schematics, this really is an early AT clone - basically upgraded XT guts with 16-bit wide data bus and some quirks to support that (and 286 in general).

Anyway, I did look at the schematics now - it seems this mobo is not 100% identical (but very close to it). Since you are not getting anything from the original BIOS and the test complains about protected mode, I'm going to assume it a reset problem related to keyboard controller. It's a start anyway.

On the schematic pin 34 of the '42 MCU goes into a '04 NOT gate, that in turn into a '32 OR gate, and that goes to reset line of the 82284 clock generator. Find that connection, verify it's intact and measure voltage on pin 34 when the system is running. Original schematic has this tied to the keyboard lock, connector J4, as well as J1. I don't quite get how that's supposed to work, unless J1 is meant to be closed by default. Also, the keyboard lock connector might need to be wired.

Then, while at it, check that pin 22 of the '42 MCU is connected to the 74s257 (U59 on schematic) - this is A20 line control. I think by default pin 1 of U59 should be at L level, and pin 15 as well (this one might be toggling). This will keep pin 4 at L as well, causing A20 line to be always masked.

The connection between pin34 '42 and pin11 on 82284 is not intact. The connection is broken between the junction of (r14, r13, d3, c74) and 82284. And if I patch that, the mobo goes in constant reset.
Voltage on pin 34 on '42 is depending on the keylock switch, 0V or 5V.

J1 is open by default, J4 pin 1 is for power led, keylock is connected at pin4 and 5.

'42 is connected to 74s257.
Pin 1 is H
Pin 15 is L No toggling visible
Pin 4 is L

EDIT: Connection not broken, it makes a detour. Hold on.

Here's a quick doodle.

BFAE1C49-48F5-4FA9-A9BB-86EE5FD7CD4F.jpeg
Filename
BFAE1C49-48F5-4FA9-A9BB-86EE5FD7CD4F.jpeg
File size
1003.24 KiB
Views
56 views
File license
Fair use/fair dealing exception

Reply 32 of 33, by Deunan

User metadata
Rank Member
Rank
Member
Vegge wrote on 2020-03-30, 17:03:

Voltage on pin 34 on '42 is depending on the keylock switch, 0V or 5V.

J1 is open by default, J4 pin 1 is for power led, keylock is connected at pin4 and 5.

And that's what I don't get. The only way I see for the 8042 to reset the system is to drive it's pin 34 high (or not drive it at all, since all TTL chips have pull-ups on inputs). But there's an OR gate (U80 on the schematinc) that will just ignore it unless J1 is closed. Because if it's open then the input will read as high and OR with H is always H.
So either this mobo soft-reset works differently (via CPU shutdown signal maybe) or not at all, so it can't actually exit protected mode. Can you close J1 and run the testing ROM again to see what that does? If the systems doesn't boot at all with J1 closed, also jumper pins 4 and 5 on J4.

Vegge wrote:
'42 is connected to 74s257. Pin 1 is H Pin 15 is L No toggling visible Pin 4 is L […]
Show full quote

'42 is connected to 74s257.
Pin 1 is H
Pin 15 is L No toggling visible
Pin 4 is L

EDIT: Connection not broken, it makes a detour. Hold on.

Here's a quick doodle.

That looks OK. Except pin 1 of 74s257 being high, weird, but then maybe it's the BIOS job to disable A20 gate and it doesn't get to that part. Does it change state at all when testing ROM is executing? I'd expect it to change at least during the protected mode test.

Reply 33 of 33, by Vegge

User metadata
Rank Member
Rank
Member
Deunan wrote on 2020-04-02, 12:56:

And that's what I don't get. The only way I see for the 8042 to reset the system is to drive it's pin 34 high (or not drive it at all, since all TTL chips have pull-ups on inputs). But there's an OR gate (U80 on the schematinc) that will just ignore it unless J1 is closed. Because if it's open then the input will read as high and OR with H is always H.
So either this mobo soft-reset works differently (via CPU shutdown signal maybe) or not at all, so it can't actually exit protected mode. Can you close J1 and run the testing ROM again to see what that does? If the systems doesn't boot at all with J1 closed, also jumper pins 4 and 5 on J4.

It wont boot with J1 closed. With 4 and 5 closed on J4 with J1 still closed it boots. But no improvment. So , maybe inactive J1 while keylock active is a "security" feature? So you can't reset system while it's locked. Anywho, tested with both bioses and all configurations of the two jumpers. No difference.

Deunan wrote:

That looks OK. Except pin 1 of 74s257 being high, weird, but then maybe it's the BIOS job to disable A20 gate and it doesn't get to that part. Does it change state at all when testing ROM is executing? I'd expect it to change at least during the protected mode test.

No, it's high all the time, even when it's doing the protected mode test.

Two reflections from my part; I noticed that the ready signal, on the post card, with the original bios shines bright at first then just glows. And if I play with the reset button it sometimes stops on 00 88 or 00 20 instead if 00 FF. This with the original BIOS.

And when supersoft is testing, it passes memory refresh test, but just before it switches to protected mode test the total errors goes up by one.