The USR filetype on the Commodore VC 1541 disk drive is a less common sequential file that according to some book sources can be executed as a program directly on the drive. The drive has its own 6502 processor and 2K of RAM. While there exist a high number of program examples and demos for the C64, I could not find a single listing of a USR program. Would it theoretically be possible to provide a number of disk-executed commands as USR files, that for example to reverse a file on disk, compress a file, etc.?

The 2K RAM with even less available is meagre, but could a program theoretically use disk space as external memory? Running locally at the drive a program could benefit from the native floppy speed, avoiding the serial protocol bottleneck.

I know of C64 programs using a VC 1541 as a co-processor for fractal or 3D computations. I'm also aware of the programs that play music using the stepper motor, but as far as I remember those programs copied the code from the C64 over the serial program into the floppy memory.

I would be interested, however, in the USR programs. Does there exist a list of meaningful USR programs or a tutorial on how to program them?

5 Answers 5


It seems as if the question mixes up the user-commands (Un) provided by DOS for loadable routines with the USR file type.

The USR file type has operations of it's own that can be performed thereon. For all purpose it's simply a sequential file. The only use of USR is to mark files that are not of any of the standard types.

The user-commands are blank (*1) entry points that can be used to hook and call programs loaded into the DOS RAM - for example by Memory-Write (M-W).

  • 1
    What caught my attention was this line in VC 1541 Wiki article: "A user-specified file has an internal structure that is identical to that of a sequential file. Commodore's original purpose for this file type was the facilitation of DOS development, as the file content could be copied into a drive buffer for execution by the drive's microprocessor. Very few programs ever made use of this file type.", especially the part on "copied into a drive buffer for execution by the drive's microprocessor". But I'm getting more and more the impression that this feature was never implemented or used.
    – Peter B.
    Oct 3, 2020 at 20:25
  • Or, as so often with various wikis, just the imagination of its writer. People often find connections where there are none.
    – Raffzahn
    Oct 4, 2020 at 11:02

I'm not sure about USR programs; but I think you can issue a Block-Execute (B-E) command to the 1541 with a Track/Sector to load and execute a program directly from disk.

I have a copy of Inside Commodore DOS on my shelf, and it dedicates chapters 5 and 6 to direct access programming of the 1541, although the example are done from BASIC - they might prove insightful.

It also vaguely mentions USR files with this cryptic text:

A user file may have the structure of either a sequential file or a program file if it was created by the DOS. It may be structured entirely differently if it was created using direct-access techniques described in Chapter 5.

But I didn't see anything jump out at me about creating a USR file and loading/executing it directly on the 1541. I also trolled through a few other books (PDF's) I have on programming for DOS and they have even less to say on the matter.

To engage in wild speculation: Maybe you can author your ML to disk as a USR file, then use the Block-Execute to load/execute the file - and from there let the code running on the 1541 continue to use Block-Read/Memory-Execute to chain further logic that didn't initially fit into memory?

  • It would have been useful to have a file type which behaves like a cross between a normal file and a relative file, treating each sector as a list of 127 sectors which the "V" command should treat as "used". Such a meaning would fit with the documented purpose. As it is, one could use the type for random-access files intended for use with block-read/block-write operations, but the directory entry would be useless unless the first two bytes of each sector formed a chain linking all of the sectors.
    – supercat
    Nov 26, 2023 at 21:04

From the DOS point of view USR files are mostly like PRG and SEQ files.

There are conventions with PRG and SEQ files, namely that PRG files have a two byte load address as the first to bytes and that SEQ files don't.

The convention with USR files is a bit more wild: The file uses a whole different structure which is not understood by the DOS, so for instance the VALIDATE command might corrupt the disk. The example for treating discs with USR files with caution was set by GEOS which uses this file type for its VLIR format files.

And then there is a special treatment by the DOS if the file name starts with a & and it follows a special structure. From a commented C1541 ROM listing:

Utility loader program

This utility is used to load and execute user proarams or system utilities from disk. This utility may be used in two ways:

a) On power-up: If the data and clock lines are grounded at power up, the routine is entered. It waits until the ground clip is removed and then loads the first file found in the directory into disk RAM using the first two bytes of the file as the load address. Once the file is loaded, it is executed starting at the first byte. b) Normal entry: The disk command "&: filename" will load and execute the file whose filename is specified. For examole: PRINT#15,"&0:DISK TASK"

File structure:

The utility or program must be of the following form.

File type: USR
Bytes 1/2: Load address in disk RAM (lo/hi).
Byte 3: Lo byte of the length of the routine
Bytes 4/N: Disk routine machine code.
Byte N+1: Checksum. Note that the checksum includes all bytes including the load address.

The only use I've see for USR commands is an anti-piracy system. The program downloaded sets a delay when writing a particular track. If that track is read normally, the red light starts flashing because it is corrupted. If this USR command is used, it reads normally. So if someone pirated a disk, on startup, after the program downloads the USR command, it can't read the disk.

It is quite easy to break the security to see what it is trying to do. The only problem is you need to get a memory map of the 1541 ROM. It can be dumped out - takes a while to work out what it is doing.

There is some code and memory map in the 1570/71 manual if you're looking for things to do with it.


In the view of the 1541 DOS, there is really no difference between files of type SEQ, PRG, and USR. (DEL files have a few minor semantic differences, and REL files are treated as a whole other beast by the 1541 DOS). They are all just files containing a series of sequential bytes. The only differentiation DOS makes for these file types is that when opening a file on drive channels 0 or 1 (the binary LOAD and binary SAVE channels, respectively), the file type - if not specified - defaults to PRG. When opening a file on the drive's normal data channels (channels 2 through 14), the file type - if not specified - defaults to the actual file type (if opening an existing file), or SEQ (if creating a new file).

By convention, the first two bytes of a PRG file are a 16-bit pointer to the suggested load location in C64 memory, whereas SEQ files are not expected to contain such a pointer. By contrast, there is no convention about the format of the data in a USR file.

What's more - the convention I speak of is in no way recognized or enforced by the 1541 DOS, the C64 KERNAL, or CBM BASIC.

So to answer the question - you can do the exact same things with a USR file that you can do with a PRG, SEQ, (and in almost all cases DEL) file. No more. No less.

  • 1
    When looking at GEOS there is a convention about the format/use of USR files.
    – BlackJack
    Nov 26, 2023 at 23:08
  • @BlackJack Well, okay... Third party software can of course apply any conventions it wants. I thought my answer pretty was pretty clearly in the context of the standard Commodore software as supplied in the 1541 drive and the C64 itself.
    – ge97aa
    Nov 27, 2023 at 21:15
  • @BlackJack In response to your answer above (I don't have the rep to comment directly), there are errors in the source you quoted: 1) The file doesn't need to be a USR file. Any file type is permitted. 2) The "power-up" version was removed from all but the earliest 1541 drives. 3) For the non-power-up version, the parser seems buggy. The sample line: PRINT#15,"&0:DISK TASK" will not work for a file named "DISK TASK". For this example to work, the actual filename on disk needs to be "&0:DISK TASK" (with the leading "&0:"). It seems that this entire feature was never properly supported.
    – ge97aa
    Nov 27, 2023 at 21:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .