This motherboard has issues. Let's try to fix it!

This XT clone motherboard was first seen in the video "PC Archaeology: A left for dead XT clone" here on the second channel. It was a machine found in an attic and brought to me by viewer Justin. It never worked right in that original machine and in today's video, let's try to solve this poor abandoned machine's issues.
-- Video Links
Follow-up repair to this motherboard:
• Update: The motherboar...
PC Archaeology: A left for dead XT clone
• PC Archaeology: A left...
Support the channel on Patreon:
/ adriansdigitalbasement
Adrian's Digital Basement (Main Channel)
/ @adriansdigitalbasement
-- Tools
Deoxit D5:
amzn.to/2VvOKy1
store.caig.com/...
O-Ring Pick Set: (I use these to lift chips off boards)
amzn.to/3a9x54J
Elenco Electronics LP-560 Logic Probe:
amzn.to/2VrT5lW
Hakko FR301 Desoldering Iron:
amzn.to/2ye6xC0
Rigol DS1054Z Four Channel Oscilloscope:
www.rigolna.co...
Head Worn Magnifying Goggles / Dual Lens Flip-In Head Magnifier:
amzn.to/3adRbuy
TL866II Plus Chip Tester and EPROM programmer: (The MiniPro)
amzn.to/2wG4tlP
www.aliexpress...
TS100 Soldering Iron:
amzn.to/2K36dJ5
www.ebay.com/i...
EEVBlog 121GW Multimeter:
www.eevblog.co...
DSLogic Basic Logic Analyzer:
amzn.to/2RDSDQw
www.ebay.com/i...
Magnetic Screw Holder:
amzn.to/3b8LOhG
www.harborfrei...
Universal ZIP sockets: (clones, used on my ZIF-64 test machine)
www.ebay.com/i...
RetroTink 2X Upconverter: (to hook up something like a C64 to HDMI)
www.retrotink.com/
Plato (Clone) Side Cutters: (order five)
www.ebay.com/i...
Heat Sinks:
www.aliexpress...
Little squeezy bottles: (available elsewhere too)
amzn.to/3b8LOOI
--- Links
My GitHub repository:
github.com/mis...
Commodore Computer Club / Vancouver, WA - Portland, OR - PDX Commodore Users Group
www.commodorec...
--- Instructional videos
My video on damage-free chip removal:
• How to remove chips wi...
--- Music
Intro music and other tracks by:
Nathan Divino
@itsnathandivino

[@necro_ware]

A lot of people think, that a repair is like you'd always know what the issues is. And in reality you sit there with a multi-meter and an oscilloscope in your hands and measure signals, desperately trying to follow some ideas, what it could be. In my opinion, the most important tool for this kind of work is patience, just a lot of patience :D Anyway, this is a very interesting case indeed, I'm very curious about the outcome, but unfortunately I have also no clue. If I would see such a behavior, I would probably end up with a logic analyzer on IRQ, DAK and DRQ pins and watching if there is something happening, what makes sense. And btw. as I saw the XTIDE card the wrong way around a second before you turned on the PC I was literally screaming "Adrian! No!" at my screen. You know why? Because I made the very same mistake just couple of weeks ago. I hate the symmetry of that card and I was almost doing that stuff couple of times already, but I always was able to notice it in the last second. Well, until that last time. Now I screwed a bracket on one side, which totally doesn't fit, but at least next time I should not insert the card the other way around. Unfortunately in my case not only the EPROM, but also the 74HTC573 were both dead after getting 12V. And I had no replacement parts at hand..... Thank you very much, just as always very entertaining and educative too!

[@soberlife]

Found your channel a few weeks ago, great content!

[@JE-wd4lu]

Agreed - it's not always that obvious as to what the cause of the error is. But, I'm very interested to see how this turns out. Following your channel as well 👍.

[@asanjuas]

I think , in... Change the DMA controller

[@adriansdigitalbasement2]

Ok issue found -- will be publishing a quick follow-up where we see the problem in action

[@necro_ware]

@@adriansdigitalbasement2 Ah! Super cool and exciting.

[@robbiesz]

Adrian, put the bracket on the xtide card. You will never make this mistake again. Awesome content btw!

[@notneb82]

yeah, was going to say this too. I have three of them and never make the mistake due to the simple bracket being in place.

[@BrainSlugs83]

I think you have to remove the bracket for ISA mode (at least on mine, the bracket is for the PCI mode).

[@adriansdigitalbasement2]

Hello everyone!! There is a follow-up video to this one, so once you finish this one, go check out the follow-up. It will answer many of your questions.

[@kaitlyn__L]

“Parts scan”, now THAT brought back some memories! One time when our car was in the shop, my mother was very impressed at the “high tech scan” they were going to do to find a gremlin. She was told something like “we’ll have to run a parts scan, it’ll take a couple days, and that will hopefully turn-up the culprit”. Good to know they were just desperately replacing parts and probably lots of swearing!

[@cracyc00]

The machine timer IRQ is required for BIOS and DOS to work so that's why it hangs without the PIC. The DMAC drives the DRAM refresh so it definitely wouldn't work properly at all if it were damaged. As for the NEC PIC working at higher clocks, it's a CMOS part while the Intel is NMOS.

[@pipschannel1222]

Yeah, that would also explain the temperature difference. The original Intel 8259 gets way hotter than its NEC CMOS counterpart.. Those early IBM N-channel MOSFET semiconductors were known for their heat dissapation which gets pretty intense, especially when compared to their newer, more efficient CMOS counterparts. With the early 8087s vs later CMOS versions for instance the difference was also staggering. The early ones (3 μm depletion-load HMOS) were like little nuclear ovens while the later CMOS ran barely at room temperature, because they literally did nothing when "idling" ;-)

[@piwex69]

I had exactly the same Turbo XT board with 10MHz V20 in 1989, my first PC! I remember spending hours and hours just mastering marvels of DOS3.3 and dwelling into Sokoban feat!

[@8o86]

I had an issue with a similar symptoms on an XT of mine -- everything looked okay, but as soon as MFM hard drive or a floppy tried to read things, it would read garbage. Turned out that one of the 74xxx-s in the address decode logic of a MDA card would generate a small pulse on an output line whenever its input changed. The glitch didn't disrupt regular memory accesses, but affected the DMA transfers. Not sure what the morale is -- but perhaps it's also something disrupting the DMA transfers while being minor enough not to affect I/O cycles generated by the CPU.

[@8o86]

Perhaps something gets selected when it shouldn't or some of the bus buffers are not tristating when unselected. First try a different graphics card. Then perhaps trigger your scope on the DMA channel line or AEN and look at what is going on with chip selects that are on board.

[@davefiddes]

Bit of a stab in the dark but there should be a 74LS670 that holds the upper part of the DMA address (the lower 64K is under control of the 8237). Maybe that's bad (in whole or part). As other have pointed out the DMA must at least partially be working otherwise the DRAM refresh would fail.

[@enojelly9452]

I feel like that's the best theory so far. If the upper part of the address is all 0 for example, the DMA controller might end up overwriting something at the base of memory, where all kinds of critical stuff awaits. The interrupt vector area, the BIOS data area, DOS...

[@adriansdigitalbasement2]

I just took a look at the board, and wouldn't you know it a LS670 is right below the slots right next to the area that got dripped on by battery juice... and it's definitely the one related to DMA as it has lines connected to the DMA controller. Now, looking at the XT schematics, it seems the 670 handles address lines A16-A19 -- so I would think if that chip were bad, DMA would only work with the first 64k of RAM and then the DRAM refresh wouldn't work.... Now looking more at the board, I see more possible trace damage under a nearby LS280 -- I'm going to have to remove it to inspect.

[@OliWright64]

I had a very similar issue on a 5150. In my case the problem turned out to be with the 74LS logic around the DMA controller. Specifically, the address latch LS373 in U18 was bad. So data from the floppy controller would end up at the wrong address in memory. But everything else was good. The DMA controller was good, and all the control signals were good. The BIOS was oblivious to the carnage. As far as it was concerned, a good sector of data was transferred from the floppy controller to memory.

[@adriansdigitalbasement2]

The LS373 latch was definitely dripped on by battery goo LOL. Also strange I was checking traces and it turned out that part was rebadged!! I was cleaning up with alcohol and the marking came off revealing a Motorola 373 part underneath. How unusual. I'll pull it to check it -- just for fun.

[@adriansdigitalbasement2]

WELL GUESS WHAT!? That was it. And interesting is is this chip test properly in the retro chip tester pro, but I put in another one -- and bam, machine is now booting. Put the old one back in, original problem. The rebadged nature of this chip was really a giveaway -- I wouldn't have noticed if it weren't for using alcohol in that area.

[@eDoc2020]

@@adriansdigitalbasement2 You could have given a spoiler warning. Hopefully I'll forget before you show this board again.

[@OliWright64]

@@adriansdigitalbasement2 It Freakin' Works! - That's awesome! You were the one that tought me not to be afraid of looking at schematics - I owe you huge thanks - you're awesome. This is what I've been doing with my 5150 BTW if you're interested (only a couple of minutes - just a bit of fun) kzbin.info/www/bejne/fGjRhHR7l696gtE Have a happy and safe new year :-)

[@krnlg]

My first thought is to check connections to the interrupt controller (as you mentioned at the end) and any buffers on there, as the fact that accessing A: throws out Ctrl-C as if the keyboard is doing something kinda... feels like the interrupt signalling is getting screwed up somehow.

[@TyphinHoofbun]

I really don't know enough about the inner workings, but the ^Cs that pop up make me think the issue is interrupt-related somehow. Possibly a damaged line causing flaky behavior? Of course, I'd have to do a lot of research just to know where to even start looking, so I doubt I'm gonna be of any help.

[@Zerkbern]

This is one of my favourite videos of all time. Failure is just as important as success. Thank you for sharing it.

[@jeromethiel4323]

Shotgunning parts is a valid troubleshooting technique. It's what you do when you run out of other ideas. I have fixed a LOT of equipment by swapping parts out.

[@fossisoft]

Because of the battery leakage you mentioned I would start testing the ISA slot connectors. But we saw with your cool post card that the IRQ worked. So check the 74xxx chips connected to the dma controller would be my next step.

[@epindigozylacone5730]

Sorry for the interruption, small screen. You seem to have covered just about everything easy. Now you can focus on the hard. Might ask your viewers for documentation. Well, good luck on your mission, Adrian. Hope you don't have to part it ( out ).

[@retropuffer2986]

Good to see people saving vintage clones.

[@lordmmx1303]

I have to admit, I've enjoyed this episode of Adrian's Parts Cannon.

[@pintokitkat]

Ah, those rubbon shirts. They are tricky!

[@YarmouthHoops]

“ I was about to end the video here”.. thank you for continuing!!

[@ovalteen4404]

It's sad that the Kickstart board left off the IRQ0-2 lights. Yes, on a functional system IRQ0 will always be lit (18.2 triggers per second from the timer), and IRQ1 will light up every time you press a key. But the reason for a diagnostic board is that you might NOT have a working system. IRQ2 on the PC and XT was available for use, then it became the slave IRQ line for the second PIC in the AT and above. 3 and 4 are COM, 7 is parallel. So 5 and 6 were available for expansion cards, one taken by the hard drive and the other by the floppy. IBM set up DMA line 0 for RAM refresh. Seems perfect since it can count through memory and it negotiates with the CPU for control of the bus already, and places addresses and MRQ/RDs on the bus whenever the CPU gives the all-clear. Timer channel 1 generates the DMA request pulses for this DMA line. So the timer must also be working properly to boot a functional system. The ^C appears when the BIOS writes into a spot (0x0040:0071) that says you've pressed CTRL-BRK. DOS samples this when it uses its I/O functions and responds with the ^C that you see. It then resets that location. So if you see ^C's happening a lot, it's a good bet that either the memory chip in charge of that location is dead, or the BIOS is constantly setting that flag. One possibility would be to use the real XT BIOS chip in it. It sets the break flag and clears the keyboard buffer when it detects the scroll-lock key while CTRL is pressed, and only in that circumstance. Perhaps that other BIOS has other occasions where it will set the flag? Orrrrrrrrr..... perhaps the DMA controller's address lines are not all making it to the appropriate address pins at the memory chips, and DMA-based disk access is overwriting the BIOS data area? Possibly even the interrupt table (leading to the system lockups), and possibly the break flag location is corrupted because DMA refresh doesn't always touch that portion of memory? I don't know how this clone did things, but the 8237A DMA controller outputs the high 8 bits of the address on its data in lines. So it's necessary for those to be buffered so that the data lines can be open for the memory transfer. The PC/XT uses a 74LS373 chip (U11) for that purpose. If its analogue on this board died or were not fully connected to the address traces, pandemonium would result. Oh, and one last thing: There is an addressable latch (LS670) that stores the top 4 bits of the destination address. It is mapped into port space at 0x80+channel, off the top of my head. The DMA controller can only address 16 bits, so you need this extra 4 bits to make the entire 1MB address space accessible, in 64K banks. So it's also critical for this chip to be working properly. And another edit: IMD uses DMA and IRQ! However, it uses a clean 64K-aligned page for its buffer, so it must always be writing a nonzero value to the page register. DOS is likely loading into page 0. So that makes the LS373 the likely culprit. If you run DEBUG from your XT-IDE card, then load a sector into various locations at 1000:xxxx using the "L" command, where would that sector actually end up?

[@themegaman91965]

I would absolutely love to see the original Duke Nukem 1 from 1991 run on one of these on one of your repair videos, or any 80's DOS game! Been watching these videos for a while, and is pure therapy; keep up the excellent work! :)

[@OscarSommerbo]

I wonder about the big clue many seem to be missing (or I missed them) are the spurious "Ctrl+C" (and once changing color) it might be a red herring as Adrian tried to eliminate that error. My guess is a messed up latch chip on the address bus, the same guess as many others. Oh, btw, great youtubing calling your own video terrible, that made me laugh. Never change Adrian, keep being honest, it is so refreshing.

[@talideon]

It's a bit of a long shot, but I'd check the caps, including the ceramic ones, to see if any of them are dead shorts.

[@PyroRob69]

Hehe, Turbo XT. I remember those. People thought they were the nutz. Amazing thing is, 30-40 years later, Arduinos have more power in about the size of the original 8080 or 8086's

[@Nukle0n]

kudos on you including the gaffe with the XTIDE, and not just being ashamed and editing it out. But yea, see if you can't put a bracket on there, even a 3D printed one.

[@michaelblair5566]

I've been a PC technician since the 1990's after the XT/286/386 era and there isn't anything wrong with what you tried.

[@JVHShack]

The only thing that I can think of is to try to change the IRQ and/or DMA for the floppy and see if that helps. Also, you could pull a "trial and error" approach to the DIP switches and document your findings. You may advertently unlock the faster speed of the V20 CPU. Being that there are 8 switches, there are about 512 possible combinations maximum.

[@truezulu]

I would test all the ISA slots first. Then make sure the floppy drive actually works. Sometimes drives will fail just sitting on a shelf.

[@enojelly9452]

I don't think a faulty drive alone can produce the weird issues we see when DOS is trying to access the drive. A faulty ISA card (or slot) potentially could, if it critically interferes with the bus.

[@CoverMechanic]

Another vote for bad or bridged trace, those Ctrl+Cs look like the FDC is asserting the IRQ1 line somehow (pin 19 on the PIC), which is the keyboard controller interrupt. Might be worth getting a scope on that. Also the interrupt vectors in the first 1kb of RAM could be screwed up, might be worth dumping those with debug and making sure the entry for IRQ6 isn’t pointing somewhere weird.

[@fnjesusfreak]

That BIOS is the ancestor of the BIOS you replaced it with.

[@shad0v]

What I know is : On some motherboards (even way newer , like 486 class, but at the beginning or pre - Plug and Pray ) some interrupts were available only on specific slots (Like: the signals for some reasons were not getting there), so in order to use a controller with specific interrupt you needed to use specific group of slots, and it was a matter of juggling the locations of the cards between the slots to make them all work. I remember groups of 4 interrupts per group of slots, for example, the VGA card was getting errors and not working properly when putted in the last 4 slots of the motherboard. On one of my machines there was literally a one single sequence of cards that was working properly and without conflicts, other orders were causing problems or freezing the whole machine. What it may suggest is : either some signals may be missing on the ISA slots (corrosion, it may be on some of them), or the controller must be in a specific slot / or specific order with other cards. Software access may just override the whole problem there.

[@john_in_phoenix]

Looked like it was thinking you have a single sided floppy drive. It's been a few years, but I worked in the factory making the IBM PC from 1981 to 1987. Interesting channel, but it seems to only have a single crystal oscillator (color burst frequency divided by 3) so it will not have a turbo mode. 8259C is not compatible, we had a memorable batch with those. Interrupt controller is used in memory refresh (along with the 8237 DMA controller). It's not possible to work without the 8259 or 8237.

[@twocvbloke]

Haven't a clue what the issue is, but sometimes the "parts cannon" can often yeild some interesting results, even if unintended or not fixing the issue at hand... :)

[@nticompass]

I once put an EPROM chip into a NIC backwards. When the computer powered on, the EPROM created a lot of smoke and there was a hole in the center of the chip. Luckily, the NIC was fine (the EPROM was dead, putting one in the right way worked ok).

[@pyromiko]

Happy new year Adrian!!

[@smakfu1375]

Just a quick note on the ROMs: I don’t recall watching the video about the laser xt, but the discrepancy in ROM sizes between this machine and the XT probably comes down to ROM resident BASIC. IIRC, IBM’s had the BIOS routines plus BASIC in ROM, whereas a lot of close just implemented the (reverse engineered) BIOS routines. On the PC and early XT’s (both had 5 ROM sockets) If using 8KB ROM’s, the first ROM was BIOS, and then 4 additional 8KB ROMs held BASIC. The final empty ROM socket was probably reserved for some type of additional option ROM. (If using a larger eprom type, you could probably cram everything into a smaller ROM set). Later models only had 2 sockets, and my guess is that IBM, rather than sourcing one 8KB ROM and one 32KB ROM, just went with two 32 KB ROMs (one holding the ~8KB of BIOS routines, and the other having the ~ 32KB of BASIC). My guess is that on this clone, you probably had to pay extra to have Microsoft Basic (IBM Basic was licensed from Microsoft), which would have been fitted by the dealer as “option ROM”. As the original IBM BIOS was only around 8KB, my guess is the clone BIOS is very similarly sized. It’s be interesting to dump an IBM official BIOS and this clone BIOS, and compare the disassembled output to see how similar they actually are. I vaguely recall (as a kid) reading articles about IBM legally chasing after clone manufacturers who’d simply copied their BIOS outright.

[@sparcie]

I realise you've already fixed the problem, but I wanted to make a guess before I see the solution and see if I'm right! I think perhaps the Programmable Timer chip or PIT. It generates interrupt 08 and that didn't seem to be working. Interrupt 08 is important for floppy access as DOS uses it for turning off the motor amongst some other things... Now to watch the second video to see if I was right!

[@timrichter1980]

Always nice to see those old boards. Btw., is there a cheap case solution for old boards? I have a old Commodore PC motherboard but no case for it. I guess newer ATX cases won't fit, even when modified with extra holes for the screws. Ebay prices are out of hand, and I would be happy with a kind of hacky solution.

[@ulerhond]

The one thing that you mentioned that you didn't follow up on was checking for damaged traces on the board. :)

[@diorthotistm1621]

I think the issue is that it's very old. 19:22 "DIR a colon", what is DIR? I hope it means wash. 19:28, "DIR a colon enter." No bro, exit only!

[@lexluthermiester]

@Adrian This was not a terrible video. That board has a squirrelly problem. You might have been right when you suggested that it might not have the correct BIOS installed. It keeps detecting a gameport and there isn't one. This is my guess as well. Maybe try to find the right BIOS?

[@Quickened1]

Feels like a dip switch to me but idk... Without stating the obvious here, you are sure the ribbon cable to the drive is fault free, correct? Back in the day, I would have thrown in the towel on this one, a long time ago! Props to you, for your persistence!!!

[@kevinshumaker3753]

Did you try the Floppy controller(s) in different slots? Move the cards around in the various slots (all slots are equal, right? :) ) and see if the slot that had the bad battery is the problem...

[@robblaize]

Back when I was fixing PCs for a living this would be the point where I would inform the customer that this PC needs a new motherboard 😃 but seriously I am not sure that a damaged trace would be the cause, since I assume that would affect the expansion bus and cause issues with any other cards you may be using. My guess would be a BIOS compatibility related issue.

[@enojelly9452]

Even an XT PC is rather complex, and a small fault can manifest only in specific circumstances. For example, floppy controllers are one of the rather few users of 8237 DMA (others being sound cards), because counter-intuitively that's actually so terribly slow that it was mostly avoided.

[@SidneyCritic]

So long as there is a mystery, it's always a good vid - lol -. If you have a piece of 5/8"/16mm board to put under the MB, it should lift the MB enough to clear the low hanging metal part of cards.

[@fragglet]

Kind of amazed it gets even that far without an interrupt controller present

[@telocho]

I remember buying once a 8087 numeric coprocessor for my XT with 8088 processor. Not a lot of programmes made use of it, though. MathCad got quicker.

[@ImmortanJoeCamel]

Did you try the floppy controller in a different slot? That phantom joystick is still spooky though. Given there's so little hardware to a joystick controller I'm wondering if there's something screwy with an IO address causing it to get a bit confused.

[@RudysRetroIntel]

Hello Sir! Great video! Here is a suggestion for you. Since you are able to seet the disk work with your diagnostic card, not sure which one, I believe it's a BIOS/software issue and not a hardware problem. See if you can find a clone ROM image. I know you made another one, but I don't think it was correct. It shouldn't detect Turbo mode of you don't have any of the parts and crystal. Just a thought.

[@ArcticWind444]

IIRC to change the speed on my old machine it was ctrl+alt+up/down arrows. You could always try that.

[@monchiabbad]

Test the floppy as the B drive. Change the floppy switch/connector.

[@FullMetalFab]

You can still see the dislike they just only make it visible on the channel dashboard somewhere, kind of stupid considering how the explained the reason for why they did it the way they did...... on a more teck related thing I have a box of XT boards in need to get around to testing so you parts canon approach will come in handy lol

[@Dukefazon]

32:45 - what!? Even the creator can't see the downvotes!? What the hell, I didn't know that! YT is insane!

[@subg9165]

they can, but only on the analytics page now

[@vatesedgar]

Love all of your content! So informative

[@PCRetroTech]

I don't know what the problem is, but I had an XT motherboard where the floppy controller only worked in certain ISA slots. Other cards worked in those slots and I could see no reason for the issue on the board itself. It was optically perfect and the slots were not dirty. I still don't know why that happened, but it's worth switching the cards around and in fact removing all cards that are not necessary. I suspect this was probably some issue with interference and/or supply voltage or something. But whatever it was, I couldn't figure it out after way too many hours trying. Repairs like this one aren't as uncommon as people might imagine. One would be tempted to show more failed repairs, except experience tells me I've usually missed something "obvious" which every viewer can see but which I can't. Usually I would suspect a BIOS issue in this case, but since you all but eliminated that....

[@nathanwoodruff9422]

Try changing the dip switches for the number of floppy drives in the computer.

[@rlgrlg-oh6cc]

Interesting that you get Ctl-C on the screen when doing disk access. Maybe see which interrupt fires when you type a key and see if that same one is activated by disk access? Or maybe scope the serial data coming from the keyboard and see if there is a glitch on it when you access the disk. Maybe some other signal is shorted to it?

[@RandomInsano2]

Others have stated (and a few too many comments to review them all) but my theory is the battery leakage damaged the interrupt traces from the sockets to to PIC. The slots are wired in parallel right? So any diagnostic cards would see the signal but not the controller. It’s sitting waiting on a signal that never comes? Could be the lines floating are causing the Ctrl+C (SIGINT according to Microsoft)

[@knghtbrd]

I'd start checking DMA lines to the ISA sockets. IRQ as well. Check those traces! (And I'm sorry.)

[@TalesofWeirdStuff]

Very odd... I am having very similar problems with the AT&T PC6300 that I have been working on recently... except the floppy was initially working.

[@OzzFan1000]

I think you were onto something with the potentially damaged traces. I think you should try checking continuity on the parts that are acting up to see if there's any problems there.

[@andrasszabo7386]

I'm in the same pair of shoes, Adrian. Only difference is that my machine is a laptop with some slightly modified bios. If a sticker falls off from the top of an EPROM, making the window visible,will its contents be damaged after a while?

[@saintcrispan5068]

People make a big deal about this, but if it's inside a machine (in the dark, isolated from UV light) the time it'd take to erase the chip would be a looooooong time. I mean, think about it...to erase one, you literally have to blast it with concentrated light for a good period of time.

[@Arti9m]

You can go full 200% on "replace another part" path. Yes, this is not the best strategy for diagnostics, but A: it will absolutely eventually work and B: you will gain even more experience at desoldering stuff =) You can even replace parts in bulks, like 4 logic ICs at a time.

[@Qyngali]

Hm, can't be a cut trace or any hardware fault since you were able to image floppies with software... the hardware obviously works so it has to be bios related IMO. Edit: Or possibly the dip switches? It's probably been decades since I touched an XT but I don't think it can be anything else than these 2 things.

[@leeharveydarke]

Has to be the BIOS IMO - we know that the drive is going as far as being seen in DOS. Especially in these earlier clones I think the absolute correct BIOS is required for the controller to be able to speak to the bare metal.

[@jeffreyphipps1507]

@@leeharveydarke If the drive is being seen, the controller is being seen. However, if there's a bus conflict (potentially because the dips are not set right) across the IRQ the action will not work. In my experience (I used to work on a lot of these clones) it's very likely that the dips are set wrong. I need to see if I can find the actual board name. HP always stuck in out-sourced boards.

[@enojelly9452]

We don't know if the software used to read the floppy read it *correctly* (that's something to check), and whether it did or not, in both cases the software may drive the hardware in a way that does not make the fault apparent. For example, if another commenter's (David) theory is correct, the DMA controller might read the sector into the wrong location in memory... causing havoc for DOS, but maybe not being apparent for the software since that part of memory may not be used by it right now. (In that case, the software would not see the proper sector content, hence my suggestion to check if it can read the sectors correctly. Maybe by trying to copy a disk.)

[@OscarSommerbo]

@@enojelly9452 I am pretty sure it read back the 18 sectors it saw, the software reports back read sectors.

[@enojelly9452]

@@OscarSommerbo watched it again and not sure what you mean. He just put the software into read mode, and it only said that it read the sectors without media error. I did not see any indication of what the sectors contain, and even then I don’t think Adrian verified that that content is as expected. If DMA happens to the wrong address for example, the sector would read successfully status-wise, but the data won’t be in the right buffer for this software (or DOS) to use.

[@AntonyTCurtis]

Bad DMA traces (DMARQ/ACK)can cause issues. Many floppy diagnostic and disk copy utils used PIO instead of DMA (in order to defeat copy protect). Originally, DMA was used for hard drive - usually DMA 3 but I may be wrong. DMA 0 is required on XT machines for DRAM refresh. Of course, SoundBlaster usually used DMA 1. DMA became less used because it was limited to less than 5MHz, even on AT machines into the 486/Pentium era. 3com made their ISA busmaster cards which did DMA without the motherboard DMAC because of this performance issue. Of course, PCI busmaster spelt the end of the DMAC.

[@S0urceror]

Check continuity from the slots to the other components.. Start with the DMA. You said there was corrosion before.

[@neverthehero566]

Is there a bad trace? Tune in next week when we hear our dynamic hero say: "It freaking works!"

[@G7VFY]

Floppy drive and VGA could be clashing. Also, trying replacing the floppy drive with a known good 360kb double sided floppy drive.

[@G7VFY]

When installing a EGA or VGA card in a PC/XT set the motherboard switches for NO CARD.

[@skyoreece9805]

Well done, you did ur best and I know you will fix it x

[@ProjektSUN]

Take a drink every time Adrian says "Turbo" 😆

[@tw11tube]

The system doesn't boot without the DMA controller, because the early POSTs by IBM really tried to test every aspect of the board. If the DMA controller doesn't respond, the system detects that it is faulty and doesn't continue booting.

[@klenchr3621]

Love the mobo repair videos the best

[@pc4ad]

Did you try Ctrl + shift + shift? Might be an option too to turn turbo on. It was on a PC I remember from the past. Just don't know the make and model anymore. Also - the jumper settings might not have been copied from the original IBM - What can go wrong by moving them?

[@obiwanjacobi]

Any news on checking the board for corrosion and/or cut traces?

[@GarthBeagle]

I mean it could still be an issue with the interrupt or DMA controller, a bad trace would cause a fail with either chip right?

[@adriansdigitalbasement2]

Yeah totally! I really need to insert my ISA proto board and make sure those signals are actually connected. I’m not sure though if there are buffers in between. (Not having schematics)

[@tarzankom]

I question the DIP switches. If the motherboard cannot be positively identified, there's always a chance that a revision was made to the switches you need to use. I think this is unlikely, but still a possibility. You seem to have covered everything else quite thoroughly.

[@StevenIngram]

This may be a ridiculous question... but have you checked that the ribbon cable to the floppy drive is working correctly?

[@dennisp.2147]

Not ridiculous at all. That's basic troubleshooting.

[@enojelly9452]

I feel like your hunches about an interrupt or DMA problem were closest. Those spurious Ctrl-Cs seem like the CPU might end up somewhere it shouldn't, or at the right place but executing code that it shouldn't. As a theory for illustration, what if in the cycle where the interrupt controller tells the CPU what interrupt number occurred (the second ~INTA cycle) a bit gets mangled? The CPU would jump to the wrong handler, potentially causing weird issues. You already swapped the interrupt controller, but maybe a trace or some glue logic is damaged? Or maybe it is DMA-related after all, given that that could overwrite memory that causes real problems real quick (the first 1024 bytes for example are the interrupt vector table). EDIT: Come to think of it, checking whether the software you used to read the disk is able to read the disk *correctly* (try e.g. copying a disk?) should be able to at least quickly address (pun intended) e.g. David's theory. If the disk is not correctly read, DMA looks more and more suspicious: It may be happening, but not to the right destination.

[@DavidWonn]

Have you tried Control + Alternate + another random key?

[@kd7cwg]

On the cpu comment. I personally seen a bad cyrix 6x86 not accept a windows 95 product key 😳. That was an interesting one to figure out

[@Astinsan]

Did the bus clock match the cpu clock? Should be the same.. if not It could be the issue. All the timing on the board on xt uses one clock reference. The nec cpu could be one part of the tweaks done..

[@andygozzo72]

give those dip switches a squirt of contact cleaner and operate them up and down a few times, then re set and try again , may be iffy

[@WindedDragonn]

That's very interesting that you can't see dislikes also, I was under the impression the creator can see them just not viewers. Also there are extensions for most browsers that show the dislike count again!

[@heffe2001]

Yep was coming to say the same thing.. IF you're using Chrome or Edge, there are plugins that show the dislikes again since it was just a display change they made, not an actual removal of the data.. Currently shows 412 likes, with 4 dislikes as of my post.

[@Storm_.]

Maybe Rammy has been having midnight snacks! Explains the missing ram chip!!!

[@u2370]

Is it possible to change the DMA channel and/or the IRQ to see if something else would work? Other than that, it does smell like some crosstalk somewhere with the ^C or some strange broken/partial high ohm trace.

[@JanEringa8k]

Floppy dip switch settings? Only 4 possible combinations... Maybe worth a shot in the dark?

[@JCCyC]

Correction: keyboard is IRQ 1, not 2.

[@peregrine1970]

Honestly, the only thing that comes to mind is, did you check with a 360k or 1.2 drive? I remember on some of the early stuff I had issues with a HD floppy drive on my xt. Back in those days I was fresh over from apple after they took away my command line, so I wasn't all that familiar with PCs. It wasn't really until the 386 days that I got in to the hardware side on PCs.

[@ki85squared]

'rubbon on the microphone" ❤️

[@johng.1703]

with the text colour change, that would suggest memory issues, faulty ram or addressing issues.

[@pangroszek3498]

I have turbo clone and mine have two oscillators one is 24 MHz (divided by 3 it is 8 MHz, 4,77*3=14,xxx). I would try to use older Dos The schematics are in the manual at the end but You have to check if it your version.

[@Eyetrauma]

Could those control codes that show up be any indication? The KB and floppy should get their own IRQ, right, but is it possible that through some means (configuration, corroded traces, I dunno, line noise?) that they're stomping on each other somehow?

[@andygozzo72]

you dont know the 'replacement' dma chip is good as you said they're untested, it may also be bad in the same way..?

[@freefall2003]

You check the traces on the bus? And the connector

[@CraZy88uk]

try this adrian DTK PIM Turbo 10-V01 or DTK PIM TURBO PC/XT MOTHERBOARD 8 MHZ

[@Paberu85]

Ok, the disc spins and definitely tries to read, so it does not seem like bootstrapping or software issue (although it might be some funny business with bioses fdd geometry settings, but the way system acts makes this highly unlikely). Communication cpu->fdd controller seems ok, controller receives and seems like responds correctly to seek command (although I haven't seen a head movement, try moving it with OmniDisk dos program (and btw, if it moves - count number of tracks from min to max pos to rule out possible geometry issues)). I bet problems begins when fdd controller configures dma controller for transferring data from it's sector buffer to the ram. Theres basically 6 steps to access data from FDD: 1) CPU talks to fdd controller, sets drive number turns on spindle, configures basic stuff like requirement for controller to recalibrate fdd heads. 2) Then CPU sends SEEK command to controller and waits for IRQ6 to occur (data bit 7 is set to 1 to indicate sector was found successfully). 3) DMA controller initialization (- sending a 46h read code, or a 4Ah write code to ports 0B and 0C of DMA ctrlr; - calculation of the 20-bit memory address of the buffer in DRAM, where the data from the sector buffer will be sent; - uploading the calculated address to the address registers 04h and page 81h of DMA channel 2; - decrement of the channel 2 byte register-counter (port 05h) of DMA ctrlr; - enable DMA channel 2 (transfer of byte 02h to port 0Ah)). 4) CPU then sends READ command to fdd controller, and it in response transfers its sector buffer content to the RAM via DMA controller. 5) when transfer is finished - IRQ is generated, and controller and disk statuses are set at 0040:0042, 0040:0041 respectively. 5) disable drive's motor. In short words, I would start with checking data/address bus integrity between cpu->dmactrl->irqctrl->fddctrl->ram (unfortunately).

[@TotoGuy-Original]

how about using the chip tester to test some of the chips if it can?

[@Arachnoid_of_the_underverse]

Maybe check the jumper switches with your meter to see if they are actually connecting? You might also put the files on the C drive and run some dos based checks from there i.e is the rest of the system working apart from the floppy drive.

[@eshwayri]

Maybe trace the dip switch connections for the floppy drive back to where they connect? and verify the dip switch itself isn't faulty?

[@eak125]

I noticed the error checking ROM said there was a math coprocessor error. Yet you set the dip switches to on, on. Was that to disable or enable?

[@RevCorpus360]

You said about the fpu when checking the switches. Was it sent as one being present compared to the diagram?