That is an interesting discovery. It seems sort of random, as it is hard to imagine there being some need for the V20 to optimize this specifically. I assume this is just a result of various other optimizations they were actually focused on. It's pretty wild that it resumes even if the I flag is cleared.

Yeah I remember using such a program back in the day. Such a program was very popular at some point. But I remember it crashing the machine for even very small increases. It'd work for a while and then boom, it just stopped.

Thanks for confirming my suspicions regarding long retention times and the other info. Regarding the CGA RAM, yes it is definitely refreshed by the CRTC. No parity bit though of course. The info you gave regarding the XT motherboards has me wondering now. I'll have to check again tonight. I see in the IBM documentation, the 4164's are usually in banks 0 and 1, but if you install more then you are supposed to switch the chips. That leads to a few possibilities: 1) I misread the notations on the board 3 times (most probable) 2) the chips are installed incorrectly or with some hack, 3) it's not an IBM board. I will have to check now that you've pointed this out.

@@pcretroprogrammer2656 here is the specific info on 640k on an XT from IBM: www.minuszerodegrees.net/5160/motherboard/5160_upgrading_256k_motherboard_to_640k.pdf

Banks 0 and 1 are closest to the slots

@@adriansdigitalbasement There's absolutely no question about it (I just checked again), and banks 0 and 1 have 4164's in them and banks 2 and 3 have 41256's in them. It's labeled as a 64-256kb board with a sticker that gives the model number as 6323560. The layout of the board seems to be the IBM layout, and there are markings on the board which match what I see online. I also don't see any evidence of any kind of mod. I can certainly modify contents in 640kb of RAM and it retains them (I checked this for each 64kb block and then went back to check the contents were still different in each block). Bit of a mystery I'd say.

@@pcretroprogrammer2656 fascinating! I had no idea that would work. Perhaps whoever did the 640k mod wired up the extra address line to bank 3 and 4? Definitely on all the 5160s I've seen the mod was done as instructed and they had the 256k chips in the first banks.

Yeah it's mainly designed to detect single bit errors (without correction) and isn't at all designed for this situation where we are turning off DRAM refresh. In our situation, it's actually likely to be most useful when many of the cells are in an indeterminate state and all the bits are essentially random, at which point there's a 50% chance of a parity error per byte accessed. After some time, it's probably the case that everything decays one way or the other (though I don't happen to know for sure), in which case it's possible that parity errors disappear. So there might actually be a point in time where parity errors maximise and then drop off after that.

Thinking about it more, it seems to me that parity was pretty well understood at this point in digital design and they should have chosen a scheme that was guaranteed to generate errors if refresh failed entirely, but I don't have a 5150 to check on the oscilloscope to be certain. Maybe later I'll try to find a schematic, but it seems more likely to me your low memory refresh is accidentally refreshing all banks somehow.

@@josephlunderville3195 You actually had me wondering for a bit. But I went back to some correspondence with Reenigne where he specifically pointed out to me that reading a memory address only refreshes the row on the bank being read and that this differs with what happens when the DMA controller does it. That certainly matches with what I've seen in practice, including when writing the code for this video, where refreshing just the first bank still allowed me to generate parity errors on the second bank. Quite why it only happens so far out of spec remains a mystery to me. Reenigne previously expressed considerable surprise that a PIT count of 76 (or something equivalent) would still give stable results. On his blog he mentions that changing this from 18 to 19 or perhaps 20 was fine back in the day, but that's about it. That was also my experience, though it is easy to fool yourself if you are not actually accessing banks that have decayed. I'm now starting to think that 30s of decay is sufficient to result in the RAM and parity bits all being wiped out and that if I had much smaller delays I'd get parity errors. I might need to do a follow up video if that is the case. For example, I could hijack the interrupt handler for parity errors to detect them and try various delays to see how long it takes before parity errors start appearing and possibly disappearing again.

According to Reenigne, in the XT the parity bit was inverted, so that if refresh circuitry failed and everything decayed to zero, the parity bit would be incorrect. And apparently the Samsung chips in my XT require only 128 rows rather than 256 to refresh the entire chip, despite what it says later in the datasheet. This explains how they were compatible with the DMA refresh arrangement in the IBM XT (which would otherwise be too slow).

No, that is unfortunately not the case. We can in fact keep the first bank alive and get parity errors on the other banks, which proves that. I don't know if there is a reason for this design. However, I think the story is different with the DMA controller. The PIT is running at 1.19MHz and with 18 PIT cycles per pulse to the DMA controller, that means it is getting a pulse at about 66.3kHz. If it had to energize 10*256 = 2560 rows at that rate it'd only be doing the whole of RAM every 38.6 ms. So that is clearly energizing all banks simultaneously. Actually, that would still be out of spec if all 256 rows in these KM4164 chips needed to be energized every 2ms. So the 128cycle/2ms figure in the datasheet must not mean precisely what I thought it meant. According to Reenigne's blog, they require energization of 256 rows in 4ms and the bigger chips 512 rows in 8ms. So I think the figure in the datasheet is actually a rate at which the row addresses need to be cycled. So that means the figures I gave in the video were actually off by 2.

Yeah that Samsung RAM is rated to operate between 0 and 70 degrees C. I'm not sure what the effect of temperature is on decay. One assumes there is some kind of effect though.

@@pcretroprogrammer2656 Mostly it encourages electromigration and delamination. The traces inside and interconnects get thinner and weaker as electromigration etches away, and components that are layered or bonded on the silicon will flex from expanding and contracting at differing rates from even minor thermal cycling, causing broken traces and even microfracturing. It's an extremely slow process, however, and is highly dependant on the frequency and voltage involved relative to the thickness of everything that conducts, and the temperature (both height and, cyclic different. Going from 32 to 80 and back every hour is going to wreck it way faster than a solid 80.) Things in this era were often overdesigned in many areas in beneficial ways for other reasons- like extra oversized interconnect points for making it mechanically easier to produce. So some will last through apocalyptic events compared to smaller, more micronized modern chips. Which is why you see a lot of 16-bit computers cooking their poor Z80's or whatever their entire lifespan, pure out of spec on temp, but they just kept marching. They were built different back then, and it took more abuse to cause the same damage! But like any chip, once they burn out, they're gone. RAM is usually either extremely hardy or extremely flimsy, depending on the area of prodding. There's a lot to do with the density of memory chips, too, and the relation of defects per square millimeter in the silicon making process that makes RAM a more random silicon lottery than most, as even within known good picks the likelyhood of a defect, if present, causing an issue is much higher. And not all- i'd say most- issues are readily apparent by outright failure. It can be like a blemish or dust mote spot on the mask that causes a trace to be 1/4 it's normal thickness at a spot, which will wear out faster or under more stress than normal. Etc.

That's a really good question, and it is exactly what I was thinking too. I didn't want to sound off without knowing more though. There's supposedly a transistor and a capacitor, so one presumes the capacitor leaks charge. But I don't know if the data is stored inverted or not.

​@@pcretroprogrammer2656 If it's getting stale it should in theory drop to 0 or whatever the system logic calls low, shouldn't it? I'm sure you can do it either way and have heard of those that invert the logic, but most go with no on low simply to prevent powering unused memory circuits. But if you knew you'd be using most or all of it during normal operation, I guess it may be wiser to invert that for the same reason. Worth investigating!

@@janglur Yes, that seems to be what happens in practice, though the designers of the XT apparently invert the parity bit so that if it goes stale it effectively goes to a parity of 1 meaning that staleness would eventually be detected when everything decays to a low enough charge (thanks to Reenigne for pointing this out).