Been hacking at this thing for seems like ages...

I've revised nearly all the code, just to try to get it working in a way it *should've* worked from the start...

Seriously, logic-wise, the only change that should've been necessary to the code would've been to set one pin low. Then it should've worked *exactly* the same as before.

I realize I'm pushing certain limits with the use of 5V TTL chips at 3.6V and a few other things, but this is getting ridiculous. The 'scope traces look good. The only piece of circuitry that's causing problems is an AND gate (or daisy-chained NANDs).

One signal in that AND is driven by a steady-state High. The other signal toggles, but does-so *around* another signal that actually handles the timing. So, basically, this AND gate's output acts as an output-enable for another bit of circuitry which already works.

Looking into the code, quite a bit, it seems the only places it's used is *far before* the signal which is being enabled, so even if the AND gate introduced a *huge* delay, it shouldn't matter. Further, I've added delays to account for it and still am not getting a functional system.

Then, to take it a step further, I've 'scoped the actual signal that's being output-enabled, both its input and its output... and it's functioning well within expectations. So, it's not like the AND gate is outputting too low of a voltage to trigger the output-enable.

So, it seems to me, there must be some tiny piece of code somewhere that I just manage to keep overlooking. This bit of code must have the output-enable and the actual signal right near each other... e.g. "enable output-enable; strobe-output; disable output-enable" back-to-back.

But, I've looked over the code extensively and just don't see it.

On the plus side, as usual, doing this has refamiliarized me with the code, which *will* have to be changed to make use of the one-shots. It's also given me the opportunity to revise it quite a bit, which will also lend itself well to conversion to one-shots.

E.G. Previously, each command sent to the SDRAM (Read, Write, Precharge, Activate...) had a function with its own setup-instructions. (I.E. turn the Command Port into outputs, Drive the Chip-Select Enable, Strobe the chip-select) that might as well be the same for *every* command.

(Originally, I tried to minimize the number of CPU cycles on each command, based on assumptions about the previous state, knowing that certain functions are only called immediately after others, etc. I did this because load-times were nearly 5minutes. But, doing it this way means that changing over to One-Shots would mean revising code for *every* function.)

Instead, I've combined all that into a single "set-up for command" function, that *should* work no matter the previous state, but is also quite a few more instructions than necessary in most cases.

And, again, doing-so was beneficial, because it made me look into every function, which is good for refamiliarizing myself with how it worked, and led to quite a bit of cleanup of code and notes that still existed all the way back to the completely incompatible sdramThing1.0 days.

Still... Surprised it doesn't work.