Thank you, mission.
Hello, everyone.
My name is Michal Pleban, and I would like to show you how to do cool things with a Commodore computer.
So, back when dinosaurs roamed the earth, Commodore introduced the Pets.
It was one of the first home computers on the market,
and it started a succession of a lot of different business computers that were especially popular in Europe.
But time went by, and competition were introducing more and more powerful machines.
So, Commodore decided to upgrade the Pets, and in 1982 they introduced the CBM-2.
And when you look at the hardware specification, you see that it's basically an upgraded Pets,
a faster processor here, more memory there, but it's basically the same architecture.
But there is one little detail that stands out, it makes this machine really unique.
It's the second processor interface.
It allows you to attach a different CPU to the system and run applications on it.
So, if you want to do serious business, you can attach a Z80 and run CPM.
Or maybe you want to do scientific stuff, so you can attach a Z6809 and run Pascal.
It's all made possible because the architecture is very flexible.
So, the way it works is both CPUs are connected by a message bus, so they can communicate with each other,
and they share access to the main memory using an arbitrator.
So, normally one CPU is running an application, and the other one is either waiting or doing some housekeeping tasks,
maybe checking the keyboard, maybe updating the timer, but basically the CPUs run together at the same time.
And the message passing bus allows you to use an inter-processal communication.
So, if you have an application running on the second CPU, and you need to do some IEO,
maybe load a sector from the disk, then the second CPU interrupts the first one.
The first one grabs the memory access from it, loads whatever it needs to be loaded from the disk,
puts it in the memory, and gives the access back.
And the beauty of it is that it can work both ways.
So, normally you would have an operating system running on the second CPU,
and call the first one for IEO, that's the standard way we could say,
but you can also do it the other way around, and use an application on the main CPU,
and use the second one as an accelerator.
That's also possible because the bus is very flexible.
So, if you compare it, for example, to the A-Cord and Tube, which is also a popular and well-known second processor interface,
that one works only one way. This is much more flexible.
So, given this powerful architecture, what did Commodore actually do with it?
Of course, there was a Z80 card plant, we have the schematic for it, but it was never produced,
but what Commodore did produce in the end was this.
It's an Intel 8088 processor card that's supposed to run CPM, and of course MS-DOS as well.
So, yes, you can run MS-DOS on this computer, and it looks like this.
I run a check disk, because that's about the only thing I could run on the machine.
Because there's a tiny little problem with MS-DOS.
Today, when we think about MS-DOS, we think about the PC,
because that was the original operating system that launched with the PC,
and the PC became so popular that it overwhelmed all the other personal computers except the Mac.
So, we say MS-DOS, we think the PC.
But in the early 80s, Microsoft had a different plan for MS-DOS.
It wanted it to be a G operating system for all 16-bit machines, just like CPM was for 8-bit machines.
So, we had more than a dozen different computers on the market,
and each was running its own version of MS-DOS.
And the theory was that once an application was written using MS-DOS APIs,
it should be able to run on all of those computers.
But the thing is, the MS-DOS API is very limited.
So, for example, if you have a spreadsheet application,
you need to be able to place a cursor on the screen and update a specific cell.
Well, guess what? There's no API in MS-DOS to position a cursor on the screen.
So, what you had to do, you had to go through the machine's BIOS.
And of course, each computer had a different BIOS interface.
And not to mention Bitmap graphics and any other advanced features.
All of them had to be accessed in a machine-specific way.
So, what really happened is the applications were written first and foremost for the PC,
maybe for a few other architectures, but if your computer was not PC-compatible,
then you had very little software to run on it.
And the Commodore is about as incompatible as possible with the PC,
so there's nothing that you can run on it.
So, the big question is, can we do something about it?
Can we somehow make this great machine PC-compatible and run real applications on it?
And the answer is, of course, we can.
And the way to do it is we need three things.
First of all, we need something that has the same interface as the PC BIOS,
so that applications can use actual PC BIOS interrupt calls to interactive the hardware.
We need video memory, because there's one thing that all PC applications do
is they write directly to the video memory instead of using the BIOS,
because that's so much faster.
And first, third, we need virtual hardware,
because the PC has a lot of I-O chips that the Commodore does not.
So, if you want to generate sound with PC speaker, for example,
there's no BIOS interface for it, you need to interface with the I-O chip.
So, we need to do something and make up for the fact that the Commodore is lacking all those chips.
So, this is what is needed to create a PC-compatible BIOS.
These are all the interrupts that need to be implemented to have MS-DOS boot on the machine.
If you are familiar with low-level DOS programming, you will recognize what they are.
They give access to the screen, to the keyboard, to the disk, some basic stuff.
So, the good news is that we can reuse a lot of code from existing MS-DOS 1.25,
because, for example, if you want to put a character on the screen,
there's already a function in Commodore Kernel that does it,
and there's already an inter-processor call in the old MS-DOS that uses it,
so we just need to slap a different interface on it.
The bad news is that it is a lot of functions.
And you need to get all of them right before anything starts to work.
So, if you have a few years of free time, this is a good way to spend it.
The video memory is actually the easiest one of those three.
So, of course, the PC stores the video data at a different location than the Commodore,
so what we need to do is to use a timer interrupt to copy the data from one location to the other.
Of course, doing ASCII and Petski conversion, but it's very simple.
So, this way, anything that the application writes to the memory where a video memory would be on the PC
will actually appear on the Commodore screen.
And the third thing, we need to pretend that the computer has the same peripheral chips as the PC.
So, of course, we could try putting all those chips inside the Commodore
and basically making just another PC clone, but that's not cool.
And that's another way to do it. We can use virtualization.
So, how do we create a virtualization platform on an Intel 88 processor from the 70s?
Well, this is a virtualization platform.
And the way it works...
We need to be able to detect when the computer is trying to perform an I-O operation and stop it.
So, we put a virtualization environment here and every time when the computer tries to access the I-O,
it is interrupted. The interrupt routine checks what kind of I-O access is being done.
That's whatever magic is necessary to emulate this I-O chip,
most likely using inter-processor calls to perform the actual I-O.
And then it turns back and the application thinks that it has actually accessed an I-O chip.
Then it's done.
So, well, is it all enough to actually make this platform PC compatible and run those applications?
I'll grab a couple of bugs and let's find out.
So, we are booting the computer and we are starting to load the operating system, which seems to be free-dose.
And once we have free-dose running, of course we are starting not on Commander, what else would be?
And because we are dealing with Microsoft, of course we start with basics.
So, this is the QBasic from MS-DOS.
This is some very simple Hello World program.
And let's just find out if it works.
Yes, it does.
And of course we are going to use Turbo Pascal as well.
Prince of Persia.
So, again, a Hello World program.
Is it going to work?
Yes, it is.
So, just for good measure, let's try to change it.
So, indeed we can position the cursor on the screen.
We can do some changes.
And it works again.
So, that was the Intel 88 processor card from the Commodore.
But as I showed before, you can attach many different processors to the bus.
So, how about we do something really cool?
This is Commodore 900.
It's an abandoned Unix workstation prototype that was being developed by Commodore,
but it was cancelled because they bought the Amiga and they tried to focus on that one.
And if you look at the hardware, it's a very strange machine
because it uses a Xiloc 8000 processor, which is very rare.
It was used in some Olivetti machines, some industrial equipment,
but basically in 1994 nobody was using it anymore, except Commodore, of course.
It has a memory management unit and it runs coherent.
And coherent is like Linux, but 10 years earlier.
So, it's a system written from scratch to act exactly as Unix, but it was much cheaper.
And it's a truly multitasking and multi-user machine.
You can attach many terminals to it, log in at the same time around applications.
The problem is because it was cancelled, only a few dozen prototypes were made,
so unless you are very lucky and very rich, you can't have one.
So, how about we do something about it and we put a Z8000 processor on the second processor interface?
Here's what is needed to create a virtual Commodore 900 using this interface.
Nothing very difficult here.
So, of course, we need to create virtual hardware again.
We need a keyboard controller, we need a disk controller, we need a serial-poll controller, and so on.
But the good news is once the Iotips are emulated properly, we can use the original Commodore BIOS.
We don't need to write a new one.
And even better, because it's Unix-like with resource protection, then no applications are touching the Iotips directly.
They are all going through the operating system.
So, once the operating system works, then everything is supposed to work as well.
And this is very different from MS-DOS, where every application had its own dirty ways to play with the Iotips
and it's needed to emulate all of that stuff to let them run.
So, you know what happens now.
But before I'm going to show you how it works, this is the Z8000 processor card that I made.
So, it has one megabyte of memory.
It can be accessed either as 8-bit or 16-bit.
It has a memory card that emulates the hard disk.
And, of course, it has the virtualization environment as well.
So, is it going to work? Let's find out.
So, now the original BIOS is starting.
It's going to perform a self-test of all the hardware.
The hardware does not exist, but the self-test passes.
And now we are booting the operating system.
Router can't without the password. That's a very secure installation.
It's a nice Unix file system. And, of course, because it's Unix,
we are going to program it in C.
That's a Hello World program again.
We have a C compiler on board, which takes a bit of time to compile this tiny program
because that's just six megahertz.
But, finally, it's done. And, the program works.
And that, ladies and gentlemen, was Unix running on a Commodore.
Thank you very much.
Three minutes for questions.
Hi, and thank you for the presentation.
Stand up.
Have you tried, like, there's another project for the Commodore,
for the BBC Micro that uses a Raspberry Pi to emulate other professors.
Have you tried using, not using the hardware that you cannot obtain today,
like the ZE-8000 and so on?
Have you tried using better metal or Raspberry Pi to do the emulation
of the other hardware or maybe the emulation of other professors and so on?
Have you had a thought of that?
Yeah, well, you can obtain the ZE-8000 from eBay very easily.
But, I have not tried using any platform from this.
I'm a Commodore guy.
The main problem with emulating the Commodore 900 specifically
is that nobody has ever written any software emulation for the memory management unit of it.
So, you can emulate the CPU because, for example, in the main repository,
you can find the code, does it?
But there is no emulation existing right now for the MMU,
and that makes it really hard to do it without the real chip.
But try the Intel stuff.
Yes, the Intel stuff should be done easily.
Yes, of course.
As long as you can virtualize it.
Thanks for the good talk.
How much performance is being lost in the emulation of the various IO chips?
A lot.
Yes, it takes a lot of time because, first, it needs to go through the interrupt routine,
then it needs to go through the message bus, then it needs to go back through all this.
So, that's quite a lot.
And that's why I decided to bump the processor speed a little bit.
So, for example, the original Commodore 900 has a 6 MHz CPU.
I put a 10 MHz.
And that makes a nice difference.
Otherwise, yes, you would really notice the difference.
But there's also one thing.
If you have static memory in the computer, you don't need to waste cycles for memory refresh.
And that also gives you a nice speed boost.
So, all in all, it works quite well.
Okay, time's up, unfortunately.
Many thanks, Michel.
Thank you.