In Part I of this series, I covered some of the basic functionality of the Commodore 64 and my trials and tribulations in getting mine to work properly. In Part 2 I will talk disk drives and disk images.
Before I can talk about the Ultimate-1541, I need to discuss the Commodore 1541 Disk Drive and how the C64 deals with floppy disks, the other major storage medium for NTSC C64 users. The Commodore 1541 Disk Drive is an external 5.25" floppy disk drive which connects to the C64 via the 6-pin serial port. The 1541 had its own power supply and its own 6502 CPU, 16KB of ROM and 2KB of RAM, it was essentially a computer of its own. The disks used were standard double density disks, but the drive was a single sided drive like the drives for the contemporary Apple and Atari home computers. The IBM PC used single sided drives for the first year of its existence. Like the Atari drives, you turn on your drive first, then the computer.
The disks were encoded with Commodore's custom GCR encoding, similar to Apple's GCR but quite incompatible MFM encoding used by the IBM PC. In the 1541 each side of the disk had to be formatted independently. C64 disks had 35 tracks, just like Apple II disks, and used a 256-byte sector size, but there the similarities end. Apple and IBM formatted their disks so that each track held an equal amount of data, even though the there is a lot more surface area on the outer tracks of a disk than there is on the inner tracks. Commodore decided to write more sectors ("blocks') to the outer tracks compared to the inner tracks. So for tracks 1-17, each track held 20 blocks, tracks 18-24 had 19, 25-30 had 17 and 31-35 had 16. As you can guess, track 1 is the track by the outer edge of the disk and track 35 is by the inner hole of the disk. By contrast, Apple used 16 sectors for all 35 tracks. This is a form of variable density encoding which would become standard with hard drives by the end of the decade, which was very forward thinking of Commodore.,
In a final touch of efficiency, the directory and disk structure is stored on track 18, right in the center of tie disk. This meant that in order to access any particular file, the disk drive head need only transverse half the radius of the disk. MS-DOS stored the Master Boot Record, FAT copies and root directory entries starting with track 1. In the 1541, Commodore called Track 18 the directory, which can be a little confusing for MS-DOS users.
In total, a Commodore-formatted disk could hold 683 blocks or 174,848 bytes. However, the file structure takes up some space, so you have 664 blocks or from 168,656-167,132 bytes available for user storage. Each disk can store up to 144 separate files.
Like the Apple, the 1541's DOS gives different designations to different files. The most common type is the Program file, or PRG. There are also User (USR), Deleted (DEL), Sequential (SEQ) and Relative (REL) files. PRG files are the only kind of file that can be LOADed, so they are the most important.
The 1541 can share the serial bus with other devices. Physically, these devices are daisy chained together similar to the Atari 8-bit computers. Typically the serial bus was shared with printers. The C64's internal ROM addressed devices logically by number. Device numbers 0-3 were reserved for specific devices, the keyboard, the datasette, an RS-232 interface and the text screen. Device numbers 4-7 were reserved for printers and plotters. Device numbers 8-30 were intended for disk drives. Printers and disk drives used a customized serial version of the IEEE-488 interface. This allowed the cables to be thin 6-pin cables.
The 1541 uses a version of CBM-DOS, namely 2.6, contained on its internal ROM chip. In order to load a non-cartridge program on the C64, you have to LOAD the program and sometimes RUN the program. If you type LOAD at the BASIC prompt, BASIC will prompt you to "PRESS PLAY ON TAPE." In other words, the default device for the LOAD program is the datasette. In order to LOAD a program off a floppy disk, you must tell the LOAD command what file you are trying to load and which device you are trying to load it from. Unlike virtually every other home computer, the C64 did not autoboot its disks. Here we get to the famous command :
This command consists of four parts. The first is self-explanatory, LOAD is the command. The second part indicates the filename of the program to be loaded. "*" is shorthand for "the first program on the disk" The third part of the command, ,8, gives the BASIC device number for the first disk drive. The final part of the command, ,1, tells BASIC that the program will load itself in the memory location contained within the program.
The command was about as easy as it gets for CBM-DOS, and eventually almost everyone used it as a convention. Unlike MS-DOS or Apple DOS 3.3, Commodore DOS used some rather cryptic commands to perform basic file operations. Apple DOS 3.x, added commands like CATALOG, DELETE, RENAME to the BASIC prompt. CBM-DOS is not nearly so refined. For example, to list the contents of a disk, at the MS-DOS command prompt, you would simply type DIR. At a BASIC prompt having loaded Apple DOS 3.3, you typed CATALOG. In Commodore DOS, you typed LOAD"$",8. Not nearly as easy to remember as IBM and Apple's mnemonics, but other commands made this one look simple. Then you had to type LIST to see the directory contents. When you get the LIST, it will start with the Disk Name (Label) then list every file with how many blocks it takes to store it, the file name and the file type, similar to an Apple II directory listing.
Some games do not load themselves with the de-facto LOADing command. If a program will not load with the standard command, you may have to start hunting down for the C64-specific version of the program's manual or reference guide. Here are some good links :
As an example of a non-standard loader, if you want to load Ultima 2, (Sierra Online version), you must type LOAD"ULT",8,1. Ultima 3 and 4 are LOAD"*",8 then type in RUN. Note the lack of the ,1 for Ultima 3 and 4. Other games, like those from EA, tell you to use EA in the quotation marks, but as the EA file seems to be the only file that appears on the disk, then the * works just as well. But sometimes you may need to use the LOAD/LIST command to figure out how to load a game.
Most C64 games were copy protected. Copy protection on the C64 is a subject which could lend itself to a series of articles, but it is virtually ever-present. There were a few games toward the end of the C64's lifespan which used document based copy protection, but most games used disk based protection. C64 disk copy protection schemes had a whole computer of their own in the 1541 to play with the disk and obfuscate its code. Fortunately for us today, the C64 was extremely popular, so the hacking and pirating community could crack just about any game. Disk images of games would be distributed by BBS services. Later those images found their way onto the Internet.
The standard dumping format for C64 disks uses the .D64 extension. There is nothing special about this type of dump, it is just a standard sector dump like a DOS .IMA/.IMG file or an Apple II .DSK file. The file size should be 174,848 bytes. You will find that most games with .D64 images are cracks. Many of the games come with Cracker Intros, short audio/visual displays that appear before the game begins proper. These Intros serve to identify the hacker/hacking group involved and to give a shout out, or greets, to other groups. These Intros may have animation and their own music. Many games also come with a trainer, which is a cheat menu.
Despite their widespread availability, cracks can be annoying. Sometimes the images are bad, but other times the crack is broken or does not completely crack the game. Some games run their protection scheme at more than one point during the game. So if a cracker missed something, then you could get halfway into the game before it fails or ratchets up the difficulty level to near impossible. Finally, cracks pull away from the pure experience of running a game out of the box.
.D64 cannot capture enough information for the more sophisticated methods of copy protection to work. The ideal dumping format for the C64 is the .G64 format. The .G64 format is not a straight disk dump, it stores the low level formatting information like sync and gap bytes, that allow copy protection schemes to work properly. Today most of these dumps come from a Kyroflux device, which was made by Commodore enthusiasts. The C64 Preservation Project, http://c64preservation.com/, has essentially preserved virtually every major US game in its pristine state.
Finding proper .G64 images can be more of a challenge. In the past few years there have been nib images made available for C64 software. Unlike Apple II nib images, C64 nib images cannot be run directly by emulators or written back to disks via a Kyroflux. They must be converted to .G64 format, and the conversion tools do not always make a working image. The WinVICE emulator has superb disk emulation, so a good rule of thumb is that if the image doesn't work with WinVICE, don't expect it to work with real hardware.
Commodore released other disk drives which were compatible with the C64. The 1541-C and 1541-II were bugfixed and more reliable versions of the 1541. The 1570 was a faster replacement intended for the C128 which supported faster transfer modes and MFM-formatted floppies. The 1571 was a double-sided verison of the 1570 with improved 1541 compatibility. Even the VIC-20's 1540 disk drive could be made compatible with a C64 with a firmware replacement. The 3.5" 1581 drive is also C64 compatible but few if any games were released on the 3.5" format.
In this overview of C64 disks, one cannot avoid discussing fastloaders. CBM-DOS, as found on the 1541, could transfer about 300 bytes per second over the C64's serial bus. This gave the C64 the unwelcome reputation as possessing the slowest disk drive transfer speeds of any major home computer. Ultima 3's Quick Reference Card informed the user that the game would take four minutes to load, and that was not atypical for the early years.
Within a few years of the C64's release, fast loaders were present. A game could use its own loading routines as a replacement for the slow DOS routines to speed up transfers. Cartridges like the Epyx Fast Loader, the Action Replay or the Final Cartridge III were released that could increase loading speeds by a factor of five to six and a half. Finally, the user could install a CBM-DOS replacement like JiffyDOS in their 1541 and their C64 for speed transfers up to fifteen times faster than the stock ROMs. JiffyDOS does require removing two ROM chips and replacing them with EPROMs, so it is not a solution for everyone.
The basic Fast Loader was the Epyx cartridge. This simple cartridge does not have any fancy switches on it, but it sold amazingly well. They are easy to find these days. The Epyx is not as fast as some of the later cartridges, but it tends to work very well with real disks. It is very unobtrusive, all you will see differently when you run the cartridge is the word FASTLOAD underneath the BASIC READY line. Moreover, the cartridge can make life much easier when it comes to DOS commands. By pressing C= and Run/Stop, you will have a shorthand way of executing LOAD"*",8,1. You can list the contents of a disk by just pressing $. You can use the £ key to bring up a menu of disk commands. You can use this menu to copy files, delete files, format disks or duplicate non-copy protected disks. You can also disable the cartridge if a program is not working with it. It also includes an assembly monitor very similar to that in the Apple II. Other Fast Loader cartridges have similar functionality, so when it comes to working with disks, these cartridges are really essential.
In Part 3 I will finally get to the Ultimate 1541-II Flash Cart!