
              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'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 the only drive  I  have  is  a  1541C  drive.  I'm  not
   planning to support the native mode of the  1571  and  1581  drives  (double
   sided disks, MFM-coded data) because the emulators don't do that either.

Q: Does the Commander support 40 track disks and disk images?
A: Now 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 will not  be  able  to
   use all the 40 tracks. In this case you might want to fill  up  a  40  track
   disk image with files first and then copy the disk image onto  the  external
   Commodore drive. Similarly, it is 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: 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 then  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.

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. When I change the timing  then  the
   delay value is not valid anymore. The  timing  is  done  with  the  hardware
   system timers which is machine independent.

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  setup
   program 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: Now 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 is now at  about  950  KBytes  -  not
   counting the little utilities I made for compiling the online help 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 or Windows'95?
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 for monitoring the system messing up the synchronization
   between the PC and the external Commodore drive.

Q: Will you do an OS/2, Linux, Windows or Windows'95 version of the Commander?
A: No, I won't. See above for the reason why the Commander wouldn't be able  to
   access an external Commodore drive under these multi-tasking  systems.  It's
   no use to run the Commander under them because you would  lose  one  of  the
   main features. Another 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  the  other
   features of the Commander under the DOS  emulator  or  DOS  shell  of  these
   operating systems.

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.

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 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 will grow. When you save it back  onto
   your disk or disk image then some new sectors will be filled  with  the  new
   data. But the program forgets to allocate those new  sectors  therefore  the
   disk copier won't copy those 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 the option 'Copy full track 18' on and track #18 will be fully copied
   even during BAM disk copy, and for cleaning the disk image use  'Safe clean'
   which does not harm a single byte on track #18.

Q: Will there be a directory editor inside the Commander?
A: No. 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 does not 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  delete  a  file,
   the Commander searches through the directory of the disk image  for  a  file
   with that name and deletes 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 can only use 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 - the best progammer ever -  and  should  rather  be
   called The Socha Commander or The Symantec Commander). I make  my  Commander
   to be similar to the The Volkov Commander and not  to  The Norton Commander.
   Admit it that after some hours  you  got  used  to  the  new  features  like
   pressing Escape turns the panels off, maybe, now you 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  much  more
   similar to 'Color 2' of the The Norton Commander and 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 recognizer
   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 found few bugs in the Commander and there are many functions in it. How is
   it then that the public releases are still beta 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.
