So far in our exploration of Commodore history,
I’ve talked a lot about the different computers, but not so much about the disk drives. And to be honest, the disk drives were almost
as important as the computers themselves when it came down to how they were used, and they
also played an important role in why Commodore computers were never able to evolve in the
marketplace like the IBM PC for example. Commodore’s disk drives started back in
the days of the PET, with these large metal drives based on the IEEE-488 interface. Using some extra hardware, it was possible
to connect many computers to a single drive. For example, in this computer lab setup in
the year 1980, you can see multiple pets connected to a single disk drive. This design made a lot of since because the
computers didn’t really access the drive a lot, and therefor this could save a lot
of money and space. If you want to learn more about the PET drives,
I recommend you watch a video from 8-Bit Show and Tell on the topic, which I will put a
link to down in the description. And so, for the rest of this episode, I’m
going to be focusing on the disk drives used with Commodore’s home computers starting
with the Commodore 1540. So, the VIC-1540 was the first drive designed
specifically for the VIC-20 and it’s IEC serial interface. It was released in 1982, which was roughly
2 years after the VIC-20 had come to market. Meaning, that initially, VIC-20 users didn’t
have access to a disk drive. Although, a year earlier Commodore did start
selling a cartridge which would allow a VIC-20 to use a PET drive, but that was probably
not a common solution. That was okay, however, because the best software
for the VIC-20 tended to come on cartridge because these could hold up to 16K of ROM. Software that came on cassette or disk would
have to be loaded into RAM and the stock VIC-20 only had about 3K to spare. Granted, you could get memory expansions,
but as we discussed before, most software developers would prefer to target the stock
system as that was were the largest user base would be. The cassette drive was cheap, and with 3K
maximum file size, the speed wasn’t even much of an issue. As such, disk drives were a bit of a luxury
item for VIC-20 users and really only the hard core users bought them. However, the same year the VIC-1540 disk drive
came out, so did the Commodore 64, which also shared the same disk drive interface with
the VIC-20. However, the 1540 was not compatible with
the C64, and reason may surprise you. It was too fast. That’s right, and if you’ve followed the
series up to this point then you probably remember that Commodore drives were notoriously
slow compared to the rest of the industry due to a bug in the original VIC-20. Despite that, the drive was still too fast
to work on the C64 and the reason may surprise you. If you’ve ever watched a VIC-20 load a program
from cassette, it looks like this. Not much to really say, actually. But if you watch a Commodore 64 load a program
from cassette, you’ll notice the screen goes blank. Now the reason for this has to do with the
VIC-II video chip used in the C64. It shares every other cycle with the CPU,
much like the VIC-20 does. However, in the C64, it steals more than just
every other cycle. On certain scan lines, it steals even more
CPU cycles than usual. We typically call these bad lines. Looking at the clock speeds, you can see the
PAL C64 is definitely slower than the VIC-20, but the NTSC version looks a bit faster. However, what isn't really explained by these
numbers is the effect the badlines have. Since the CPU clock speed takes a dip every
8 scanlines, the C64 actually gets less work done than a VIC-20, what's worse because the
clock isn't running at a stable rate, it makes things like serial timing routines far more
difficult. In order to maintain compatibility with the
same cassette format, the C64 kernal will disable the video chip during loads, which
means the CPU can run at a constant speed. However, when loading from disk, they did
not implement the screen blanking feature. Which means, the only way to solve the problem
was to make the disk drive a little bit slower. And for this, the drive was changed to the
VIC-1541. The only real difference between the VIC-1540
and the VIC-1541 is the badge on the front and a slightly different ROM revision. Otherwise, these drives are identical. The 1540 was not manufactured for very long,
and therefor they are pretty rare and highly sought after by collectors. In fact, most of the ones that remain have
had their ROM chips upgraded so they’re actually 1541 drives that just happen to say
1540 on the front of them. The C64 was initially treated much the same
as the VIC-20, with the early games being on cartridge and cassette. However, it didn’t take long for the disk
drive to really take off, especially in North America. The situation with the C64 was exactly opposite
of that of the VIC-20. Cartridges still held 16K, but using a disk
you could load programs that could utilize all of the C64’s RAM. In fact, in many ways you could even go further
than that. A game could be much larger than 64K, and
thus only loading in the parts that it needed when the time came. Thus games on disk tended to have much more
complexity, better graphics, and better sound than games on cartridge. And so, it didn’t take long until Commodore
rebranded the disk drive again, this time matching the color to the C64, and removing
the VIC branding from the drive. However, all 3 of these drives are still essentially
the exact same plastic mold, same board inside, and except for the 1540, they even have the
same ROM. Although the 1541 was at times distributed
with different drive mechanisms, so this one for example has a lever to close the drive. Both styles are very common. As we’ve talked about before, the commodore
IEC interface is just a serial port. And while it is notorious for being slow,
it did have some significant advantages over competitors of the era. The inside of the disk drive had its own 6502
CPU, RAM, and ROM. And it contained its own DOS. Thus the computer never needed to know anything
about the physical media that was being used. All the computer did was request a file, and
the drive would deliver that file. This meant the computer didn’t need to allocate
any RAM area for any sort of DOS like an Apple or IBM PC would have needed to do. It also meant there was no need to disassemble
the computer and install a disk controller card like an Apple or IBM. And surprisingly, it also meant you could
in theory use a variety of media types, including hard drives, or different types of floppy
disks, without the computer really caring. The downsides to this design meant the drives
tended to be larger and more expensive than for other computers. This was especially true when accounting for
multiple drives on a single computer. These drives were also notorious for overheating,
especially when people blocked the top vents by laying things on top. That’s mostly because the drives also contained
internal power supplies that produced a lot of heat. Back in the 1980s, nearly every computer used
a different disk format that was incompatible with everyone else. Commodore was no exception. They used a format known as GCR. This means that for every 4 bits of data written
to the disk, actually 5 bits were written. This was done to prevent any situation where
more than two zero bits would occur in a row. A simple lookup table could be used to determine
which 4 bits needed to be written, or to translate them back when reading. And while this seems inefficient, it was actually
more efficient than many other systems of the time. Commodore also did a few other things different
from everyone else. For example, on a typical IBM formatted disk,
there are the same 9 sectors on the inner tracks as there are on the outer tracks because
the disk spins at a constant speed, and the read/write speed of the head also remains
the same. Commodore, on the other hand, used a system
were more data was written to the outer tracks than to the inner. So the inner tracks have 17 sectors and the
outer tracks have 21. This actually made more efficient use of the
disk space. Another interesting thing is that most computers
store the directory information starting at track zero, but Commodore drives stored it
at track 18. This was probably done to reduce seeking time
because the head would always be within 18 tracks of the directory track. The intended way to list a directory was to
actually load a file called dollar sign from that device number. This actually causes the disk drive to construct
a special BASIC program that you can list, which will show the contents of the drive. The main problem with this design is that
it will overwrite whatever program you have in RAM, so if you were in the middle of writing
a BASIC program, you couldn’t actually list the directory of a disk. Of course this wasn't a huge problem since
most Commodore users invested in some sort of fastload cartridge, and every one of them
added a feature where you could just type a short command to get the directory listing
without overwriting your BASIC program. Filenames could be 16 characters in length
and could be one of 5 file types. PRG files were program files and by far the
most common, SEQ were sequential files, or essentially text files. REL files are relative files, which are sort
of like primitive database files. USR and DEL files are pretty rare, and probably
not worth talking about here. Also you could store a maximum of 144 files
on a disk, which is a limitation of the directory, although that’s a barrier few people ever
encountered. Also, Commodore DOS is not hierarchal, meaning
there are no sub directories. And files are always displayed in the order
they are written to the disk, so there is no alphabetical order. If you list a directory and ever see an asterisk
next a file type, that is called a splat file. Essentially these are caused when a file is
opened for writing but the file is never closed. For example, if you pulled the disk out while
writing a file, or if there were a program crash or a power failure. One interesting fact about Commodore DOS is
how it handles the location of the head. Most disk drives used sensors to figure out
the head location. Apple disk drives eliminated the sensor to
reduce cost and instead just sent the head back 40 tracks every time the power was turned
on, usually causing the head banging sound. This ensured the head would be at track zero
before any disk access started. Well, Commodore drives also had no sensors,
yet they don’t bang their heads every time you power them on. So how does this magic happen? Well, one time you are certain to hear the
sound is when you format a disk. Then, as the disk is being formatted, the
track number is written to every single track on the disk. That way, even on a fresh power up, when you
go to read a disk for the first time, the drive will know exactly what track it is on
by just reading the header to the track. So, under normal operation, you won’t hear
any head banging. However, many copy protection schemes, as
well corrupted disks, could still cause the drive head to bang. And if this happened often enough, it could
cause the drive head to go out of alignment, in which case it would stop reading disks
properly, and therefor it would require service to realign the head. After formatting, listing a directory will
show 664 blocks free on a newly formatted disk. So how much is that? Well, a block is 256 bytes. So, 4 blocks is equal to 1K. And, the 1541 drive only had a single head,
which meant you could store about 170 Kilobytes per side. If you wanted to use the other side, you’d
have to flip the disk over and it would be treated like an entirely different disk. If the disk didn’t have a write protect
notch on both sides, you would need to punch one yourself and there were special tools
made just for doing that. In 1985, with the introduction of the Commodore
128, Commodore also introduced a new drive to match called the 1571. Besides having a very different visual appearance,
the 1571 also added many new features. It supported the C128’s “burst mode”
which meant it could finally transfer data at a really high speed. It also had 2 heads so that it could read
both sides of the disk without having to flip it over. Now, at first you might think that you could
take a disk from a 1541 that has data on both sides, and read both sides in the 1571. But, it doesn’t work that way. The problem is when you flip a disk over in
a 1541 the disk will be rotating in the opposite direction. And so, to use both sides of the disk, you
will have to format the disk in a 1571 as a double sided disk, and then that disk can
only be read in a 1571 from that point on. However, when formatted, a blank disk would
have 1,328 blocks free. So, twice what the 1541 had. However, being that most commercial software
wanted to target the 1541 for the widest compatibility, virtually no software was ever distributed
on disks formatted for both sides, even software that was designed for the Commodore 128, because
some 128 users were still using 1541 drives and never upgraded. Another benefit of the 1571 is that it had
a track one sensor. This almost completely eliminated the head
banging problem since it would always know when the head had made it back to track one,
so there was no reason to keep trying to move it. This helped over the long term with keeping
the heads in proper alignment. And yet one more benefit of the 1571 is that
the controller is more flexible and can read MFM formats as well as the Commodore GCR format. This allowed for compatibility with CP/M software. That meant when using with a Commodore 128,
it was possible to read disks from machines like the Kaypro, for example. However, this was also exploited to allow
the drive to read and write disks formatted for IBM PCs, or MS-DOS. It required a special program on the computer
side to be able to read the disks. And, just because you could read them doesn’t
mean you could execute programs or anything. But, this could be helpful for transferring
things like text files from one format to another. And while a minor detail, the 1571 also introduced
DIP switches to the back of the drive, so that you could easily change the device number
without taking the drive apart. And one last important benefit is that when
a 1571 is attached to a Commodore 64, or a Commodore 128 that is running in 64 mode,
the drive will also go into a 1541 emulation mode so that it will be compatible with any
software designed to work in a 1541. During the early days of the 1571, Commodore
was having trouble keeping up with demand in some regions. And so, as a stop gap measure, the 1570 was
born. It used the same case molds as a traditional
1541, but on the inside you can see the board is essentially a 1571 board being held in
place with some custom brackets. The drive mechanism itself is still a single-sided
drive with just one head, but it does have the faster burst mode for the C128 and also
includes a track one sensor. So, it’s very much a hybrid between a 1541
and a 1571. The 1570 drive is pretty rare these days as
it wasn’t made for very long. Interestingly enough, you can actually see
a 1570 on the floor in the movie Ready Player One. Of course, after Commodore switched to making
the 64C instead of the bread bin, they also changed the 1541’s color yet again, back
to a white or light beige color. They called this the 1541c, although there
are no actual markings on the drive referring to it as such. It is essentially identical to previous 1541
drives except for the color and the badging. However, shortly after they introduced the
1541-II. This has the same external design language
as the 1571, but as you can see it is quite a bit smaller. It’s also quite a bit lighter. And while functionally, it is identical to
the regular 1541, one major improvement is that the power supply was removed from inside
the case, to an external brick. This greatly improved the issues with heat
buildup inside, which made the drives considerably more reliable. And, it also does have dip switches for the
device number. The 1581 was introduced in 1987, well towards
the end of the 8-bit era. This drive uses 3 and a half inch, double
density disks. Because very little Commodore software would
ever be distributed on this format, the main benefit of this drive was that it had a lot
of storage on a single disk. A freshly formatted disk would have 3,160
blocks free. That was a colossal amount for a Commodore
machine, as that would be roughly five times what you could store on a 1541 disk. As such, these were popular with BBS operators,
often having more than one of these drives, giving their file transfer section a lot more
files to pick from. They were also popular with people who used
GEOS, especially GEOS 128. They could store a lot of data and they supported
burst mode so they were very fast. They could also read MS-DOS formatted disks,
just like the 1571. Again, they couldn’t read this format natively,
but with the use of a special transfer program on your computer. Despite not being directly supported by any
games and virtually no commercial software, they were very popular with hobbyists and
BBS operators and power users and therefor these are highly sought after today and they
do tend to fetch top dollar when they show up for sale. Also worth mentioning is the Commodore 1551
disk drive, which was made primarily for the Commodore 16, Plus/4, and other TED based
computers. While using a traditional 1541 case mold,
the 1551 gets rid of the serial port and plugs straight into the cartridge port of these
computers. This did solve the speed problem, of course,
as these drives were very fast. However, they do not work on the Commodore
64, or the 128, or VIC-20 because they do require the custom cartridge port of the plus/4
or the C16 or 116 or any of the other TED series that are out there. In fact, these drives are pretty rare because
even the TED machines had standard serial ports just like the 1541 and so those users
wound up using standard disk drives more often than not. So, these are actually pretty rare and fetch
top dollar when they do come up for sale. Up to this point every drive I’ve shown
you has been actually manufactured by Commodore. But, what you may not know is that there were
also numerous third party drives developed by other companies that were compatible with
Commodore’s ecosystem. So, each one of these 3rd party drives has
at least one or two interesting tidbits or things I want to tell you about. Let’s start with the MSD drive. This is actually one of the first drives. This thing’s actually really heavy too! Now, this is actually a dual drive. It has two drives in the front of it. They also made a single drive version of this,
which I do not have. The MSD SD-2 is an industrial looking drive
with a metal case on it. This particular one has been modded with toggle
switches to set the drive number, a practice I am not fond of, especially when placed right
on the front like this. There is also a drive reset button. There’s another toggle switch on the rear
that I am not even sure what purpose it serves. Then it has the regular two serial ports like
any Commodore drive, but also has an IEEE-488 port so that this drive can work with the
PET computers as well, which were still popular at the time of this drive’s release. In fact, it shares something else in common
with the PET drives, which is how it handles having two drives on the system. To demonstrate this, I will insert Planet
X2 into drive zero and then Ghostbusters into drive one. To get a directory from drive zero, you simply
add a zero after the dollar sign. And as you can see drive zero will fire up. And yep, there’s the directory for Planet
X2. And then to get the directory of drive 1,
you just type this, and again, drive one will fire up, and there’s your directory. Of course, to actually access a specific file,
you must place a zero or a one, followed by a colon, then the file name. Or in this case, I’m using an asterisk to
represent the first file on the disk. Now, the problem with this is, of course,
some software will have to load in additional files afterwords. If no drive number is specified, the drive
will usually assume drive zero. So, some software will fail to load correctly
from drive 1. The MSD drive was popular in the early days
for BBS operators, because they could store essentially twice the amount of data as a
single 1541 disk drive. They were also very popular at copy parties,
because they were designed to be able to copy from one drive to the other very quickly and
accurately. But, moving along, I want to talk now about
the Indus GT. The Indus GT has a very refined outward appearance,
as compared to the industrial look of the MSD drive. The front face is supposed to open by pushing
the button, but mine needs a bit of help. Of course, the cover doesn’t really do anything
other than just look cool. On the rear, it has the two Commodore serial
ports and then these mystery “auxiliary” ports, which nobody knows what are for. Even the manual says they are for future use,
whatever that means. Then there are dip switches for setting the
device number. Oh, and as you can see it uses an external
power supply. This is how the drive ended up being a good
bit smaller than the 1541 of the era, and probably helped keep it from overheating as
well. When powering up, you may notice it has a
little 2-digit screen here. This does a few different things. For example, it usually shows the track number,
so if I tell it to load the directory you will see it jump to track 18. Of course, there is no disk in the drive,
so I can show you the second use for it, which is displaying error codes. You can look these up in the manual, but over
time most people would remember the common error codes. This one means drive not ready. But, I think the most fascinating thing about
the Indus GT is its built in ROM drive. The way you access it is just like a dual
drive such as the MSD I just showed. So, if you load dollar sign one, like this. You’ll get a special directory of files
stored in the drive’s ROM that you can load. You can load the first one like this, which
stands for fast IO and DOS wedge. And so, what this does is essentially like
a fast load cartridge, it replaces the internal drive commands in the C64 with easier to use
features and faster loading routines. For example, you can use a slash to load a
regular file. And, in this case, since I still haven’t
put a disk in the drive, it will also display the error message on screen without even asking,
which is pretty neat. Although, you can also use the at symbol to
check the drive status as well. You can also get a directory reading like
this, without erasing your BASIC program. So, all pretty useful stuff. And you may be wondering what the Fast Copy
thing is on the drive. Well, as you can see, it’s a full disk copier. Not very fancy, but it works. I should also mention that there was an Atari
version of the Indus GT, which I believe was actually made first, and as you can see it
looks exactly the same in front, but on the rear it has the Atari SIO ports instead. So buying an Indus GT drive would be kind
of like buying a Commodore drive plus a fast load cartridge. Although, granted the fast load cartridge
would probably be a little bit more convenient because with the Indus GT you do have to type
a command every time you power on the system in order to get access to the fast load features. Now, before I talk about the next 3 drives
I need to talk about a little problem with making drives completely compatible with Commodore
computers. You see, the protocol used by Commodore’s
IEC disk drive port is pretty simple, and it wouldn’t be hard to build a 3rd party
device that would allow users to load and save files over that protocol. The problem is that the 1541 is itself a computer
and it is possible to upload code into the drive itself to change the behavior of the
drive. This is how all of the fast loaders work,
and it is also why you can run the drive music program, unplug the disk drive from the computer
and the drive will keep making music on its own. Its also how certain copy programs would allow
you to unplug the drives from the computer and the drives would continue to copy any
disks you insert into them on their own. However, this feature was also used by many
copy protection schemes. In fact, many games used entirely foreign,
non-standard disk formats. Only track 18 needed to remain compatible
with the Commodore format, just enough to load the directory and the first file. After that, the rest of the disk could be
an entirely foreign format, designed specifically for that game. After a few years on the market, practically
every piece of commercial software was completely dependent on the 1541 disk drive being exactly
how it was. If you changed any part of it, it would break
compatibility with hundreds or thousands of software titles. That includes the ROM code. So, while it would be easy enough to design
a disk drive that would be compatible enough for users to load and save their own programs
to disk, in order to be a commercially successful product, it would need to load commercial
games. This presented a problem for third party drives. They could copy the design of the motherboards
easily enough since they were mostly off the shelf parts. But the ROM code was the biggest barrier to
creating a fully compatible disk drive. Some companies, like the Excelerator Plus,
simply copied Commodore’s ROM code as is, and as you might expect, they were sued by
Commodore for it. So, they agreed not to use their own code,
but what they really did was take the original ROM code and swap around some of the bits,
which changes all of the values to look like nonsense if you were to read the chip in an
EPROM programmer. However, in order to make the chip still work,
they just swapped around the matching traces on the board so that it all ended up making
sense in the end. Of course, Commodore quickly figured this
out and sued again, eventually taking this drive off the market. It’s often discussed online that many of
these drives, if not all of them were targets of lawsuits by Commodore at one point or another,
but the truth is in my research, I was only able to find specific information about the
lawsuit against the Excellerator plus. So, while it’s very possible Commodore may
have sued the Enhancer 2000, or the Indus GT, or the MSD drive, I just don’t know
for sure. It wouldn’t surprise me, but I just can’t
find any information on it. The enhancer 2000 was a very common 3rd party
drive that seemed to be mostly 1541 compatible. There’s not a lot to really say about this
other than it’s the only 3rd party drive that matches the color scheme of the bread
bin C64 And the last drive I have here is the BlueChip
drive. They actually made several different models,
but this is one of the last models they made, and the thing that makes it unique is that
it is actually not a clone of the 1541, but rather it is a clone of the 1571. So this drive was targeted for Commodore 128
users, and it supports all of the features of the 1571. And there’s one very important 3rd party
drive, which I don’t have, so I’m going to let Robin from 8-Bit show and tell, tell
you all about it. Hi, it’s Robin from 8-Bit Show and Tell. I have here the Creative Micro Design FD-2000,
which is a 3 and a half inch high density drive. It’s much like Commodore’s 1581 but that
only accepts double density disks. This also works with high density disks. It formats the disk to 1.6 megabytes, which
is almost 10 times as much as a Commodore 1541 can store on one disk side. The FD-2000 is a little smaller than the 1581
in width and depth, and it has the same serial ports, allows configuration of up to 16 different
device numbers, and is powered by 9 volts DC. Using the included FD utilities program, you’re
able to partition the disk into several smaller 1541, 1571, or 1581 partitions, as well as
program the optional realtime clock. There is also an FD 4000 model available that
that used the rare ED disks and could store up to 3.2 megabytes, but I don’t have one
of those. But, I do have something even more rare, this
is a dual FD-2000. As far as I know, only 3 of these were ever
made. You could almost call it a prototype, but
it’s more of a custom build that was used for disk copying. You can see on the included disk, make master,
for use only with the FD copier, a custom version of the FD-2000. The case is kind of ugly. They took a regular FD-2000 and just added
this extra bracket on the bottom here. And on the back, it’s even open. This was used by Loadstar for duplicating
their monthly disk magazine. So, it made thousands and thousands of copies
very reliably for Loadstar. I’ll be doing a more in depth video about
this disk drive in a future video on my channel 8-bit show and tell, so please subscribe. Unlike 10 years earlier, by the late 1980s,
compatibility was a driving force in the computer industry. Nobody wanted to produce products or even
buy products that weren’t compatible in some way or another. And because the vast majority of games utilized
special disk formats and copy protection on the 1541 disks, that meant a 1541 or 100%
compatible disk drive was a requirement for owning and using a Commodore 64. Unlike IBM PCs, for example, which rarely
ever used this sort of copy protection. In fact, by this time, most IBM compatible
games were more or less expected to be copied or installed onto your hard drive for execution. But this simply wouldn’t be possible with
Commodore software because they were so heavily intertwined with the 1541 disk drive. And, while this initially made Commodore happy
because they were able to sue other manufacturers trying to create 100% compatible Commodore
drives, it also meant they sort of painted themselves into a corner because the Commodore
8-bit line would never be able to move beyond the 5 and a quarter inch floppy disk unlike
competitors like the IBM PC, for example. And, like I said, it’s probably not the
only reason for the decline of the Commodore 8-bit ecosystem, but it was certainly a contributing
factor.
