I got stuck trying to fix this 40 year old RAM card (AST MegaPlus II)
Вставка
- Опубліковано 3 тра 2024
- -- Links
AST MegaPlus II Manual and Schematics:
www.minuszerodegrees.net/manu...
Github Repo for ISA Card:
github.com/misterblack1/isa-r...
Minus Zero Degrees Diag ROM for XT
www.minuszerodegrees.net/supe...
Adrian's Digital Basement Merch store:
my-store-c82bd2-2.creator-spr...
Adrian's Digital Basement ][ (Second Channel)
/ @adriansdigitalbasement2
Support the channel on Patreon:
/ 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 - Наука та технологія
A man with one mem checker is always certain. A man with two mem checkers can never be certain.
needs a third one for insanity checking
Yeah, and someone with three of them will be utterly confused! 😆🤣
Funny and true, that's why I guess voting logic for redundancy involves an odd number of least 3 computers, sensors or systems, as it's unlikely that the majority of them is wrong.
There's an old Navy adage: Never carry two clocks at sea. Carry either one or three.
Spat my tea out - Genius 😀
1) try booting from floppy without XTIDE installed just to rule it out.
2) do you have anything 386+ that can employ this card? if so, try memtest86+ 4.1 or lower.
3) actually do you have any other system to test this card in?
4) it was you who taught us all to look at the scope before swapping chips around, please use your own advice!
Look for: unstable voltages, unstable clock signals, strangle logical levels, the stuff you always check.
If replacing S/LS/ALS changes the outcome you most definitely need to look at logic levels and voltages!
5) Can you dump the addressing ROM - the one you first suspected to be bad - and check it dumps the same every time?
The 'scope is the tool to use here IMHO. Confirm that signals in the DRAM array all look OK (as expected) on all the chips. Check power rails at the DRAM chips, all of them. Especially when the memory test is actually executing. Check all the unmux'd and mux'd address lines. Etc, etc, etc.
These are good tips 5008j
The scope is the tool. Weird timing issues are possibly evidence of some passives going bad resulting in bad waveforms. Is it a bad chip? It is a bad cap? Is it a bad resistor pack? Are the square waves rounded? If only there were some tool that could display these signals in some way that we could see the rise/fall, timing, etc. ;)
A poem for you for 44:25
Tiger got to hunt, bird got to fly;
Man got to sit and wonder 'why, why, why?'
Tiger got to sleep, bird got to land;
Man got to tell himself he understand.
-Kurt Vonnegut, 1963
My money's on the addressing logic on the card. The output from debug (42:48) shows a marked difference between sections 5000:0000-5000:003F and 5000:0040 onwards. That's not at all what I'd expect to see when examining uninitialized RAM. Who knows what we're actually looking at (or where).
The PROM is probably the most obvious suspect, so if it could be dumped and recreated that would be ideal, or even just dumped repeatedly to see if it's flaky. But besides that, my next step would probably be to probe the RAS/CAS and data lines on the various memory chips while accessing the RAM to see if the levels look OK, and if the right chips are even being selected. Then repeat that exercise but with the probe directly on the ISA bus.
Addendum: Probing RAS should show whether or not the DRAM is being refreshed. It is my understanding that on the original PC/XT/AT, the refresh signal is provided by the motherboard via the ISA bus. Bits semi-randomly flipping could be the result of RAM not being refreshed.
Hi Adrian -- I haven't watched this video in its entirety yet, so you may have discounted this already (or fixed the issue) but -- a few weeks ago I was trying to get an AST Advantage memory expansion card working on a 286 and had inconsistent memory check fails. My issue actually boiled down to a faulty resistor pack -- it had failed internally (looked fine) so that the resistance between the ram chips and the LS logic chips was wrong for one of the bits. It took a while to track down -- first time I've ever seen a bad resistor pack. I replaced the packs and card worked perfectly. ANYWAY, easy check might be to ohm out between the LS chips and the ram via the resistor packs and make sure all resistances are legit. Always love the content!! Cheers!
Something I noticed which might be worth investigating: When checking the contents of RAM from a particular starting segment, like 5000: or 6000:, the initial 64 bytes read from each block of 128 bytes tended to be fine but then the following 64 bytes would be where most of the problems were, and this pattern continued as more of the RAM was read in chunks. So, 5000:0000~5000:003F would be mostly good but 5000:0040~5000:007F would be where most of the bad bits were, then 5000:0080~5000:00BF would be mostly good but 5000:00C0~5000:00FF would have a lot of bad bits. I'm curious if anything important could be learned about the problem by starting the 128-byte read 64 bytes forward, such as specifically reading out 5000:0040~5000:00BF. A part of me almost feels like that might reveal a refresh, voltage, or capacitor problem...?
I noticed this too, which made me think it might be an address mux problem. Large block RAM fills that memtest software does might read back fine because the ambiguous addressing won't trigger any data bus conflicts, but the small manual fills (and certainly trying to load code) will reveal the data bus conflicts because the other block of RAM that gets "paired" with the one being focused has different data. Changing out the data bus buffer for differently timed parts would expose the CPU to the data lines at different points during the contention.
Yeah, it feels like an issue with address line 6, though I can't explain why the last byte before the 64-/192-byte offset is hit often also showed corruption. If reading with a 64-/192-byte offset doesn't show immediate corruption first and then clean reads in the second half of the data, but instead has the same pattern as observed before, then I'd lean more to a capacitance problem or something.
I would expect to see parity error messages if the memory itself was having trouble, but maybe something isn't getting set up right in DOS for that to happen -- maybe that's why it's not booting up. It seems more likely that this is an issue outside the memory itself, and is more on the side of transceivers/buffers that interface the card to the bus.
I'd also try disabling the serial port and clock on the board to see if those have anything that interfere. The schematics seem to imply only the serial port would have anything to do with that address line. Looks like pulling U5, an 74LS244, would detach the serial port from the bus, if simply removing jumpers to disable it isn't enough
The fact that the test program showed an error on bit 7 but not bit 15 implies that addressing is indeed part of the problem.
That´s a headscratcher for sure! The 7643 PROM seems to be doing very straightforward address decoding. Outputs O1-O3 select one of 8 RAM banks (4 of which are on the optional MEGAPACK daughter card). Output O4 is a general enable signal for the whole card. O4 is gated through U64, what that does is making sure the card only tries to use the optional 4 RAM banks if the Megapack is installed. If there is a Mepapack it will pull signal "MP" low, which allows the card to be enabled when O3 is active (meaning one of banks 3-7 ia selected).
This gated O4 output from the PROM is what enables the LS245 transceiver, it should be enabled whenever an address in the card's range appears on the bus. The fact that the card does anything at all makes me think that the 7643 PROM and U64 are fine...
What I am wondering, could it be that the XT clone, when reading the RAM, needs the data to remain on the bus for a short while after MEMR goes high again at the end of the read cycle? As soon as MEMR goes high, the 245 latch will switch direction, removing the RAM data from the bus. The motherboard choking on that is the only reason I can think of why different speed grade 245s would show different behavior..
Amazing in-depth repair without "throwing components at the board" as usual! I look forward to the next part, assuming there is one :) Thank you!
Had almost exactly this problem years ago - a DMA transfer from the floppy disk failed because it was using a memory address that was also used by a peripheral card for IO. . So the IO select line had long gone after reading data *from* the disk, but was still enabled on the crap after market card due to decode delays. So as the PC attempted to DMA into its memory, the peripheral card said 'hey, that's me' and write two FF bytes on the bus.
I would look closely at any IO address decodes on the card. Faster logic might improve it. Also try changing IO addresses on the card. It may not be the RAM that is then= issue anymore, it may be the I/O that is interfering and grabbing the bus as e.g. the lower memory addresses hit the sort of 200 hex area of the IO.
In my case we did everything and the issue only appeared when reading from floppy using DMA. A file was read with two corrupted bytes. Once up and running the problem never appeared.
Back then there were some very inexperienced digital designers cascading address decode chips resulting in very very long delays.
But modern fast chips should fix it, also cooling the board might work
The fact that behavior changes, based on logic family, and is intermittent, suggests that some logic (or trace) on that RAM board is only MOSTLY dead. I suggest checking the select logic signals with a scope and look for suspect voltage levels or unusually slow transition times (see IC datasheet). One approach could be to pick a logic IC, like that LS245, and trigger the scope on output enables, while looking at data input. Measure timing between output enable, and data input transition. IC's datasheet will list minimum input hold time required before output-enable. If a signal looks healthy, but timing is too tight, that could indicate that the problem is farther up-stream. Excellent work so far! Your tenacity is inspiring!
Changes in behaviour based on logic family would tend to make me suspect timing that is right on the edge.
could be a handshake that changes when software loads, like I haven't seen that
Not too shabby, man. I think you might be onto something.
Ahh that Sony Trinitron in the background. I used to have 15 inch model. Such a nice monitor.
Why not try the card on a different board? I have no intention of working on the older boards, but this video, brought back memories of how crazy making the switch selection was, in terms of getting the cards functioning properly.
Thank you for all your work making your videos. You have a great way of showing trouble shooting techniques. I found during my career not many people have that ability. I sure wish I'd had some of the tools we have today like the infrared camera I recently bought. What an amazing tool. Thanks to your videos I now think I can try and fix an old IMASI 8080 computer I have.
To me it looks like a DRAM refresh issue. Given the memcheck utility passed, it probably read back the values immediately after writing them, so the value likely persisted long enough for that to work. But on a human timescale, bit rot from incorrect refresh would look very much like what you’re seeing (random bit errors). Just a thought anyway. Love your content and debugging skills!
Awh, I love watching you go through the boxes.. I am a fan of long format videos though.. must my opinion.
Just some ideas:
* check the original ls745 in the retro chip tester
* check continuity / resistance between address and data pins from edge connector to bus transceiver
* replace the logic chips that enable / disable the ls745
* dump the programmable ROM and look for any patterns that may indicate it has failed, e.g. stuck bits
The logic between the ISA bus and the RAM chips is relatively simple that it seems like it's possible to get to the bottom of this.
Manual page swapping! lol!😂😂😂
I suggested he change video cards, I have seen that be an issue. Along with network and sound
>check continuity / resistance between address and data pins from edge connector to bus transceiver
this! it seems that different addresses give different amount of errors. Maybe there's a corrosive bridge or something? Look at logic levels too.
I'll add my 2 cents as well. Summarizing other's comments amongst my own. Change video card, perhaps to a hercules/mono one, do not use the XT IDE, us an actual floppy drive. Do ensure it's not running in turbo mode (BIOS says it's a turbo system). On that floppy, boot an earlier version of dos, I'd recommend something at least below 4.0. Then use older version of memtest (or later that supports it) under that for really good test of the memory. Lastly, try another PC or XT system entirely.
Yes, this was long but I enjoyed all of it and would even enjoy a followup, trying the most likely scenarios proposed here already.
It might be a good idea to dump that 4096-bit control ROM, in case it ever does break in the future.
There's also a good chance that it's relatively simple to replicate the data that's supposed to be in that ROM. It's probably a basic generated pattern to decode the address lines, with no surprises.
You always say “without further ado” and the cut to your opening montage, otherwise known as “ado” lol. You’re the best! Love your shows! Good thing we aren’t neighbors because id be at your house everyday!😂
This is the first time I’ve noticed adieu and ado sound the same, but have different meanings. I always thought it was spelled adieu- the French word meaning goodbye. So without further goodbye, or without drawing out a goodbye. Apparently, it’s not so, and I don’t like how the word ado looks. 😅 I’ll never be the same.
Adrian's Digital Opening?
@@TheBitPunch that's what the French does to you, you're never the same after
@@TheBitPunchi thought it was two different spelling of the same word and it was siri that made the choice. Had i proofread it i would have been googling away the spelling myself 😂. I use voice to text too much, it always leads to interesting responses! Lol
@@TheBitPunchthey don't sound the same! Adieu is like "add-yuh".
An easy fix. Just pull out all of the DRAM from the board using ESD precautions. Enable a DRAM bank and continually observe the same memory locations for any data bit flicker. Use pullup and pulldown resistors on the DRAM data out bits and observe the data contents to ensure that they are stable. Whiist in this config check out the DRAM signals A0-Ann, /RAS, /CAS and R/W. If it seems fine, remove install a single DRAM IC and check it if works properly (remembering to remove any pullup/down resistor on its Dout pin). Check for stability again and check it if it can be set high and low on demand. Rinse and repeat until errors occur. 😊
These hardware debugging videos are pure gold, i love the troubleshooting😀
Based on the schematics and the full board, the logic chip programming can be reverse engineered ;) I did something similar back in college
38:25 - I noticed way earlier in the video that it was not displaying all FF. There were some FE's and I believe an FD in there too. I was basically yelling at the monitor lol
Same. there’s something odd happening in the 5000 range
I saw that too
That's why I hate the CGA font! I always hated it from day 1.
There was one FD. Noticed it right away
Also one FE in addition to the FD 25:20
i myself love watching long videos. i also like when you dig through boxes and find stuff. usually i like watching long videos before going to bed. best thing i think.
It's all interesting, Adrian.
Oh heaven, heaven is a place, a place where the retro computer parts, never stop happenin'
FYI: i work with several systems where memory checks worked but when software loads system crashed.. One was a p75 isa bus system where a video card caused an issue. Another was raw ram chips for a video card. The diagnoser said good, but software froze, the chips specs of the different brands were the same but software said no.
I also seen one one line for PBX cards that there were certain card you do not pair in the systems. They will not work.
One thought is to change video card in the system and maybe any other that may be plugged in. I am aware back when networking was young that you wanted to have at least 3 different brand cards because one card might not want to work with the system. I have also found this to be true for sound cards as well
Maybe its an addressing problem, in any 64 byte block, it is interesting that the fist 32 bytes are relatively error free but the second have comparatively more errors.
I'd break out the scope and check the /RAS & /CAS lines and probe any TTL output for normal activity. It may just be one of those quad gates giving problems.
what a rollercoaster!
I had the sub-logic flight sim back in the mid 80s... was basic, but for the time was pretty cool. How things have changed now with the new MS flight sim that looks so real.
A lot of valid suggestions here, my money would be in timming. I would check the propagation time on the output of the decoder address ic/nand gates to the input of the 245. Another interesting test might be boot as is, machine is frozen -> disable ram board with dipswitch 5, boot and analyze if DOS wrote something on those banks and what might be stuck. Cool video!
Hi Adrian, I checked the schematics as well. Something suspicious is that, like others have already mentioned, the first 64 bytes are always correct.
You also mentioned that only the 74F245 makes a difference and that you suspect some timing issues.
I would take a closer look at the CAS/RAS enable generator part of the circuit. This is U66. This IC is a logic delay module. My suspicion is, that this part of the circuit might be problematic and generate unstable timings for adress multiplexing. This might cause the memory ics to behave in a strange way.
I'm not an expert. This is just a guess from my side. Probing RAS and CAS as well as the address bus might be worth a try to verify that this is not the issue.
Another thing to verify is, that the refresh is actually working. Maybe the ram test passes because it checks the previous value before the data degrades too much due to the lack of a refresh. You should be able to probe this at U10 and check if U48 is passing A0-7 to the 4164 while U49 is tri-stated.
This investigation gave me flashbacks to CuriousMarc's RAM refresh issue on the HP 9825 computer repair.
One thought I have is a voltage issue and differently a thought is that there is a slight difference from the IBM line to the clone. Checking these might lead to something showing up. Great video and keep it up.
[25:20] Notice that when the 5000:0 ram bank was supposed to be disabled, there were still some FD and FE bytes!
[51:41] Again, disabled, but notice some text glitches. The important thing is that both sides are done with separate reads. The left side got all FF, but the right side got a few FD! ('}')
[32:47] Actually, if you can get a good read of that Motorola PROM chip, it should be possible to program a GAL chip to do its function (thankfully the outputs are all on the high side of the chip!) Or it would be possible, if there was such a thing as an 18-pin GAL chip! But all is not lost. Pin 8 is ground, so you could use a 16-pin chip if you lose pin 10. Which is, uh, grounded. So it may be possible to program a GAL16V8 to fit into all but the bottom two pins (9, 10). Of course that chip probably wasn't the problem, but it would still be good to know what functions it is trying to generate so that another board could be repaired.
And you still didn't try doing anything with that 74S00. And as others have pointed out, you didn't use an oscilloscope at all.
Your comment at 44:17 is a valuable one. It's easy to shrug off a problem and move on, but if you can figure it out, then it may be useful in the future. A curious mind is a good thing.
It's 1983..AST is selling these cards while Hawkins, Indiana is going through great turmoil.
This AST card was hilarious!
I had a Future Domain SCSI card in my 286. I got it for a song, they were excellent cards, top of the line.
On diagnosing the RAM board, do you have a logic analyzer and a DIP clip? Doing the fill and the read will create a very predicable pattern on each of the RAM chips that you could capture and decode. That should tell you what is going on. If that looks good, you could also capture the bus transceiver too.
I live near you and have a couple of things we can use if you don't have something. I have a logic analyzer pod of my scope (though I haven't used it before) but, I also think I can get my hands on a SALEAE8 which would be even better. I also have some DIP clips but I would have to hunt for them.
Are you interested in debugging the board further?
These videos are awesome.
@9:40 Also, in addition to parity errors being detected, having an empty bank enabled on the motherboard and on an expansion card can create a bus conflict, if there is a 245-type driver between the RAM chips and the processor bus.
@21:00 The "slow refresh" test in memory diagnostic utilities is usually *not* refreshing "properly", but refreshing at a too low rate on purpose, so that you can identify marginal cells that don't have much margin on the refresh timing. A failure on that test thus just means a chip has been proven to perform "not that great" outside the specified refresh rate, but not necessarily that it is "bad" (as in "violating specifications"). Now that you get this error on a freshly booted cold system can very well be an indication that after warm-up, the bit is also going to fail at proper refresh - which is the key point of the "slow refresh" test.
The issue with MS-DOS not booting might be an addressing error. It's possible that your memory tests only test constant patterns, so bad addressing wouldn't be visible. In the case of your debug tests, its obviously the case. I hope memory some test programs do better, but I can't be sure. Furthermore, I wonder why you did not try to take (or at least show) oscilloscope traces of the data bits while running memtest. You always check for flaky signal shapes on your C64 computers, and it should work similar on this card. The different behaviour of the different transceiver chips can indicate broken levels.
Today on Adrian's Digital Boxes! Yeah I can see how that could become you entire channel if you let it.
Looking at the AST manual you should have been following section 2.3.3 for the switch settings when the card is installed in a XT (clone).
I feel really old, having had a whole bunch of those SCSI NEC CD-ROMs over 20 years ago (mostly used them in external enclosures with SGI Indy machines, which didn't have any room internally for a cd-rom drive)
Besides the LS245 being bad, there also may be an addressing issue as there were different patterns in the debug output with the bad LS245 at 0x40 boundaries. You only did block fills and thus may have missed an addressing issue, if the memtest tool also didn't check for those, just like the bios..
That sounds like a buffer or transceiver. When errors are vague and move around, I'd say it is an IC that is in common.
Or maybe a bank decoder. Or something floating or bad noise.
You do have the schematic. It should be possible to come up with a truth table for those column output pins on that rom. I don't know if that rom part is still available, or if there is a pin compatible replacement, but it should be possible to construct a hw hack to replace that part (which is in a SOCKET!). OR just set the GD switches correctly!!!! :-)
You should dump that 4-bit ROM so that others may make a replacement if theirs dies.
Some theories:
* Could one of the card's other functions (Serial, Clock, etc) be overlapping an IRQ or address that is used by the internal functions or one of the other cards? Something that is not being accessed until later?
* Try an older version of MS-DOS. 6.22 was used at the later PC era before Windows became the default operating system (386/486)? Could it be expecting something present on newer PCs or this card use a different addressing than it was programmed for?
* Could the card be expecting an external driver for some of its functions?
* Try disabling Config.sys and autoexec.bat to make sure it is not trying to load something there
* Is the time clock incorrectly set and this is throwing DOS booting off?
Have you tried an earlier version of DOS, like 3.3, 4.0, or 5.0? Maybe the older versions are less sophisticated in their memory usage.
could be, could also be another card on the bus, video, sound , network
I also suggest using DOS 3.3 first. I have a system that freezes running Windows 2.0 under 6.22 but works flawless with 3.3.
I had the same thought at the end of watching this video. Maybe this card always had subtle flaws / latent bugs in its RAM implementation, which just didn't show up in most or all contemporary software.
If you have access to a programmer well versed in assembly, you could take advantage of MS-DOS 4 being recently open-sourced, and actually track down which part of the OS initialization is causing the freeze :D (assuming it freezes the same way under MS-DOS 4 -- as I've noted you've been testing with MS-DOS 6.22)
I'm thinking about this from a common denominator standpoint. The common denominator is the XTIDE. Maybe you should try using an actual floppy to boot from. Maybe there is some sort of incompatibility between the boards.
Adrian, check the +ve lead on the bypass cap at the transceiver and then the individual ram chips. The BIOS mem test might load the voltage rails differently than those piddly mem test and DOS likely does something different altogether which would mean different loading conditions. My money is on a bad bypass cap - Occam's razor, and all that...
Hi Adrian,
A PicoMEM ancestor. The PicoMEM could told you the RAM it was able to see :) It does not test all the RAM Address, but for some bytes per 16Kb range.
The PROM control's 64K chunks. You should be able to test it in a bread board with switches & LEDs. or make an adapter to a 4k EPROM pin out (tie upper data bits low) & read it on your EPROM programer.
it is like there is a bus conflict with your IDE card and the mem card
You probably tried it without battery too, had something similar before with a different model ram card. Without battery, that card worked fine, but once the battery was back on the board, everything locked up. However this battery has nothing to do with ram errors, but the ways of IT are inscrutable 😁 These are not normal problems and I wish you good luck 🍀
Adjusted that mandelbrot basic to RCA basic3 and it took 45 minutes to run on an emulated RCA MS2000
I haven't finished the video yet, but did he make sure turbo was turned off? These cards weren't made for over 4.77mhz.
It WAS running on 4.77MHz all along.
the 74LS240 could be feeding back to the 245.
Before the comouter stooped seeing the ram, you werent getting all Fs, you were getting the occasional FD or FE as well.
Before I would give up, I would be tempted to remove the top half of the memory on the card to see if it makes a difference in loading MS-DOS.
Speaking of multi-function cards it makes me miss my HardCard which had expanded memory on it as well as having a hard disk married to it. back in the day it was a pretty novel idea. Then the hard disks that were on the cards started to fail mechanically. I seriously doubt any of them still exist in a functional state.
I see Rammie is awake today
Another idea or two for Adrian.
1) I assume you did the “stick your finger on the chip to see if it was hot” test, but were any ice cold?
2) On the schematic, the data bits from the RAM chips were going to an ‘LS245, but they also went to the chip right next to it (on the schematic, not necessarily on the PCB.) Did you replace that one?
3) Did you check the R/W-bar line going to the banks of RAM chips with a scope? It could be that - during writes - that line is asserted logic low, and the CPU is able to write the bytes into the RAM chips, but when it asserts it logic high for reading (the ‘d’ command in debug.exe), it’s got noise, or isn’t rising to the voltage level necessary for the bus buffer to pass it through from the RAM chip back to the CPU.
4) Once you discovered the DIP switch to re-enable the card memory, did you go back and check the CAS-line from that custom chip again?
For me most probable culprit is this 7643 PROM. It's in direct path of address decoding and it might have some differences in response time depending on address decoded. Is should have a pattern that could be recreated by some GAL and small pcb.
Hello Mr. Adrian. I love these repair videos. As you mentioned maybe the problem is resource conflict, but I don't think the motherboard is the problem. This board should be tested on a system with components specific to its time. For example, booting MS-DOS using an old floppy disk controller, because the modern one you are using may be the source of resource conflict and MS-DOS hangs on boot.
would also fit to the observation with the different ls als f type chips…f for example is fast but that comes with a cost…it daws mor current to force the transistors to go faster through the transit state…
Not all those earlier 8bit cards worked with every system out there. Test the AST on a different machine was what I was thinking from halfway through the video. :D
The fact that different banks of memory were behaving differently kind of tells me that it is the PROM which I believe you said was doing the row and column lines. Maybe parts of it are good and parts of it are bad and that's giving weird results.
Also the MS-DOS problem shows why march tests are important. A simple memory test just writes a value and then read it. Programs write values and then need to read them back again later after writing a bunch of other values other places. If those values get messed up then nothing works. I think the x86 stack also ends up at the top of memory (I tired to look this up but couldn't find anything) which would put it on the RAM card. A messed up return address will definitely lock the system.
The PROM is doing bank selection by controlling which address combinations enable the various CAS signals. It has nothing to do with RAS, and only gates CAS, it doesn't generate CAS.
@@Brian_Of_Melbourne what is the implication of this difference?
@@wearwolf2500 It's just a clarification. You wrote "doing the row and column lines", whereas it is actually ONLY involved with steering CAS to the enabled and addressed bank. Although CAS itself is generated from MEMR & MEMW via the tapped delay line U66.
@Brian_Of_Melbourne I also wrote "which I believe you said was".
I'd be interested in seeing if playing with the +5V rail voltage or adding bypass caps could help
I translated the BASIC program to C++ to run it on a modern computer and got the Mandelbrot set.
I wonder if its introducing a lot of noise being introduced somewhere. If not that i'm betting theres some physical issue with the socket, soldering, traces, or a broken chip somewhere.
Hi Adrian,
Days after your video, I haven't read ALL of the comments but I'd throw my $0.02 in on RAM timing issues. I saw in a close up that the chips in at least one of the banks of RAM chips ended in "-20" which back then correlated to 200 (milliseconds or microseconds or nano seconds?). This seems incredibly slow. And if the computer is dumping a block of memory, I could see the behavior where the start of the block operates correctly and it gets worse and worse as you move further and further into the block of RAM and it can't keep up electrically.
With all of your extra RAM, you might try putting one bank of "-15" chips in and seeing if that bank behaves correctly. I've never heard of RAM degrading or slowing down over time, but I've certainly heard of RAM being marked incorrectly or with marginal timings and what's on the card already seems quite poor.
Just an idea. Love your channel!
Craig Zody
I vaguely seem to recall himem and emm386 being flaky sometimes, maybe there is a switch you can use that would skip regions of memory to help narrow it down.
@25:20 "I know we're seeing all F's" I'm looking at the 1 D and 3 Es
@Adrian's Digital Basement
the death is not actually terminal
given the wealth of data on how the dip switches work and how the card addresses ram, you can quite easily figure out the function, then form your own rom dump for a new chip
that chip is basically acting like a programmed gate ADDER array, it is similar to sending a hex value to a rom chip address pins and having rom code that converts the hex value to a 7 bit led display for displaying the hex value
given the dip switch functions and actual address pins, what the dip switches are likely doing is shifting when the CAS lines activate, basically acting like a rom based adder circuit
all you have to do is build a rom dump that activates the CAS lines when the dip switches are in the correct position
basically when you set the card switches to 128k, your input address lines should only activate the CAS lines(basically an AND gate code block) ONLY when the address being read at input is 128k+the output
in fact I would be happy to define a rom for you to fix that old card, it seems quite easy to reverse engineer a ROM for that card, please don't let it become E-waste, let me code a replacement dump for a new chip
Sounds like you got flaky timing somewhere in the chain yes. If you got a logic analyzer you can check the propagation delay of all the gates involved in the chip-select logic.
i love 486's there my fave
From my experience with the Atari ST line of computers, swapping the same family chip (74LS) but from a different manufacturer could cause the machine to stop working or misbehave...
Need a RAM test that doesnt do serial access, but instead uses some sort of LFSR routine to "randomly" test the memory.
Would also be interesting to stick the scope on to the buses and see just how "noisy" the signals are.
use rem tester to check every dram chip, clone prom chip , deoxit all sockets, check for bad caps...but first check card with other motherboard
Maybe there is an compatibility issue just using the XT-IDE and the AST card together... Go back to basics, and use a period correct IDE controller and HD and see if MS-DOS boots from that.
Try removing the xt-ide card and booting from floppy, perhaps there is a conflict with the I/O address (or IRQ/DMA if it uses them). It certainly sounds like the ast works now. I've had similar problems with xt-ide, especially with the older firmwares
Have you done the baselines and checked the voltages and signal sanity? Family changes mean electrical load changes, if there's a capacitor or other component that's slowly failing you could be limited in how many watts are available before voltages start to dip. Things like Q1 are suspect too, that transistor's been smashed over at some point in it's life and triple-legged components don't like that.
I also assume the timing is bus derived.... what speed is your ISA bus set to?
Others have mentioned as well, will it boot from a floppy, without the XT-IDE controller?
Makes sense that SW5 disables RAM entirely, it's hooked to A9 of the decoder PROM. If the top half of the decoder PROM is all zeros, none of the outputs will ever go high and the RAM won't respond.
You really need to test that big ass ps/2 card!
Just had a thought Adrian. Could it be something in the page decoding, where pages (or some other power of 2 I guess) are being duplicated across the address space? That would pass rudimentary RAM tests while also failing when in use?
I would love to watch the livestream where you go over the boxes even non-patreon, stream it on your second channel if you think it's not quite good enough for the main one?
if you're getting random bit errors, then you're firmly in the analog domain. you need to break out the 'scope and watch the timing/voltages of the bus/control lines on those ram chips. my money's on a bad chip weakly pulling a control line high/low and causing its timing to lag.
Hi Adrian, this was an interresting video. What if, IC U68 is removed and the output O1 through O3 is simulated by setting these to low or high to check the RAM. I'm also not sure if IC U27 (74S138 for CAS) or IC U11 (74S138 for RAS) works correctly. There should be always a low signal on one of the output signals Y0 through Y7.
Best luck to fix this card. 🙏
Does your IDE adapter use DMA? May then there's a slight difference in timing. At least the varying behaviour when changing the bus driver with parts from different families which have different speeds point in this direction.
You should dump the PROM chip. I expect to see quite simple patterns for bank selection. With 35..70ns delay the PROM chip not extremely fast, so it could be replaced e. g. by a 10ns GAL chip.
When you said "that's definitely a bad chip," I couldn't help myself. I instantly thought "bad chip. Bad, bad chip! No electrons for you!" 😆 😏 Well... it sounded funnier in my head.
The only thing I can think of that might be causing the problems is that the RAM can't "recover" from an access quickly enough to allow the next location to be immediately accessed when the next instruction cycle comes around, but the slower access speed used by a memory test means that the "recovery time" is longer.
The 74LS245 chip could the problem. It looks like it's remaining "enabled" for longer than it's supposed to be. But it might not actually be the chip's fault. If there's some stray capacitance on the chip select line for the 245, that could be holding it "enabled" for longer than it's supposed to be. The reason why swapping chips partly fixed the problem may be just because they happen to have a slightly faster "recovery" time which helps them to cope with the extra capacitance.
So in short, I'd go looking at the CS for the 245 and see what causes that to be enabled, and check for stray capacitance or anything else which would tend to hold it at the enabled potential. It may even be a low-value resistor which is tending to pull it down (iirc, it's negative logic which means it's enabled when low). Good luck and thanks for the interesting videos.
PS: Come to think of it, the same problem could be caused by one or more of the CAS lines not "recovering" quickly enough.
Adrian, at 25:52 and 37:50 it's NOT all FFs.
Also at 39:17 there is also "ED" which you didn't take note of.
Just noticed that. Dunno if that helps with anything.
When you find a board that works, you might want to download the Motorola PROM contents. When used as logic as it is here, it should be easy to debug a possible bad PROM in the future. It would also allow programming a new part if you can find one along with a programmer. As for the problem at hand, you might want to check the signal integrity around the control logic. Slow rise/fall times can change the effective timing and may also create the random results you are seeing.
also fits to observations
This youtube video made me feel like I'm in the Tron movie.... bits bits....(tnx)
I suggest trying diffrent flavour Dos, (MS have issues with older hardware pre 286) , 86-DOS, FreeDOS, PC-DOS..... Also maybe the card just not likeing the 2024 date , try using 80s setup date (I had issues on MS-DOS and setting newer date's , sometimes , on older hardware). Other than cleaning the slot pins and trying on diffrent motherboard or inside a case or a floppy/hdd boot with dos flavours , not much you can do. (I hope my comment helps , mr. @Adrian's Digital Basement) I enjoy all your retro stuff , even if it's long. (sometims it helps me sleep - little joke , no offence.).
I kept telling the screen to just check the hex results. I could see the FE results were not always showing in the ASCI output.
Maybe defective capacitors cause power glitches when the RAM is accessed frequently (e.g. when booting DOS)?
42:49 It‘s like playing the game „Mastermind“.