So, watching the series so far, nice work on the use of derivatives, I didn't consider that when trying to noodle out the problem myself. Question I have is what we can do about those square roots and squares as those might be pretty slow themselves. I'm at start, so I'm hoping this gets addressed in this video, though that may have to wait for part 4.

Nice of IBM to let you disable DRAM refresh and do things like this. Can it be done on other contemporary systems? Once per frame refresh would be a big improvement over anytime during a frame refresh that it does by default. Even if doing it during frames you can cycle count your custom dram refresh and exit it if you need to do something at that time. It would be tricky to time your cga register writes using dram refresh code but it might be doable if there was no other choice but the dram chips seem very forgiving so it is probably more trouble than it's worth. Testing temperature dependence might be an idea, blast the chips with very warm/hot air and see if they decay faster. A hair dryer on low heat would probably be good enough and shouldn't get hot enough to melt things

Nice. Any chance of using this method for drawing a partial ellipse (elliptic arc between 2 angles)?

so how often? ^^

b is related to both skew and rotation

Watch out for a typo on my slides. I have - Ex in one place that should obviously be - Ey.

careful in these tests that length between refreshes and length the system has been running (therefore the temp) don't correlate in any systematic way not that it would change the results. but if you did want to quantify the time to corruption more precisely you would have to incorporate both temp and time between refreshes into your analysis very nice video. i loved the systematic and logical approach you took to the question :)

The refresh doesn't touch every memory location. It only has to touch the row or column addresses.

It's my understanding that the refresh period is bound not by how long it takes to decay in isolation (what you test), but how long it takes to decay when memory rows around it are accessed. But I don't know how big of an effect this is on chips this old, it can be quite pronounced on newer chips but they're many orders of magnitude denser. But you may find that as you use the memory the retention time creeps down, so a healthy safety margin might be in order. But even with modern (ultra-dense) chips it's often possible to get away with setting refresh rates way below the official numbers in practice, "overclockers" often maxing out the register allocated for this in the memory controller which translates to something like 5-20 times longer than the official refresh rate which is IIRC spec'd at 85C. At least for some memory it's documented to require refresh four times as often at 125C ("military") over 85C ("commercial") so there's definitely a temperature component - perhapos a doubling every 20C? I've never seen any manufacturer project this to lower temperatures but it sounds possible that it might hold - it's known you can store memory content almost indefinitely at cryogenic temperatures. IE, reading a row ALSO depletes nearby rows "a bit" and writes also "leak" somewhat into nearby rows - this is the basic idea behind the RowHammer attacks on recent DDR memory (unfortunately with DDR4/5 things are getting so cramped NO reasonable refresh-interval might be safe and other remedial actions has to be taken). I do know that how long memory lasts without refreshing can be extremely variable depending on brand and model of memory chips, there's examples of 8-bit micros where some will survive a few seconds while others doesn't survive a brief flick (200ms?) of the power switch. This "accelerated decay" can be hard to profile since rows may not be layed out how you think, often both row and address lines are routed based on "easiest" path rather than A0/A1/... since it doesn't matter. For the memory you show I guess you could try hammer the "next" physical row by trying incrementing A8 to A15 (given the 8+8 setup) and try reads and write (inverse bit value?) - that's "only" 16 (8 address lines, read/write) sampling tests (or 18 for a 256kbit chip) but as you mention it's already slow and this would work as a multiplier, but you can use your existing results as a guide to narrow it down to find out if it has an appreciatable effect or not on your XT's memory.

We used to do a fun trick in our lab back around the DDR2 days. Write a pattern to memory up in an area DOS doesn't use. Then power off the system, remove the DIMM, pass it around if you'd like, and put it back in. Depending on how long you took, you could see various amounts of the 1's in the pattern decay to 0's.

Setting tREFI to 262k clock cycles on DDR5 is way more interesting. 2Gbit/32banks/8192bytes per row (maximum)=minimum of 8192rows. Refresh - takes at most 1 row in each bank at a time -> 262k*8192rows/(5200MT/s)=0,413s for whole memory to refresh.

Downside of trying to include error-correction back in the 1980s is the number of extra bits you need. For parity, it's just one extra bit, and therefore one extra chip. If you want to protect 8 bits of data, you need 13 bits for ECC, needing 62.5% more chips. Really making use of ECC came later when memory was being accessed in larger blocks from chips that would read out multiple bits at a time. With 9 chips of 8 bits each, you can do a 72-bit code with 64 bits of data, which can correct one error and detect two. Though this isn't using the code to its full capacity, and neither was the 8-bit example from earlier. That 72-bit code is just a truncated version of a 128-bit one, but that wouldn't have a nice power-of-two number of data bits in it (120). The 13-bit code is truncated from a 16-bit one, which would have 11 data bits. It took me a while between finding out about Hamming Codes and figuring out how the 72/64 one used for ECC memory would actually work. It's basically just calculating the error-correction bits with bits 0-71 normally, and acting as if bits 72-127 are always zero, and as that last range of bits would all be data bits, it doesn't need to bother storing any of them.

Wow, you uncover super topics ! I am not tired to like your videos !

After all my speculation it's incredibly gratifying to see the subsequent thorough testing. I'm happy you felt compelled to go down the rabbithole and thanks for taking us with you!

I don't know about DRAM but when I was working with SDR SDRAM on FPGA, memory contents easily survived reconfigurations which take couple of seconds. There are no refresh cycles nor memory accesses during that time. Every pin is in HiZ state.

I'll be testing: -) You don't need to refresh the whole chip by the way. Just the part you're using. So no issues only refreshing 64k on a 256k bank. In fact you can use 256kbit chips in place of 64kbit chips and addresses line A8 are just not used.

Those results seem odd, surely the decay can’t always be identical yet you wait 10 times the same duration and only see 1 error. Even on the larger test the error stays almost constant after the first wait? If you use a slightly longer wait or more iterations do you see more random behaviour?

What changes will need to be made for Mode 6 (640x200) if any?

If you were to use square roots, what would be the input range? Would it depend on the screen resolution? If so, a lookup table is an option.

A filled general ellipse is much harder than a one-pixel outline general ellipse. You convert the rotated ellipse formula to a sheered circle and then you can go through getting the left and right extend for every Y value. You can get any ellipse this way. for ellipses that are very skinny you often have to worry about precision artefacts so you'll want some logic to decide whether to do horizontal or vertical scanlines. I seem to remember that when you get to a certain point that general conics come into play. My maths skills fail me at this point. I never had an intuitive understanding for parabolae and hyperbolae that I had for ellipses either, which doesn't help.

I think it would also be possible (or at least interesting) to explore Feynman's construction. Feynman uses it for Kepler's orbits. This method allows the construction of ellipses and hyperbolas. Square and compass construction uses a reference circle and lines. The tools required are straight lines and the ability to draw an orthogonal line from the centre of another line. It sounds complex, but there may be arithmetic and algorithmic shortcuts. en.wikipedia.org/wiki/Feynman%27s_Lost_Lecture

You may want to fire up DeluxePaint II for the PC to see Dan Silva's solution to this. In that program, you first draw the standard ellipse, then hold down a mouse button to rotate it to the number of degrees you want. This implies that the algorithm is 1. calc regular ellipse, then 2. rotate all previously generated points around the ellipses' center point. This seems pretty fast to do since the rotations are only one axis. For ensuring there are no gaps in the rotated points when drawn, you draw lines between the points rather than the points themselves.

Do you plan to make a tutorial about coding an emulator for an 8 bit pc like the zx spectrum someday ?

Hi there. Some RAM chips have extremely long retentions. I've had machines retain most of their RAM contents several seconds after power off with just minor decay. It seems to vary wildly from brand to brand, series to series. I have others that 1 second after power off are totally cleared. I assume the stock refresh time is setup to be safe across all types of tested chips from back in the day. Unless your XT has 256k total on the motherboard, banks 1 and 2 are always 41256, with 3 and 4 being 4164. And then only the very esrliest 16-64k 5150 machines use 4116 the all the laters ones use 4164. Parity errors only happen on reads as the circuit generates a non maskable interrupt. If you dont hit one then the contents of DRAM matches what was originally stored in the parity chip so your refresh timer is good. I have not confirm this but I'm pretty sure the ram that's on the CGA card itself is refreshed by the 6845 redrawing the screen 60 times a second. I'll need to dig into it a bit more to be sure.

OSU

Coming from an Amiga background, it sounds odd to me that you can customize or disable memory refresh on a PC at all! OCS Amigas have a register for setting the current refresh row, so in theory banging it will stall memory refresh. I tried testing this on my AGA system, but I found out the hard way that on AGA systems the register is a dummy and writing it does nothing. Guess I'll have to dig my A500 out of storage sometime and try again. 8)

I discovered something interesting investigating the V20 CPU - it will resume from halt nearly instantly (2 cycles) on interrupt, if interrupts are disabled. That's right, it resumes on interrupt even if the I flag is cleared; although it does NOT perform the interrupt in that case. It just immediately starts executing the next instruction after HALT, and so as long as you guarantee the next instruction is fetched going into halt, then you have an almost instant resume. Might have some intriguing applications for demos; not sure!

OMG I realise I have gotten older in the last 30 years... these things were my usual subject of exploration when I was younger. Today I couldn't stand all this complexity and even RISC machines make me angry 😛

Like ❤

I have a similar utility on my XT to slow down refresh. Came from a Peter Norton article I think. Same as yours just modifies the timer. I too could set it wildly out of spec. Gives a measurable speed boost, I do see the odd parity error once in a while so it’s definitely doing what we expect. Love the detail in this video series btw!

I have one last possibility for you -- is it possible that RAS is energized on ALL RAM banks even when they aren't selected? It's valid and shouldn't hurt anything if you don't otherwise enabled the chip.

Also, I know you say you don't observe too much margin in other test scenarios so maybe don't put too much stock in this speculation, but: my electronic designer spidey sense says thaf if I was the engineer designing that DRAM I would be specifying that refresh time VERY generously, because I wouldn't necessarily be very confident about the margin on the components as the silicon ages. Remember the RAM is probably specified to work at 80 degrees for 20 years or something, and with say 10x margin left at that point on both the amplifiers and the capacitors, with the supply voltages just barely in spec -- and your ram is probably operating at a nice cool temperature, has never really been stressed in its life, and maybe the process was just a little better dialed in on that batch and you can easily see how those margins could multiply out to a 1000x margin overall. But see my other comment -- if you're only checking parity, it could also just be that the RAM really is losing its brain and you're not detecting it because parity kind of sucks!

If the parity is even, and all the bits degrade to 0, or if the parity is odd and they all degrade to 1, or in general if your DRAM pairs tend to degrade 2 or 4 or 6 at a time, the parity will still come out good. Parity isn't generally a very reliable way of detecting errors, which is why you dont really see it in new designs! You might see a parity error faster if you fill memory with random data or a mixed bit pattern (say 0xAA55CC33) before doing your DRAM parity tests, or alternatively actually write a program to fill with a specific pattern, halt refresh, wait, and check the precise pattern.

when a bit corrupts does it flip or always get set to 0 OR 1?

cool stuff!

According to the 8042 keyboard controller datasheet the buffer is just one byte!

A long time ago I wrote a program that slowed down ram refresh to get a slight speed up. I remember that I could set very slow rate and pc still worked fine.

Multiplication by 50 via LEA could be faster ?

always like !

Me clicking on this vid thinking CGA stood for "conformal geometric algebra" 😭

oh that prompt ... i spent a dozen years looking at "c:\>" (until win95 -- win 3.1 still required DOS), so many days dealing with autoexec.bat & config.sys .... (my trauma from "command line" days are so huge i never touched linux OS...)

could something like GlaBIOS' CGA optimizations make things even faster?

I don't have enough brain bandwidth for this... 🤪

What language is that example code in? Why do you have multiple 1-bit shifts in a row in the assembly instead of combining them?

Elipses are like communist rectangles

KZfaq's algorithm at it's best - subscribe ! :) Brought back so many memories of my first steps in programming - on IBM/Apple clones in the early 90's (eastern europe thing); I miss those (failed) teenage attempts at 3D rasterization on a 80286/CGA... and 30 years later, I still look at the assembly output of my code and itch for (micro)optimizations. Thanks, I will have fun watching your videos!

Awesome

Fond memories of early graphics and assembler :)

Since we're running the PIT system counter roughly three times faster than before, we could count the number of times the interrupt is run and adjust the tick counter in the BIOS data area by about 30% of it before the program exits, so the DOS clock stays largely untouched. Alternatively, every third interrupt call could JMP FAR [handler_offset] rather than returning itself, although this is probably not great for avoiding jitter.

Have you looked into Bresenham's algorithms?