... it occurs to me there may be *another* way to go about this...

I have *read* working, it seems, with the SDRAM clock at at least 2x the AVR clock...

And, it seems, it's not freaking out about the other commands being received twice sequentially...

(assuming that's the case, what with the one-shots apparently appearing as two-consecutive commands)...

(which was a huge consideration, earlier... as, I'm somewhat certain, Activate, Precharge, or *at least* Load Mode Register, were once not happy being sent back-to-back...)

... what about considering the concept of *intentionally* allowing it to write multiple locations back-to-back with the same data ... ?

*If* it handles other commands being back-to-back... then... I could actually get away with this...

If I understand the issue correctly, we're getting *two consecutive* columns, written with the same data...

And, I can, clearly, choose *any* starting column...

So, if I wrote each "column" (pair) consecutively...

Then I'd only have an invalid column *at the end* of the page...

AND

Currently, it's set up such that each page (of 1024 columns) is only *using* 1022 columns (IIRC: 146 * 7, because each LVDS transaction takes 7 columns/bits to work with the LCD display...)

THEN

It doesn't matter what's in columns 1022 and 1023

BECAUSE
Free-running works *at the SDRAM Clock* and columns 1022 and 1023 will never be accessed.

THUS

I could actually REMOVE the one-shot circuitry, and *still* run the SDRAM at, at least, 2x the AVR clock.

No kidding.

The only potential issues, I can currently predict, are "Activate" and "Load Mode Register"...

IF it's working as I think it is, then BOTH of these ARE occurring back-to-back, despite the (flakey) one-shot-circuitry...

...And... It's running.

IF that's the case, then this is entirely plausible.

PRIOR EXPERIENCE

suggests that some of this is entirely plausible...

READ, for instance, from the same column, in multiple sequential identical commands, results in multiple sequential outputs of the same column's data.

WRITE, works similarly...

This was a key-factor in sdramThing1.0... This concept is what made sdramThing1.0 (and 2.0?) possible...

...Again, the concept that, e.g., the SDRAM's reception of multiple consecutive "Read" commands at the same column results in a steady output of that column's data.

...And a "Write" command, received consecutively, at the same column, results in a *write* only to that column.

Again, if the SDRAM isn't pissed about a back-to-back consecutive Activate commands, and Load Mode Register commands, then, really, there's no need for one-shots, even with 2x SDRAM clock. (Precharge has since been determined, from the SDRAM's truth-table, to result in NOP on a previously-precharged bank/page... so it's no longer a concern, leaving only Activate and Load Mode Register).

Why didn't I try this from the start?