Here are some questions I was asked many times and my answers to them. I'd like to mention that the Commander was not meant to be a multi-purpose utility with lots of goodies; that the main executable file is already too big and it eats up a lot of memory; and that I simply have no time to implement all ideas. And to advertize my favorite Commander, The Volkov Commander: one of the features I just love in it is that there are no redundant functions in it, it is as simple as possible.
Before you'd read specific questions and answers, you should have a look at the "Usage", "Troubleshooting" and "Known problems and limitations" section of the documentation.
Q: I'm desperately trying to make the Commander access my Commodore drive but it just displays "Drive #8 not present", "Timeout detected" or simply locks up. What shall I do?
A: Please, read the "Troubleshooting" section in the documentation. This should cover all common mistakes.
Q: I found few bugs in the Commander and there are many functions in it. Why is it then that the public releases are still 0.xx versions?
A: The reason is that I hate version numbers like 12.3 or 1.2.34 and I only want to call 1.0 the final version. On the other hand, many people have the prejudice of thinking that beta releases are buggy. Don't worry, the public releases of the Commander are as bugfree and complete as any other non-beta software.
But to make you happy, starting with Version 0.73, the Commander is not called "beta" anymore. Not that this would make any real difference.
Q: Does the Commander support non-1541 drives: 1571, 1581, SFD-1001, FD-2000, FD-4000 drives and CMD hard disks?
A: Currently, only the 1541 drive family, 1541 compatible drives, and both the 1541 emulation mode and the native mode of 1570 and 1571 drives. Support for 1581 drives will be implemented in the next release. I can't implement support for other drives because I don't have any of them.
Q: Can the Commander copy protected disks?
A: Not really. Fortunately, there's now a well-documented standard for a GCR-coded disk image format. However, reading enough data from a Commodore disk is quite hard. Currently, you should use warp transfer mode because it can duplicate simple copy protections, those involving intentional read errors on the disk. Copy the source disk into a sixpacked ZipCode archive and then further convert the archive into a GCR-coded disk image.
Q: Can the Commander work the other way around, that is, act as a Commodore drive, connected to a Commodore machine?
A: No, and I'm not planning to implement that. The Commander acts as a Commodore machine, to make the drive think it's communicating with the real thing. To implement the idea above, it would have to simulate a Commodore drive which is just the opposite and a more sophisticated problem. There exist file servers running on the PC, try those instead.
Q: How do I access the built-in drive of my C128D or SX64?
A: Please, read the "Usage" section in the documentation.
Q: After having accessed my Commodore drive, I noticed that the DOS clock is late. How is that possible?
A: There are two separate clocks: one is the CMOS clock, updated by the hardware, the other is the DOS clock, updated by a software interrupt. While accessing a Commodore drive, all interrupts are disabled so that they don't interfere with the synchronization. In these intervals, the DOS clock is not updated, therefore it gets late.
Don't worry, if you reboot your machine, the DOS clock will be back to normal.
Q: I tried to extract LHA archives using the Commander and I saw a file name at the beginning of the uncompressed files and some of their last bytes were chopped off. How is this possible?
A: You are using LHA 2.13 or an older version. The Commander and Star LHA are using the "print" command instead of the usual "extract" command. The reason for this is that when specifying the name of files to extract, a file name with a space inside (not unlikely for a Commodore file name) would make LHA assume it to be two separate file names.
Therefore, all the files in the archive are printed, as one continuous stream, into a single file and then the necessary parts are picked out. Unfortunately, LHA 2.13 and older versions prepend the file name to each printout which is garbage for the Commander and Star LHA. Get the official LHA 2.55 English release to solve this problem.
Q: My Commodore drive makes so awful noises when I format disks with the Commander. Can I avoid this?
A: Yes, you can, but make sure that your drive is not misaligned. When you format a disk, the original format command bangs the head against the bump, to make sure that it's the outermost track being named "track 1" during the actual format. To be compatible with the original way, the Commander also does that in turbo and warp command execution mode.
However, you can switch this feature off in the configuration menu and the disk formatter will only seek onto track 1 instead of the head rattle. But remember, if you used a misaligned disk before formatting another then the misalignment will spread onto the freshly formatted disk.
Q: Why does the Commander not work in GNU/Linux, OS/2 and Windows?
A: Please, read the "Usage" section in the documentation. It contains information on the extra requirements under multi-tasking operating systems.
In all cases, get prepared for timeouts and lockups because Commodore drives expect a tighter synchronization than the Commander can keep under a multi-tasking system. You get the best results by running the Commander under plain DOS.
Also, if there exists a native transfer software for your favorite operating system then use that one instead for transferring and use the Commander for conversion only.
Q: Will you do a GNU/Linux, OS/2, or Windows version of the Commander?
A: No, I won't. Although the routines of the Borland Pascal run-time library rely on being run under DOS, I did take my time with extending them with the capability of handling Windows-style long file names. Unfortunately, there are some more aspects keyboard, file and screen handling and some quirks that are related to DOS too much.
I'm not willing to create a native version of the Commander for these platforms, especially not one with a graphical user interface. You can use all features of the Commander under the DOS emulator or DOS shell of these operating systems, perhaps, even access external Commodore drives with more or less success.
Q: I would like an OS/2 version of the Commander for another reason: running on HPFS, it could use the original long Commodore file names and I could forget the 8.3 file name limitation of DOS. What do you think?
A: Such a capability has already been implemented for Windows. There are no plans to do the same for OS/2 since I don't have it installed and have no documentation about accessing OS/2 long file names in its DOS emulator either.
However, there is some kind of solution: you can keep the files in TAR or ZIP archives as these formats support long file names and there are TAR and ZIP archivers for OS/2 as well as other operating systems.
Q: I've edited the directory of a disk and then copied it onto my PC with the option "BAM disk copy" checked. The end of the directory was lost. Why?
Q: I've edited the directory of a disk image and then cleaned it with the "Clean" option in the user menu of disk image panels. Why did I lose the end of the directory?
A: There's a serious problem with early versions of Dir Master (by Wim Taymans), which is the most wide-spread directory editor around. When you insert some phantom files into the directory (e.g. deleted files whose names make up the logo of your group) then the size of the directory grows. When you save it back onto your disk or disk image then some new sectors are filled up with the new data.
However, the software forgets to allocate these new sectors: the BAM disk copier won't copy them and the disk image cleaner will destroy all data inside them.
Validate your BAM with the "Validate" function in the user menu or manually in the disk editor before copying or cleaning. Alternatively, you can switch to "Safe BAM disk copy" mode and the directory track will be fully copied during a BAM disk copy. Similarly, use "Safe clean" for cleaning disk images and not a single byte will be harmed on the directory track.
Q: I know that a diskpacked ZipCode archive contains all the data found on a 35 track disk. How is it possible then that there are archives that don't work if I unzip them on my PC and then transfer the resulting disk image onto my disk?
A: There is one difference between unzipping the archive on your PC and your Commodore machine. The second two bytes of the first ZipCode archive hold the ID in all the sector headers of the original disk (not to be mixed with the one in the BAM). When you extract the archive on a Commodore machine, the ZipCode software reformats the disk on the fly with that ID. This way, e.g. the disk identifier routine of "Test Drive 2" recognizes the master, car and scenario disks on basis of the sector header ID's being "MD", "CD" and "SD".
All you can do is look into the first ZipCode archive and reformat the destination disk with those two bytes as an ID before transferring the disk image. However, if the ZipCode archive was created on a PC, not on a real Commodore machine, you will possibly find an invalid ID there, e.g. "64". In this case. you will have to find out the correct ID yourself.
Please, note that the Commander will always keep sector header ID's, when converting disks, provided that both the source and destination formats support them.
Q: I switched to "EGA Lines" in the Commander and saved the setup. How is it possible then that the next time I launched the Commander it didn't automatically change to "EGA Lines" upon startup?
A: The Commander changes the screen mode only if it has to: the screen is in graphical mode. This is similar to how other Commanders also work. The state of the "EGA Lines" option is not even saved into the setup file.
Q: Why can't I copy all the files on the disk of my favorite demo?
A: Probably some files on that disk are phantom files (directory entries with no real file data) or have non-standard characters in their name (graphical characters or characters that are not allowed in file names, e.g. comma, colon, asterisk, question mark etc.). The Commander uses the Commodore drive's DOS to open files so it doesn't support such file names either. Rename those files using the disk editor or, even better, copy the whole disk instead.
Q: Why is it that, although I have defined several standard viewers in SCVIEW.EXT, the Commander still can't use them like The Norton Commander does?
A: Perhaps, you are using the viewers of The Norton Commander 5.0, which need the file NCVIEW.MSG to be able to run put this file into the directory where the viewers are. However, these viewers support the parameter passing convention differently than the ones that came with an earlier version (3.0, 4.0 or 4.5) of The Norton Commander, so don't be alarmed if they e.g. launch in color mode although the Commander has been set to black & white.
Q: There are some minor but annoying differences between your Commander and The Norton Commander. Why?
A: A personal opinion: when I started using The Volkov Commander, I began to hate The Norton Commander. Consider that The Volkov Commander is written fully in assembly, not a high-level language. It's a lot smaller, still it can do most of what The Norton Commander can, sometimes even more. It's not the overgrown fatware that The Norton Commander has become (not to mention that now it has nothing to do with Peter Norton who is said to be the best PC programmer ever) and that's why I make my Commander to be similar to The Volkov Commander.
Admit it, after some hours, you got used to the new features, maybe, now you even miss some of them from The Norton Commander...
Q: I hate the colors the Commander uses. Can I change them?
A: Yes, you can. There is a full color configuration menu in the setup for all screen modes (black & white, color, laptop and monochrome). You can also try the prepared palette files that make the Commander look similar to the "Color 2" scheme of The Norton Commander and to DOS Navigator.
Q: What language is the Commander written in?
A: I started coding it in Turbo Pascal 7.0 with Turbo Vision 2.0 but changed to Borland Pascal 7.0 a bit later since it had a better IDE and online help. When I got the sources of the Borland Pascal run-time libraries, at once I began to rewrite the user interface so that it looks competely like that of The Norton Commander. Many of the original Turbo Vision routines were deleted or changed during this process.
The source of the Commander, the viewer and the editor takes up more than 70.000 lines and 2 Mbytes, not counting the little utilities for compiling the online help, creating the sample Commander screens for the palette setup and other purposes. There are also many assembly routines in the source, mainly for data transfer and data conversion where speed is very important.
By the way, the full source is available, under a GPL-style license, on the homepage.
(This page best viewed with any browser)