First off, here's the parts list, with digikey links, and price breakdowns.
https://docs.google.com/spreadsheet/ccc?key=0ArVW6ZRBoIhOdFdyY25QMkppejJFc19sd1FpWF9UNHc&usp=sharing

Now, to the fun part!

This is a simple design for an ez8-based computer. The ez8 is, like the ez80, a modern chip based off of an old zilog chip. However, instead of being based on the z80, which we all know and love, it is based on the z8. This chip was designed to be similar to the z80 in syntactical programming, but the architecture itself is quite different. There is also a C compiler provided by Atmel for the non-gurus.

The computer has 2 ez8 chips, each running at 20 MHz, with 16 KB of flash, 2 KB of RAM, and 29 I/O ports. One of these acts as the primary CPU, for general tasks, while the other is slaved, doing tasks as it is polled, such as managing the included sound system (speaker and headphone port) as well as other routines.

The computer uses a B/W 128x64 display, with a built-in driver chip that makes interfacing it extremely simple. An 8-bit bus for data and instructions, with a few other bits on the side. Duty Cycle is adjustable, so greyscale should be easier than on the TI series.

The main method of input is intended to be a PS/2 keyboard. Also included is a MicroSD card slot, which will interface to the main chip via SPI.

For power, an LM237 regulator hooked to a 4xAA battery holder is also included.

Some notes:

For the most part, this project should be relatively easy to work with. The ez8 chips are 40-pin DIP, with sockets. Most (not all) of the components involved are thru-hole, and most of those that are not can be easily substituted with materials on hand. (For example, I plan to use a floppy connector for the prototype's SD card slot) As of yet, I have no plans to make boards for this, or any other manufacturing arrangements. If there's enough interest later, then maybe that can change .


Here's Zilog's page on the exact chip.
http://www.zilog.com/index.php?option=com_product&Itemid=26&task=parts&familyId=6&productId=Z8F1621&mpn=Z8F1621PM020EG&mpnid=5183&scrollmpn=1&rootpage=b3B0aW9uPWNvbV9wcm9kdWN0JnRhc2s9cHJvZHVjdCZidXNpbmVzc0xpbmU9MSZpZD0yJnBhcmVudF9pZD0yJkl0ZW1pZD01Ng==

Seems interesting. TO answer Xeda, I think it should be fine with 2 KB of RAM as long as the RAM doesn't have to be used for storate purpose like on Z80 calcs. In fact 2 KB might be more than enough in many cases, but I think 16 KB of flash storage might not.

Seems interesting. TO answer Xeda, I think it should be fine with 2 KB of RAM as long as the RAM doesn't have to be used for storate purpose like on Z80 calcs. In fact 2 KB might be more than enough in many cases, but I think 16 KB of flash storage might not.

Depends. a 128*64 screen needs 1024 bytes of RAM for buffering. And the other kB gets filled up pretty quickly. Let alone greyscale which requires at least two buffers. 128kB of RAM FTW.

Well it depends for the screen, since you can always store directly to the LCD like on the TI-84 Plus CSE (which doesn't even have close to enough RAM for buffering by itself). As for other KBs I thought that maybe map data could fill it up fast, but other than that you could maybe do some decent games.

And yeah with external SD card support I guess the lower internal Flash doesn't need to be as high.

The internal flash isn't low at all for having a basic OS. I was thinking a simple program loader, with support for loading from USB. The programs would then implement such things as BASIC interpreters and such.

Also, the screen is NOT driven by the ez8. It has its own driver, and the ez8 chip only has to feed one byte of screen data at a time.

Another thing to remember: There is technically another 16K of flash and 2K of RAM available in the auxiliary ez8. The plan is to have it be a slave CPU that you can send tasks to, but if you desire, those tasks could include loading and running programs, or even managing on-the-fly decompression of data.

The LCD datasheet lists the ability to adjust duty cycle ie. framerate, from anywhere up to 60 hz down to 5 or 6. This fact alone makes it far easier to make greyscale happen: You can tune the LCD to your game's timing, rather than the other way around!

Also, for those wondering why the low specs in some areas, this is because my first priority was cost. This thing will be under $30 for parts, and it's a dual core handheld computer, with a good LCD. Just moving to a microprocessor instead and having more RAM and Flash would likely boost the cost by at least $5. Also, you would lose the two CPU bit.

Oh also, I was debating whether the LCD should be on the coprocessor, and now I think it should, specifically for greyscale. Even if you can't fit a whole buffer, you could go atari-style and store individual greyscale sprites and have a background buffer that can be displayed in any of 16 shades (Yes, more than 4, because it would be totally possible with a chip dedicated to it)

Any program running off of the SD card would have to be copied into RAM first, and executed there. This means it would have to be <2k. However, they would load relatively quickly.

I'm actually debating about having a shared RAM pool now....it would be really handy.

In any case, the parts are ordered for my first prototype, and they should arrive in about a week.

To more directly answer your question, there is no installing at all. If a program is on the card, or in the flash, or in the RAM, it can run. If it's not, it can't.

Oh, it runs from flash, it just wouldn't run from the SD card, and I don't think anyone wants a loader to write to flash from the SD card. The chip is designed for the primary program memory to be from flash.

There should be plenty of flash to spare, really. This is especially true if I make it possible to write SD card programs to Flash. (However, this would require some kind of position-independent code handling)

Another issue of interpreted languages is speed, but there's no reason they wouldn't work just fine.