If I implement a linking protocol it will probably be over the DBG interface. You can run code directly, write to Flash or RAM, and lots of other fancy features.

Also, a USB link cable is just an FTDI cable.

SD cards would be easy if I bypass filesystems, and just allocate chunks of it to user programs, but then the PC-side portion is harder. That way it's just an SPI Flash chip.

@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.

I might try to join you, but I'm already working on two pieces.

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.

Yeah. Also, I forgot to mention, I'm planning on having an interactive shell prompt as well, like python or Lua. It won't be the primary interface for running programs, but it will run identically to running a program, and you can drop to it from within one.

I am excited for 0x10c!

Oh and btw, modding minecraft would be MUCH harder in C++. Either on the community or on the mojang devs. Right now, minecraft is broken up into a series of classes inside the jar. Because of this, you can simply swap some out with new ones. If it was in C++, it would be one big block of code, with no such ability. Modding it directly would be nearly impossible, so the mojang devs would have to build in a new system like the Elder Scrolls games use, where you have an external set of files it can load in and integrate with the game. VERY COMPLICATED.

Either that or they release the source, which they don't look like they plan on doing for a long, long time.

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.

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.