Discussing modern storage solutions for the 64 and other 8bit Commodore machines can at times look like discussing iOS versus Android, which is somewhat funny because while one phone won't run both systems, one 64 can use all the popular alternative storage solutions at the same time with little issue, and there may even be a point to using more than one alternative.

The non-competing competing solutions we'll be discussing

• sd2iec
• Pi1541
• 1541 Ultimate 2(+)

All 3 devices are capable of using D64 floppy images, and let your 8bit Commodore access those as if it is a floppy, so why not simply get the cheapest device and be done with it? To understand why we need to delve into the (pre)history of especially the Commodore 64 and 1541 floppy drive.

Some history

This isn't a comprehensive history of Commodore storage solutions, or Commodore in general, it will just touch on some of the things relevant to understanding the current storage situation and why it is more complex than for many other contemporary systems.

The first generation, the PET era

Commodore needed an add-on floppy drive option for their PET line of computers, but had a bit of a problem with this. The PET computers do not have internal expansion slots, and did not have rom space available to add much in the way of a disk operating system. To address this, Commodore used the relatively easy to add IEEE-488 interface to connect the (external) floppy drive, and moved all the controller logic and disk operating system to the floppy drive itself, which meant this external floppy drive needed a cpu and memory for running that disk operating system. In fact, Commodore used 2 (!) 6502 CPUs in their first generation drives, which gave them more computing power than the actual computers they connected to, or better said, turned those into a fairly powerful cpu wise (for the time) but memory constrained computers in their own right.

As those drives have their own memory to which you can upload data, and understand commands that make it call machine code at any location it can address, it is possible to run custom code on those floppy drives. Also, they could perform many tasks that didn't involve sending data to, or receiving data from the computer without needing any help from that computer beyond the initial instruction to perform the task. For example, a dual floppy drive device can do a disk to disk copy on its own, without the computer having to do anything beyond telling it to copy from drive 0 to drive 1 or the other way around.

The second generation, the VIC/C64 era

With the introduction of the VIC 20, Commodore needed a cheaper floppy drive and a cheaper way to connect it to the Computer (IEEE-488 uses extremely robust and expensive cables and connectors). The connection issue was solved by using the serial IEC bus instead of the parallel IEEE-488 bus. This meant cheaper cables (less wires) and cheaper, fairly common connectors. The floppy drive was made cheaper by only having one CPU (and a bunch of other things which are less relevant to our story). An interesting implementation detail is that its DOS code is closely related to that of the older dual cpu designs, with the one remaining CPU switching between the tasks originally performed by those 2 CPUs. This explains some of the at first glance somewhat odd implementation of the DOS in this generation of floppy drives.

The first device of this newer generation is the 1540, which was designed for the VIC 20. While this drive is now relatively rare, especially in its original (VIC 20 only) setup, it and the VIC 20 have a legacy we are still encountering today with modern storage solutions connected to the IEC bus.

In order to partially make up for the loss of bandwidth (due to going from an 8 bit parallel to a 1 bit serial means of communication), Commodore thought to use the MOS 6522 VIA, which has a hardware shift register for sending and receiving serial data efficiently. This shift register turned out to be buggy, which was discovered too late to change the hardware, so a workaround was created by slowing down the serial bus and not using the shift register at all. Somewhat later when the 64 was introduced, Commodore found out the 64 still could not keep up with the bus due to so called 'stolen cycles', once every 8 display lines, the VIC II video chip steals some time from the CPU to read color data. This resulted in a rom update for the 1540 to make it compatible with the C64, and in further slowing down the serial bus. We still encounter this legacy today when not using some fastload cartridge or rom.

The 1541 is an evolutionary development of the 1540, and retains the 6522 VIA chip, and the slow serial bus implementation, with the patches to deal with the timing issues for the 64. Both the 1540 and 1541 retain the ability to upload code to their memory and support commands to execute code of the choice of the programmer, and soon people figured out the 64 (and VIC 20) kernal code for talking to the IEC bus was quite inefficient, and needlessly slowed things down, and soon the first 'fastloaders' appeared, in the shape of a small program you'd load first, as integrated part of larger programs and games, as a cartridge, or as alternative ROMs for computer and floppy drive. Most of those make use of the ability to upload code to the drive and execute it, to make the drive communicate at a higher bitrate, typically changing the protocol on the bus, at times using signal wires as extra data bits. Only solutions that replaced the drive ROMs did not depend on uploading code to the drive, as such code was already part of the replacement ROMs.

After a while, people also figured out a way to create a parallel connection between the 64 and 1541, eliminating almost all of the IEC serial bus 'trouble' by bypassing it entirely for data transfers. While technically interesting, this is outside the scope of this article as none of the modern storage options discussed support this.

Some of those fastloaders became quite popular, and while many have fallen out of use over the years, a number of them are still relevant today, most prominently, the Action Replay (and its many variations), The Final Cartridge III, The Epyx Fastload cartridge, and JiffyDOS.

All those are 'generic' fastloaders in the sense that they are active at boot, and speed up the loading and saving of files (and in case of JiffyDOS, every disk access). Besides those generic fastloaders quite a few games used their own specialized fastloaders, often as part of a copy protection scheme. Usually those are rather custom, but they still use the same feature of the floppy drive, upload code and run it, or alternatively, to have the drive read code directly from a floppy disk and execute it internally.

Often the code running on the drive is not the most straightforward implementation of things, due to considerations of very very limited memory, and also in the cases that involve copy protection, obfusication. This resulted among other things in calls to locations in the middle of rom functions, counting on specific values being in certain locations without ensuring they were actually there, use of undocumented cpu instructions, self modifying code, depending on the exact timing of specific mechanical events and well, almost everything you shouldn't do if you want to write easy to understand code :-)

Running such code on an emulated floppy drive requires perfect emulation of the hardware including all timing oddities and undocumented behavior, and a copy of the Commodore DOS ROMs. As such code is commonly used for games and modern trackmos (track loading demos filling one or more disks), this level of compatibility can be very important.

Second generation try 2.5 and 3 (and 3.1), the 157x

With the 157x models, Commodore finally fixed the IEC slowness issue by adding a 6526 to the floppy drive, which gives it a working shift register. They also used one of the assigned but so far unused IEC lines for a new fast mode, seriously improved the IEC interface on the floppy drive side in general, and fixed many of the bugs in the 1541 code, through initially leaving one of the most prominent ones unfixed.

As the 157x DOS ROM introduced a lot of changes, too much to fit in the patch area, some of the more nasty custom (fast)loaders initially didn't work with those drives, but in many of the prominent cases that was fixed, and the resulting code is often far less nasty in how it makes calls to DOS code, through still requires perfect hardware emulation to run on an emulated device.

Ah, that prominent bug that wasn't fixed initially, saving files with the replace option (@filename). This was finally fixed properly with the 3.1 DOS update that is only available with the metal case Commodore 128D internal 1571 drive.

Generation 3, the 1581

The 1581 is a 3.5" floppy drive, that still follows the 'computer in its own right' concept, but received many improvements in its implementation of DOS, and support for 2 important features: directories and partitions. This drive is relatively rare today, but the image format for representing floppies for it (D81) is fairly popular because of its around 800kb capacity (enough for a fairly complete GEOS install and many multi disk games). It contributed the partition scheme to some non Commodore mass storage solutions and alternative floppy drives, most notably the CMD harddisk.

Code counting on the implementation specifics of 1581 drives is relatively uncommon, and hence full emulation is often less of a concern when using a modern storage solution with D81 image support.

A bit of an oddball device in this all is the SFD-1001, it is technically a double sided, quadrupple density (as it was called at the time) single floppy drive with an IEEE-488 interface and dual 6502 CPUs, and hence a first generation device. Its DOS is however newer than the 1541 one, and it comes in a case that makes it part of the 64 peripheral lineup, unlike its 8250 double floppy drive sibbling, which was part of the PET and CBM II business computer lineup. It provides a whopping 1 megabyte of storage (which is a lot for a 64kb computer), but without the later advancements in DOS that are present in the 1581.

The CMD harddisk

while relatively rare, the CMD harddisk is a relevant device still today because it contributed extensions to DOS that are commonly supported by modern disk and file management utilities and filesystem browsers, most notably the CD command.

Back to the modern storage devices, usage considerations

The 3 modern storage solutions we consider come at 3 rather different price points, but which one is best is not directly related to those prices, rather, the intended use case is the most important factor, followed by what extra hardware you will need.

Mass storage versus floppy emulation

Mass storage devices (strictly speaking, the CMD harddisk, the modern sd2iec, and to a limited extend the Pi1541, but often the SFD-1001 and 1581 are also included due to their capacity) are especially useful when running things like BBS software, productivity software, GEOS, but can also work very well for many classic games that consist of a single file, or use the kernal routines to load additional files. Additionally those devices are very useful when using an 8bit computer for software development and working with large files. For this kind of use, the modern sd2iec is currently by far the best option, and also the cheapest. That said, you do want to install JiffyDOS for all those mass storage devices, except for the SFD-1001 as it does not use the IEC bus at all. The sd2iec and the CMD harddisk are both natively compatible with JiffyDOS and do not need alternative ROMs, but you still need an alternative ROM for your computer, those are still commercially available for all Commodore computers with an IEC bus. JiffyDOS currently does not provide any advantage for the Pi1541 when using it as a mass storage device, but it does when using that device as a floppy emulator.

None of those mass storage devices with the exception of the Pi1541 provides anything close to perfect compatibility with the 2nd generation of floppy drives, and in case of the sd2iec, it is not possible to upload and execute code on it at all. The good news however is that most of the software that would benefit a lot from the use of such devices does not depend on this. GEOS is somewhat of an exception but an update exists to support the 1581 and CMD harddisks, and the sd2iec can emulate the code it tries to upload well enough to allow GEOS to run from one.

The SFD-1001 is again a bit of an odd case, as it simply won't work with most more modern software, is incompatible with (but also doesn't need) jiffydos and any popular fastloader (but doesn't need those either) yet from all the 'mass storage' devices, its DOS is most closely related to the 1541 DOS.

It should be noted that while the Pi1541 does support the defacto standard CMD DOS extension for directories, and 1581 style partitions, and also emulates a 1581 drive, especially the first one is still quite in development, and that and the lack of JiffyDOS support for this mode of operation make it less suitable as a mass storage device for now.

The 1541 Ultimate II+ can also act as mass storage device, however it does not support the CMD DOS extensions for directories, instead requiring the use of an API to access its storage directly. This approach provides technical advantages, such as using DMA to load files into memory as fast as you can write data to memory (so at approx 1mb/second), but there is very little software supporting this, and especially none of the currently popular disk/file browser and management utilities support this, so for now this is not really usable unless you are developing software for using that API.

If you want to have a trouble free solution that will work with pretty much every bit of software that supports a 1541 drive, you should by now have gathered you will need a device that provides perfect emulation of all the mechanics and electronics, and the entire computer that make up a real 1541. This means that for this requirement the sd2iec is out, it cannot run custom code, and hence none of the custom loaders will work with it. It should be noted the sd2iec does support the most important generic fastloaders, and is especially geared towards being used with JiffyDOS, but with the exception of some very specific bits of software (GEOS), it doesn't support custom loaders at all.

That leaves us with the other 2 options, the Pi1541 and the 1541 Ultimate II+. Which of those 2 provides the best option really depends a lot on what other hardware you already have, and what other hardware you also need. The following features and devices are relevant to this:

• Tape drive alternative (do you even need one? if so, do you already have something like a tapuino or such?)
• Cartridge image support (do you want this at all? If so, do you already have an easyflash or such?)
• Do you already own a fastload cartridge or JiffyDOS ROM for your system?
• Do you need a ram expansion unit, and if so do you already have one?
• Do you want or already have a network solution for your 8bit Commodore?

And of course... what 8bit Commodore do you have to begin with!

Compatibility with various 8bit Commodore computers

The modern storage alternatives under discussion all support the IEC bus, and can all be used with every Commodore computer with an IEC bus, and also with some non Commodore machines that support Commodore's IEC bus. However, the 1541 Ultimate II+ is a lot more than just a floppy (and tape) drive emulator, but most of those additional features can only be used with installing it in a cartridge slot of a 64 or 128. When used with a VIC 20 or one of the TED machines (C16, Plus/4), it requires external power (simply USB charger will do). Additionally, connecting it to your wired network is highly desirable as this allows you to telnet to the device for configuration and attaching floppy images.

The Pi1541 and the sd2iec both work equally well with any IEC bus equipped machine.

For all the 'how are you going to use it' questions, if you don't need those features or already have alternatives for those, the Pi1541 is the device to look at for a floppy emulator. If you do not have at least a fastload cartridge or JiffyDOS, you should count on having to buy this for the Pi1541 (or sd2iec). The 1541 Ultimate however comes with images for all the popular fastload cartridges, and hence you do not have to buy one of those. For the remaining features, if you desire those but don't have something that provides those features, the 1541 Ultimate II+ provides all of them, and hence it mostly is a matter of cost. All those extras when bought as separate devices will end up costing a fair bit more than a 1541 Ultimate, but not everyone needs or even wants all of them. This really is something you can only determine for yourself based on how you are going to use the device.

Other modern storage solutions

There exist a few alternatives for the storage solutions discussed in this article, most of those are functionally similar to the Pi1541, and may provide attractive alternatives to that device.

Combining different modern storage solutions

It can be desirable to both have the very good 1541 emulation provided by the 1541 Ultimate and Pi1541 devices, and the very good mass storage support and CMD hdd compatibility of the sd2iec. It is possible to use those devices at the same time, connected to the same machine, provided all have their own device ID. You can even use all 3 at the same time, and add a 4th one if you so desire.

I use a 1541 Ultimate II+ with my C64, and both an sd2iec and 1541 Ultimate II+ with my C128. The 64 is mostly used for gaming and running demos. I do those things with my 128 as well, but also use that machine for development, IRC, accessing telnet BBSes, running GEOS and such, and especially development and GEOS make a mass storage solution very desirable (eliminate the 170kb storage per floppy limit). For running demos, and for networking and the REU, I also need the 1541 Ultimate II+ on this machine. Connecting both devices to the IEC bus requires a so called Y cable, an IEC cable with one male connector and 2 female connectore (or alternatively, 2 male and 1 female connector). This lets you split the IEC bus (electrically this is absolutely no problem, and is exactly how the 2 IEC connectors on a 'real' 1541 work. Beyond the cable and ensuring no device ID conflicts, no special equipment or configuration is needed to make this work.

Conclusion

The sd2iec, Pi1541 and 1541 Ultimate II+ are all very good devices but also somewhat different devices. For the typical user looking to use a 64 for playing some games, the 1541 Ultimate II+ is the ultimate solution, but one with a fairly high price tag. However, considering one often also wants a tape device and most certainly wants a fastload cartridge, and the U2+ includes both, while you'll have to buy extra hardware for this when using a Pi1541, the price difference ends up a lot smaller.

For those mostly interested in running a 'retro BBS', productivity software, GEOS or doing development, the sd2iec is a very desirable, and very affordable solution, but you may find yourself wanting an U2+ as well as an sd2iec. Obviously, if you can deal with the limitations of the sd2iec as a floppy drive emulator, it is a cost wise very attractive device also for running games.

---