Foremost, there are direct continuations, CPU'S able to execute 8080 code and (basically) hardware compatible, like the 8085, Intel's answer to the Z80, as it's mostly software and hardware compatible.
Beside Intel's direct extension, there is of course the series of enhancements of Z80 design, from Z800/Z280 all the way to the eZ80, which in some way can be ...
There were of course clones produced in the COMECON countries. Being clones, they would probably not be a good answer, with the exception of:
КР580ВМ80А was a Soviet clone that has been developed further into:
КР580ВМ1 with a frequency 5MHz needed just 5V and added some new commands, had support for bank switching and multiprocessor systems
Obviously what's compatible (or an advancement) to the Z80 also has to be compatible to the 8080.
That includes the Hitachi HD64180, the Zilog Z180 (which is essentially the same thing), the Toshiba 84013 and 015, and to a limited degree, the Toshiba TMP90 (which is only source-code-compatible to the Z80 but uses different opcodes). Rabbit Semiconductor is ...
[Since not closed by now, I'll try to give it a historic spin]
Hold Your Horses
In some way this is a case of second step before the first, or at least it seems like.
Thinking about how to swap segments, do caching or whatsoever is about implementation. There are many ways to do so, not at least shown by various home computers. But I belive this would fall ...
If Intel 8008 qualifies as answer one can add the Texas Instrument TMS-1795 which was TI's take at the Datapoint 2200 microprocessor. It even came out before Intel's 8008 as explained by Ken Shirriff .
Going backwards, the 8080 is "mostly compatible" with the Intel 8008. They share most of the same registers, and most instructions map between the two. With some changes (or using a cross-assembler), you can assemble the source code of most 8080 programs for an 8008.
There certainly are differences between the two processors. The 8008 had an ...
The assumption in the question is incorrect. The common wisdom about C being a bad choice for the 6502, is wrong.
The choice of source language, does not gate the quality of generated code for the 6502.
In fact, code quality on the 6502 (or any other platform for that matter) is gated by the quality of lowering intermediate-representation code to MOS ...