I bit off a huge sub-project looking into this cursor-thing...

See, the thing is, "Free-Running" works by pre-loading each page in the SDRAM with instructions to begin reading the next page...

These instructions are near the end of each page (1024 columns of data... bytes, words, etc. depending on the SDRAM's layout).

Starting "free-running" takes quite a few CPU instructions, as it requires sending the "read-burst" command/address on the same pins that the SDRAM will eventually use to send commands to itself.

So, that means starting the read-burst, then changing the directions of a whole bunch of pins, and a few other things before the read-bursted-commands can actually be fed back to the SDRAM's command/address lines.

So, I thought, maybe there was some issue starting the read-burst from an arbitrary location in the page that's too close to the fed-back commands.

E.G.

If the cursors are allowed to be placed *anywhere* on the screen, then it's entirely plausible a "free-running" read-burst (in the sample/repeat mode) would be started from column 1020... and, well, columns 1020-1022 contain commands... and it takes more than a half-dozen cycles for the CPU to switch the port directions etc. So those commands would be lost, and the system would crash.

That was the thought.

It took *days* to rewrite this code to handle that safely. And it didn't solve the underlying problem... WEE!

It *will* be necessary when the SDRAM runs faster than the uC, but we're not there yet.

I'm still avoiding doing read-back/verification of the written-data. I don't know why. It seemed so daunting at first, so much *ancient* code that hasn't been used for *years*. But, the more I think about it, and the more I avoid it with hugely-complicated things like this, the simpler that seems.