Let’s go back to 1985 with the introduction of the Commodore 128, one of my favorite 8-Bit computers
of all time. Notice that on the front of the box it actually says it is expandable to 512K. But at
the time of launch, that wasn’t actually possible. In fact, I don’t think to this day that you can
expand it to 512K, which I’ll explain later. But a year later in 1986, they did come out with
the 1750 RAM expander for the C128. This one has 512K inside. And they also produced the 1764 RAM
expander for the C64. This one has 256K inside. They look identical. And pretty much, they are.
In fact, there were 3 official REUs produced by Commodore, two of them were marketed for
the Commodore 128, and one of them specifically for the C64. And while technically speaking any
of these will work on the C64 or the C128, one important consideration is that the original
power supply on the C64 isn’t capable of handing the load of the REU. So, when buying the 1764 REU,
it actually shipped with a beefier power supply for the C64. Notice it looks an awful lot like
the C128s power supply. Interestingly enough, the C128’s power supply was already adequate to
handle an REU and thus when buying the 1700 to 1750, it did not include a power supply.
And so the reason I said it isn’t really possible to expand your C128 to 512K
is because with the two choices they gave you, you could expand it to either 256K
or 640K total, but there’s no combination that will produce 512K total.
The color is light beige to match the C128 and the 64c, which had also just came to market the
same year. However, the 1764 will also work with the older bread bin style C64 as well.
So, the problem with expanding the RAM on the C64 or C128 is, at least from
the perspective of the cartridge port, there’s no where from the RAM to go.
RAM expanders were relatively common on the VIC-20, but the VIC-20 was a different story.
Looking at the 64K address space of the VIC-20, you can see there are lots of empty areas. So, it
was relatively simple to design a RAM expander to fill in these blank areas. And all you needed were
a few RAM chips and some simple decoding logic so that it would show up in the right addresses.
The C64, on the other hand, had no such empty areas. Its 64K address space was so full already,
that some bits, like the ROM, had to be banked in or out in order to use it all. So, how are
you going to add massive amounts of extra RAM to the bus? Well, believe it or not, you don’t.
You can really think of the REU less like a RAM expander and more like an ultra fast
storage device. The CPU can never directly access any RAM in the REU. So, how does this work? Well,
let’s take one apart and have a look inside. You’ll find the insides are heavily shielded by
a thick sheet of galvanized metal. Next you can pry that open, and inside you’ll find the PCB.
This particular model has two banks of 256K, which totals 512K.
And then there’s this chip here called the REC, which stands for RAM expansion controller.
There’s also an extra spot next to it for a 32K EPROM, but I’m not sure if this was ever
used or what it would be used for. But in theory you could put some sort of ROM here. There was
also a later model of REU that used a square package REC, but they work exactly the same.
The REC’s job is to copy data between the REU’s memory and the C64’s internal RAM.
At first glance, this may seem like a clunky way to use extra RAM,
since the CPU can never access it directly. But at the same time,
this is one of the biggest strengths of the REU, because it can copy data at fantastical speeds.
To understand why the REU provides such a performance boost, I’ve made a little
illustration for you. So, imagine this is a square wave showing the clock pulses for the CPU.
In order for the CPU to copy a byte of RAM somewhere, it will need to use an LDA command,
which is going to consume 4 clock cycles to read a byte.
You might wonder why. It’s just a single byte, why can’t it do it in just 1 clock cycle?
Well, if you break down the LDA instruction, you will see the first cycle is used to read the
op-code from RAM. Then the next two cycles are used to read the 16-bit value showing
where in RAM the CPU needs to read the byte from. And then the 4th and final cycle is used for the
CPU to go actually fetch the byte in question that it has been commanded to do in the first place.
So back to our copy process. Once you’ve grabbed the byte from RAM,
you’ll need to store it somewhere else. That’s another 5 clock cycles. And then you’ll need to
update a register that’s keeping track of this loop, another 2 clock cycles. And of course
you’ll need some kind of branch command to decide if the loop is finished yet, so
another 2 clock cycles. This example is one of the simplest loops you could create to copy a chunk
of data from one place to another, and it needs a minimum of 13 clock cycles to copy a single byte.
The REU. on the other hand, using it’s dedicated block copy function, can move that same byte in
a single clock cycle. So, in this example, it could move 13 bytes in the same amount of time
the CPU can do a single byte. This is somewhat similar to what the Blitter does in the Amiga,
which allows it to copy objects to the screen very quickly. Although the Amiga Blitter has
several advantages such as being able to use transparency bits and stuff like that.
During the original run of this product, there were no games I’m aware of that actually
supported it. There are a few now, which I’ll be showing you here in a little bit.
But let’s talk about some of the things these were actually used for back in the day.
The first thing I want to show you is the utility disk and the manuals.
Here’s the C64 version and the C128 version. There’s nothing terribly
interesting to you show you about the manuals, so let’s jump straight to the utility disk.
There are a number of different utilities on here, as well as some demos. I guess
the first thing we can do is run the diagnostic program, and good news.. my REU is working fine.
The next thing I’ll show you is the RAM disk. It works pretty much how you’d expect it to. You can
pick what device number to assign it to, we’ll go with 9. And then we’ll initialize the disk.
And basically, you get a giant empty disk as device 9. I’m not sure how useful this would be,
since it will lose its contents every time you power the computer off.
Next I’ll show you the spinning globe demo. So,
what you’re seeing here is 32 unique bitmap frames being copied to the screen using the DMA.
This was very impressive in 1985 due to the speed at which this runs.
Anyway, let’s talk about some other uses. One really handy use was with copy programs,
such as Maverick. This is one of the more popular copy programs of the time. And so, let’s say we
want to copy a disk and we only have a single drive. Notice down at the bottom is says RAM
expansion active. So with this, it will basically copy the entire source disk into the REU.
If you didn’t have an REU, you’d have to swap the disk several times to make a complete disk copy
because a disk could hold 170K, which was over twice the RAM of the computer itself. Even worse,
you have to keep some RAM for the software program itself. But with the REU, disk copying was much
faster. In fact, once it was finished, it would ask if you wanted to make another copy. If so,
you could make a second duplicate without even reading in the source disk again. So, very handy.
And of course, another use was with GEOS. The C128 was already a pretty capable machine for GEOS by
itself with its faster disk access, and 128K of RAM. But notice it detects my 512K RAM expansion,
and I can choose to use RAM reboot, which I’ll show in a minute,
and DMA for move data. This generally just enhances and speeds up GEOS on the 128.
As for the RAM boot. Watch this. I’ll hit the reset button on the side here, and you’ll notice
it can restart GEOS at pretty remarkable speed. Normally even the 128 takes a little while to get
to the desktop. While the REU does help the C128 run GEOS better, it some ways it has a far more
noticeable impact on the C64 since it barely had enough RAM to begin with to run GEOS.
Now let’s talk about some contemporary uses for the REU.
There are only 3 games that I”m aware of that make use of it. And the first one I want to mention is
Sam’s Journey. This is one of the… no, I take that back. This is THE most visually impressive
side-scrolling platform game for the C64. It was developed back in 2017. This game is really
interesting in how it uses the REU. So first and foremost, if you are using a PAL Commodore 64,
then you don’t need the REU at all. But you do need it for NTSC systems. Now, why is that?
Well, it has to do with speed. Ironically, the NTSC Commodore 64 is about 4 percent faster
than the PAL version. However, the problem is the game uses extensive CPU raster effects,
and the frame rate of a PAL system is slower. So while the NTSC system may be 4 percent faster,
it has 20 percent more frames to draw per second than the PAL system.
So the developers leaned on the DMA block copy capability within the REU to help speed
up the screen draw functions so that the game will work on an NTSC system. So, ironically,
even though this is a RAM expander, it wasn’t the extra RAM they needed.
The next game I want to show you is Sonic the Hedgehog for the C64. And if you are thinking
that no such game ever existed, well, you’ve been living in a cave for the last year or so.
This game wasn’t actually produced by Sega. It’s simply a home-brew developed game
developed by some very talented people in their spare time. Much like Super Mario Brothers was
also ported to the C64 a few years ago, although that one doesn’t require an REU to work. But Sonic
does require an REU. This game is an absolute masterpiece. And I think had there been more
games like this back in the day, there would have been a lot more demand for REUs. In fact, I
suspect the C64 could have really competed better with 16-bit systems had the REU been more common.
Anyway, I have one more game to show you, which is Petscii Robots for the REU. Now, I know I’ve shown
this before on my channel. But hey, I said there were only 3 games that supported it and this is
one of those. With Petscii Robots, we make use of both the extra RAM and the DMA copy.
The original game was very much restricted by available RAM, and that’s why for example the
intro screen is just text characters. But in the REU version we were able to give you a little
nicer bit-mapped graphics. Actually, the entire game runs in bit-mapped mode. Let’s have a look.
So this is the original character based game. And here’s how the REU version looks by comparison.
I know this isn’t nearly as impressive looking as the smooth scrolling Sonic the Hedgehog. But,
believe it or not, what you are seeing here could not be accomplished on the C64 for
two reasons. One has to do with lack of free RAM. I mean, sure, if we wanted to sacrifice the music
track and a number of other things, it might have been possible to get the graphics to fit.
But even if we had, the frame rate would have been unacceptably slow.
And thus the REU helps us solve both problems.
In fact, if you compare this version with the Amiga version, you’ll find the Amiga only looks
slightly better. And so I think that’s a real testament to what the REU can add for gaming.
So, what if you don’t have an REU, but you want to try some of these games out? Well, most all
Commodore 64 emulator support the REU. But you do have to select it in a menu and turn it on.
Also, there are some aftermarket alternatives to the REU such as one from CMD, and of course
modern cartridges like the 1541 Ultimate also offer REU emulation on real hardware.
I will also mention, that Sonic the Hedgehog is a free download for those that want to try it out.
And both Sam’s Journey and Petscii Robots have shareware versions that
you can download for free and try those out. I’ll put links in the descriptions.
So, there is one thing I could not find in my research. I couldn’t find the original price.
Google searches came up dry. So I resorted to reading through dozens of computer magazines
of the era. And when I’d find a price sheet of Commodore stuff, most ads didn’t even feature the
REU at all. And the ones that did, didn’t actually list the price and instead would just say “call”.
The one person I know that owned one of these back in the day can’t actually remember what he paid
for it. But, he did say it was pretty expensive and that’s not surprising especially considering
the cost of RAM back during that time and also the fact that the C64 version came with its own power
brick. But that would go a long way to explain why they weren’t more common. Anyway, I hope you
learned something interesting about the mysterious Commodore REU and I kind of think you might be
seeing some more games coming out that make use of this. They are considerably more available today
since there’s 3rd party at a pretty reasonable price and it raises the bar of what the Commodore
64 can accomplish. And yeah, so I definitely think you’re going to see some more games that
actually make use of the REU but that’s it for this episode. So, as always, thanks for watching!