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!
Không có nhận xét nào:
Đăng nhận xét