Frequently Asked Questions about The Star Commander Here are some questions I was asked many times and my answers to them. First, I'd like to mention that the Commander was not meant to be a multi-purpose utility with lots of goodies and that the main executable file is already too big and it eats up a lot of memory. 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. Q: I found few bugs in the Commander and there are many functions in it. How 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 program. But to make you happy, starting with Version 0.73 the Commander is not called "beta" anymore. Q: I'm desperately trying to make the Commander access my Commodore drive but it just displays "Device not present" or simply locks up. What shall I do? A: Please, read the section "TROUBLESHOOTING" in the documentation. Q: Does the Commander support non-1541 drives? A: No, only the 1541 drive family, 1541 compatible drives, and the 1541 mode of the 1571 drive since I only have a 1541C and a 1541-II drive. I'm not planning to support the native mode of the 1571 and 1581 drives (double sided disks, MFM-coded data) and GCR-coded disk images because I have no 1571 and 1581 drives and the emulators don't support them either. Q: Does the Commander support 40 track disks and disk images? A: Yes, it does. However, there is a restriction: since the Commander uses the original DOS routines to allocate blocks for the files during file copy from the PC to the external Commodore drive in any mode, if your drive cannot handle the extra tracks or the extra BAM entries, you won't be able to use all the 40 tracks. In this case you might have to fill up a 40 track disk image with files first and then copy the disk image onto the external Commodore drive. It is also possible that the ROM of your Commodore drive is not patched to let programs seek to the extra tracks - in this case you're totally out of luck. Q: I tried to extract LHA archives using the Commander and I saw a filename 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 filename with a space inside (not unlikely in a Commodore LHA archive) would make LHA think it to be two separate filenames. Therefore all the files in the archive are printed in one continuous stream into a single file and then the necessary ones are picked out. Unfortunately, LHA 2.13 and older versions prepend the filename to each printed file which is garbage for the Commander and Star LHA. Get the official LHA 2.55 English release to solve this problem. Q: The benchmark in the documentation says that copying a whole disk in warp transfer mode takes not more than a minute and a half. How is it possible then that it's even slower than turbo transfer mode on my machine? A: Perhaps, you are using the delay value computed by the calibrator of an earlier release. The synchronization method has been changed since that and you should not use the old delay value. If you have a 386 or a 486, you should try the default delay value of 48. If you have a 286 then lower it; if you have a Pentium or above then raise it, to about 80. Q: Anyway, why do I have to change the delay value every time a new version is released? A: I'm constantly playing with the transfer routines so that they become more and more stable and as fast as possible at the same time. When I change the timing then the delay value is not valid anymore. The timing is done with the hardware system timers whose speed is machine independent but the little routine initializing the timer takes different times to run on different configurations. This is the possible reason why you have to change the delay value if your machine is reasonably slower or faster than a 386 or 486. Q: And what about the other options? Do I have to set all of them again and again? A: No, you don't. Since Version 0.71 beta the Commander and its external programs are able to read the setup file created by the previous version so that you only have to set the new options and those having been changed. Q: Does the Commander support file images (files with the extension '.P00'/ '.S00'/'.U00' created and used by PC64)? A: Yes, it does. You can press Enter or double-click on such files to see their contents just like with disk and tape images. There is an option "Into file image" in the copy/move dialog box, as well. By checking it, the Commander copies/moves the source files into file images (creating them on the fly), provided that the destination is a DOS directory. Q: May I know what language the Commander is 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 absolutely 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 external setup and the internal viewer and editor is now at about 1230 KBytes - not counting the little utilities I made for compiling the online help, creating the sample Commander screens in the external setup and other purposes. There are also many assembly routines in the source, mainly for data transfer and conversion where speed is most important. Q: Why doesn't the Commander work under my OS/2, Linux, Windows, Windows'95 or Windows NT? A: Because it's technically impossible to achieve correct timing under these multi-tasking environments: the kernel, the control program of the operating system, steals time from the Commander for monitoring the system and giving time slices for the other precesses, messing up the synchronization between the PC and the external Commodore drive. However, if you use the XP1541 parallel cable then you'll possibly be able to access your Commodore drive even under these multi-tasking systems because the parallel handshake is asynchronous. Q: Will you do an OS/2, Linux, Windows, Windows'95 or Windows NT version of the Commander? A: No, I won't. A major problem is that most routines of the Borland Pascal run-time library rely on being run under DOS and I don't feel like rewriting them from scratch. On the other hand, you can use all features of the Commander under the DOS emulator or DOS shell of these operating systems, perhaps, except for the access to an external Commodore drive. 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 version of the Commander wouldn't help much with long file names because Commodore file names need to be converted into ASCII. During that many PETSCII characters would be lost because they have no equivalent in ASCII or are not allowed in an HPFS file name. The same goes for Windows '95 long filenames. However there is some kind of solution: if you want to upload Commodore files onto your Unix account and keep the long filenames then you can copy the files into TAR archives then upload and extract the archives under Unix. 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 the early versions of Dir Master by Wim Taymans, which is the best and 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) 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. But the program forgets to allocate these new sectors therefore the BAM disk copier won't copy these blocks and the disk image cleaner will destroy all data in them. Validate your BAM with the "Validate" option in the user menu or manually in the disk editor before copying or cleaning. You can also switch to "Safe BAM disk copy" mode and track #18 will be fully copied even during BAM disk copy. Similarly, use "Safe clean" for cleaning disk images and it won't harm a single byte on track #18. Q: Will there be a directory editor inside the Commander? A: No, there won't. However, it's possible that I code a stand alone directory editor for disk images. 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, like colon, asterisk, question mark etc.). The Commander uses the original 1541 DOS to open files so it doesn't support such files either. Rename those files using the disk editor or copy the whole disk instead. Q: When I want to delete a separator line in the directory of a disk image, why does the Commander delete another separator with the same name? A: The Commander identifies files with their names and not with their position in the directory - just like Commodore drives do. When you process a file, the Commander searches through the directory of the disk image for a file with that name and processed it. It assumes that there is only one file with a given name in the disk image. The directory editor coming later will help you with that. Q: Why is it, that although I have defined several standard viewers in the file SCVIEW.EXT, the Commander still can't use them like The Norton Commander? A: Perhaps, you are using the viewers of The Norton Commander 5.0, which require data to be passed in a special file instead of a special parameter block on the command line. The Commander only supports the parameter block, therefore you should use the viewers that came with an earlier version (3.0, 4.0 or 4.5) of The Norton Commander. 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 a single 64KB COM file (written fully in assembly, not a high-level language), still it can do what The Norton Commander 3.0 can. It's not that overgrown fatware like The Norton Commander has become (not to mention that now it has nothing to do with Peter Norton - said to be the best programmer ever - and should rather be called The Socha Commander or The Symantec Commander) so I make my Commander to be similar to the The Volkov Commander. Admit it that after some hours you got used to the new features like pressing Escape turns the panels off, maybe, now you even like them... 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 external 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 The Norton Commander and to DOS Navigator. 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 certain archives which 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 contain the ID in all the sector headers of the original disk (not the one in the BAM). When you extract the archive on a Commodore machine, the ZipCoder re-formats the disk on the fly with that ID so that e.g. the disk identifier routine of "Test Drive 2" recognizes the master, car and scenario disks based on the ID of sector headers being "MD", "CD" or "SD". All you can do is look into the first ZipCode archive and re-format 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 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. Q: I switched to 'EGA Lines' in the Commander and saved the setup. How is it then that the next time I launched the Commander it didn't automatically change to 'EGA Lines' upon startup? A: The Commander never changes the screen mode, only if it has to, e.g. the screen is in graphical or 40 column mode. This is how the other Commanders also work. The state of the 'EGA Lines' option is not even saved in the setup file.