Up to this point, Petscii Robots has been working on the Commodore PET, which was the original
platform for the game, the Commodore 64, VIC-20, Commander X16, and even the Apple II. And in this
episode I am going to show off the new version for the Atari 8-bit computers, and the updated
version for the Commander X16 and talk about some of the interesting challenges along the way.
Around the time the Apple II version was going on sale, I was contacted my Christian Kruger,
who was interested in doing a port for the Atari computers.
So, I sent him the source code to the PET version. And by the way, all 6 versions
of the game have been converted from the PET version. A lot of people think, for example,
that the Apple II version was converted from the C64 version. But it’s not. The PET version is the
easiest starting point because it doesn’t use any graphics, sprites, or fancy music.
So, like a month goes by and I haven’t heard anything, which
is not unusual. A lot of people ask for the source code to my games only to find that they’re simply
not qualified and they’re in over their heads, and so nothing ever comes of it. Nevertheless,
like a month later I got this email from Christian saying “well, here it is, it’s all done.”
So, I was a bit skeptical. So I fired up my Atari 800 emulator and mounted the disk.
Only to find that, well, yes. It was done. He did an exact 100% port of the
PET version. I mean, quite literally it is identical, even the sound and music.
The thing is, of course, I was sort of expecting a bit of an enhancement since
it’s running on a much more capable machine than the PET.
So, we started talking about ways we could enhance the Atari version, and that opens a whole new
can of worms we’re going to talk about here in a minute. But, about a week after the first port was
done, I got this email from Blair Wilson and he also attached a fully working version of the game.
And well, here it is. And yes, it’s basically a port of the PET version as well. Now the thing is,
I didn’t send him the source code. And no he didn’t get it from anyone else either.
He had taken the PET version and ran it through a dis-assembler. Now what that does, it will take
6502 machine code and turn it back into a source code. Sort of. This is what that looks like. It
basically just makes up random names for labels, and of course there are no comments of any sort.
So this leaves a person with a ton of work to do because they have to try to figure out
what each piece of code does and then try to document it themselves.
And then he had to make the changes necessary for this to run on an Atari.
So, I replied to him and told him how impressed I was with his reverse engineering. And then I
told him that “hey, you know, if you’d just asked me for the source code,
I would have sent it to you. I actually sent him a copy right then.
And then of course I also told him that there was in fact an official port already in progress.
Anyway, so back to Christian’s port. Obviously the first thing I thought we
should do is improve the graphics and give it some color. However,
this is where I found out my knowledge of Atari graphics systems was somewhat limited.
To my surprise I learned that text mode on Atari 8-bit systems is monochrome. Which struck me as
odd being I’ve seen color in so many different Atari programs. In fact, when I boot up my Atari,
I’m presented with a blue screen. Well, it turns out the Atari allows you to select a global
foreground and global background color. But you can’t change the color of individual characters.
Sometimes, some Atari programs will use raster controls called display lists to
change the color of a line of text, which gives the illusion of full color text,
but you still can’t control a single character’s color.
Of course, it is possible to get more color, but it comes with great sacrifice,
which I’ll talk about in a bit. But first, I want to tell you a little bit about the character set.
So, this is the Atari character set. It consists of 128 unique characters.
As you can see it has upper case, lower case, and a few graphic characters. But,
it also has an additional 128 characters which are hardware reversed. So, while it technically has
256 characters, the second half of those will always be a reversed image of the first 128.
This behavior is actually identical to how the Commodore PET character set works. Except the PET
drops the lower case set in favor of more graphics characters. But the Atari does have one big
advantage over the PET, these characters can be customized. Well, at least the first 128 can be.
So, it’s really easy to load in the character set from the PET on the Atari. And thus,
Petscii Robots, that is the PET version, was relatively easy to get working on the Atari.
So, the question was, would it be possible to enhance the characters like I did on the C64
and VIC-20? Well, yes and no. The Commodore 64 actually has 256 completely customizable
characters. It just so happens the default character set has the second half reversed
so that it mimics the PET, but make no mistake, all 256 of these can be used however you want.
Which honestly, still wasn’t enough to really do what I wanted.
But, now I’m being asked to create a tile set using half that number.
So, rather than create a new program to do this, I just modified the existing tile editor I had been
using on the Commodore 64. I made it so that the second half of the character set is always
a reversed copy of the first. And then I worked for days to construct a tile set that makes the
most efficient use of this setup. And, believe it not, I actually did the testing for this tile set
with the Commodore 64 version like this. I know, it looks weird with everything being in color
except for the play field. Nevertheless, this proved invaluable for the process.
In the end, here’s what the new Atari character set looks like. I’m actually using 100% of
the first 128 characters, and then I’m using about half of the reversed characters as well.
Now, if you’re wondering what these 7 little square pieces are. These
are just placeholder characters, I’ll explain that in a minute.
And so here we go. Christian had spent some time working on the weapons and items display. He
used some sprites in those areas much like I did on the C64. And although those could technically
be color, we both agreed that it looked out of place so he went with a grayscale look.
Also, notice that we have a much nicer looking player character as compared to the little
stick figure of the PET version. This is where those little 7 boxes come into play. The player
is actually composed of 7 characters. But the player character exists in 8 different states
of animation. So, quite literally every time you move a tile, these 7 characters are reprogrammed
on the fly. And believe it or not, that’s exactly how the VIC-20 version works as well.
Some people have said that it still looks like PETSCII, but it’s not.
I wanted to show you some screenshot comparisons between the PET and the Atari version, starting
with this one. I’m just going to keep alternating these so you can see all of the changes. I mean,
the side panel is sort of obvious, so no need to even mention that. But if you look at the floor,
the crates, and of course the player character, you’ll see the difference. Here’s another view,
this time an outdoor view. You can see the grass and trees look considerably better.
And here’s one last comparison. Obviously the canisters are round and look nicer, but also the
bathroom sinks look better too. So yes, it’s still monochrome, it’s still character mode,
but I do think it looks a lot better than the PET version.
However, at this point we were still using the sound engine from the PET.
So Christian began work on enhancing the sound some, and
here’s what he came up with. There’s no dedicated music track like the C64 and Apple versions got,
so it still has the same musical track from the PET. In fact, the music is disabled by default,
but you can turn it on with SHIFT-M. But the sound effects have been vastly improved. Plus,
the sound effects run on different voices than the music, so they don’t interfere with each other.
So one question is likely to come up, which is people are going to be asking why it is that
other Atari games clearly have plenty of color and why Petscii Robots can’t? Well, these other games
are likely using color tile mode, or bit-mapped graphics mode, or some combination. Petscii Robots
could use these modes as well. But, using the color tile mode comes with significant tradeoffs.
For one thing, your horizontal resolution is cut in half. So everything would be a lot blockier.
But the second problem is, in color tile mode, you sacrifice the reversed half of the character set,
which I needed those desperately to make the tiles I already had. So,
it could be done, but Christian and I both agreed the monochrome version was probably for the best.
And now I want to show you this. This is an experiment from Blair Wilson using Atari’s
5-color text mode. This will illustrate some of the things I was talking about. So,
obviously it looks chunkier, but that’s not the end of the world. The two main problems
are lack of available characters to use to draw any detail. And, of course, another problem that
may not be as obvious. The Atari still has no color-RAM like Commodore machines have.
So while you can assign one of 5 colors to a character in this mode, it will affect every
instance of that character anywhere on the screen. So, if you needed a red circle and a blue circle,
you’d have to have two separate characters for that, which as you know are in short supply.
As for bit-mapped graphics mode, well, that could certainly be done. That’s how
the Apple II version works, as discussed in the last video on Petscii Robots. However,
this requires a significant rewrite of the display system. That also means it would need more RAM,
which probably means the Atari 800 would no longer be able to play the game. And quite frankly,
Christian wasn’t willing to commit to such a massive undertaking by himself,
and I don’t blame him. The Apple II version had a team of 5 people working on it.
Where the Atari version is basically just Christian and a little help from me.
And so there we have it. This is Petscii Robots for the Atari.
It’s not going to knock your socks off or anything. I mean, visually it’s not the
most impressive version of this game. But, it does play very nicely. It’s just as smooth and
responsive as the Commodore versions, has all the same levels, and is just as fun to play.
And there is just a tad bit of color used. When you take on damage, the background flashes red,
and when you use the EMP it flashes blue. This is consistent with the Commodore versions too.
Also, the Atari version is compatible with this guy. It’s a new adapter that will let
you connect an SNES controller to the Atari, so much like the Commodore and Apple versions,
it can be played with an SNES controller. However, unlike this Commodore version, these will not be
included with every boxed copy. Of course the Atari version will be cheaper to compensate.
So what kind of Atari 8-Bit setup will you need to run the game? Well, the basic requirements are 48K
of RAM and a disk drive. So, that means most any Atari 8-bit system will work except for the 400
and the 600XL because they don’t come with enough RAM. However, if you are handy with a soldering
iron, these can be upgraded to 64K, in which case they should be compatible at that point.
And now I need to talk about a matter of economics. So, the Apple II port got it’s
own box and it’s own manual. And the Apple II port also set me back about
ten thousand dollars. In order to even break even, I needed to sell about 300 copies,
which unfortunately, I have yet to do. I have only sold about 260.
Where the Commodore version, on the other hand, has sold like 6 times that many.
So, I’m trying to be a little bit more realistic with the Atari version and so this is the plan.
I’m going to re-use the Commodore box, but I’ll be putting a sticker over the fake sticker it already
has, showing the Atari specs. I’ll be re-using the Commodore manuals as well. Since after all,
most of the manual is devoted to the gameplay, which is the same on all versions. And I’ll
have an extra insert here for the Atari with some information that is unique to the Atari version.
I do have a dedicated disk label for the Atari version. I went with a gray background
to differentiate it from the Commodore and Apple versions. Funny thing is, this sort of thing
was common practice back in the day anyway. So there’s really nothing unusual about doing this.
But anyway, hopefully this means I’ll only need to sell maybe 150 copies to break even.
So, moving along, let’s talk about the Commander X16 version. In the last video on Petscii Robots,
I showed that I had ported over a color-PETSCII only version of the game.
It used no graphics whatsoever, used the same sound system from the PET,
and worst of all had this huge gap at the bottom of the screen. Of course,
this was always just meant as a quick proof of concept. I wanted to eventually have it look more
like the Apple IIgs port that was in the works, although that is currently stalled at the moment.
So, one problem with doing an X16 port is there’s just a complete and total lack of tools.
For example, it’s really difficult to compose music for the X16 when there’s
no tracker available. So there’s a laundry-list of things like this
that need to be completed before the game itself can be fully realized.
The other problem I had with the X16 was somewhat unexpected.
The video and sound systems in the machine are just so versatile. They might actually be
too versatile. So, I actually spent months trying to figure out which was the best direction to go,
using which features to do what things, because I didn’t want get deep into a huge amount of
investment of time in working on the game only to realize I should have gone a different direction.
Because, I’d have to start all over again, it would be a big huge waste of time.
And so, I was stuck for several months in something called “analysis paralysis.”
For example, the video chip is a 3 layer system.
The way this works is you have a top layer that can work in any number of modes such as text mode,
graphics mode, multi-color tiles, etc. Then you have 128 sprites that live in the middle,
and then a bottom layer that also works exactly like the top layer.
So, I tried to consider how best to construct a game like this. I considered using full bit-mapped
graphics like the Apple-II version. I even considered using sprites for the play field.
Since there are only 77 tiles and the video system supports 128 sprites. I could literally make each
tile a sprite. Then all I’d need to do is change the base-address for each sprite to determine
which tile it was going to display. The only reason I wasn’t able to do this is that my tiles
are 24x24 pixels in size, and the nearest sized sprite would be 32x32 in 16 colors. So a lot of
the sprite area would simply be wasted. Multiply that by 256 different tiles needed and the amount
of video RAM needed was actually 128K, which would leave no room left for anything else in video RAM.
So, anyway, let me show you what I do have. The title screen is a 16 color bit-map image.
And it’s actually packed with an RLE compression system I devised
just for this game. Another one of those tools I said had to be made. And, so lets start the game.
So, as you can see, I’ve reworked everything so that it now fits the screen size properly.
Now, let me tell you what you are looking at here. This part here is layer 1 and is
a bit-mapped graphics image. This part here is text mode on layer 0.
And this part here is all sprites. So you can see how I’m using the different layers of the X16.
At the moment, I’m still using the same character engine from the Commodore 64 version, with the
same tile set. It looks pretty good, but it’s still temporary. At some point, I plan to rework
this part to run in bit-mapped graphics mode, and borrow those Apple IIgs graphics I talked
about earlier. But for the moment, it doesn’t look too bad, actually. But, anyway, hopefully it makes
sense why, for example, the weapons and items displays look so much nicer than the play field.
So… about the sound. Believe it or not, this is still more or less the same sound engine
from the PET. The only thing I added was the ability to set waveforms for specific sound
effects. This makes things like the explosion much nicer. But this is all temporary as well.
As you can see, I’m working on a tracker here,
which will allow me to design custom music and sound effects for the X16, taking advantage of
it’s 8 voice PSG. At some point I might even have music for the Yamaha FM sound chip.
This tracker is still a work in progress, but as you can see, it is somewhat operational.
Here’s another thing we’ve experimented with. This code is by George Kirkham. And
he wrote essentially a software emulator that allows the original game music for the C64
to work on the X16’s sound system.
Clearly it isn’t perfect, but it does work. But I think everything would be cleaner just
to have a native tracker for the X16, so that’s the route I’m going for now.
And so, the game is still in a transitional stage of development.
I’m leaning heavily on assets from other versions of the game since I
don’t have all of the tools needed on this platform. But it’s getting there.
And so, there you have it. The Petscii Robots have invaded nearly every 6502 based system.
The only things that remain if anyone would like to take the challenge would be the BBC micro,
the Nintendo, and Super Nintendo. I suppose it might even be possible to port it to the
Atari 5200 and 7800, but I’m definitely not up the challenge on any of these systems.
That being said, I definitely plan to start work on an MS-DOS version
at some point maybe later this year. But that’s it for this episode. I probably won’t have another
video on the channel until after I return from VCF Midwest. So, in fact, the very next video will be
filmed on-site at VCF Midwest. So, stay tuned for that, and as always, thanks for watching!