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!
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 👍.
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.
“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!
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!
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.
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" ;-)
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.
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.
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.
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.
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.
@@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) th-cam.com/video/F7nSAEbJGLo/w-d-xo.html Have a happy and safe new year :-)
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.
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.
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.
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.
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...
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.
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.
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?
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.
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 ).
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.
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.
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.
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! :)
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... :)
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.
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
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...
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).
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.
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!
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.
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.
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.
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.
@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?
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)
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.
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.
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!!!
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.
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?
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.
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
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....
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.
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.
@@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.
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 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.
The difference to the car industry is that in the car industry you make the customer pay for every part that you mindlessly replace during the "parts scan".
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.
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.
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!
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.
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)
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.
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.
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?
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.
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.
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?
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.
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.
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..
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?
I have a similar board, it's power connector is not the same as the usual P8/P9 connector. Is yours having problems fitting there. Could it be something needs different wiring, or -5v.
Depends on what the cap is there for, but probably. Manufacturers don't put caps in for LOLs: it's probably there for AC decoupling or some kind of power smoothing/filtering on a chip that might not be tolerant of fluctuations. It could also be there for timing purposes, in which case the card wouldn't work right at all with a broken cap.
![Adrian's Digital Basement ][](http://yt3.ggpht.com/ytc/AIdro_k7CrQRe71qN6c0Ua7A1P_I8KkxjqLa70u0zYeCvdvnKw=s48-c-k-c0x00ffffff-no-rj)
![Top 40 Best PS1 Hidden Gems [You Must Play]](http://i.ytimg.com/vi/S6HNmstzIrI/mqdefault.jpg)
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!
Found your channel a few weeks ago, great content!
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 👍.
I think , in... Change the DMA controller
Ok issue found -- will be publishing a quick follow-up where we see the problem in action
@@adriansdigitalbasement2 Ah! Super cool and exciting.
Adrian, put the bracket on the xtide card. You will never make this mistake again. Awesome content btw!
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.
I think you have to remove the bracket for ISA mode (at least on mine, the bracket is for the PCI mode).
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.
“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!
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!
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.
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" ;-)
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.
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.
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.
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.
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.
@@adriansdigitalbasement2 You could have given a spoiler warning. Hopefully I'll forget before you show this board again.
@@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) th-cam.com/video/F7nSAEbJGLo/w-d-xo.html
Have a happy and safe new year :-)
This is one of my favourite videos of all time. Failure is just as important as success. Thank you for sharing it.
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.
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.
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.
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.
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...
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.
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.
“ I was about to end the video here”.. thank you for continuing!!
Good to see people saving vintage clones.
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?
I have to admit, I've enjoyed this episode of Adrian's Parts Cannon.
Ah, those rubbon shirts. They are tricky!
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.
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.
That BIOS is the ancestor of the BIOS you replaced it with.
Kind of amazed it gets even that far without an interrupt controller present
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 ).
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.
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.
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.
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.
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.
The one thing that you mentioned that you didn't follow up on was checking for damaged traces on the board. :)
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! :)
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... :)
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.
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
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...
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).
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.
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!
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.
Test the floppy as the B drive. Change the floppy switch/connector.
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.
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.
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.
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.
Try changing the dip switches for the number of floppy drives in the computer.
@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?
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?
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)
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.
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.
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!!!
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.
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.
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?
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.
how about using the chip tester to test some of the chips if it can?
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
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....
IIRC to change the speed on my old machine it was ctrl+alt+up/down arrows. You could always try that.
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!
Take a drink every time Adrian says "Turbo" 😆
Is there a bad trace? Tune in next week when we hear our dynamic hero say: "It freaking works!"
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.
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.
@@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.
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.)
@@enojelly9452 I am pretty sure it read back the 18 sectors it saw, the software reports back read sectors.
@@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.
Happy new year Adrian!!
The difference to the car industry is that in the car industry you make the customer pay for every part that you mindlessly replace during the "parts scan".
Check continuity from the slots to the other components.. Start with the DMA. You said there was corrosion before.
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.
Floppy drive and VGA could be clashing. Also, trying replacing the floppy drive with a known good 360kb double sided floppy drive.
When installing a EGA or VGA card in a PC/XT set the motherboard switches for NO CARD.
32:45 - what!? Even the creator can't see the downvotes!? What the hell, I didn't know that! YT is insane!
they can, but only on the analytics page now
Well done, you did ur best and I know you will fix it x
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.
Have you tried Control + Alternate + another random key?
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!
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.
Any news on checking the board for corrosion and/or cut traces?
You check the traces on the bus? And the connector
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)
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
This may be a ridiculous question... but have you checked that the ribbon cable to the floppy drive is working correctly?
Not ridiculous at all. That's basic troubleshooting.
You said about the fpu when checking the switches. Was it sent as one being present compared to the diagram?
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.
Maybe Rammy has been having midnight snacks! Explains the missing ram chip!!!
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.
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?
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.
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.
I'd start checking DMA lines to the ISA sockets. IRQ as well. Check those traces! (And I'm sorry.)
Maybe trace the dip switch connections for the floppy drive back to where they connect? and verify the dip switch itself isn't faulty?
Love all of your content! So informative
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?
FYI when you Google the turbo bios you put bios 98 instead of 89
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.
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
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.
'rubbon on the microphone"
❤️
disk 1/0 jumpers on the floppy drive itself nxt to ribbon skt ?
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..
that is a precise turbo XT board
you dont know the 'replacement' dma chip is good as you said they're untested, it may also be bad in the same way..?
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?
Check floppy drive jumpers for correct channel and make sure floppy cable is not one of those that flip the select lines on floppy connectors.
I have a similar board, it's power connector is not the same as the usual P8/P9 connector. Is yours having problems fitting there. Could it be something needs different wiring, or -5v.
Floppy dip switch settings? Only 4 possible combinations... Maybe worth a shot in the dark?
Wondering about the keyboard ... looks like an AT with the LEDs and F keys at the top. Is it a switched XT/AT?
is the chip labeled "PC turbo 89" supposed to be offset 2 pins to the left?
Is the broken capacitor on the Kickstart IRQ card hurting anything?
Depends on what the cap is there for, but probably. Manufacturers don't put caps in for LOLs: it's probably there for AC decoupling or some kind of power smoothing/filtering on a chip that might not be tolerant of fluctuations. It could also be there for timing purposes, in which case the card wouldn't work right at all with a broken cap.
@@talideon I have an Aureal Vortex Advantage that has a broken cap and everthing works fine. It's physically broken off.