Hahaha, found a DIMM which apparently only has *TWO* banks per chip... Most I've worked with have 4... Thus BA0 (Bank Address 0) and BA1.

The chips on this DIMM apparently use A11 for BA. The question, as yet unanswered, is whether the DIMM itself is wired such that BA0 on the DIMM-pinout is wired to A11 on the chips. I'd think it'd have to be.

How'd this discovery come about...?

Been working on a bit of feedback from the Free-Runner to the "Host".

The only locations where the addresses need to be output is alongside a command which will be fed-back to the Free-Runner... There are basically only three commands loaded in each "page" of memory, one to Precharge (close) the previously-used bank, one to Activate (open) a row on the next-to-be-used bank, and finally one to actually perform the "Read-Burst" operation on that recently-opened bank.

It's pretty much a *requirement,* for Free-Running, that there be at least two banks... You can't have one bank open, perform a read-burst on it, and reopen that same bank at another row. You have to open/close *another* bank from within whichever one is currently bursting.

So, another plausible limitation on what DIMMs may be compatible... There may just happen to be 1-bank SDRAM chips... (seems less-likely they'd be used in DIMMs intended for PC's, but what do I know?)

This 2-bank guy... it worked, free-running, but had the oddity that it was detected as 512 columns per page, and yet when Free-Running, it was taking the same amount of time to burst one row-address as the previous DIMM which was only 256 columns per page. If they both had the same number of banks, it should've taken twice as long to burst a row.

Funny this slipped my notice for so long.

And it worked, at all, because...? I'm guessing, here... Whatever it wrote to Bank 0, then 1, was overwritten with whatever was written to the imaginary Bank 2, and 3. Bank3 just happens to be where the Free-Runner stores the "Activate the *next* row in the next bank" command, rather than "Activate the *same* row in the next bank" which is stored in all the other banks.

Oh, right... So what I've done is store the Address-data in *all* memory-locations, regardless of whether there's a corresponding command to actually be executed. (For those that don't have a command, the command stored is INHIBITED-NOP).

With a bit of finnagling, it's possible to use the same address (roughly) for *all* commands.

The commands, again, are:

"Precharge the previously-burst bank"

"Activate the next-to-be-burst bank" (in either the same row, or the next row if we're bursting the last bank in this row)

"Read-burst the next-to-be-burst bank"

......

So, the Precharge command, basically, doesn't care about the address-inputs... (except for A10, which must be low in this case). The Bank-Address bits tells it *which* bank to close.

The Activate command uses the address-bits to determine which *row* to open, in the selected bank

The Read command uses the address-bits to determine which *column* to start the read-burst from, in the selected bank.

The goal was to keep *all* the lower-address-bits (A0-A7) constant throughout an entire read-burst of an entire page. That way, my microcontroller could keep an eye on the Free-Runner, see how fast it's iterating through the rows, (or *whether* it is), etc.

So, yeahp, it can be done... The READ command uses the address-bits to determine which *column* to start the read-burst from. BUT, the read-burst *wraps*. So, shift all your commands by the *row* number, and begin your read-burst at Col = Row, and... now there's no need to change the lower 8 address-bits during each page-burst. Then a *slow* processor can peak at those address-lines whenever it gets a chance and know which row it's Free-Running at.

This, again, was made use of way back in sdramThing1.0, wherein the AVR was responsible for supplying the address, and the Free-Runner had *only* it's *command* signals directly fed-back from SDRAM Data I/Os.

This method's pretty much the same, but the implementation is kinda the reverse of that.

May not be 100% within-specs, as there's some amount of "dead-time" between data-byte outputs... So it's plausible your slow microcontroller might be reading the Data I/Os when, technically, they're transitioning between columns' data (even though, that column-data is the same in all columns)... There might be a brief moment of Hi-Z going on, or maybe even a tiny glitch of data from elsewhere...? I dunno, but it's workin', and been workin' in several forms on several devices, so there yah go.