Six months ago when I posted about my “dream computer” I had a lot of people asking questions that didn’t seem to be addressed in the original post.  Plus, I’ve had time to think more about what would be best to have or not have.  Plus, some other unexpected surprises have come up.   Once I’m done with Planet X3, this is the project I plan to undertake next. So first, I want to answer some frequently asked questions:

Why not use the Raspberry Pi?

Well, to be honest the Raspberry Pi is just a linux computer.  You cannot program the Raspberry Pi directly, rather you program it just like you would a desktop computer in modern languages like C, Python, Java, etc.  It’s not the same.  It’s also a platform that is ever changing, something I’d like to avoid.

Why do you want an 8-Bit computer?

Imagine trying to learn to work on automobiles for the first time.  One one hand you have a 1957 Chevy and on the other hand you have a 2018 Toyota Prius.  Which one will be easier to understand how all of the drivetrain works?  The complexity of modern computers makes the barrier to understanding them much harder.  If you start with something more simple, it will be easier to understand.  People will be able to write code and actually understand how the hardware they are interacting with actually works.

Why not just wait for the Mega65?

While I’m really excited about that computer, I suspect it is going to be far too expensive to actually get a critical mass of users.  It will certainly be too expensive for kids to buy and learn on.  I believe the Mega65 will be a niche market.

Why do you NOT want it compatible with the C64 or some other 8-Bit system?

Compatibility has pros and cons.  But the main thing is, I want this to be a fresh platform that people can code on.  If you hand somebody a C64 and tell them to write a platform game, suddenly they’ll realize their platform game will have to compete with Giana Sisters and Sam’s Journey.  It can be discouraging.  But if nobody’s ever written a platform game on that system yet, then yours will be the first!  It’s a new frontier!

What’s wrong with FPGA?

I have two major gripes about FPGA.  One is the cost.  But the other is that people will be tempted to modify it.  In order for the platform to be successful it needs a community built around it.  If it splinters off like Linux did, then there will be a bunch of systems running different FPGA code and ultimately not be compatible with each other.  I don’t want that.  However, I realize there are ways to avoid that problem.

Sooo.. This was my first plan.

Since I wanted a cheap 8-bit computer that was made with modern components and boots to BASIC, I looked at several different platforms.  I had been thinking I would go with the NES-on-a-Chip design.  So, essentially I’d build a computer around that little epoxy blob that you find in little NES clones and other direct-to-TV video games.  It is essentially a Nintendo condensed down to one chip.  But I’d have access to the full address and data bus.  So I could put a nice sound chip like the OPL3 on there.  And have it boot to BASIC.  Of course, it’d be a custom version of BASIC that would be similar to C64 BASIC but with added commands for graphics and sound. I would add a PS/2 keyboard and PS/2 mouse port.  And top it off, an IEC disk drive port so that it could talk to Commodore disk drives.

The Pros of this setup would be:

  • Lots of documentation on how to code for the NES
  • Can do most of the work in an emulator
  • would be very cheap with the final product costing around $30
  • Would run almost twice as fast as a C64
  • Would be like a hybrid of Nintendo + C64, which would be cool.
  • Might even be able to get some NES games to work on it.

The Cons of this setup would be:

  • Uses composite video output only.  No way to interface with modern TVs and monitors.
  • Not really as fast as I’d like.  I’m hoping for a system 8Mhz or faster so that BASIC runs at a decent speed.

This was the backup plan!

I had a conversation with Jeri Ellsworth about using her DTV chip in my dream computer.  Of course, I wouldn’t be using it for the purpose of C64 compatibility.  In fact, it would likely be clocked at a much faster speed than the version that shipped in the Commodore DTV joystick.  It would boot up to a custom kernal and BASIC that I would design.

Pros of this setup would be:

  • Decently fast, running at at least 8 Mhz, maybe more.
  • Large memory map
  • It might be possible to add a “Go 64” command and make it C64 compatible.
  • Jeri says it is possible to use the digital output from the chip and convert to HDMI easily.

Cons of this setup would be:

  • The possibility of C64 compatibility might doom it to the same fate as the C128 and nobody will bother to write code for it.
  • Adding proper keyboard and mouse support would be complicated. The DTV already has a PS/2 port but it maps to the legacy C64 keyboard matrix, which is inferior to reading the PS/2 keyboard directly. That’s fine for operating as a C64, but I want more than that.
  • I would be dependent on a single source for the main chip.

And now this happened!

When I was at the Portland Retro Gaming Convention, Stefany brought her C256 Foenix prototype to show me.  I didn’t realize she was so far along on the project.  She’s using FPGAs for things like video, but they are encrypted and self-contained. So essentially, once programmed they cannot be reprogrammed by somebody else for small modifications, thus locking the platform specifications down. However, at the moment we are in a disagreement over what features it should have.

Pros of this setup:

  • It is based on individual chips like a traditional computer.  So there is a separate 65816 CPU running at 14 mhz, and a separate video chip, separate sound chips, etc.  This makes the system somewhat easier to understand.
  • It’s already far along in development, thus making it a system almost ready to go for me to start developing my custom kernal and programming environment.
  • It already supports DVI / HDMI out of the box.

Cons of this setup:

  • Stefany and I disagree over some of the design at the moment.  For example she has an integrated floppy drive, MIDI ports, SID chips, and a whole host of other things that I don’t feel are necessary and will inflate the cost of the computer.
  • Even if she agreed to all of my design changes, it would still be a computer that would be $80 or more for somebody to buy, well above the original price point I was hoping to target.

So what’s next?

Well, when I’m done with Planet X3, I want to start designing a custom kernal, BASIC, and 6502 assembler.  I want to give people a really user-friendly environment when they boot up the computer.  I want them to have a menu at boot where they can pick BASIC or Assembly.  I want it to be easy to program in either language. I want it to have a familiar interface and look for those that are current Commodore fans, but it will ultimately be its own platform.  So, imagine the C64 vs. the Plus/4.   Both offer that familiar Commodore environment, PETSCII character set, screen border, screen editor, etc.  They can even attach and use the same disk drives and file systems.  But they are ultimately different machines and not compatible with one another.

I’ll start designing this for the Commodore 64 using an emulator. Ultimately, whatever architecture I go with will be based on the 6502, so the code I design on the C64 should be easy enough to move to a new platform.   Eventually I’ll settle on an architecture after hearing lots of feedback from you guys over the next few months.  Then I’ll start trying to tailor the software to that specific architecture.

Basic will be for fun and for kids to learn on.  It will be faster than vintage BASIC systems, and easier to use with nice graphics commands and stuff.  It will also have a full-screen editor that you can scroll up and down and edit code, similar to how the Maximite computer does.  It will use labels instead of line numbers.  But, just like vintage 8-bit systems, any serious programming needs to be done in assembler.  I do all my assembly work on a modern PC with a cross-compiler, then test in an emulator. But, since there will be no emulator for this setup, it will definitely need its own assembler in ROM so that serious development work can be done right there on the machine.  I have some ideas of how to implement this all, and I think I have a way to even mix the two so that people can write sub-routines in Assembly and call them from BASIC.  So, I hope this will be great, fun system to code on.