With FamiCalc and TI-Boy being so successful using JIT, I figured it would be interesting to see more Z80 computers being emulated on the CE.

I've always had an interest in the Sinclair ZX Spectrum, so I've thought a bit about how it would be done:

1. The 48k version of the speccy is the most popular, and all 48k will fit in the CE's BSS with room to spare.
   
2. The 256x192 memory-mapped bitmap area of the speccy will fit nicely in the middle of the 320x240 screen, with room for the colored/striped border. Theres only a simple memory re-formatting needed to make the display, as there are no hardware sprites or different video modes to implement.
   
3. Tapes/programs for the ZX rarely exceeded 48k [citation needed] (since they needed to be loaded into RAM to run), so a "tape" or even an entire memory snapshot can be saved in an AppVar. Loading memory snapshots would be much simpler to emulate than having to deal with reading (and writing!) to AppVars as if they were a tape.
   
4. Controls for most games are the Joystick (up/down/left/right/button1/button2/trigger). These, and the rest of the keyboard, are memory-mapped inputs. This should make writing a keyboard+joystick driver pretty simple.

So, from a technical perspective, this should be possible.

Name-wise, here are some options:

1. SpecCE
   
2. TInclair
   
3. SPECcalc
   
4. ZX-48 CE
   
5. SpecTIca
   
6. ZXtium
   
7. ZedEksCE or ZedEks48

(Personally, I favor number 7 and number 1)

I'm fond of either SnClair or TInclair: I like the pun that Sn is Tin, so the two are almost interchangeable. The logo for SnClair almost creates itself, too: Sn in a square like a chemical symbol.

SnClair is a stoke of homophonic genius. Love it.

Here's the Sn-in-a-box-but-with-a-rainbow-on-the-bottom icon:

Code:

Yeah I'd vote for SnClair as well

This would be a great addition to the CE! The TI-89, TI-92, TI-92+, Voyage 200 and Voyage 400 all got a ZX Spectrum emulator called Tezxas, so it should be more than feasible.

Cool project idea!

One piece of advice I have, given your inspiration by Famicalc and TI-Boy JITs, is that the JIT approach was especially suitable for those due to the large majority of those systems' code executing from ROM, so there wasn't much concern about self-modifying code. I can only speak for TI-Boy, which doesn't have particularly sophisticated SMC detection, opting to do a memory comparison before running code from RAM to make sure the recompiled code is still valid.

For something like the Spectrum where programs are loaded entirely into RAM, you might have to think about some better ways to handle that, or maybe go for the interpreter option.

By interpreter, do you mean switch-casing on each opcode etc. etc.? If so, there is this Z80 interpreter written in ANSI C that _should_ be portable enough to compile with the CE toolchain.

But I worry that 1: it will be too big once compiled to fit both the interpreter and the 48k of ZX ram in available space on the calc, and 2: it will be an order of magnitude slower than running native.

The Spectrum runs at 3.5MHz natively, and while the CE runs at over 10x that (48MHz), wasted cycles on waiting for memory to respond and having to switch-case and do all the bitwise math for each instruction means that running an interpreter will easily take way more than the 1:1 speed of 48/3.5= 13.5 eZ80 instructions per emulated Z80 instructions.

Now, I did look into TIZXAS, and while it is a bit more to wrap my head around, it seems that this approach may on the eZ80. From what I can tell, it looks like a 64k lookup table that maps Z80 opcodes and their operands into m68k instructions and operands. It also requires 155k of ram to run, but that includes multiple buffers of the screen to implement grayscale.

Yes, an interpreter is usually implemented with a switch-case or similar, but I'm not suggesting to ditch the advantages of running Z80 code on an eZ80. An interpreter implemented in assembly can still fully take advantage of the architectural similarities, such as keeping emulated registers in native registers and directly using the flag outputs of operations. You might also be able to do memory emulation by using MBASE and 16-bit instructions, rather than having extra overhead for array indexing. Using shadow registers can be a huge help too, allowing you to quickly swap the emulated registers in and out, including the flags which might often need to be preserved.

Still though, you're right that interpreter overhead is super important to consider, especially if you can't achieve the speed ratio you want. But keep in mind, the ratio is the worst for the fastest instructions, and can be somewhat balanced out by the slower ones.