For this project:

100MHz crystal oscillator (Yep, looks like I'll be trying this one-shot thing after-all)

74AC574 (D-Latches for one-shot circuits)

74AHC125 (TSSOP, blech... $0.29 YAY!) 5V-tolerant buffers for my inputs...

Mighta forgot a few things, I'll need a divider from 100MHz to something the AVR can handle... Also, forgot to look for 3.3V glue-logic (inverters+ANDs) needed for the one-shot... hopefully my vast assortment of 70's-80's TTLs can help out. (I'm currently using an S-series 74S51, and LS series (two) 74LS86's each rated for 4.5-5.5V at 3.6V, so we'll see!

Also, was up most of the night trying to figure out the one-shot circuitry... That part's easy. The hard part is how to interface it with the CS + CS_Enable arrangement I've got now.

This is an old design... Unfortunately, it means I need yet another pin, and I'm already pretty much maxed-out. (Glad I looked, though... the repeatedAccess pin is something I'd forgotten in my attempts last night... that may help).

//nCS_RepeatedAccess >------------------------------
//                                                  |  ____
//                                            ___    -|    \       
//                           -----------------\   \   | AND |->SDRAM_nCS
//                  _____   |    _____        | OR >--|____/       
//nCS_OneShot >----|D   Q|--+---|D   Q|--|>o--/___/                   
//                 |     |      |     |
//               --|>____|     -|>____|
//              |             |
//SDRAM_CLK >---+-------------

So, e.g. when the nCS_OneShot output goes active (low) for 10 SDRAM clock cycles (one AVR cycle), the output of the OR gate shows it active for only *one* SDRAM clock-cycle. Good...

But, again, in this design, with the funky burst-writing-timing-scheme, this means I can't use nCS_OneShot to drive the associated DQ line to actually write the *data* on the nCS_OneShot pin.

It's hokey to describe, there are actual commands being actually fed, in real-time, from the AVR to the SDRAM. Then there are commands being written into the SDRAM's *memory*; these commands aren't *executed* they're just *stored*, and later they will execute on their own because of the fed-back DQ->Command/Address pins.

So, I guess, a "Write Command" sent to the SDRAM is different than a "command written" into the SDRAM.

...and I need a one-shot circuit for the various chip-select lines *as well as* the DQM lines. The CS lines *also* need to have *non* one-shot access, as described. Likewise, the DQM lines need non-one-shot access to allow the "Free-Runner" to output its data. So, if I use the "nCS_RepeatedAccess" method, as shown above, then that means I need an additional.. 5? pins?! I have *one*. And that'd be disabling the UART.

Further, it just occurred to me, in sdramThing3.0 (the functional version, now, before the one-shot gets added), the CS pins must also *switch direction*. Yeah, this one-shot won't do that. So, of course, I could add another buffer with an output-enable... but then we need *6* pins (possibly 8?)!

I think I can multi-purpose some pins, maybe reduce some logic, It's plausible... Maybe, even, without needing to use a demultiplexer.