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!
