So... one of the ongoing issues with sdramThingZero (turning sdramThing into a peripheral rather'n an entire system) is the number of GPIOs necessary... I haven't done a *total* count, but roughly:

Address and Command pins (also tied to the Free-running Feedback DQs) take something like 17 pins

There's also the DQMs

There's also the intent to *read back* the data sampled into the "Side-Kick" memory-bank (which stores the logic-analyzer's sampled data), which is 32 bits (or could be more with an additional DIMM). (These, in this new system, could *also* be used for *outputting* data, if that's somehow useful... but would require additional buffers...(?)).

So, in all, we're talking easily 8 buffer/latch-systems necessary to whittle it down to 8 bits to interface to whatever system it'll be connected to, like an RPi, or plausibly even a PC's parallel-port.

These buffer-latch systems aren't exactly simple... Well, conceptually they're not that bad, but implementing them with 7400-series chips is something like 3 chips per 8-bits.

So the basic idea is that each of these 8-bit "ports" would be essentially no different than, say, a port in an AVR (or most uCs), with the ability to latch data in one direction and sample data in another direction (and Hi-Z when necessary).

The thought occurred to me... there must be some sort of device capable of doing this. Low-and-behold, the good-ol' 8255 used in the early early x86 (8086?) motherboards is pretty much exactly what I need. Unfortunately, as far as I can tell, these guys are *really slow* compared to this era, even with the newer versions which are still stocked at places like Digikey. Implementing it in the high-speed 74xx's of this era would be much faster. But, again, we're talking something like 8*3=24 chips doing nothing more than directing data-flow.

So then, the thought occurs, of course, of CPLDs/FPGAs, but I have yet to be convinced these are particularly "hacker"/"maker"-friendly. Further, if using an FPGA, then the basic concept of sdramThing's free-running system is basically nullified... an FPGA can do pretty much all of it (and, probably, better. And even with DDR, etc...).

So then, the thought... what about just using a high-pin-count AVR (like the mega128?) for little more than its number of bidirectional ports... It *could* be used, quite literally, as little more than a data-flow-director. One port would interface to the "bus" connecting to whatever (embedded) system it's to be run off of, the remaining ports would be connected to the SDRAM's pins.

Again, we have the issue of... at that point *much* of the low-level interfacing *could* be implemented in the AVR, and then we're basically back at the original sdramThing, just with a higher-pin-count AVR as the controller. That's not *so* bad, but kinda defeats *a* purpose of showing just how much can be accomplished with SDRAM and a few (a lot, really) regular ol' logic gates/chips.

So... I don't know.

There's also: A *lot* of this can be handled by resistors... Why? I don't know.

A quick calculation suggested that if the input-capacitance is something around 10pF, then a 1K resistor would allow for up to 100MHz.

Here's a basic idea, this concept originally from sdramThing1.0. (The newer versions of sdramThing take advantage of the fact that the DQ's and Command pins can be read/written at *different* times by making use of the DQMs, but the *concept*, shown here, is relevant for other pin-multiplexing, as well, which is in *high-demand* in sdramThingZero):

Data/Command Feedback wiring example:
    _________/\/\/\________
   |     _____________     |
   |    |   SDRAM     |    |
   +--->| /RAS    DQ5 |><--+
   |    |             |    |
   |                       |
   |     _____________     |
   |    |    uC       |    |
   \---<| CMD    Data |>---/
        | out    out  |
When the SDRAM is free-running, the uC is out of the picture (Hi-Z)
  DQ5 is essentially wired directly to /RAS
When writing Data/Commands from the uC to the SDRAM
  Both uC pins are outputs
  The resistor looks, essentially, like an open circuit.

The idea being that, basically, a simple resistor could be used to replace a (bidirectional!) buffer (with output-enables) in cases where data might be driven to both sides simultaneously. Doing the same with buffers would look more like:

Data/Command Feedback wiring example:
    __________|\___________
   |          |/o----------|-----<
   |                       |
   |___________/|__________|
>--|----------o\|          |
   |     _____________     |
   |    |   SDRAM     |    |
   +--->| /RAS    DQ5 |><--+
   |    |             |    |
   |                       |
   |     _____________     |
   |    |    uC       |    |
   \---<| CMD    Data |>---/
        | out    out  |

So, now, we need another couple pins to determine the direction... but can't use a single direction pin, because there's a case where the uC will write to DQ5 and /RAS simultaneously, wherein BOTH buffers need to have their outputs disabled. So, using the resistor, instead, removes the necessity for *both* output-enable pins.

Then it gets a little more complicated when latches are involved, which are necessary when interfacing the SDRAM to e.g. an 8-bit bus, since the Address/Command pins must all be set-up simultaneously. So, now, we'd need a latch with an output-enable, and a "return" buffer, and both output-enables need to be separately-controlled. So, then, the "return buffer" could be replaced by a resistor, but we still need the latch... it's still a bit of work, and resistors will slow things down.

Doable, absolutely. DoIWantTo...? Hmm...

So, say we use an AVR with a lot of GPIOs to replace all these buffers and latches...? Again, the AVR, then, is more than capable of actually running the low-level sdramThing/free-running system on its own. And, now, we're basically back at the old sdramThing4.6.

With discrete latches/buffers the I/O speed could be as fast as the system connected to it... divided by the number of latches to be set-up and buffers to be read... RPi's GPIOs have been shown to be limited somewhere around 50MHz. A 20MHz AVR directly-connected with *all* its ports, mightn't really slow things down, much, especially since the actual Read/Write code could be on-chip rather'n buffered from the RPi.

So... I dunno. Doable, absolutely.