As an aside... I've been pondering the possibility of ways to do further deprocessorization

E.G. windowed-repeat could occur sans-processor with the addition of one more multiplexer... Plausibly another chip-select one-shot circuit. (Or, possibly, just a rewiring of the other half of the 7451 multiplexer already in-use on the Free-Runner's chip-select? Or, possibly2.0: There's still *some* unused memory... maybe after the free-runner's LCD-update, the windowed-repeat commands could be stored... no multiplexer necessary? no change in circuitry at all?)

I have no idea *why* exactly... I guess it's the sort of mental-challenge my mind is suited-for at the moment.

Well: "possibly2.0" lends itself toward a feature I'd otherwise not found a particular use for...

Free-Running, as it stands, basically only goes through every page *sequentially*. The only place where it *doesn't* is at the very end of the LCD refresh, where it jumps back to the beginning. It doesn't exactly *wrap* to the beginning, as there is, technically, unused memory. But, otherwise, it's basically just outputting the memory sequentially.

There's no *need* for it to free-run sequentially. And, in fact, there's no *need* for the "Free-Runner" and "Side-Kick" to even free-run in the same addresses (right?).

As I said, I just haven't yet come up with a particular use for another, more complex, jumping-scheme.

So, since I'm on this thought-path (all of which is new, as of this writing, except for the first two sentences of the "E.G." paragraph)... why not some hypothesizing...

...

Rough-calculations and sketches suggest "possibly2.0" is only possible with quite a bit more memory. Disregarding horizontal and vertical blanking-times on the LCD... 1024x768*7(bits per LVDS transaction) is nearly 55Mb, and my chips are 64Mb (right?)... or 128? Maybe, then...

... Well, I might need to do some more thinking along these lines. I dig the idea it might be possible with Zero hardware-modification. Though, too, v3.0+ has shown that I'm somewhat intrigued by just how much can be accomplished by simple logic, sans processor. OTOH, at what point does it become less about pushing the memory's capabilities to the limit and more about something like making a custom processor out of (mostly) logic gates...?

We'll see where this goes.

------

OTOH, now that I think about it, the non-sequential jump-scheme is something I'd been contemplating *for the side-kick*

As it stands: The LCD and Sample/Repeat-scheme are handled in the same fashion, sequentially, as described earlier. That means, some of the samples are actually stored during the LCD's H/V-blanking-periods and therefore aren't seen on the LCD. (Though, they would be seen on the 'scope). In one of my recent photographs three serial-transactions are visible near the edge of the screen, selected by the cursors. In fact, there were five serial-transactions between the cursors (as seen by the 'scope), two of which must've been during the horizontal-blanking period.

...The reason: The "Free-Runner" and the "Side-Kick" use the same addresses in their two separate groups of memory.

Again, this needn't be the case... Though the math gets quite ugly.

There would have to be two separate sets of commands for the Side-Kick... Currently the *addressing* is shared by both the free-runner and the side-kick, and the latter in *both* sample and repeat modes.

The side-kick would need two separate addressing schemes based on whether it's in sample/windowed-repeat mode or LCD-Refresh-mode. ...another multiplexer.?

... Plausibly I could use that otherwise-unused-multiplexer on the Free-Runner, instead... Plausibly keep the Free-Runner's and Side-Kick's addressing-schemes the same, but include two different addressing-schemes *for both*...? But, still... more circuitry.

...

And then, in the realm of ugly-math...

The actual commands would have to be offset. E.G. currently the "read-next-page" command occurs near the last-used column in the page (a couple short of the last column, due to the CAS Latency).

But if we had two separate sets of commands for sample-stuff vs LCD-stuff, then the ... but wait!

The "read-next-page" command isn't actually "read next page" it's merely "read the selected page" and page-selection is another command entirely, which needn't be aligned anywhere in particular... so then the "read selected page" command could be used for *both* sets of commands, and the *selection* of the "next" page could be separate commands placed somewhat arbitrarily in each column. Woot!

... still, more circuitry.

unless, maybe, I merge the earlier idea with this one...?

What if I had two separate groups of commands in two separate locations in the Free-Runner's memory... (no multiplexer necessary!)

The first location is for the LCD refresh, identical to how it is now...

The second location is for sampling/repeat... It would be laid out basically identically to the LCD-Refresh location, but skipping over the Horizontal/Vertical blanking-periods used only by the LCD.

The actual windowed-repeat wouldn't be possible without a processor... (as thought-attempted, earlier)... but the concept of separate command-spaces... hmm...

..................

There is one *minor* flaw with this technique, that has been gnawing at me for a while... It's mostly an OCD-factor, and really doesn't matter...

Currently, when sampling occurs, the process is seen *in real-time* on the LCD. Again, the LCD-Refresh commands are tied-directly to the sample/repeat commands.

With the original sampling-to-visible-pixels-only idea, it would've shown the sampling in real-time, but would've shown the samples somewhat skewed (by the H/V-blanks). The next LCD-Refresh, and those thereafter, would show them properly-aligned with the pixels. That would've been an only-minor annoyance.

With this "new" technique (separate command-spaces in the Free-Runner for LCD-Refresh vs Sample/Repeat), it's *quite likely* *nothing* or even *complete garbage* would appear on the LCD during sampling. Another minor-annoyance... slightly less-minor than the other, but really only a visual-factor...

(A similar minor visual annoyance is the long-standing fact that when a large repeat-window is selected, the LCD sometimes displays the repeat-window repeatedly... wiping out the normal display during repeating. Again, just a factor of trying to make the circuitry as simple as possible... generally doesn't affect the functionality *much* but could stand to be slightly improved. Also, generally, if a large repeat-window is selected, then there's no reason to repeat it so-often, as the 'scope would have to have slower sweeps to show the entire window, anyhow, and thus they'd be brighter...)

......

And then, there's the issue of... if only sampling what can be stored in *visible* pixels, then the actual number of samples taken is reduced...

wherein I begin to contemplate the difficulty of having a sliding sample-window *on the display*... and now I won't be able to think about anything else for the next 20 minutes. Time to shower.

....

And, if you're wondering... The video could certainly stand to be improved. Apparently video isn't my canvas. I've plenty of ideas for improvement, but it's such a friggin' drag. And drop. And clip. And slide. And take after take... And watch after watch... I don't want to watch myself *that much* sheesh!

... sliding window on the display... something about having some Adder logic between the Address Data-Pins and the Address Inputs... oy.