When I first got my Commodore VIC-20 at the
age of 6, all I had was the computer. I turned it on and stared at the blinking
cursor. Curious what I could do with it, I looked
through the user manual and started to type in some of the example BASIC programs. Within a matter of minutes I began to experiment
with modifying the examples to do what I wanted the computer to do. Before long I was writing my own little programs
that did all sorts of neat things. Commodore BASIC was sort of limited in that
it didn’t provide any sort of commands for graphics and sound. So, if you wanted to do anything like that,
you had to access the chip registers directly with POKE and PEEK commands. And while this was somewhat inconvenient,
it did have one advantage, it better prepared me for my journey into programing assembly
language. In fact, I remember the first time I bought
a commercial game and I tried to list the program, only to see a single line with an
SYS statement. I was totally mystified by this. It was like magic. What was the meaning of this one line in BASIC? And how did these programs run so fast? I eventually moved on from my 8-bit computers
into the Amiga, eventually into MS-DOS computers, and now of course with modern computers. But, today, when I think back about the computers
I was most fond of, it wasn’t the Amiga. Despite being much more powerful, the Amiga’s
operating system put a layer between the hardware and the end user. I couldn’t just peek at a memory address
anytime I wanted. I couldn’t make a change to a hardware register
and see it happen immediately on screen. And so, today, I still have a fondness for
the 8-bit computers. And I don’t have a particular favorite. I love writing code. And I’m just as happy to code on a VIC-20,
C64, or Plus/4. As long as it has that same closeness to the
hardware. I get a lot of emails from people asking me
which vintage computer do I recommend for them to learn about computer architecture
or programming or whatever, and the problem is vintage computers aren’t necessarily
ideal for this anymore because for one thing they’re getting more and more expensive
and when you do get one, half the time they don’t work. Or, maybe they do work for a little while
and then they break down shortly after you start working on them. It can be really challenging for people to
keep these systems maintained and functioning if they’re not familiar with how to work
on them. So, I made a proposal about a year ago on
my website talking about my dream computer. In my proposal, I had these requirements: The computer would be made completely from
modern, off the shelf parts. No old stock, no sourcing parts from vintage
computers. Would output VGA or even better, HDMI video. The main reason for this is that composite
video is more or less dead and I don’t want people to have to search for old monitors
to use as a display device. it would have a real CPU, preferably a 6502
or compatible. It would preferably not rely on FPGA or Microcontrollers That it would be capable of natively running
Commodore BASIC 2.0 That it would be inexpensive, preferably around
$50. Of course, after making this post there were
numerous questions that would continued to pop up, such as why not use a Raspberry Pi? Ok, so to answer that, the Raspberry Pi is
a fantastic little computer for many things, but at it’s heart it’s just a Linux machine. So, coding for the Pi isn’t really any different
than coding for a modern desktop computer that runs Linux. So, what I want is a computer like I grew
up on, I want something that’s simple enough that a single person can understand all of
its components. If I were to give you an analogy like with
cars, for example, which would be easier to explain? A car made in 1957, or something like a Toyota
Prius? So, another one that pops up a lot is why
not wait for the Mega65? For those who aren’t familiar it is an attempt
to recreate the Commodore 65, which was still in development when Commodore went bankrupt. The Mega65 is a really ambitious project and
it’s actually everything I could want. You might even say it is my dream computer. But, it remains to be seen if it will ever
actually come to market, and if it does it will likely cost many hundreds of dollars. As a result, there may not ever be enough
of them sold to get a critical mass of users to start a software ecosystem. But, we’ll see. What about something like the BASIC engine? Well, I like this product but it has a few
problems. For one thing it only outputs composite video. The second problem is you can only program
it in BASIC. So again, you’re kind of shielded from the
real hardware. The same problem exists with the Maximite
computer. Again, I’m looking for something you can
actually program in BASIC or Assembly language and that you can access the real hardware
registers. Then, of course, there’s the C256 Foenix
project, which ironically was actually started as a result of my request for such a machine. In fact, I was planning to collaborate with
Stefany on the project after we first discussed it in at the Portland Retro Gaming Expo last
year. However, we eventually decided that her design
goals and mine are not really going in the same direction. Primarily, we disagreed over issues of cost. You see, I am under the opinion that if I’m
going to be selling a product thats no more powerful than a Raspberry Pi, then it shouldn’t
cost 5 times what a Raspberry Pi cost. So, my goal is to produce something that can
be sold for around $50. $100 is kind of a maximum upper limit. So, at first my plan was to just build something
almost identical to a Commodore 64, but ditch any chips like the SID or VIC chips that are
no longer available and design in modern substitutes. Compatibility wouldn’t be a concern for
me because this computer would be primarily aimed at people who want to write their own
programs. But I wanted to capture the look and feel
of what Commodore offered. But, after many discussions, I realized that
maybe I haven’t been asking the right questions. So, I asked several people what it is that
they actually missed about 8-Bit computers and here’s some of the responses I got. Now, I think for me, when we talk about 8-bit
computers, there’s two things I really miss the most about 8-Bit computers. The first one is the user guide. Now, typically, when you would buy an 8-bit
machine an 8-bit micro, you would a user guide that was the size of a book. And the user guide would teach you everything
there was to know about the machine. What I really miss about 8-Bit computers when
I’m using modern computers is the immediacy. The full control. For example, you just turn your C64 or 128
on and you’re ready to program in BASIC or play a game whatever you want to do. It’s that single tasking. There’s no updates to worry about, just
the beautiful blue screen. No notifications or pop-ups or anything. So, for example, if I just want to program
my favorite little one liner here. 10 print. Hey Robin! Oh. Why did I install that Commodore messenger? That keyboard could really use some retrobrite. I like it just the way it is! What do I miss about 8-Bit computers? Well, I like the fact that they’re 8-bit
computers, I suppose. That’s the thing that I enjoy the most about
using something like a Commodore 64 or a ZX Spectrum or any number of those 8-bit machines
from back in the day. It’s just they’re restrictive. And they’re not going to do a whole lot,
and yet at the same time people are still able to do so much with them in terms of making
impressive games or demos and audio and graphical effects that the people that created these
machines never actually thought was possible. So, I really miss the experimentation and
and the ideas that come about from being restricted. I often find that is something that is true
in my own creative process as well. When I restrict myself in some arbitrary way,
I end up having to come up creative results. You know, creative solutions to make it something
that’s actually interesting. As opposed to just you have all the unlimited
resources in the world, you can just come up with anything. But if you can’t do that, there’s something
that just triggers in the creative process and it makes it more interesting. Now, I think the second thing that I really
miss the most about 8-Bit computers is the possibilities. And, what I mean by that is when you turn
the machine on, typically most machines just have a startup message about the ROM or the
BASIC that it’s running. And then a flashing cursor. And that’s it. So, it’s really up to you to figure out
how to learn how to use this machine in order to take advantage of it. Do you just load games and start playing them,
or do you start writing BASIC programs or do you load up an assembler and start writing
machine code on the machine? Sometimes we tend to look at old computers
through rose colored glasses. But, not everything about them is still desirable
today, so I also had to ask the question, you know what things do you not miss about
8-bit computers, and here are some of the answers I got on that. But, what I don’t miss about 8-bit computers
is trying to use them for productivity tasks. You know, those things that your mum or dad
actually bought the computer for? Trying to do word processing on it, like here
I’ve got fleet system 2, the manual for paperclip for the PET, and here’s WordPro
3 plus for the 64. There was only enough RAM to keep a few pages
of text in memory at a time. You could only see 40 columns of text, even
though the output was going to be 80. So, there’s no preview mode. Then there are all the problems the printers
themselves had like configuring it properly. There were no drivers in the operating system
so it was up to every single program to implement drivers for every kind of printer. So, for the biggest thing I don’t like about
8-Bit machines and I’m going to use the Commodore 64 as an example because that was
really the 8-bit machine that was something that I grew up with, and that is the amount
of time that it took to do pretty much any task on that machine was an exercise in patience
and frustration. So, in other words if you wanted to play games
off a cassette or floppy disk even, it was a long wait in order for that game to load. So, what don’t I like about 8-bit computers? Or anything retro? Honestly, the biggest thing is just getting
the stuff on there in the first place. You know, a lot of times as cool as some of
these old keyboards can be, the layouts and stuff are not standard, you know, for what
you would expect now days. So, that’s a problem if you want to just
type in and code stuff yourself. I would prefer something more standard like
a PC. I also just, I don’t like loading stuff
from disks or tapes or anything like that because, well, I mean I do, in a nostalgic
sense. If I’m in the mood for it. If I want to go through that process, it’s
great, you know? To revisit every so often. But, if I’m just sitting down and I want
to play with it for hours at a time, I don’t want to do that. Which is why I install like flash memory solutions
on like everything I have now. This Commodore 64 has an SD2IEC, the IBM PC
back there, that’s got an XT-IDE and you know it’s just.. it makes so much more sense
nowadays to not rely on like magnetic storage and platters and tape and things like that. Why?! Why do you. Why would you put yourself through that if
you’re actually wanting to use the things? So, some of my friends and I set out to design
a computer that incorporated all of the best bits of old-school simplicity but also try
to get rid of some of the more irritating aspects such as floppy drives. Now, originally I wanted to go with a straight
6502. However, I wanted to have more than 64K RAM. This gets kind of complicated with a 6502,
so Lorin convinced me to go with the 65816 processor. The 65816 is actually a 16-bit version of
the 6502. It’s totally backwards compatible with existing
6502 code, but it it can access up to 16 MB of RAM and has 16 bit registers. This same CPU was used in the Apple IIgs and
the Super Nintendo. Another notable use was in the SuperCPU expansion
cartridge for the Commodore 64. In fact, I bought several of these development
boards. What I have here is actually a completely
functional computer based around the chip, but also includes 32K of onboard RAM, and
a socket for a flash memory chip. This is what our final design will be based
on. But before we can get to this point, I need
to write a custom kernel. On the C64, the kernel does essentially these
main functions: Display text on screen, read input from keyboard, load/save to disk drive,
load/save to cassette tape, and handle input and output to RS232, among other things. Now, our new system will not have a cassette
drive, which is typically device #1 on a Commodore. I’m going to replace this with an SD card,
which will be the default device for loading and saving. But I still wanted to include the IEC disk
drive port so that you can attach old disk drives if you want, or even an SD-2-IEC, but
these will all be optional. Originally, I thought I would probably take
the existing kernel and re-write about 10% of it to update it for the new hardware. However, after looking at the source code
to the original Commodore kernel, I can see that I had it backwards. It’s more like I need to re-write 90% of
it, and 10% can remain. This is compounded by the fact that Cloanto,
the company that currently owns the rights to the Commodore ROM chips, refuses to even
talk to me about licensing the Commodore Kernel. I’ve made several phone calls, send a dozen
emails, and filled out their web-based contact form. And they just won’t answer me. So, I guess they aren’t interested. That being the case, I’m just going to design
a new kernel from scratch. So, here’s my plan. I’m going to start with a C64 as the base
computer. What I need to do as I write my kernel is
figure out ways to replace pieces of it one at a time. So I’m going to start by getting rid of
the VIC chip. Well, I won’t actually be removing the chip
from the computer, but I’ll be writing a kernel that doesn’t use it. For video, I’m going to use something called
a Gameduino. I’ll talk more about this in a minute. So, once the new kernel is designed to output
video to the gameduino, then I’ll add in support for an external PS/2 keyboard. Next, I’ll implement support in my new kernel
for the disk drive port. Once all of this is working, I won’t actually
need the C64 anymore. I’ll have a working kernel that should function
on any 6502 based computer with minor modifications, whether it would be a VIC-20, Apple II, or
even some custom board like the PE6502. As long as the gameduino and PS/2 keyboard
are connected, that’s all it would need to boot. At this point, that’s where the little dev-board
I have will come into play, as I’ll connect all my stuff to that, and get the kernel working
there. Once everything is working on the dev board,
the final step would be to design a new board that includes everything on a single board. Right now I’m still at step one. So let me show you how that is going. This is a gameduino. It’s a little video board that outputs VGA
and it’s designed as an Arduino sheild. As such, it communicates through a serial
protocol known as SPI. This is perfect because I only need 4 pins
on the C64’s user port to control it. It runs on a custom FPGA and has its own internal
RAM. So, I needed a quick way to get this thing
running on the C64, so I reached out to Kevin at Texelec. Hello, I’m Kevin Williams from TexElec.com. David has asked me to help him just design
a quick prototype board to work with the gameduino. We just wanted to show you real quick how
it worked. Here’s the gameduino board and it requires
4 pins to interface with it through data pins and two different voltages, 5 volts, and 3.3
volts. In order to plug it in to the Commodore 64,
David asked me to build a small board which has a user port connection and a 3.3v regulator. The Commodore 64 provides 5 volts already
through this wire here. It’s a straight forward board. It’s just has a Arduino shield board connected
to a standard PCB prototyping board. Just has the pins connected on the bottom
for the 4 data lines and the ground. And the 5 volt line is connected here to the
regulator. So, all you really need to do now is take
the gameduino and plug it into the. This board is just a temporary solution in
order to get some development work started. But, we do plan to build a better board which
will have a PS/2 port as well so that we can get closer to having a functioning computer
working. So, now we’re just going to plug it into
the user port. So, now that the board is plugged into the
user port we’re plugging in the VGA cable. At this point, there’s no code written,
but there is a splash screen that displays when you turn the gameduino on to show you
that it’s working. So, just turn it on. You see the Commodore 64 came up, and there’s
the splash screen for the gameduino. So, after Kevin left I got to work writing
a little proof of concept program in BASIC, just to see if I could communicate with the
Gamedunio. The serial communication works very similar
to what I showed recently with the Nintendo controller, where you have to take an entire
byte and transmit it one bit at a time. The gameduino has a built-in character set,
and just to see if it is working I need to transmit 3 bytes to it. The first 2 bytes contain the memory address
inside the gameduino that I want to write to. Since it has 32K inside, it only really needs
15 bits for that. So the first bit determines if you want to
read or write to that address. The 3rd byte is the byte you want to actually
write to that spot. So, I’m going to start by trying to send
it this. So, the first two bytes will say I want to
write to RAM address zero, which should correspond to the first character column on the screen. And then I want to write a 65, which is the
ASCII value for the letter A. So, let’s see if it works. And it does. So, next I set off to design a program in
assembly language, which would be much faster. At this point I’ve already got a lot of
screen editor functions working and I can cursor around and type things to the screen. I’m still a long way from having a custom
kernel. But it’s going to be a series of baby steps
to get there. The gameduino has the ability to display thousands
of colors, 256 different sprites, and a lot hardware accelerated features. But, it isn’t necessarily ideal for the
final product. The main problem is that the SPI interface
is kind of slow for our purposes here. And the other problem is that it lacks a true
bit-mapped mode. It does tile graphics, and so you can write
games like this just fine, but if you wanted to do a game like this where it required being
able to write to the whole screen, you wouldn’t be able to. In fact, we have yet to figure out what sort
of video chip is going to into this final product. And we’re definitely open for suggestions
on that. However, the gameduino will work for now as
a temporary substitute. However, since the gameduino is an open-source
FPGA, I’d certainly be open to have somebody who knows FPGA to go in there and modify it
so that it can take 8 bits at a time in parallel, or better yet modify it work on the main data
bus, just like a video chip. In fact, a lot of this system is still yet
to be decided. I’ve started a facebook group with the code
name Commander 16 Prototype, which I invite anyone interested in helping with this project
to join. I’m going to need some help finding a suitable
video chip, and writing the operating system for the thing. I suspect this will be a year-long project,
so there will be multiple updates showing the progress. I actually wanted to start work on this about
6 months ago, but I had decided I needed to get Planet X3 finished first. In fact, this photo is representative of how
many orders I’m actually shipping out every day. And so, if you’ve wondered why there haven’t
been quite as many videos on my channel lately, well that’s the reason. Anyway, as soon as I’m caught up with Planet
X3, this project is going to become my primary focus for this year’s long-term project. So, I’ve created a facebook group for this
project and you’ll find a link down in the description field of this video. The purpose of the facebook group is to have
discussions about this project. If you are someone who would like to contribute,
whether it is just with ideas, or you’ve got an idea for a good video chip that might
work for this project, or maybe you know how to work on FPGA stuff, we could certainly
use some help with people who could do that. If you want to help write the kernel or something
of the built in ROM programs that we’re going to be looking to do, again, I’m looking
for help on all that stuff and this facebook group will be an excellent place to talk about
the ideas. And so, I look forward to discussing it with
you! But, that’s all for now, so as always, stick
around for the next episode and thanks for watching!
My dreamlist:
Gimme this for 50-100 eur and I'll buy three or four! I'd settle for 720p for minimum videomode, I wouldn't be interested in supporting 320x240 or 40 columns VGA
Does anyone know why "No Micro-Controller" is a requirement?
It seems like a lot of headache could be bypassed and he could get a lot of support using a micro.
If the aversion is because micros have built in peripherals to do stuff, he could find one with a memory mapped bus (8-bits or 16-bits) and use that to address and access all of his external peripherals and just ignore all of the other on-board peripherals.