Update: WE HAVE FREE-RUNNING. Really, this time. (more at the bottom)

We have free-running!

Sorta.

OK, I can FINALLY free-run 1022 rows of data... but 1023 fails. That's of allegedly 4096.

Must just be a bad connection or something on an address-line, right...? But why 1022, but not 1023? Huh.

TBD.

Next test, maybe, to make the R/W-verification software a bit more sophisticated... As it is, it just writes a page then reads it back, making sure my clocking/latching scheme does what it's supposed to. Maybe this DIMM's got some bad memory-cells somewhere (handy I used a slot, this time!), or maybe my upper-address bits aren't wired right.

Also, *right at* the limit of my ATMega8515's program-space... so maybe it's time to start experimenting with that asynchronous-bus latching-system (as opposed to the asynchronous *control*-latching that's accomplished by the one-shots) and move over to another processor altogether.

This whole endeavor's a bit funny, as it's kinda going through a very similar development-process as sdramThing1.0 - #sdramThing4.5 "Logic Analyzer"... Not quite identical, but *very* close. The biggest difference being that 3.5's one-shots are being implemented so early-on... But, e.g. Free-Running was one of the first things accomplished in sdramThing2.0... so it's kinda like stepping back in time.

And, equally oddly, is the fact that the development-process is causing me to basically rewrite all the code I wrote before. Not because it's not reusable, but because I need to build my way up from various levels of functionality/circuitry, testing pieces of these new hardware implementations along the way... and that procedure seems to be lending itself down the path...

Turns out, there's a *lot* of code... Weee!

AND NOW!!!! WE HAVE FREE-RUNNING! All Rows. On Three of my Six DIMMs

(Sizes-detected: 32MB, 32MB, and 128MB. The last two are two-sided, so may be 64MB and 256MB, respectively. Chips from Mtec, Hyundai, and VIS(?) (Kingston DIMM)).

Changes Made:

1. I use a resistor for the feed-back path on /CS... Originally used 1k
   1. Dropped it down to 390ohms.
2. I use a one-shot circuit on /CS which introduces some gate-delays
   1. Added a D-latch *after* the gates, so the output-transitions will occur *at* the clock-edge

The last one requires a bit of thinking... E.G.

Normally, the very last column in a page would be filled with a "read" command to start a new read-burst at the first column in the next page. (Actually, that's a bit simplified, since there's CAS-Latency, so technically it's the second-to-last column).

But, now the /CS from that read-command is delayed by one clock-cycle... So, technically, the address/command need to be stored there, but the /CS needs to be stored one column prior.

I opted to store the address/command at both locations, that way I could swap between using the D-latch or direct output from the gate. Though, doing-so could also be resulting in more "charge-time" if, e.g., the input-capacitance from the address/command inputs (on all 16 chips!) takes some time to overcome due to the drive-strength of a single DQ output... So, realistically, I don't know whether the edge-switching is the reason, or the capacitance-compensation, or maybe many other factors I haven't thought of. And, some of those cases/characteristics may very well be DIMM-specific... Wee!

But, three outta six ain't bad.

OH... And... Somewhere within these changes, we've gained read/write functionality from another DIMM, which wasn't being detected at all, previously. So, six out of six DIMMs are detected and show no errors in read/write tests, but so far only three are free-running.