In both cases mentioned in the previous logs (SDRAM and LCDs' column-drivers), it seems newer devices sometimes carry-over features once thought worthy of designing-in to the early products, and basically forgotten and undocumented in the later products.

In the case of SDRAM's full-row burst mode, it seems it was a design-idea early-on, amongst the brands involved in such designs/standards (maybe related to JEDEC?). But by the time SDRAM was common-enough for other brands to start making it, too, some weren't mentioning it in their datasheets.As I gather, by then Intel had written a reduced standard for desktop PCs... and that's what most manufacturers put in their docs. Yet, why, then, would they still have full-row burst-mode at all?

At this point in my archaelogical dig, I begin wondering... Obviously SDRAM DIMMs were *very* common in consumer products. And so many "no-name"/just-starting chip-makers wanted to appeal to them... BUT, SDRAM chips were somewhat standard, before PCs standardized their needs. So, then... marketting? Why would they go to the trouble to make their chips compatible with a bigger standard that they weren't marketting to in the first place? High hopes? I dunno.

But this is the "history" aspect of it all that gets me wondering.

I think I explained similar in the last log about LCDs' column drivers pretty well... But I could take it further... 

In my experience, column-drivers were pretty simple, I'd've doubted there's a JEDEC-style standard for them, but all the ones I'd encountered before were very similar. Basically a huge shift-register capable of outputting numerous different voltages for "1" depending on the timing (LCDs prefer AC, not DC). 

So... what weird unique features would a column-driver designer try to throw into something so otherwise well-defined? How could something like that be revolutionized?

That's why finding this new-to-me design is so interesting... Obviously, it didn't "catch on" in the mainstream. Yet, it actually might have.... MIPI displays, for instance (many *many* generations later), have a similar ability, to stop streaming data and instead enter self-refresh. That *seems* like a feature of the MIPI-receiver/controller chip, no? A built-in framebuffer would be a fair amount of RAM if it were centralized. But, maybe not, if we're talking about the comparatively small/few rows each of the numerous column-driver chips handles. 

Maybe they finally just tapped-in to the feature already in column-drivers mostly-unused for so long?

(Whoa, and that too could help explain those single-chip VGA-to-LCD doodads for $15 from ebay.. Vertical scaling is a big ask from such a tiny chip from the era those came out; a chip that *also* has 3 100+MS/s ADCs, and presumably a dual-port framebuffer, and has to *change* the input-pixel/line-rates (and even framerate) to work with a different-resolution panel... hmmm... You know what wouldn't be so hard? alternating which row gets the data during each refresh... or telling the column-driver shift-register to hold the data from the previous row and repeat it to the next. And, now that I think of it, I had seen that effect in many panels I experimented with... Definitely not in the panels' datasheet! Maybe the col-drivers', if we could even figure out their partnumbers!)

So, maybe this isn't so much a dig through history as a quest to find data on epoxy-blobs and unmarked silicon... 

The history portion may be more about thinking about how these things are/were used in less-well-known ways. E.G. many later SDRAM manufacturers were probably aiming at the biggest market (PCs), but also didn't want to be left-out in other markets (maybe servers, or Macs, or GPUs? Medical equipment?...).

Maybe those column-drivers in that 64inch gaming LCD with 120Hz refresh are the same ones, or slightly improved, once used in a highly power-conscious PDA...

Maybe these "undocumented" features are actually well-documented (maybe even standardized?) and I'm just looking at the wrong use-case examples... and their considerably higher-level datasheets.

This isn't quite where I expected this dig, nor this writing, to go... Heh!

.....

...

...

Wow. This Datasheet, nay DataBOOK might lead somewhere.... From SupplyFrame, no less. 

https://www.datasheetarchive.com/datasheet/HD66840/Hitachi-Semiconductor?id=dafa000c9282ffe6&term=hd66840

...

Many hours later...

An interesting perusal, but alas, nary a similar controller to be found. Hitachi did, in fact, make column-drivers with internal RAM, but it seems, from that databook, that those were designed with similar mindset as the ubiquitous HD44780 character-displays they're known for. Which... by the time of full-on CRT replacements (and PDAs) was a bit outdated due to computers' having video-controllers, rather than, say, an embedded-system (say a musical keyboard) writing a little data to a screen from time to time.

The Epson chip used in the PDA differs because it's designed for the typical raster-drawing a display-controller provides, and yet, allows for that raster-drawing source to stop rastering, and the display will keep refreshing from the internal framebuffer. So far, it seems a very unique approach. Though who knows what I'd learn looking at similar databooks from other manufacturers (OKI comes to mind).

There were other, differing, unique/dated (forgotten?) approaches in the Hitachi databook, to other matters, such as analog-input for NTSC and even techniques for interlacing... And, frankly, the idea of having a column-driver *as* a CPU-accessible memory/framebuffer (read/write!) with a standard data/address bus like any ol' SRAM was a pretty cool one, but... again... Imagine a panel like that, and its use-cases, Heh! No racing the beam, mind-you. And they even had a workaround for the "snow" problem of accessing the location that's currently being drawn. 

I dig all the crazy things that were thought-of in that era...