• Please review our updated Terms and Rules here

Diagnosing sick Turbo XT clone board

Makefile

Experienced Member
Joined
Jul 13, 2020
Messages
151
Location
MD, USA
Hello,

I got this Turbo XT clone board from ebay. It came with no CPU or BIOS. I have put a NEC V20 on. The first sign of life I got was that using an AMI XT BIOS, partway after powering it on the turbo LED comes on, and this didn't happen with no BIOS at all.

I got Ruud's diagnostic ROM booting in it. On a (modern) ISA POST card, I get nonsensical codes like 0xbe and 0xbf that don't appear anywhere in the source. On the parallel port, I am getting the correct codes in the source with three error codes--0x86 (8253 channel 1 failed), 0x88 (8253 channel 2 failed), and 0x8a (8237 failed). Accordingly, none of the BIOSes I have tried nor this diagnostic ROM can make the PC speaker beep.

With the 8253 pulled, I get 0x84 (channel 0) failed plus 0x86 and 0x88 as expected. With an 8253 borrowed from another board, I also get all three codes. Huh? It's like the 8253 this board came with is specially blessed so that channel 0 works enough to pass the test. The Ruud ROM writes 0000h to channel 0 and waits for it to decrement to 0ffffh; can't 0ffh appear on an I/O port coincidentally if nothing is there?

I also tried swapping the 8237, the CPU, the 8288 to no avail. I tried testing with the 8237 pulled (no codes at all) and with the 8255 and 8259 pulled (no difference).

I also pulled all but 256k of the ram and have also tried with no ram at all.

The 8253 clk pins show a 1.19 MHz signal, the 8237 clk pin shows a 4.77 MHz signal.

Ideas? Might it be something with the 74 series logic?

Excuse the overhanging EEPROM which is adapted to work with the 28-pin pinout and known to work in other boards.
 

Attachments

  • 8088.jpg
    8088.jpg
    2.8 MB · Views: 41
This is 10MHz Turbo board. I found this speed problematic. Does it not work in standard speed mode?
When turbo LED comes on it should be running at high speed which is not what you on the scope.
 
This is 10MHz Turbo board. I found this speed problematic. Does it not work in standard speed mode?
When turbo LED comes on it should be running at high speed which is not what you on the scope.

Hello, thanks for the suggestion. This board always powers on in non-turbo mode, then switches to Turbo mode later (perhaps in response to an IRQ0 or BIOS probing at the keyboard controller?). I put a jumper cap over the turbo switch header which prevents switching to high speed and have done all testing that way at 4.77 MHz. The 8088 clk pin shows as such. So, it is not a 10 MHz issue.
 
30mhz Crystal?. Then your V20 it's running at 15mhz in Turbo Mode. Maybe that's mother comes originally with a 8088-10 (/3 clock divider)
NEC V20 can work in 12mhz with no problem, but no way at 15mhz. (ISA BUS cards start's to fail at 13-14mhz...)

Well, from what you said, i think that you already known the below page.
Try to find a motherboard with similar components (to find a correct bios). Or you can even try with "Super Xt Bios".

PD: Come on!, get a Standard 8kb rom for bios :). I've had mixed results with "compatible" roms or +8kb roms. (Well, W27C512 works).
 
This board always powers on in non-turbo mode, then switches to Turbo mode later (perhaps in response to an IRQ0 or BIOS probing at the keyboard controller?). I put a jumper cap over the turbo switch header which prevents switching to high speed and have done all testing that way at 4.77 MHz.
FYI: it is the BIOS that switches your board to Turbo mode. After checking the basic things it checks one the pins of the 8255 whether it is connected to Ground or not and when it is (when placing the jumper in your case), it does NOT switch in turbo mode.

Regarding your problem: do you have other working boards? Then it is just swapping parts. If all removable parts have been exchanged and the donor board still works fine, it is clear that culprit is one of the soldered ICs. If the 8253 works fine on another board, I suspect one of the ICs in the tree for selecting the 8253 is to blame.

Regarding the nonsensical codes: does this ISA POST card support I/O address 80h? I think that this is the standard I/O address. If not, choose one that is supported by your card and recompile the source.
 
30mhz Crystal?. Then your V20 it's running at 15mhz in Turbo Mode. Maybe that's mother comes originally with a 8088-10 (/3 clock divider)
NEC V20 can work in 12mhz with no problem, but no way at 15mhz. (ISA BUS cards start's to fail at 13-14mhz...)

Well, from what you said, i think that you already known the below page.
Try to find a motherboard with similar components (to find a correct bios). Or you can even try with "Super Xt Bios".

PD: Come on!, get a Standard 8kb rom for bios :). I've had mixed results with "compatible" roms or +8kb roms. (Well, W27C512 works).
Hello, thanks for replying. The board has both 30 MHz and 14.31818 MHz crystals. My understanding is that the 8284 divides the input clock to produce a new clock for the 8088 with a 33% duty cycle, where for a clock period the clock is high for 1/3 of the time and low for 2/3 of the time. So 30 MHz runs the 8088 at 10 MHz and 14.31818 MHz runs at 4.77 MHz. I do not understand what you are saying about 15 MHz.

I'm confident the problem is much deeper than the choice of BIOS.
 
FYI: it is the BIOS that switches your board to Turbo mode. After checking the basic things it checks one the pins of the 8255 whether it is connected to Ground or not and when it is (when placing the jumper in your case), it does NOT switch in turbo mode.

Regarding your problem: do you have other working boards? Then it is just swapping parts. If all removable parts have been exchanged and the donor board still works fine, it is clear that culprit is one of the soldered ICs. If the 8253 works fine on another board, I suspect one of the ICs in the tree for selecting the 8253 is to blame.

Regarding the nonsensical codes: does this ISA POST card support I/O address 80h? I think that this is the standard I/O address. If not, choose one that is supported by your card and recompile the source.
Hello, thanks for replying and for writing the diagnostic ROM. Checking the turbo jumper state is definitely implemented in hardware--your diagnostic ROM causes the turbo LED to come on partway through its tests even though it has no code in it to turn on the turbo. I also have a more-well-known DTK board where the turbo similarly does not kick in until the first DRAM refresh cycle. The jumper does inhibit this switch to high speed from happening. But in any case, everything stays at 4.77 MHz with the jumper on so it's not a speed issue.

I have a working board that I have been borrowing parts from. I have not tried the reverse of swapping away the suspect parts and then trying the good board. I will have to try that. I just have to be careful as every extraction/insertion risks damaging the chips.

The POST card works at 80h on other boards, but it is a "modern" one, and I see from other threads they do not work on XT class hardware for reasons I don't understand. I do have parallel working which is where I get the 86h, 88h, and 8ah codes from.
 
Regarding your problem: do you have other working boards? Then it is just swapping parts. If all removable parts have been exchanged and the donor board still works fine, it is clear that culprit is one of the soldered ICs. If the 8253 works fine on another board, I suspect one of the ICs in the tree for selecting the 8253 is to blame.
The "bad" chips (8284, V20, 8288, 8255, 8237, 8253) indeed work fine when transported onto the "good" board. The diag rom goes to code 7, beeps, and loops as expected from the code.

You would point the failure most likely at a 74 series chip and not a passive component?

WRT the 8237 also failing the diag rom test, might it be a 74 series chip up the tree from both of them causing both failures? Or is 8237 inherently going to fail without the 8253 working properly.

Might there be any poking with oscilloscope I can do to pinpoint the bad chip or will this need to wait until a VCF workshop? I'm awful at desoldering so I'd rather not do it without the new chip in-hand.
Thanks
 
If it was eBay surplus board, look it over VERY closely for nicked traces, etc. The smallest one will kill a board if in the right place.

These all got thrown in boxes with other boards and banged around for 30 years or more.
 
I got Ruud's diagnostic ROM booting in it. On a (modern) ISA POST card, I get nonsensical codes like 0xbe and 0xbf that don't appear anywhere in the source. On the parallel port, I am getting the correct codes in the source with three error codes--0x86 (8253 channel 1 failed), 0x88 (8253 channel 2 failed), and 0x8a (8237 failed).
The POST card works at 80h on other boards, but it is a "modern" one, and I see from other threads they do not work on XT class hardware for reasons I don't understand. I do have parallel working which is where I get the 86h, 88h, and 8ah codes from.
At [here] are pictured my modern and vintage ISA POST cards.

The following is what I observe with those two cards. Different make-model cards may differ in behaviour.

------------------------------------------------------------------------------------------------------

1. On my IBM 5160 (IBM XT), I create a ROM to replace the BIOS ROM in socket U18. The only code in the replacement ROM, is code that sends 33h to port 80h.

MOV AL,33H
OUT 80H,AL
HLT


At power on of the computer, I discover that:
- If my vintage POST card is plugged in, I see "33", as expected.
- If instead, it is my modern POST card that is plugged in, I see "FF".

The unexpected behaviour of my modern POST card may be due to the AEN/ALE issue discussed around post #37 and onward at [here].

------------------------------------------------------------------------------------------------------

2. Even with my 'vintage' POST card that can read {bytes sent to port 80h} on a PC or XT class computer, I discover another problem.

From experience, if I was to modify the IBM 5160 BIOS, inserting POST codes at various points, I would discover that as soon as the DMA controller was enabled/activated, that my vintage POST card would no longer show the POST codes. The answer is to disable the DMA controller before I send the POST code.

MOV AL,4
OUT 8,AL
MOV AL,33H
OUT 80H,AL
HLT


------------------------------------------------------------------------------------------------------
 
Hello, thanks for replying. The board has both 30 MHz and 14.31818 MHz crystals. My understanding is that the 8284 divides the input clock to produce a new clock for the 8088 with a 33% duty cycle, where for a clock period the clock is high for 1/3 of the time and low for 2/3 of the time. So 30 MHz runs the 8088 at 10 MHz and 14.31818 MHz runs at 4.77 MHz. I do not understand what you are saying about 15 MHz.

I'm confident the problem is much deeper than the choice of BIOS.
Well...my XT motherboard has a jumper to switch between NEC / INTEL CPU. So it switch cpu divider 2/3. With 30mhz crystal i can run a 8088@10mhz or my NEC D70108HCZ-16 at 15mhz. Not much ISA cards support that, but that's another history.

That's why i prefer to do all troubleshooting without turbo, it's safe.
Maybe it's a hardware failure, not bios. But without the correct bios, it's a blind bet.

Regards.
 
Well...my XT motherboard has a jumper to switch between NEC / INTEL CPU. So it switch cpu divider 2/3. With 30mhz crystal i can run a 8088@10mhz or my NEC D70108HCZ-16 at 15mhz. Not much ISA cards support that, but that's another history.

That's why i prefer to do all troubleshooting without turbo, it's safe.
Maybe it's a hardware failure, not bios. But without the correct bios, it's a blind bet.

Regards.
Ah, that makes sense. None of my boards have such a jumper, so they will always run a V20 with a more lenient clock cycle than it requires I suppose.
 
- If instead, it is my modern POST card that is plugged in, I see "FF".
Thanks for pointing me in this direction if unintentionally. I get "EF" not "FF" on the POST card screen. And I made a custom rom to loop through 00h through FFh and output them to the parallel port. Sure enough, it seems bit 4 is stuck LOW on the data bus when the CPU is outputting to the bus. As there is nothing but one 74LS245N between the CPU and slots, that must be the failed part. It must be "stuck" only in this direction and not with the direction reversed, since the CPU is able to execute code from ROM perfectly fine (Ruud ROM checksum passed and everything or it would have stopped earlier).
 
There appears to be some extra “crust” around some of the pins on the resistor pack between slots 1 and 2, IC12 and IC13. Probably nothing but staining but The data bus is on the resistor pack end of the slots and IC13 is a LS245 so either could cause data bus issues, although I suspect the LS245 between slot 8 and processor is the slot driver.
 
You would point the failure most likely at a 74 series chip and not a passive component?
There are hardly any passive components involved so that chance is very small.

Or is 8237 inherently going to fail without the 8253 working properly.
The 8253 triggers the 8237 so the DRAM is refreshed. No 8253 = no trigger = no refresh = board won't work.

Might there be any poking with oscilloscope I can do to pinpoint the bad chip or will this need to wait until a VCF workshop?
I'm still working on a Debugger for the PC. It enables the user to halt the CPU at any moment, even pin pointed to a given address, and then single-step through the rest of the program. But there is a huge problem: the moment you halt the CPU, the refresh stops as well. So within a second you can say goodbye to your stack and the program in your RAM. In this particular case it would work because you stop the CPU the moment it addresses the 8253 and now you have all the time to check the signals leading towards the 8253.
This "problem" is the reason why this project has a very low priority on my "to-do" list. Just popped up: maybe someone can use the idea to make a small card with some dip-switches that just halts the CPU at a given address.
 
Sure enough, it seems bit 4 is stuck LOW on the data bus when the CPU is outputting to the bus. As there is nothing but one 74LS245N between the CPU and slots, that must be the failed part. It must be "stuck" only in this direction and not with the direction reversed, since the CPU is able to execute code from ROM perfectly fine (Ruud ROM checksum passed and everything or it would have stopped earlier).
A while back my 5150 died and I had to replace one of the address bus drivers because one of the address lines wasn't working. The '245 transceiver is (essentially) two unidirectional bus drivers sharing the same set of pins, so it's not too surprising that it still works in one direction. Seems like a prolonged data bus conflict has happened on your board at some point and destroyed the output transistor in the transceiver. That ummmm shouldn't ever happen in normal operation, and points to perhaps an issue in the bus control logic (the "sea" of 74LS gates), so you'd be wise to put in a socket when replacing the chip...

I'm still working on a Debugger for the PC. It enables the user to halt the CPU at any moment, even pin pointed to a given address, and then single-step through the rest of the program. But there is a huge problem: the moment you halt the CPU, the refresh stops as well. So within a second you can say goodbye to your stack and the program in your RAM.
That would be really neat! While the CPU is halted is there a way to get it to stop driving the bus? You could probably 'inject' synthetic refresh cycles if so....
 
That would be really neat! While the CPU is halted is there a way to get it to stop driving the bus? You could probably 'inject' synthetic refresh cycles if so....
To be able to do so the CPU has to release the bus. And it cannot when it is halted in this way. (do not mix up this situation with the HaLT instruction!)
 
I replaced the 74LS245 and 74LS373 chips with nothing to show for it but three bodge wires to account for the damage I did desoldering. Ugh...
So this has been an exercise of learning an XT schematic.

On the 74LS245 between the D bus and XD-bus--it seems the DIR is stuck low. DIR is fed from output 3Y of a 74LS27. Input 3C to the 74LS27 appears to be stuck low, and comes from output Q1 of 74F20. Input D1b to the 74F20 is from INTA# on the 8288. Input D1a is pulled to Vcc through a 4.7K resistor. However, D1a to GND is only 22 ohms. That sounds bad?
 
I cannot be sure without seeing the schematic you use. But 22 ohms is not a value I expect in a digital circuit.
 
I cannot be sure without seeing the schematic you use. But 22 ohms is not a value I expect in a digital circuit.
I don't have a schematic for this board. I'm using the IBM 5160 technical reference and it was close enough to follow along and identify the AD/D 245, the high address latch, low address latch, D/XD 245, and D/MD 245 and started tracing from there. And yeah, I desoldered the 74F20 and out of circuit it still has the 22 ohms between those pins so seems like at least one of the problems this board has.
 
Back
Top