I've often encountered situations where quadrupling the speed allowed reduction in code loops that were 800+ bytes long and straight-lined for performance reasons to less than 40 bytes. You'll help me LOTS more by building a 250 MHz one-clocker than by putting 200 TB (figuratively, not really) of code storage on board if it's slow.

IMHO, you can do WAY more with a small code space and large bandwidth than the other way around. For critically timed code, you also lose functionality, i.e. interrupts have to be disabled, so you can only service one task at a time, you can't maintain precisely timed background tasks, e.g. display muxing or keypad scanning, among others.

If you want a practical use for more FLASH, you might consider making lots of redundant copies of the FLASH, then, on reset, and before the MCU releases reset, verify that all 17 copies (original + 16 copies) of the FLASH are exactly the same, and fix any that aren't. It's also vital that the FLASH be in-application programmable, of course, since one might want calibration parameters stored there.

Tops on my own wish-list would be a full complement of XRAM, i.e. a 64KB on-chip full-speed RAM, to go with the ultra-fast MCU I want. This should be managed through an SFR-accessible page table that contains two bits for each 256-byte page of code and data space, so that the page can be mapped into either code or data space, or both.

If you're tweaking the MCU core, then the bit-accessible memory space could be mapped as well, so that more of SFR-space (essentially I/O space) is bit-addressable.

Another thing on my wish-list is fixing the serial port(s). First of all, I find it terribly annoying that one has to clear those flags rather than having it happen automatically. Motorola figured that out in the '70's. I don't know why Intel built the serial channel the way they did, as it always wastes time that could be used for useful processing. This "fix" would have to be selectable in order to maintain compatibility with prexisting code.

The way in which Dallas approached the multiple data-pointer situation was pretty helpful. It's important to note that they have programmable auto-increment/decrement functions and it's important that those apply, selectively to each DPTR separately so that you increment the pointer to/from a memory buffer while addressing a fixed external I/O device.

If you really want to improve the 805x-series, there are lots of things that would help the MCU core itself. Many of the instructions that presently take multiple cycles could be executed in a single cycle, and some could be executed concurrently.

One thing that's likely to open doors in the communication arena is a PLL. Now, I'm not referring to one of those devices that multplies up an external clock in a few milliseconds and uses the result as a system clock, but, rather, I mean the "REAL" PLL type that acquires and tracks an external signal, producing a precisely synchronized output. That would be useful for multi-channel communication in synchronous mode, where modulation/demodulation might need to be performed in firmware. It needs to acquire and track, as well as tolerating the switching transient when signal sources are muxed. A digital loop might be desirable, but there's question as to whether the technology would support the associated counter speed requirement.

For me, making the FLASH survive the power-up/power-down cycle (the ever-present RESET issue) is high on the list. Increasing the on-board XRAM is high on the list. Fixing that stupid serial port structure is on the list. Adding an external clock input, and possibly a PLL that could serve to provide a system clock and/or a serial channel clock would be on the list. Just increasing the code space wouldn't make it to the top 10 for what I do.

RE