Many logs back I had the idea that a latch, or a couple, could be removed from this system, when attached to an 8-bit bus...

As it stands, *all* the address/command pins require their own dedicated GPIO, that's 19 signals, right there. And, some signals actually require two.

So, to attach those 19 signals to an 8-bit bus would require three 8-bit latch chips...

I'm partial to trying to figure out ways to use the SDRAM's inherent circuitry wherever possible, so I came up with a way that would allow for removing some of those latches...

Those logs start 'round this one: https://hackaday.io/project/10119-sdramthingzero-133mss-32-bit-logic-analyzer/log/44789-bus-latch-contemplations-addrlh-via-feed-back

The basic idea is to use a "default address"--which needn't be latched--as a jump-off point to wherever you actually want to read/write.

(TODO: Brain's not functioning in that realm right now... Did I figure out how to use this for *both* activating a row-address *and* reading/writing a column-address?)

-------

The biggest problem was that I couldn't figure out how to *set* that "default" address.

It couldn't be at address-zero, because the SDRAM itself has a very specific initialization-procedure *before* data can be read/written (including, then, my jump-address). So, that default-address would've had to correspond with data required on the address-bus by those initialization-instructions (specifically the Load Mode Register instruction).

I was planning to use pull-up/down resistors, but they interfered with others, and that caused voltage-dividers which *couldn't* work in all the data-directions/data-values necessary.

BUT TODAY: I think I figured it out!

The thing is... They don't *have* to be controlled by pull-resistors, at all! And, further, there's no reason I couldn't mix-up the command/address signals on different 8-bit latches.

So, wait... what'm I saying? I'm saying: The Load-Mode-Register *command* could be ON the bus at the time when it's strobed, right? AND since we're using *resistors* to connect multiple bytes to that bus simultaneously, the bits within those bytes could be reordered such that the *command* and *address* bits have the same values.

WHEW I can barely wrap my head around this, right now...

I THINK what I've accomplished is reducing those *three* 8-bit latches down to *one*.

--------

The Load-Mode-Register command requires only 5 bits to be high, the rest low. That's including all the command and address bits (19). So, simple-case: load the 1's into the latch, and the remaining bits will be driven 0 by the 8-bit bus (through resistors). Alternatively: some of those 1's could be "shared" on the bus... hmmm...

The other important factor is the use of separate DQM inputs for each byte in the SDRAM when writing the free-runner instructions *into* the memory-locations. But, those DQMs were planned to be used, already, for reading.

--------

The biggest problem with this is that it easily doubles, (or more!) the number of instructions necessary to begin a read/write [burst]... because you have to first write your desired-address to the "default" address, and *then* begin the actual read from the selected-address. And, we're already at *quite a few* instructions to perform a read/write because of the directly-wired-back command/address signals.

So, doing this, this way, would make many operations *significantly* slower.

OTOH, the smallest SDRAM devices I've seen have 256 columns of data in each page (largest: 1024), and there might be a trick I could throw in there to reuse that same desired-address setup routine for all banks, which would reduce the number of "jump-point-writes" by 2, or 4... so, worst-case, maybe, would be necessitating this long jump-process once for every 512 data-locations. (assuming everything's written/read sequentially)

That's not *so* bad...

Oh, and... it's plausible whatever system this is connected to might not be able to drive the bus... it might draw some current when e.g. the jump-to address is being output from the DQs to the address-inputs (via direct-wiring), those values would be, essentially, "pull-resistors" attached to the bus, and plausibly two at a time...

So it might be worthwhile to insert a 74x245 in the mix, with high output-strength.

Again, not *so* bad... 2-for-1. And, realistically, the '245 might've been a wise idea even before this.

--------

And... None Of This should interfere with the sample-rate :)

I dig it because... I guess... It reduces the number of support-components... by making use of the SDRAM's inherent functionality in weird ways like this, those parts are redundant. I dunno why that's important enough to me as to justify slowing the system down, nevermind development of the system, but it is.

Now what was I *planning* to work on before this realization?