I might have to give up on the "RAM issues" motherboard
![Adrian's Digital Basement ][](http://yt3.ggpht.com/ytc/AIdro_k7CrQRe71qN6c0Ua7A1P_I8KkxjqLa70u0zYeCvdvnKw=s48-c-k-c0x00ffffff-no-rj)
HTML-код
- Опубликовано: 14 май 2024
- Uhh, RUclips seemed to have removed my entire description from this video. Anyway, here we go with part 2 in trying to fix this "RAM issues" motherboard. The process kind of broke my brain! If you have any thoughts about what might be issue, I'd love some feedback.
Part 1: • I just can't escape co...
Part 2: This part!
-- Video Links
Adrian's Digital Basement Merch store:
my-store-c82bd2-2.creator-spr...
Support the channel on Patreon:
/ adriansdigitalbasement
Adrian's Digital Basement (Main Channel)
/ @adriansdigitalbasement
My GitHub repository:
github.com/misterblack1?tab=r...
-- Tools
Deoxit D5:
amzn.to/2VvOKy1
store.caig.com/s.nl/it.A/id.16...
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.com/products/digi...
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.com/item/33000...
TS100 Soldering Iron:
amzn.to/2K36dJ5
www.ebay.com/itm/TS100-65W-MI...
EEVBlog 121GW Multimeter:
www.eevblog.com/product/121gw/
DSLogic Basic Logic Analyzer:
amzn.to/2RDSDQw
www.ebay.com/itm/USB-Logic-DS...
Magnetic Screw Holder:
amzn.to/3b8LOhG
www.harborfreight.com/4-inch-...
Universal ZIP sockets: (clones, used on my ZIF-64 test machine)
www.ebay.com/itm/14-16-18-20-...
RetroTink 2X Upconverter: (to hook up something like a C64 to HDMI)
www.retrotink.com/
Plato (Clone) Side Cutters: (order five)
www.ebay.com/itm/1-2-5-10PCS-...
Heat Sinks:
www.aliexpress.com/item/32537...
Little squeezy bottles: (available elsewhere too)
amzn.to/3b8LOOI
--- Instructional videos
My video on damage-free chip removal:
• How to remove chips wi...
--- Music
Intro music and other tracks by:
Nathan Divino
@itsnathandivino 
Наука
Please don't take this the wrong way(!) but your frustration is our entertainment. Pure geekery at its finest. Thanks, Adrian 🙂
i disagree, i want adrian to be happy
RAM decoupling old tantalum caps. When you load the bus with more RAM chips, you get brown outs, because these old RAMs are quite power hungry. I think changing the tantalum will fix the issue.
That's something I always wondered about myself, I've run across many situations where the power was causing issues with not only new electronics but even older stuff, once I worked on a house that had fried every LED light, including the ones built into the their bougie azz touch mirrors, fried the stove, five expensive fans, four expensive thermostats, and much more, the power company came out and said it was inside the house, after a lot of troubleshooting, finding 240v on the metal breaker panels also, found out the main disconnect the power company installed, charged my customer for it, because he has a large automatic generator, was installed incorrectly and had fried and melted into the disconnect... Had no noalox on the source or load, was overtightened badly, replaced it myself properly, at my customers cost, he didn't want them doing anything else to his house lol. Id love to see the power on the oscilloscope, if it's a little nasty or something else in the house is feeding back it could cause some intermittent problems when troubleshooting, Thank You For Your Time And Effort!
Can be. It's a job to do and test results.
Sneaky - I love your thinking though!
Genuine question - and please bare in mind, all I know about electronics what I've gleaned from fanatically following Adrians videos! ... Is there a way you can test certain components on a board without desoldering them, by using a very high OHM resistors between the probes and the rest of the circuit? or would the natural flow still make the electrons go to the path of least resistance?
@@suvetar You can do in cct testing but sometimes not as easily as just adding a big R. Depending on the cct you can drop voltages to below Vbe-on (transistor) or Vf (diode) i.e.
I had a similar issue with an old OSI C8P. Bad cap adjacent to RAM bank or cap with lead just slightly broken at solder point on MB.
Imagine if a bad board went around from retro channel to retro channel until finally someone manages to solve it... would be a thriller...
That’s a (series of) crossover episodes I’d love to see.
The phantom "Game Port" and "Clock", and the lack of BASIC ROM indicates to me something weird is happening with the address lines - The BIOS is reading something from the Game Port address (201h) and the clock port and getting value, and is trying to read from the BASIC ROM address and not getting anything. And the second bank of RAM causing errors tells me it's at least an address between 256k and 512k (address lines 10 and 11 - 0x201 is also on line 11).
I don't know anything about repair, but this sounds like a good line to go down. The ram errors change every time, and with only 256k haven't shown up, but the extra hardware detected and inability to boot basic have been consistent the whole time.
If he comes back to this, maybe set aside the ram error and try to tackle those other problems, and might solve the ram parity error along the way.
Kind of wonder if there's still corrosion crud under that ISA socket he mentioned. a slightly conductive link between two pins perhaps?
Yep, I'd surely chceck for those higher address lines cross-talk
Could you close in on this by adding your own test routines to a customized test rom?
How might ou you capture the address bus for 201h?
First time I've seen Adrian stumped by a hardware issue, yet still equally enjoyed the content. Thanks for sharing!
It is enjoyable to see you apply logic, schematics and a red pointer to develop a theory of attack to solve these retro problems.
The red pointer is important
Desolder and check under the edge connector where the corrosion was. There's a bunch of address lines there plus ale.
The detected gameport and clock really seem to me like the best indication of where things are going wrong, I really think some IO signals are ending up at the ram. This seems like a problem best solved with a logic analyser or at least a quad channel scope on those io and ram r/w lines and seeing if any are enabled at the same time.
Might also try just disabling ram bank 2 on the dip switch but leaving the chips installed and seeing if that helped. If it has issues with just the chips installed but the bank disabled with the dipswitch then it might be a power issue as suggested by others. or an addressing problem that might be seen with multichannel channel scope on the cas/ras lines of both banks. It might also help to pull out some of the Bank2 chips till it starts working
There's a good chance that's correct. What I'm assuming is if the system is reading 201h (the game port) that tells me that different signals from somewhere are ending up where they aren't supposed to be. And if that's happening for the gameport and clock, I bet if anything that those same signals are ending up in RAM. I'm looking through the assembly code of the BIOS RN to see if I can pinpoint anything that could narrow it down further
Adrian, you are definitely on to something regarding the I/O addressing. The fact that the BIOS consistently detects a non-existing clock and a game port is a major hint that something is messed up with I/O, and the most likely explanation for the BIOS detecting these non-devices is that at least some I/O reads (and probably writes as well) gets redirected/mirrored to RAM.
If I/O access gets mangled up with RAM access you'd expect some RAM addresses to work and others not, depending on which I/O addresses are in use. And since I/O addressing wraps around at $0400 on ISA systems, the issue would affect basically every memory bank.
It's interesting to note that both the CGA card and the XT-IDE work, which you wouldn't expect if all I/O access was mangled. However, if the I/O issue is limited to certain onboard components using I/O, of which there are precious few on a PC XT, you'd get symptoms very much like the ones you're seeing.
Unfortunately, the BIOS doesn't report exactly on which I/O addresses it believes its seeing a clock, but while XT clocks were non-standard and could use a wide range of ports, the game port sits squarely at hex 201. If you can somehow track down the component responsible for the phantom I/O devices, you'll probably also have found the reason why RAM errors are being reported.
How about probing pin 28 (IO/M) on the CPU, and then trace the signal through the various chips on the board to see if either memory or I/O access is being selected when it shouldn't be? Perhaps a tiny program that just runs in a loop with interrupts disabled could help narrow it down?
if i/o signals for IDE is ok.. might it be a Rogue IRQ ?
I agree that it looks like there is something with the decoding of the IO/Memory signals. The XT has the 8088 in maximum mode, so S0, S1 and S2 on the 8088 are sent to the 8288 for IO/M decoding. Four signals come off the 8288 - IOR, IOW, MEMR, MEMW. Those lines go to sheet 5 and 10 on the 5160 schematic - to U13 on sheet five and the expansion ports on sheet ten. U13 output goes to a bunch of sheets - I like sheet 8, which has U58 (74LS32) buffering data from the 8253. I think that the 8523 is being activated when it shouldn't be.
The "thinks it's warm starting" issue is interesting. The process behind it is essentially that there's a "magic word" written to a specific location in RAM. I think something like 0x55AA or 0xAA55 (some on/off bit combo) and if that 2-byte value is present during start, it is considered a "warm start". if not, it's a cold start. After booting, the value is put into the location, so as long as the RAM holds it's values between boots, it is considered "warm start". To "software cold boot" you first have to clear that magic bytes an then jump to the init-vector of the BIOS.
I didn't know that I just thought that were some vectors on the low memory that if were not initialized (meaning had the correct values) it was considered a cold start.
I didn't think I would see you here by the way.
It's at location 0:472h, and the warm boot magic value is 1234h. (Thanks to The Assembly Language database published by Peter Norton Computing, Inc. in 1987)
@@agranero6 the vectors are for interrupts. If they aren't initialised to point to valid software routines when you enable interrupts and try to call one, you'll just start executing code from random locations which may or may not do anything useful.
You don't need them to differentiate between cold and warm boots, but you probably could use them in that way. Afterall, you're just comparing the contents of a memory location to see if it's a certain value, and that value could always be some interrupt vectors.
Sorry if I missed that you've already looked at this, but check the HOLD line going into the CPU. This tells the CPU to wait while DMA is happening. If that isn't happening, the CPU memory accesses won't wait for DMA (like the dram refresh) and they'll occasionally conflict and cause crazy intermittent corruption like this.
Worth looking into. However, I would expect such a fault would cause the bus to conflict like crazy and not work at all. There's no way the board can boot into DOS with this fault present.
@@andyhu9542 Agreed, if it was totally dead it would probably be far worse. But I think he's made some good guesses that this is potentially connected to refresh circuitry, and I've seen similar weird corruption when the CPU wasn't holding correctly. It might not be reliably generated (isn't there an inverter in line there?) or a pad socket is making it slow to transition. Worst case it's a good place to trace backwards from. I'm not betting on my own suggestion, but i would be surprised if it was just totally missing or something. It's just where I'd look next and go from there.
I've had issues with the hold line going wacky when the system attempted to access a drive, I Believe it was on a 5150 style computer but I can't remember when.
I thoroughly enjoyed this video while swapping about 100 SMD capacitors on a board. Kind of therapeutic :)
I love the in-depth discussion, I really look forward to a solution though I appreciate it might not be the case of course, so no pressure!
I admire your tenacity in trying to resolve this problem.
If your cameras are running out of battery, I suggest picking up some dummy batteries. They're usually USB powered and most cameras have some kind of hole/slot in the door so you can hook them up to power with the battery door closed, and you can then run the cameras indefinitely on a bench setup like this.
As a secondary benefit, because you're not discharging a lithium ion battery inside the camera housing, they tend to stay a bit cooler so if you ever have overheating problems recording for long time spans, dummy batteries can help somewhat to get longer recordings before the camera needs to cool off.
I noticed the added/removed peripherals in the last video, but I forgot to leave a comment!
I love your videos!
*** 3 Years Later ***
Adrian robbing the 25th part from his 'parts board'...
"Oh! That's what it was!"
Well, sharing a failed project characterises you as a great youtuber imho.
I kinda feel, that this board is a good candidate for some CuriousMarc cooperation, although a little too new :-) You know, just for some Fancy-Pants power!
I think I even saw Atkelar here, this board is getting some attention for sure! 🤣
Sure does, Adrians made the point in the past before that he feels the bad rasults are as instructive as the good ones!
These videos are extremely helpful. Your methodical approach and your explanations help a lot on understanding how these circuits work. I am in an unfortunate situation where I soldered together an Amiga 4000 using a brand new PCB and a mix of brand new parts and NOS for the most exotic bits. The computer boots, but have some stability issues and show graphical problems (and eventually freeze) when scrolling graphics happen. These videos have been of great value to me in order to understand and pinpoint possible culprits. Hopefully I will get to the bottom of my problems thanks to you sharing your experience and knowledge, Adrian!
i watched the complete Episode without skipping. I would do it for a second one. I love how the pathes are leading into dead ends. that is quite a learning experience to watch.
My bets are on "5v rail ripple"
Day in the life of a C64 repair tech! If we had to work on the board over half an hour, it was a board swap, the most expensive option. We cured more than we didn’t. Some were obvious (PLA), but some made no sense whatsoever. Gremlins!
Yup. Every now and again, you find those boards that just don't want to behave. Those are better off recognizing the symptoms and putting it out to pasture.
@@Renville80 During down time, we’d screw around with the reject boards, getting one back working some of the time. Most were multi component failure, not worth fixing with a brand new board for less money.
To refresh a DRAM, it is not necessary to run through every address. A whole column of bits is refreshed at once, so it is only necessary to cycle through all the row addresses. So with every refresh operation, one of the rows is selected by the adddress lines and the row-address-strobe line is toggled. in a 41256, only 256 rows need to be refreshed every 4ms.
The 24S10 in the original XT is a PROM that maps address ranges to RAS lines based on the configuration DIP switch settings. The one XT clone I have used the same chip but only uses two locations in the whole PROM for switching between 256k/640k, which is selected by a jumper. That PAL is probably just doing the same job in this system. If it has any floating pins, it could be messing up the RAS lines by suddenly activating the wrong RAM bank.
Another possibility is a marginal delay line screwing up the RAS/CAS timing.
I was thinking of the delay line as well.
The second bank causing problems makes me think there's some cross talk between CAS lines for the two banks, or a some other line and the cas line for the second bank... Like some junk between pins or something
That's what I think, too. Adding a second bank causing trouble just shouts 'bus conflict'.
@@andyhu9542 Or power load/supply problems, or ground problems, which are basically the same thing in effect. Like maybe there's an intermittent ground connection on bank two, like a passive component that just moved out of tolerance and is causing it to happen.
It should be easy to test by putting the extra RAM in a higher bank and skipping the second bank.
@@solarbirdyz I thought about power problems or even EMI issues with those newly installed lighting in the basement. However, although he did not show the +5V waveform in the video, the digital signal looks relatively clean and that implies an acceptable power ripple.
Measure VCC on the various RAM chips, look for noise. Compare with one bank vs multiple installed. Swap tantalums, some of them might be open.
The evergreen, bulletproof way to check if your PC has hung is by seeing if the caps, numlock or scroll lock keys are still responding. If they won't turn on or off, the sucker is hard-locked.
IIRC the XT and AT don't have keyboard indicators so the numlock trick doesn't work.
Just a silly off the wall suggestion. Continuity check on the DIP switches to see if they are bad. I know it's a long shot.
I think the diagnostic bios he had showed the layout of the detected dip switch block and showed correct every time. So they have to be good enough for that.
@@michaelturner2806A failing, dirty, or corroded switch could cause intermittent problems. I know it is a long shot but I have had switches go bad. I just thought it was interesting that it worked with one bank of memory, switched DIP 3 when added another bank and then problems. Three minutes to check the switches for continuity to rule that out is time well spent.
Try Ruud's Test ROM..the updated one on minus zero degrees. It's quite comprehensive and still being actively updated.
If it were me, I'd take a good hard look at the sockets. I'd also be taking a long look at the capacitors in the memory bank. If you have an ESR meter I think it would be interesting to see how many of the capacitors in the memory bank are different. Another thought is to do a close inspection of the solder joints under a microscope if you have one.
An MCL86+ in place of the CPU could perform focused read-write tests on the DRAM for both your motherboard and ISA card.
Hey, I finally got one of those little oscilloscopes, except it was "Zotek" brand, and it's great! I had an analog 1990s-era scope and it's completely primitive in comparison. Mostly I needed a frequency counter too for an old 6802 board that I've been trying to get working, and it's good to have a digital scope now, because they do that.
At the moment, I'm in the ball court with the people who are saying that the tantalum capacitors designed to suppress noise may be the main problem. If they've gone low or otherwise failed, there may be switching noise causing problems.
What I'd try would be to temporarily solder on some extra bypass capacitors (especially near the RAM) and see if that makes a difference. If not, you've only wasted a little time. If it improves things, then you've likely found the problem.
EDIT: Could it be that the PSU you're using for that older board isn't supplying sufficient current on the 5V line? Maybe those chips are taking more current than more modern chips would?
EDIT2: If the problem is insufficient power to run the memory, then I'd be looking for a pattern that the more hardware is both connected and doing something, the more likely it is for the RAM to give errors, although to be fair, that could also be a problem with the bypass capacitors.
EDIT3: Isn't the LS243 merely a buffer while the LS245 is a latch? What if someone put the wrong chip into the board, substituting a 245 for a 243? If that's so, the 245 could still have its output pins enabled instead of sending them to "high impedance" mode once the input has ceased. I'd be inclined to try putting a 243 in that socket and see if that has any effect on the problem. And you did say that the "enable" pin was tied active, so that supports my theory.
EDIT4: The errors you're getting only cause me to be even more suspicious that the 245 is entirely the wrong chip in that location and it should be substituted for a 243. 47:00 is the one, in case you're lost.
EDIT5: NM, my error. Both are bus transceivers, but the 243 is 4-bit and the 245 is 8-bit. My bad. I still suggest that the problem is insufficient switching noise suppression.
Double check the power on those chips. I have had a failing cap on a board cause the occasional power drop giving me the wildest of random issues.
maybe try the cold/hot trick on it. Just a thought. But I am convinced it is a cap.
Using a two channel oscilloscope allows you to focus in on different parts of the memory cycles.
For example, connect one channel to the refresh DMA enable and trigger the scope from that, and use the other channel to examine the data, address and chip select signals while the DMA enable is active.
I enjoy the deep dives, some of these old computers really do have gremlins
Refresh is initiated by strobing a row address into the DRAM using RAS. That causes the DRAM to latch an entire row, which then gets written back at the end of the cycle. CAS isn't necessary unless you then want to read or write a column, so a refresh is basically an access cycle without the access. This is usually known as "RAS only" refresh.
Newer DRAMs can also do what is called a "CAS before RAS" refresh whereby strobing CAS before then strobing RAS causes the DRAM to refresh a row based on an internal row counter. In this mode you don't have to supply a row address because the DRAM takes care of that detail itself.
Infrared Camera to see what gets hotter than it should. I was also thinking the mainboard may have a dry joint that needs to be reflowed. Interesting problem. Going away from it to do something else works for me too. It gets processed subconsciously and then goes to the project with a fresh eye. Thanks.
I have no clue about anything computer. I found you channel 8 months ago and it is so interesting.
Your mannerism, engagement with the audience, knowledge on all the stuff you’ve shown, ability to diagnose, and much more. It’s all very engaging and both your channels are amazing!
All that said, have you tried that dip switch selector down by the bios? It’s not that far from where the corrosion and leaky battery was. Maybe something leaked into it while in the upright position and the switch is bad?
Allowing voltage crossover inside of it?
Again, I know nothing about computers and their components. And this is just an outside look. Maybe it’s possible or maybe I’m way off base.
Please don’t take this as a bad thing.
Your channel is also what I use to help shutoff my brain and fall asleep.
Not that your content, voice, or anything is boring. It’s quite the opposite.
If something bores me my brain starts wondering and thinking about 10 things at once.
Your videos are so engaging, entertaining, informative, descriptive, and detailed that it’s keeps my mind focused on what you’re talking about and doing.
With that, I can slow my mind and actually sleep. Thank you greatly for the content and uploading so frequently.
@@JASPACB750RRyeah, Adrian’s chill but still engaging. But he’s chill enough that you absolutely can safely have it on while asleep. I’ve got a whole playlist filled with people who speak calmly enough for that purpose. Like Radio 4! But about computers 😊
but what about the serial and clock installed? :) loving this series. Thank you Adrian
I think it worth checking how POST detects clock and game port. Maybe fixing problem from that lead are easier? I suspect I/O can leaks into memory but only in specific conditions?
You need a scope with a separate channel / trigger input so you can trigger on a chip select or enable signal. Then probing the data bus will be synchronized to those types of bus cycles.
Adrian, at the start of the video, I was wondering if the rise/fall time of the signals were fast enough. At about 1:07:56 (give or take) you mention the resistors for the multiplexers for the DRAM. From what I can see on my shoe-phone, they look like 220R or 330R resistors. Now, I am not sure if they are limiting current or pulling the signal down (with TTL logic I'd be more willing to put my money on pulling the signal, especially given the number of connected ICs). 220/330R is a pretty hard pull. If one of those resistors went open or high(er) resistance the signal might look more like a capacitor curve when zoomed in on the scope but still look reasonable when zoomed out.
I do hope to see a follow-up when you can clear your head. Thank you!!!
Hey, a look at the slot connectors for pins that are across from each other but are very close. The pins can get close and short. If they look okay, check for corrosion from the leaked clock card battery around the slots; corrosion can partially conduct and cause weird problems.
One thing I think this video demonstrates is why deeper troubleshooting like this went the way of the dodo for many people once we hit the PC era. The issues are complex and difficult to trace out, and once PC parts became commodity, it just wasn't worth it anymore precisely because of how complex it can be to figure out the exact issue.
I will echo others here that this is starting to look more and more like it is potentially related to the game port and clock showing up as enumerated and or there's a problem with the board with noise, possibly via the capacitors and or resistors. I'm very hesitant to jump to recapping, I think it's far over suggested in general, but in this case It may actually be time for a recap; tantalum caps are known for going bad on this era of motherboard, and this may be an early indication.
Adrian, @10:47 I see a flip flop there just above your hand, that would certainly be a suspect, in my experience the most common failures of active devices in the gear I fix (not computers) is op-amps, followed by flip flops... so whenever I see a flip flop attached to a section that is misbehaving, that is a part I will look very closely at.
I’m enjoying all this testing. Just want to make sure I’m not missing something. What I remember from the first video is the board was working and you used a chip off it to fix anther system. Then you replaced the chip with one that wasn’t exactly the same. Did you ever put back the original chip to make sure that wasn’t the problem?
@adriansdigitalbasement2
Great video and thank you for sharing!
As far as the RAM issue. Since it seems to have worked when you had only 1 bank installed, but stopped when you added the second bank. What about the bank selection circuit goes? Could multiple banks being selected at the same time causing a buss conflict?
It seems likely that whatever is causing your phantom game and clock port is also causing the RAM and parity errors.
I dug into the Turbo XT BIOS source a bit after watching this episode. Both the game port and clock detection code work by reading an I/O device via the "in" instruction.
To check for the game port, for example, the BIOS reads from the I/O device at 201h 100 times. If it ever gets something other than 0xFF it decides that a game port is present.
Interestingly, the CPU talking to an I/O device is nearly identical to talking to memory. The main difference between the two is the behavior of pin 28 - IO/M. It's high for an IO operation and low for a memory operation.
That tells me that whatever is misbehaving on that board is misbehaving for both memory and IO operations and that whatever it is fails consistently when checking for the game port or clock.
The code to check for the clock is more interesting. It checks for a clock at 2C0h, 240h, and 340h, but it only checks each ONCE. That would imply a consistent failure if the clock is always detected.
Could you maybe have a bad CPU? Or something is shorting pin 28 on the CPU to ground?
I'm also suspicious about the machine often doing a warm boot after a power cycle.
you'll need to check around all signals and chips involved with ram and io selection, i think, not just 'buffers' , theres a lot of gates in there as well, it only needs one output to be weak at pull down to cause issues, you may have to fully socket it! it'd then be useful for other testing purposes if you can sort it eventually 😁
I have a XT clone board with massive RAM problems too, I could never figure it out.
What is that little O-scope you're using? I'd love to have one.
Hi i don't know if it is related, but i noticed at the boot screen a error that there was no basic rom present. And i saw you pointing at a chip where both some ram and ram signals are going trough. Good luck
I'd be checking the chip selects (CAS). Each bank should have one, likely from the PAL. May have a short even.
I suggest you use the Trigger funtion of the oscilloscope (may need a better one than the handheld.. maybe your NI one). With it, you can trigger on the DMA pulse, for example, and see what other signals line up with it.
What about the dip switch block for the RAM configuration? Maybe internal contact problems?
Could be a setup time issue with DRAM. You could check CAS rising edge to stable data time on the scope. Each motherboard has slightly different timing, so issue may not show up on all motherboards. Second bank data line load would make the issue worse, perhaps. You may need a faster speed grade of the DRAM chips.
One of the things I found weird is that one of the BIOS you tried didn't find the BASIC ROMs...
So maybe the Issue is with those and they do something weird?
Just a thought, check resistance packs, for pull up and down and in between. It has been seen before that resistance breaks and has strange errors.
Have you checked the Rockwell Retro Encabulator chip?
I'm curious if the '92 OKI bus controller IC ran cooler than the '83 NEC? And ya, I also wondered if some of those tantalum's are flaky... at least compare them with an ESR meter in-circuit? But thanks as always!
With a single bank installed you get no errors, so the data buffering, address multiplexing and refresh work fine. With two banks everything breaks down. That could be due to too high loading on the buffers driving the RAM chips, but I would rule that out as it would indicate a very marginal design (would never be able to cope with four banks of RAM). My guess is that there is a problem with the RAS and CAS lines going to the individual banks. If those are decoded incorrectly or have flakey connections on the board (or even have shorts to ground, VCC or other lines), the errors you see are totally what I expect to happen. Happy debugging!
I was thinking that your dip switches might be flaky
Could the jumper pads by the PAL be selecting 64K/256K DIMMS for each bank of RAM? Does this board support 1 MByte RAM installed? 🙂
Alternatively have you upset the Sophons in aome way to cause them to mess with your diagnostics? 😁
@1:07:06 it looks to me to have some pulses that are at about 2V level, these might be causing issues as they are right at the threshold of being a 0 or a 1.
Maybe some decoupling cap issue's? What does the 5v supply line look like around the drams in terms of noise?
It's amazing to compare this Intel/IBM system design from 1981 to a contemporary 6502 design from the same time period.
Have you checked the basement for excess cosmic rays? Your recent spate of RAM issues makes me think the Earth's magnetic field is off in your neck of the woods.. :)
Most people who work in repairs of any kind come across faults that refuse to be repaired. Im a mechanic by Trade I can think of two cars that we never resolved, in one was my own car that recused to idle. Another became the workshop car that wound run rough at low RPM but ran fine at high rpm…
have you tried monitoring voltage across the decoupling caps at the memory?
I once had a confusing issue on a c64 which drove me nuts. It would kinda work, kinda not. Some games would load, some wouldnt. Everything seemed to test ok.
In the end, it was the CPU. Subtle flaw in BCD mode.
If not the CPU, it could also be a marginal power issue. Is anything rectified on these boards?
On the other video I got the feeling about the bios chips ( the basic ones ), I know they get disable if not in use but they can be on the bus, not all the time but perhaps can they be enable all the time.
I'm talking about the basic ones because they do not show up (not detected), something strange about that bios ones, try to remove them just to check
There were a couple of times you mentioned the voltages being a little low on the scope. If one of those chips is borderline a little low might be a little too low?
And adding in the extra ram lowers the voltage just a bit more
Is there a place in the bios to adjust dram timing / refresh ?
you can always go back to basic if anything fails
pull any chip out and socket it, test connections between chips for shorts between traces, check capacitors next to ram chips in the failing row. check pulup resistors and resistor latices for breaks,
because let's be honest if there is no problem with silicon, pcb or pasives becoming more and more suspect, especially tantalum caps and chiped insolation
i had a nes clone once that i wasn't able to diagnose, every chip was good, every trace was conducting point to point where it should
and the only problem was a bit of crud under the cart socket partially shorting reset line to one of the data lines. i missed it so many times it is embarysing. so check every solder point visually if any crud isn't growing there connecting things it shouldn't too.
and good luck finding the actual fault
As you seemed to have excluded the decoding circuit for RAS and CAS lines, my experience says that when you take parts off like cards or memory and all works and when you put things begin to break that the power supply is not supporting what is needed. As your workbench probably has a power supply that is way powerful than necessary and the other board works, I would recap all this board.
It could be flaky tantalum caps like others have said, but they more often fail short and any shorts would take down the system entirely. It isn't impossible to have a marginal tantalum cap, but that is extremely rare. Testing for that wouldn't be easy though.
However, to me all of the symptoms so far points to a bank select issue between the RAM banks. Almost like either it is selecting banks at the wrong time or multiple banks at once, but we would expect to see conflicts on the RAM data bus on the scope if it were selecting multiple banks.
It is quite possible there is a poor sync when bank selection is happening leading to some overlap. The DRAM refresh then could be selecting banks when refreshing, but CPU RAM access tries to get back to the bank it was looking at, but due to addressing slew it didn't switch in time. The DMA might not be affected, but as soon as the CPU tries to see its RAM it is accessing the wrong place for a fraction of time. Might not be noticeable on the scope if that were the case and it would look like gradual or random corruption of RAM.
Hi Adrain, I have started ordering the parts to build one of you 8Bit ISA ram cards but have been unable to find the value for the resistor network. Can you tell me what the resistance value should be?
do you have a rom image anywhere for that 'system already' bios?
I wonder if the failed memory region is not important until say a bunch of files are opened?
Hi, this might sound goofy,, but did you check the resistors for correct value ???? just thinking. maybe one resistor either went open or developed high resistance
There comes a point where it's best to cut one's losses, save what can be, and move on. There's no guarantee that the board won't suddenly start working after replacing a marginal part, only to refuse to work the next time you power it up.
I your system thinks it's warm sarting and warm starting requires certain keys to be pressed, there may be some issue with the keyboard circuit (or with the circuit responsible to turn that key press combination into a "warm start" signal).
Could there be any trace issue on the second bank of memory?
Im thinking the issue here is that the wrong bank of RAM is being selected or both banks at the same time. Im assuming the PAL is replacing the chips that generate the RAS/CAS lines for specific banks of RAM. It probably also generates the CE liines for the ROMs. Given the PAL swap doesn't make any difference, it would be worth checking the inputs to the PALs to see if there are any bad signals there. I'd look at the IO/M- line from the CPU as if thats not worling reliably then this could explain why its finding the serial ports etc and not able to see the BASIC ROMs
What happens if you try and read the BASIC ROMs using DEBUG, as if something else shows up instead of the BASIC code then this would point you in the right direction.
Have you checked for continuity between the RAS/CAS lines as if there is a short/some resistance, then signals could be passing between them ie between bank 0 and bank 1 due to damaged trace/a blob of solder in the qrong place.
Could it be that there is still a broken trace below the ISA slot?
Maybe take a different angle, use cold spray/put the board in the freezer to see if the issue temperaruly is resolved. Then use cold spray to smaller areas until you've found the culprit.
Same can be done with heat.
Power filtering issues or maybe address decoder issues are worth to be checked.
Serious Deja vu! I lived this exact experience with a DTK non-turbo motherboard about two years ago. There is a long story, but it turned out to be a RAS/CAS/Address timing issue. There is a delay line that separates the CAS time from the RAS that could be the problem, but I always see this component soldered in. In desperation, I tried swapping it with one from another board and that was not my problem. Some DTK boards use 74S157 for address multiplexing whereas IBM uses 74LS158. A difference between these is propagation delay. Maybe the multiplexers are failing or are the wrong ones. Why would the “wrong” chips be in there? That’s part of the long story. In the end, I swapped ‘S157 for ‘LS158 (or other way around, can’t recall) and that board has been running ever since.
One thing that bothered me is when you tested the suspect board with the known-good DMA controller chip at around 45:30ish. If you have multiple hard-to-separate issues, this probably doesn't tell you much. If the suspect board doesn't work with the known-good chip, in principle that just tells you you still have a problem on the suspect board - it doesn't tell you that the suspect chip is good. To know if the suspect chip is working, test it in the known-good board, so that it's the only suspect component in the test. If you prove the suspect chip bad, you still need to try the board with the known-good chip to try to diagnose remaining problems, but you know better than to put the now known-bad chip back in the board.
I understand things will normally go faster if you just test the known-good chip in the suspect board, and even if there are other problems on the board, usually the change of chips will change the behaviour of the board. I just think maybe this is a particular special case where maybe two or more components involved in RAM refresh have subtle problems that are each causing similar symptoms, so there isn't necessarily an obvious change of behaviour by replacing any one component.
Is it usual for boards of this age to encounter so many problems like this?
There is a modern GLaBIOS for PC/XT clones, you may take a try with it.
@ 1:59 I wonder why those Basic rom chips are out of order like that? Could have sworn I seen them in some other order.. yeah I must be getting old..
BTW.. Have yo all checked the caps "The ceramic ones" near the ram? what with the Extra Ram ergo extra noise
Dumb question, have you checked that switch block that configures the memory size? It could be dirty making bad contact and causing the issues.
Look for a radiation source in your basement.
It is funny to see a machine with a BIOS dated from 2018 booting into a DOS dated 1994.
A blown socket on the second bank of RAM since the first bank seems to work fine?
Since there was battery corrosion at some point, it may have corrosion that grew over time and is probably hidden.
I don't like it too when a computers doesn't work. I have two (same type) old computers. One of them is working. In the non-working computer, two ic's, both good, power is good, no shorts on missing connection. On the connection between those two ic's, no signal where the working has one. All other signals on the two ic's are good. Strange.
You could have bad, pull up or pull down, resistors causing the problems or maybe bad bypass capacitors that are located for each chip's 5v & ground connections. Which could be letting digital noise upset other chips functioning.
the flashing question marks were on the top left Adrian not top right
Bypass caps on the RAM chips? (The chips themselves might be good, but the power to them might not be...)