What about tokenizing a string that you type? Or doesn't it have enough ram for that?

Ah! very well. That will save ram too.

Might build this, when I have time and money.

That would be ideal. I'll be careful to make sure that the pins I use won't get in the way in the future, so they wouldn't need to be changed to accomodate additions to the circuits.

All good suggestions, yes. Although, I don't think I'd have a built-in sqrt function since there's no plan to support decimal numbers at all.

I haven't exactly started writing it yet maybe I'll change my mind.

If someone mass-produced 'em I might actually buy one ^^

Honestly, if you are going to make a design from scratch, you may as well use a more current design - the ez8 does not make that cut, being just as elderly as the z80. By the way, the only similarity between the z80 and the z8 is assembly mnemonic.... you will not be able to use existing code without a rewrite.

By the way, putting two independent CPUs will just increase the headaches involved in general purpose programming, rather like what happened to the sega saturn. Worse, these are microcontrollers, effectively independent systems by themselves - they will not be able to share a bus seeing as it's fully internal, and synchronization would be a nightmare. Unless one is going to be a dedicated co-processor handling IO, display, or other such things, it will be largely wasted as it would be incredibly cumbersome to use.

Since you won't be able to use any existing code anyways, you may as well go for an ARM chip, such as the LPC1114. 50mhz, 32-bit ARM Cortex-M0 with 4kb of SRAM and 32kb of flash. The SRAM and flash is unfortunately small, but it is still an order of magnitude more powerful then what you've suggested, never mind cheaper at less than 3$ per. Plus, it comes in a nice DIP package and has vastly more toolchain support - gcc.

Grab this 240x320 2.4" Color LCD - 15$. 3.3v-tolerant and has a built in ILI9340 controller again, requiring an 8 bit interface and 4 control lines (CS, WR, RD, RS).

Use an 8x8 key matrix: use the 8 pin data bus that is also connected to the LCD for input, and hook up a 74HC165 Shift-in register - 3 pins, CLK-out, LD-out, Ser-in to read it out. You may be able to find an existing keyboard module you could use, or just design a PCB. Alternatively, you could use PS/2 as you suggested.

2 more pins for a bit-banged USB interface - the ARM is easily fast enough to manage USB low speed, it should be able to manage full speed as well. SD card interface would occupy another 4 pins - MOSI, MISO, CLK, and CS; one of the SPI interfaces. Could use an I2C eeprom or flash instead of a SD card. Probably makes more sense: less overhead, by far.

Unfortunately, it seems that it would be difficult to use NXP's ISP interface in-situ, but the uC may be able to reprogram itself via a bootloader. If you could bake enough USB into the bootloader, programming could become quite simple. ASM programs will be incredibly difficult, however; 4kb of SRAM would be enough for some programs and overhead, but it's nowhere near enough for a complete binary program. An interpreted language would be possible, but honestly rather depressing. a Forth clone could be decent, though - not too much overhead in the interpreter.

Though, discussing a language now; doesn't that strike you as counting eggs before they hatch? You need to have working hardware before you can do much else, and it will not be as simple as buying all the parts and wiring them together - you will need hardware to program the uCs, as well as toolchains, debugging facilities (meter and logic analyzer), passives for LCD and uC(s). It's a great feeling to get it all together but it's a lot of work before you have something working. If you've got the background for it, by all means go for it, but if not I'd recommend playing with standalone microcontrollers first.