Відео

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.

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

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.

Adrian .. supose that the pins on the RAM are identical to the newer RAM chips .. If we replace what would happen ? Does the memory increases ? Just curiosity !!

27:10 I can confirm the Rio daughterboard is compatible with the standard WaveBlaster connector. Additionally, this is one of the rare daughterboards that not only receives MIDI commands but also can _send_ MIDI commands back. These are used for proprietary commands, such as loading your own sound fonts over MIDI into the SIPP memory.

I love watching your vids, sir, I'm learning... well, a bit. After this one I can't help but notice apple's pricing strategy seems to have already blossomed with the horrid amount of ram on the Classic... 1... and to make it useful you have t purchase what was probably a very expensive daughterboard.

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

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.

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

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.

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.

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.

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?

When your modern drive got 71 000 Hours

2 hours? Too long but don’t go very high temp.

I repaired the GPU on my iMac mid-2011 by baking it. This fix resolved the issue, and it has been functioning without any problems since then. I continue to use the same iMac today. The small circuit board that houses the chip had no plastic parts so it was ok. I left it in the oven for approximately 10 minutes, although I don’t remember the exact duration as it was about four years ago. However, I did purchase a separate oven thermometer to ensure precise temperature readings. I placed the circuit board in the oven while it was cold and allowed the temperature to gradually increase while monitoring it. After 10 minutes at the preset temp, I turned off the oven and allowed it to cool naturally. It does work. Before the oven process the iMac had 4 green vertical lines. I can tell you that it worked for me.

. . . Obviously, you are wearing an Apple T - shirt incompatible. . . .

2 guesses. A V20 cpu chip can be incompatible with AST 6 pak type cards ? Timing issues - see minuszerodegrees. Also youve got a mix of 4164, 4564, 4264 type chips - some had paging support some didnt. ?

Am I the only one who saw the FD when he checked 5000 the first time and said they were all FF?

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!

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 😀

Since the card is sort of working the Logic Rom is probably mostly good so you should dump the ROM, By using a rom dump and the schematics someone might be able to reverse engineer what the rom's equations are supposed to be and construct a new one.

There are plenty of FE and EE bytes as well looking at that debug readout. Edit: Nevermind, you just noticed that.

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

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?

the 74LS240 could be feeding back to the 245.

The motorola rom maybe acting as a state machine, just need the rom contents to adapt a replacement....

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?

Did you try memtest86? It's a boot sector memory test. No need for operating system.

At 25 Minutes there is one value FD

I had one of those cyrix clock doublers - I still have the motherboard somewhere. I would have taken the old processor and put it in the box that the new one came in so I do have the box somewhere but with the old CPU inside!

I've got one of those caddy CD drives but in an external case - I've used it as a CD player before but too slow to use as a CDROM these days!

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?

So; switch 5 on the AST card had an effect of disabling the memory... because it all goes into that custom prom. You didn't seem to change the other settings to off. I think switch 7 was also "on" in your video. Have you tried setting everything to "off" on any "undocumented" switch? At least any switch connected the addressing PROM.

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.

Looks like classic poor decoupling.. check the caps inc the ceramics on the power lines to any of the ram control logic.

I wish I could have my 1:13 minutes back ;) Maybe start by spraying that entire 40yo card down with CRC electronic cleaner. It has acids in it to dissolve corrosion. And then reseat every chip. I think corrosion is most often your biggest battle. It's the easiest thing to get rid of to start. That has bitten you more times than I can count. Even if you wiggle it and get a connection. It's not road ready. That's just regular maintenance, before you even work on them.

Send it to the 8-bit guy he worked for AST 😂

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.

You might do a close order inspection of the memory board under a microscope or high-power magnifier. Look for the usual suspects: trace damage, shorts, opens, cracked solder joints, etc. Get back to first principles. Ya never know, it might actually help.

the memory bank is in series meaning that if any of the chips are bad the card locks up the pc. use your open source chip checker, chip by chip

Check the resistor packs, and if they exist related capacitor packs. When using the ALS chip, I suspect that DOS is finding and trying to use the high memory area (HMA). Try booting without any DOS configuration - Ctrl-F5 at boot, I beleive. If memory serves, the HMA is RAM above 1MB, yes above the 1MB addressing limit of an 8088/86. Basically exploiting an implementation, ah, feature...

I have to ask, where can I get an Apple ][ T-shirt like that? :)

5:10 Some Asian countries have a history of gamers over exerting themselves and dying. They neglect sleep and food. Seems like the vendor is just trying to cover everything.

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?

Be funny if dip switches 6 and 7 has something to do with parity enabling.

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

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'm not sure, don't you check timing of /WR, /RD and D[7] using logic analyzer? I wonder if data output buffer is driven a bit late when reading from MegaPlus II. (I remember correctly, LS, F, ALS have the same TTL threshold, the speed of them is in the order from F, ALS, to LS. So it is very confusing that ALS is better than F.) Anyway, I doubt if MegaPlus has a little timing margin on bus control...