'The Omnimaga Portable Computer Kit' ?

My main suggestion would be to go for something that is very low power, especially if portability is a goal of this project.

@zigzagjoe

The ez8 is far newer than the z80. It's actually as new as the ez80, both being redesigned versions of their architecture. For one thing, the original z8 only came as OTPROM at best, Mask ROM at worst, with no On-chip debugger. Hardly suitable for this kind of project.

I only brought up languages because other people asked. I was just discussing ideas while I waited for parts to arrive, and you're absolutely right that it's far too soon to start working on any such thing.

Using an ARM chip would make this a far more complex project, for the same reason using a z80 would: To get any kind of decent setup you need ROM and RAM chips external to the chip, AND there are practically no prototyping-friendly options. Good luck finding an ARM chip that has 29 I/O pins, a reasonably fast clock speed, and a DIP layout.

Even using an ARM MCU like you suggest has major drawbacks, not the least of which being the fact that the 32-bit ARM architecture has MASSIVE code compared to this 8-bit MCU. It would need at least 4 times as much Flash to EQUAL the size for programming ability. So, in terms of program size, the two chips are equal in Flash and the ez8 takes the lead in RAM. (Of course, this would change depending on how much of the program is data, etc. but it's mostly accurate)


The coprocessor will be just that: A coprocessor, with a fixed set of commands, mostly dedicated to audio. It will communicate with the main CPU via a hardware UART connection, which is relatively easy to use. (Also only 1 pin) Since the audio clearly won't take up all the CPU time, it would be easy enough to also handle I/O management along this line, using a  2-byte transfer protocol. The only reason I don't put the LCD on this CPU is so it's possible to drive it directly, in case there are any hidden features of the LCD people wish to take advantage of.

The LCD is perfect for the CPU I chose, and cheaper than the one you recommend. Also, why use a shift register when you can use a port directly? It's far faster that way, and I do have the I/O to spare thanks to choosing a larger chip.

The hardware SPI makes the SD card access easy, on the byte level at least. For filesystem management, this part becomes a fair amount more complicated, but this at least is something far less rigid at the moment.

PS/2 is the easiest part of the build.

I'm well aware that code cannot be shared between the z80 and the ez8. The register file differences alone make this quite obvious. I merely mentioned it because it will ease the transition for many of the people here who have programmed for the z80, compared to switching to a new architecture like PIC, AVR or ARM.

I don't plan to use USB at all, and don't see a valid reason to. Rather, there is a built in Debugging interface that is designed  to map to RS-232, which allows for programming the board directly, with a variety of other wonderful features. An FTDI cable would work perfectly, unlike many ARM debuggers which cost far more.


I think the disconnect is this: I didn't design this thing to be the most power-effecient, powerful board I could. If I wanted that, I'd just buy a Raspberry Pi and start from there. Far more power, better screen interfaces, etc.

P.S. If I went ARM, I would go with Native USB, not bit-banged. Why skimp on something so useful?

@Art of Camelot
I avoided the ez80 for two reasons: It's not an MCU, so it would be far more complex to build (and far more expensive), and it doesn't come in a DIP package. Otherwise, it's a far better chip in most regards. Faster, more RAM space, etc.

@Tr1p1ea
The chip is quite low-power. If anything, the screen will be the biggest draw, or the speakers. The CPUs will be negligible in comparison. I can't find any power draw specifications in their documentation, but I'll be sure to post some info when I get a setup built.

z8, which the ez8 is based on, is just as elderly as the z80. Sorry, should have made that more clear. The ez8 is faster than the z8, but it will still be blown out of the water by any newer processor - such as the ARM Cortex-M0, powering that one chip, which is fully pipelined nevermind 32 bit and running at several times the clock frequency.

The ARM chip I linked was a microcontroller, too - no need to futz with ROM and RAM chips. If you give up DIP requirement, even more options become available. Could also use a module such as the teensy3 rather than a raw MCU, but it drives price up. That specific one, the LPC1114, has 22 IO pins available, which based on some quick futzing about is sufficient for the set up I described. Also, has 4kb of SRAM, vs 2kb per ez8 chip. 50mhz also strikes me as quite a reasonable speed. The IO pins are the hardest part, relatively, and with a shift register (or PS/2 instead) it's a nonissue.

Code size is a concern, though with thumb available it reduces the damage to some degree. Additionally, ARM/Thumb instructions are likely more powerful on a per instruction basis thus *possibly* leading to fewer instructions. Would need to do research to confirm that, though. Going to be hard to fit much more than a basic OS, library routines, and a simple interpreter in either of their ROM spaces, though. Achilles's heel.

The shift register was mentioned due to IO constraints of that specific ARM chip; it lowers the pin requirement to where that chip is usable. For scanning a key matrix, the speed reduction is largely moot. Or, of course, just use PS/2 and don't worry about it.

Yes, that LCD is cheaper, but it's also greyscale at a fraction of the resolution. For $4 more, it seems to me that getting colour and significantly more pixels is quite worth it. Does use more power, though, due to the backlighting.

Accessing a SD is not as easy as you seem to think, though: even throwing filesystems out the window, you must operate on a 512byte block basis, which eats into available RAM. Using the fatlib for AVR as a guideline, you are looking at something like 600-1200 bytes of RAM dedicated to the SD interface (with a FS), never mind code size. Implementing a PC-compatible FS, such as FAT32, will drive complexity way up, and be a pain to write with the lack of good development tools. No PC compatible FS throws away the primary benefit to using a removable storage interface. An i2c flash/eeprom IC will be far simpler to deal with, and maybe save a few pins, too.

USB I mentioned simply because you could: the 50mhz ARM can manage low-speed interfacing with user code active, and probably can do full speed interfacing (12mbs) with full cpu usage. It's a freebie - why not? A dedicated hardware interface is much better, as you say, but you can't get a DIP ARM chip that has it. The presence of a USB interface would also be a point in favor of not using a SD card. A USB stack will use up some RAM and ROM, though.

There are ez80 MCUs, but they are only available in large SMD packages. Pain in the ass to deal with for a hobbyist. Basically, I mentioned this first because it was a fun thought-experiment, and second because two ez8s increases hardware complexity, code complexity, cost, power use and reduces performance.... for the gain of similar mnemonics. Buying a PI or other some such is boring; having a hardware design that one can understand and tweak as well as play with bare metal code is way more fun.

@Art_of_camelot: Registered mostly to reply to this post; I was bored, and it was fun to design a minimal system (as outlined in my post). Originally discovered it as I had to purchase a TI-84 C for a class - can't use 89 - and was doing research concerning it. Absolutely disgraceful what TI ended up shipping, also, could have been so much more.

EDIT: Spelling

Unfortunately, it looks like eeproms only go up to 128k (1mbit) in DIP packages. Though, there is this flash chip. 8 pin DIP, 1mb (8 megabit), 52 cents. Page size is 256b, which is okay. Obviously the byte level access an EEPROM could provide would be better, but this is still nice. Will be vastly simpler to interface with compared to a SD, even with having to deal with pages.

Here's the 128k I2C eeprom: http://www.digikey.com/product-detail/en/CAT24M01LI-G/CAT24M01LI-GOS-ND/2683760

Also, Here's a 128k SPI SRAM (?!): http://www.digikey.com/product-detail/en/23LC1024-I%2FP/23LC1024-I%2FP-ND/3543083
Could be interesting....

Not for binary program memory, no; there's no way around that for either MCU without using one that exposes some of its internal bus. But for an interpreted program, it could be used to defray operating expenses of a SD card, possibly. Would be unable to keep much/any user code in RAM. Just something interesting i saw, anyways.

Linking software can get messy if it's allowed to grow out of control, but it'd be superior to using SD card in terms of access speed and ease. At the simplest level, though, linking software is quite simple, especially compared to rolling a whole SD stack. Of course, you'd want to implement either serial over USB or just plain bit banged serial, but hey, options. For programming, eeprom usage would be more deterministic than FAT layered on SD; simpler to deal with.

Just some thoughts, anyways.

You're still going to have to deal with the SD interface, which is quite a bit more complex than a SPI/I2C flash will be. I'd recommend looking over sdfatlib (AVR code) to see just exactly what you're getting into. Specifically, Sd2Card.cpp and Sd2Card.h. Also, low-level access to a device is a privileged operation, will complicate PC software to some degree.

FTDI cable is another way of accomplishing serial over USB; was suggesting the virtual com port method of serial (or raw HID) in the context of that ARM design - not actually using serial, just showing up like that to the PC. Can simplify programming of the link software.

zigzagjoe, the SD interface has an SPI mode that's directly supported. It is exactly the same as what an SPI flash chip would do. sdfatlib only applies if you use a FAT filesystem, and do software SPI.

can someone post a photo of one of this "portable computers"?