A man with one mem checker is always certain. A man with two mem checkers can never be certain.

@RedstoneLP2

20 күн бұрын

needs a third one for insanity checking

@williamsquires3070

20 күн бұрын

Yeah, and someone with three of them will be utterly confused! 😆🤣

@offspringfan89

20 күн бұрын

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.

@horusfalcon

20 күн бұрын

There's an old Navy adage: Never carry two clocks at sea. Carry either one or three.

@suvetar

20 күн бұрын

Spat my tea out - Genius 😀

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.

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?

@Brian_Of_Melbourne

20 күн бұрын

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.

@paveljelinek772

19 күн бұрын

These are good tips 5008j

@yohannwilkerson6058

13 күн бұрын

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. ;)

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!

@kaitlyn__L

6 сағат бұрын

I was thinking some pins seemed to be pulled down to ground all the time, instead of only when not driven by other chips; a shorted resistor (pack) is a perfect candidate culprit!

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!

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...?

@seancurtin6103

20 күн бұрын

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.

@mulad

20 күн бұрын

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

@eDoc2020

14 күн бұрын

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.

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

@jonweimer

27 күн бұрын

Same. there’s something odd happening in the 5000 range

@coreykirkpatrick4392

20 күн бұрын

I saw that too

@ultrametric9317

20 күн бұрын

That's why I hate the CGA font! I always hated it from day 1.

@Numfuddle

20 күн бұрын

There was one FD. Noticed it right away

@Numfuddle

20 күн бұрын

Also one FE in addition to the FD 25:20

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..

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!

@NotMarkKnopfler

20 күн бұрын

Changes in behaviour based on logic family would tend to make me suspect timing that is right on the edge.

@billfusionenterprise

20 күн бұрын

could be a handshake that changes when software loads, like I haven't seen that

@horusfalcon

20 күн бұрын

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.

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.

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.

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.

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!😂

@TheBitPunch

20 күн бұрын

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.

@StarsManny

20 күн бұрын

Adrian's Digital Opening?

@monad_tcp

20 күн бұрын

@@TheBitPunch that's what the French does to you, you're never the same after

@95Comics

20 күн бұрын

@@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

@batlin

18 күн бұрын

​@@TheBitPunchthey don't sound the same! Adieu is like "add-yuh".

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.

[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.

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.

@pgriggs2112

20 күн бұрын

Manual page swapping! lol!😂😂😂

@billfusionenterprise

20 күн бұрын

I suggested he change video cards, I have seen that be an issue. Along with network and sound

@jwhite5008

20 күн бұрын

>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.

It might be a good idea to dump that 4096-bit control ROM, in case it ever does break in the future.

@niels_m_h

17 күн бұрын

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.

These hardware debugging videos are pure gold, i love the troubleshooting😀

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. 😊

Based on the schematics and the full board, the logic chip programming can be reverse engineered ;) I did something similar back in college

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.

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!

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.

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.

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.

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.

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

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?

This investigation gave me flashbacks to CuriousMarc's RAM refresh issue on the HP 9825 computer repair.

It's 1983..AST is selling these cards while Hawkins, Indiana is going through great turmoil.

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.

I had a Future Domain SCSI card in my 286. I got it for a song, they were excellent cards, top of the line.

It's all interesting, Adrian. Oh heaven, heaven is a place, a place where the retro computer parts, never stop happenin'

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.

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)

what a rollercoaster!

Today on Adrian's Digital Boxes! Yeah I can see how that could become you entire channel if you let it.

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.

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)

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..

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).

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!!!! :-)

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?

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.

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.

@billfusionenterprise

20 күн бұрын

could be, could also be another card on the bus, video, sound , network

@terrylutfi8888

20 күн бұрын

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.

@davidellsworth4203

19 күн бұрын

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.

You should dump that 4-bit ROM so that others may make a replacement if theirs dies.

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...

Before the comouter stooped seeing the ram, you werent getting all Fs, you were getting the occasional FD or FE as well.

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.

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.

@therabin2554

18 күн бұрын

It WAS running on 4.77MHz all along.

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?

the 74LS240 could be feeding back to the 245.

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.

To me, Diagnosing RAM problems is like Pears or Bananas going over-ripe the second your back is turned - I swear that they've lying in wait for you to distract yourself for half a nano-second 😀

This AST card was hilarious!

it is like there is a bus conflict with your IDE card and the mem card

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

42:49 It‘s like playing the game „Mastermind“.

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 🍀

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.

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?

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

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?

I see Rammie is awake today

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.

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.).

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.

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.

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.

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

Yeah, I forgot. The old XT machines did have parity errors unless you used 9-bit RAM or 9 RAM ICs.

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.

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. 🙏

DOS4 is now open source. You need someone to add some debugging info output in it for you!

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.

@Brian_Of_Melbourne

20 күн бұрын

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.

@wearwolf2500

20 күн бұрын

@@Brian_Of_Melbourne what is the implication of this difference?

@Brian_Of_Melbourne

19 күн бұрын

@@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.

@wearwolf2500

19 күн бұрын

@Brian_Of_Melbourne I also wrote "which I believe you said was".

I translated the BASIC program to C++ to run it on a modern computer and got the Mandelbrot set.

Just talking off the top of my head: Parity chips, are they good? What does switch 6 do - do i remember it isnt in the manual? Does it possibly disable the parity chips or would the machine not work with it disabled?

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.

I'd be interested in seeing if playing with the +5V rail voltage or adding bypass caps could help

Adjusted that mandelbrot basic to RCA basic3 and it took 45 minutes to run on an emulated RCA MS2000

You really need to test that big ass ps/2 card!

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.

Do the long box videos over time, damnit! lol also there were some FDs and FEs in there, could be support logic or bad RAM cells.

is this board turboing at all? I feel like this could be a situation where the ram is running too slow for the ISA bus. The memory speed (200ns if the ram labels are correct) are generally recommended for 5 Mhz or below. The tests may be taking their time with running and the 200 ns ram is ok with that but when you are using any normal program it may just be trying to write to ram continuously and getting errors after some point.

U66 is a delay element with taps used at 20, 40 and 100ns. If you pop a scope probe on the input and another on each output in turn, you can see if the delays are correct. A0-A15 are multiplexed onto 8 bits using U48 and U49. If the enables overlap then both will be driving the internal 8-bit bus at the same time, so you could check that. Also, popping the scope on each of those internal address lines to see if they're nice and clean might reveal something. Have you checked the expected refresh interval for the two types of DRAMs you've got?

I'm at 54:01 i'd guess there's some bus conflict? Have you tried to mess with other (especially 6th one) dip switches?

I really enjoyed this one. I'm wondering if maybe the RAM chips in this card are not the right ones. They look to be 20ms parts. Maybe that isn't supported? Also, I'm thinking that the chips are sharing the address and data lines, so while they might appear to be working, they could potentially "poison" the lines, maybe? I think I would try to populate the board with only one bank at a time and see if the problem goes away. Also, maybe check if the refresh is working as it should. And, does the number 6 dip switch do anything?

@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

very first view of the memory isn’t ALL FF, I see FD

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?

When the memory is being read sequentially (like when the BIOS performs the initial memory check) or in small chunks (when you are using debug), by the end of the video everything seems to be working fine. It's when memory access patterns become more diverse, that's when the problem appears. If my understanding of the way electronic circuits work is correct, then in the first case current going into the memory chips should not be changing all that much, while in the second case it will vary a lot. Is it possible that those capacitors near the memory chips are not performing as well as they should? Might also explain why replacing logic chip with more energy-efficient CMOS version made it work a little bit better.

@melkiorwiseman5234

20 күн бұрын

Sounds like it's worth a try. At worst, it'll do nothing. At best, it could fix the problems.

I had an weird ram issue in the old days with some apple IIe's and there were some schools that added their own ram cards and somehow they mixed up some ras before cas chips instead of cas before ras, might be a long shot, maybe some of the ram on the AST card was replaced with mislabeled chips?

Great 😊