This motherboard has issues. Let's try to fix it!
![Adrian's Digital Basement ][](http://yt3.ggpht.com/ytc/AIdro_k7CrQRe71qN6c0Ua7A1P_I8KkxjqLa70u0zYeCvdvnKw=s48-c-k-c0x00ffffff-no-rj)
Вставка
- Опубліковано 1 жов 2024
- 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
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.
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.
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.
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.
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) ua-cam.com/video/F7nSAEbJGLo/v-deo.html
Have a happy and safe new year :-)
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!
try this adrian DTK PIM Turbo 10-V01 or DTK PIM TURBO PC/XT MOTHERBOARD 8 MHZ
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.
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 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.
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.
Test the floppy as the B drive. Change the floppy switch/connector.
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.
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?
“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 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!
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 ).
Try changing the dip switches for the number of floppy drives in the computer.
you dont know the 'replacement' dma chip is good as you said they're untested, it may also be bad in the same way..?
This is one of my favourite videos of all time. Failure is just as important as success. Thank you for sharing it.
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.
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
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.
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.
Ah, those rubbon shirts. They are tricky!
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.
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
Good to see people saving vintage clones.
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.
I"m just spit-balling here, you know more about PCs than I do but the ^C's is very strange and it makes me wonder if it's actually related to the keyboard. I'm sure the keyboard itself is good but what if the interrupt for the keyboard and that of the floppy controller are cross-talking somehow? is that even possible?
It's triggering me as well.. because in unix a ^C is a catchall quit command... it's making me think the routine which is running the floppy seek is quitting.
Had a customer once. Kept coming in complaining it was not working, random lock ups , and ended up with a dead motherboard. Ended up having them bring in all their peripherals with it. Yep, it was their keyboard causing all the issues………. Guy threatened to sue because of down time.
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.
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.
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.
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.
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.
@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?
HOW DO YOU LEARN HOW TO DO THIS!!!!!!!!!!!!! I want to work with computers but HOW!
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)
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... :)
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.
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).
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).
Oscilloscope the address lines. Do some captures triggered off a read request. I bet you find something.
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.
A very dry episode for those playing the drinking game. 😆
Seriously though, I'm guessing you've confirmed the drive is correctly terminated and the drive select jumper set correctly?
Was that BIOS dated '89? That's well after the AT came out, so it's possible the BIOS supports higher-density drives and that's what it's set to use? Although usually you'd just get an error when it tried to read the floppy, rather than crashing. That may be a bad assumption, it's possible the BIOS relies on the board's DIP switches to be set to a low or high-density drive to know how to know which floppy access routines to use. I noticed the document you were referring to when you set the DIP switches referred to drives 0 to 3, whereas I believe the AT only supported drives 0 and 1. However the document you showed later looked different, as it showed pictures of the jumpers rather than listing the settings, although you did mention it was for a different board.
Without going too deep into the weeds with the BIOS floppy routines, it sounds like the BIOS doesn't know how to access the drive. I'm leaning towards the idea mentioned above that the BIOS thinks it's a high-density drive and they've stripped out any code from the BIOS to handle otherwise.
This is something easily testable. You could just try a 1.44MB floppy drive and see if it boots. I guess the other thing you could try is a third-party floppy controller BIOS extension. Minus zero degrees has this page with a bunch of them listed: minuszerodegrees.net/rom/rom.htm, and this thread on Vogons suggests getting HD floppy support in an XT using a 16-bit floppy+IDE controller along with the Kouwell KW-530D ROM from the page listed above: www.vogons.org/viewtopic.php?p=480348#p480348. Presumably the suggestion of a "modern" card was because you can set the jumper to specify what kind of drive you're using.
I believe on an AT you have to set this in NVRAM using a setup utility, since the BIOS might support it, but there's no jumper setting on the motherboard for it. Hence my suggestion previously that they might've re-purposed the DIP switch settings for drives 2 and 3 for low/high-density drive support. If that's how it's telling the controller what kind of drive it's using then the BIOS extension ROM probably won't work without a card with its own jumpers.
Although now that I think about it, how would a DIP switch on the motherboard tell a floppy controller chip on an expansion card what settings to use? I have no idea, and it's nearly 2 am so I should probably leave it at that.
Best of luck figuring it out! And happy new year if I don't see another video from you tomorrow! Today? You know what I mean. Thanks for all the great videos this year, they've been a great retreat from you-know-what. And here's hoping to many more in 2022!
Back in the good old days, I would have got me an IBM BIOS listing and used AFDpro to step through the BIOS initialisation routine in ordee to see what went wrong. Copying the ROM BIOS segment F000 into RAM at 7000 first may be necessary, as AFDpro can only step over CALLs if they are in RAM as it inserts an INT3 breakpoint after them. But in another video you mentioned that you are not good at 80x86 machine language, so maybe you could delegate it to another UA-camr or a Patreon? And check that it has read those 18 sectors correctly, as others have suggested.
I think you're way to focused on hardware here.
The floppy+controller works with a program that doesn't use the BIOS.
When you use DOS (which uses BIOS routines) the floppy doesn't work.
So tell me why it can't be an incompatible BIOS?
The BIOS is labeled as Turbo BIOS, but there's almost no way this thing is a Turbo machine.
My guess is the previous owner installed some other strange BIOS that's incompatible with the motherboard floppy controller.
It's a crummy answer, since it basically means you don't have any idea of what BIOS to install, and have to roll the dice on breaking it up into segments. But.... I think this is going to be the most likely answer.
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!
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.
I have a Computerland BC88. I have to switch from low speed (4.7Mhz) to high speed (8Mhz) with software. There is no hardware way to do it. Your board could be similar. I hope to have my system fully restored soon.
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
This motherboard looks very much alike the Fujitech Jumbo Turbo XT that I own. I can send you the bios binary. However, I can't see the 24MHz generator that would be necessary for turbo mode. There is space for this generator, so maybe you can do the upgrade.
There's got to be something screwy with the BIOS. You booting from 1.2mb floppy? Try an old 360kb drive.
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! :)
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
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.
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)
Control-C is an anomaly. You should not get those. For some reason, the keyboard controller thinks you’re typing Cont-C. I’d check all the solder joints on the keyboard socket and then back to the keyboard controller. If that looks ok, then it has to be something from the interrupt controller… the system is so busy trying to service spurious interrupts, that it can’t boot…. It can see the floppy, but just is so flooded trying to service spurious interrupts, it can’t see any data coming off the drive.
That’s a guess, but I would go on the hunt for bad/corroded lands/traces on the motherboard.
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.
This system is not 100% IBM compatible, like all old HP vectra's from back in 80's , needs a dedicated oem version of MS-DOS
Floppy dip switch settings? Only 4 possible combinations... Maybe worth a shot in the dark?
I'd start checking DMA lines to the ISA sockets. IRQ as well. Check those traces! (And I'm sorry.)
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!!!
Check continuity from the slots to the other components.. Start with the DMA. You said there was corrosion before.
on commodore PC they use ctrl D or T or N i think for the 3 speeds, so maybe test with an letter and not only numbers.
Also on the commodore PC there is an app speed.exe to set the speed in dos
Faulty floppy cable? It's such an obvious cause it might have been overlooked.
You can still see "thumbs down" if you hover the mouse pointer over "Likes (vs. dislikes)" in "Your videos" ...
You haven't addressed an important clue, the game port that don't exist.
I would be looking at the I/O addressing as a chip might not be releasing the data buss
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".
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..
IIRC to change the speed on my old machine it was ctrl+alt+up/down arrows. You could always try that.
The one thing that you mentioned that you didn't follow up on was checking for damaged traces on the board. :)
Okay, but that Atari Jungle Hunt product placement tho...
I was cringing for the 4 minutes of video were you had the old Bios chip half stuck in a socket.
That BIOS is the ancestor of the BIOS you replaced it with.
with the text colour change, that would suggest memory issues, faulty ram or addressing issues.
FYI when you Google the turbo bios you put bios 98 instead of 89
disk 1/0 jumpers on the floppy drive itself nxt to ribbon skt ?
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?
What happens if you set it to 2x floppies in the dip switches and connect another floppy drive? does it work?
I have to admit, I've enjoyed this episode of Adrian's Parts Cannon.
I am in the same group with one of your other commenters it sounds like a bad dram i know it sounds silly though sometimes a bad ram can get past the best ram check.
I wish they wouldn’t scream when you pry the CPU out 27:25
My second PC had a similar issue, turned out the bios socket had a broken address pin.
idk anything about ancient technology but if i had a problem like this i would try a new os
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
“ I was about to end the video here”.. thank you for continuing!!
is the chip labeled "PC turbo 89" supposed to be offset 2 pins to the left?
The computer does see the floppy drive because it reports that it is not ready. Is it just that the data cannot be read?
Correction: keyboard is IRQ 1, not 2.
i was thinking the keyboard controller could be causing this
You should still be able to see the dislike counts on your end. It's just us viewers that can't see it no more!
Could it be a motherboard manufacturing error and bad quality control?
While that processor may have come from an HP Vectra, it is very unlikely that motherboard is from a HP Vectra. At least according to wikipedia the early HP Vectras were not 100% IBM compatible, to the extent they required their own proprietary versions of DOS. I've encountered keyboard incompatibilities on HP clones as late as the 386 days.
Yeah this is most definitely a generic XT clone board from Taiwan. Interesting about the CPU coming from a Vectra!
The ctlr-c's makes me suspect the keyboard system.
probably broken RAM, has MT RAM in it, very bad brand