I do not claim to know everything about these processors, or Assembly (in fact, I only have a very rudimentary knowledge of assembly on the z80). I did a little bit of research, and one person said that the ez80 and z80 were identical in all but speed. If this is true, could a person, in theory, replace the z80 processor on a +cse with an ez80?

I can't be for certain, but in theory YES. Yes you can, but you won't see anything on the screen.

I remember looking a few years ago at the differences between the z80 and ez80. The ez80 was able to do something like 4x the instructions per second because of a different bus design, but recently I have been informed that there are some mathematical things that a z80 does much better (easier) than an ez80.

Also, the ce has dedicated screen ram, meaning you can push hex code to certain parts in that ram and it will immediately show up on the screen (look at the Ti 84+ CE project).

The z80 calculators don't do this. I don't pretend to understand it all, but I do know that there's a separate buffer for the LCD in the system ram (Note the 48k vs the 24k you can use).

TI does say the ez80 is instruction (sort of) compatible with the z80, but there are enough small differences in addresses and instructions that you'd have to make your own OS to use it.

The eZ80 can be used as a drop-in replacement for the Z80, meaning that no significant changes to neither hardware nor software are required to switch a design from using the Z80 to the eZ80---aside, of course, from changing the CPU. However, TI calculators do not have a discrete CPU chip. Instead, the CPU is integrated into a System-On-a-Chip (SoC) that contains the CPU, RAM, internal bus, and configuration logic, as well as logic for interfacing with an external mass storage bus and LCD bus. (Most other forum users have called this chip the ASIC, which isn't wrong, but I think SoC is more appropriate.) Due to the way integrated circuit chips (ICs) are manufactured, an end user simply cannot make any changes to the chip; you can't just use a tiny saw to cut out the CPU part of the chip and replace it.

However, had TI simply replaced the Z80 in the TI-84+CSE with an eZ80, the resulting calculator would have likely given much better performance than the TI-84+CE, even if you kept the awkward and slow paging system for memory access.

The eZ80 boots into a Z80 compatibility mode. If you did engineer a new SoC using the eZ80 as a drop-in for a Z80, you wouldn't need to patch the OS at all (or any changes would be minor).

It's called a pipeline. Simple Z80 instructions require at least four phases, and the original Z80 does each phase sequentially for each instruction. On the eZ80, when phase 1 of an instruction is done, the eZ80 starts processing phase 1 of the next instruction while it also processes phase 2 of the first instruction.

However, the bus in the TI-84+CE is completely redesigned compared to the bus in the TI-84+CSE. For some reason---most likely utter laziness and a management with complete apathy for performance considerations (the alternative is total incompetence, and TI isn't incompetent)---, the internal bus in the TI-84+CE is the wrong type. The eZ80 was designed, like the Z80, for use with a low-bandwidth, low-latency bus, which is simple and works well for a CPU that only runs at a few tens of megahertz. The bus actually used in the TI-84+CE is high-bandwidth, and high-latency. The ARM CPUs the bus was intended to be used with have a cache that lets the CPU take advantage of the performance benefit of a high-bandwidth bus, while mitigating the performance hit of a high-latency bus. The eZ80, lacking a cache, gets no benefit and a serious handicap.

The memory-mapped VRAM is a bit of a wash. For text and sprite-based games, the TI-84+CSE's driver can actually be better, because it has a windowing function. Basically, you set the window bounds, and then just dump a bunch bytes into the drive, and it automatically handles mapping the pixel data to the rectangular area you want. Additionally, it's much easier to handle rotated and flipped sprites. With the memory-mapped VRAM, you have to transform the coordinates you want to display to into a memory address, and do that for each line of the sprite. The memory-mapped VRAM does, however, have the advantage of not being limited to exactly 16 bits-per-pixel, and it is very useful for games to use only 8 or 4 bits-per-pixel, because that reduces the total number of bytes that need to be written.

On both the Z80 and eZ80 models, the LCD module itself has a little silicon IC integrated. This IC generates the analog signals needed to drive the pixels. On the Z80 models, the IC itself also contains RAM for storing the LCD picture. To change the image, the CPU would send commands to the LCD, instructing it to update specific locations. Part of the reason that the TI-84+CSE was so slow is that the Z80's OUT instruction, which is used to send that data, is terribly slow. (However, the OUT instruction on the eZ80 is actually acceptably fast.)

Conversely, on the TI-84+CE, the LCD driver circuit does not contain any internal RAM. Instead, there's a logic block on the SoC that continuously sends 32-bit blocks of RAM to the LCD driver. The upshot is that, on the TI-84+CE, changing VRAM is no slower than writing to any other part of RAM. However, that streaming does further reduce the bus bandwidth available to the CPU by about 8 %, which is only a minor performance hit compared to the bus type mismatch. (The bus type mismatch hampers performance by at least a factor of 3.)

Given the aforementioned facts, the real the TI-84+CE is faster is that it doesn't use the Z80's slow OUT instruction for sending data to screen. This results in the stuff being displayed on the screen faster, which makes the calculator feel faster. However, if you actually ask the TI-84+CE do a purely mathematical task such as multiply two large matrices, you'll find the TI-84+CE isn't much faster than the TI-84+CSE.

So, the TI-84+CE is not slower than the TI-84+CSE at doing mathematical tasks. It's merely not significantly faster.

Actually, the reason you can only access 24 K of RAM on the TI-84+/SE is that the OS reserves about 8 K of main RAM for itself. The 2.55 OS also reserves a large part of the other 16 K, and the reason you can't access the rest for program and other data storage is simply that TI never felt like programming the OS to be able to handle storing user data on that extra 16 K page. It would have made things a bit slower, anyway.

Not at all true. The only incompatibilities the eZ80 has with the Z80 instruction set is a few seldom-used undocumented instructions that really just took advantage of quirks in the instruction decoding logic. TI never used those instructions, so the OS wouldn't need any changes. Few programmers ever did use those instructions. And for the most part, those instructions weren't very useful anyway. The eZ80 does add a few new instructions that are quite useful, but new instructions don't cause incompatibilities.

TI's decision to redesign the TI-84+CE SoC from scratch was likely motivated in part by a desire to modernize the engineering and documentation and make it all ISO-9000 complaint and whatever other newfangled best-practices-of-the-week management wanted. And I'm sure it's all very shiny now. The fact remains, however, that the management-approved wonderfully-cromulent design gives a mere fraction of the performance an eZ80 ought to be able to give running on external XIP flash.

Maybe they also thought the new design would improve security. However, the old design had no hardware security bugs; all the security flaws were in the software alone. The new design, unfortunately, has at least two hardware-related security bugs. That's what happens when you try to roll your own MMU.

But this post is getting much too long. People have written many books on the merits of modern protected-mode operating systems. (If you're reading this, TI, I suggest the MINIX kernel. Linux is overkill (I like how Linux has nearly identical system calls named dup(), dup2(), and dup3()) and those VxWorks guys would probably overcharge you.) People have also written books on why you shouldn't try to roll your own security. You can major in computer science if you want to read them.