... is that you can disable the autoincrement on one or the other DPTR, as when it points to a specific memory-mapped peripheral.

In order to move a 256-word block of data, I'm presently reading/writing using the data pointer and ignoring the data. It enables data in response to an interrupt signal and generates the write strobe to memory, despite the fact the data path is 16 bits wide, and because the code is simply a block of 256

MOVX A,@dptr
MOVX @dptr,A

instruction pairs, the whole thing takes 60 ns per byte (120ns /word) at 33 MHz. Moreover, if I clock an external counter with the falling edge of A15, I get another 4 bits of address, which, like the DPTR can be programmed, so the MCU functions as a DMAC. The cool thing is that it only has to have the data path steered once per block of data, and enabled only on nRD or on nWR. This can be done in half the time, of course, with a little trickery associated with the high address nybbles (3 of 'em, up to A19) but that's not quite happening yet. I'm aware that there's that @R1 approach. That may work very well, too, since there are only 256 words to move. Access time limitations prevent me from doing that right now.

BTW I've put one of those SiLabs F120-DK boards on a prototype card in my little development system, in order to compare the overall performance with the Maxim/Dallas MCU. I'm really curious how that will compare.

I'm even more curious how long it will take me to learn how to set the MCU up for all the things I want ... and don't want
... <sigh> ...

RE