home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ENTERPRS / CPM / UTILS / A / CONVERTB.ARC / CONVERTB.DOC < prev    next >
Text File  |  1987-08-10  |  5KB  |  102 lines
  1. CONVERTING TURBO PASCAL DATA FILES FROM CP/M TO MS\PC-DOS
  2.  
  3. by William Meacham                                 8/9/87
  4.    1004 Elm Street
  5.    Austin, Tx  78703
  6.  
  7.  
  8.      I found the editorial "A farewell to CP/M?" in TUG Lines,
  9. the journal of the Turbo User Group, issue 19, very timely.  I am
  10. one of those who have made the transition from CP/M to DOS.  One
  11. of the nifty things about Turbo Pascal is that it was so easy! 
  12. My source code was almost completely transportable; I only had to
  13. change a couple of BDOS calls.  (The transition the other way
  14. would not be so easy; you can do a lot of things on the IBM
  15. clones that you can't on a CP/M machine.)  However, I had a bit
  16. more trouble transporting my data files.  I could not just
  17. transfer the files to the DOS machine and use them.
  18.  
  19.      A CP/M Turbo Pascal data file (other than a text file)
  20. differs from its DOS equivalent in two important ways:  (1) it is
  21. longer, and (2) it contains extra information.  This means that
  22. you cannot simply read the CP/M file from a DOS program; you have
  23. to convert the file format.
  24.  
  25.      The CP/M file is longer than its DOS equivalent because it
  26. is rounded up to a 128-byte boundary.  In CP/M the logical length
  27. of a file is different from its physical length.  By "logical
  28. length" I mean the number of bytes in all the records in the file
  29. as defined in your Turbo Pascal program.  By "physical length" I
  30. mean the file length recorded in the operating system directory. 
  31. CP/M does not keep track of the logical length of a file.  Every
  32. file is rounded up to the next 128-byte boundary (or 256 or 1K
  33. byte, depending on your BIOS).  DOS, however, keeps the exact
  34. file length in its directory.
  35.  
  36.      The CP/M file contains four bytes at its beginning not found
  37. in the equivalent DOS file.  These are two integers giving the
  38. number of records and the record length.  They are used for the
  39. FileSize function, which works differently in CP/M from the way
  40. it works in DOS.  The CP/M FileSize function reads the first four
  41. bytes of the file and computes its logical length.  The DOS
  42. function finds out from the directory.  It does not need the
  43. extra four bytes at the beginning, and the DOS data file does not
  44. contain them.
  45.  
  46.      This means you've got trouble when you transfer a CP/M file
  47. to DOS, whether by modem or direct serial transfer or by using
  48. a disk compatability program.  If you recompile your source code
  49. and then run it against the CP/M data file you either bomb out or
  50. get erroneous results.  Your Turbo program does not recognize the
  51. extra four bytes at the beginning of the file, so all your
  52. records are now four bytes off.
  53.  
  54.      I wrote the program CONVERTB.PAS to fix this problem.  It
  55. will work on any CP/M data file that has been transferred to a
  56. DOS machine.  What it does is read the first four bytes and
  57. compute the logical length of the file by multiplying the number
  58. of records times the record length.  Then it reads that many
  59. bytes from the CP/M file and writes a new DOS file that many
  60. bytes long.  When you are done, the DOS file's logical and
  61. physical length are the same.
  62.  
  63.      The program is called "ConvertB" because it uses the Don
  64. Taylor's buffered read routines in TUG Lines, Issue 18.  The
  65. input file is declared as an untyped file and read 32 128-byte
  66. blocks at a time.  This works because the file, having come from
  67. CP/M, is a multiple of 128 bytes and we don't know or care, yet,
  68. what its logical length is.  We just want to read bytes.
  69.  
  70.      The program uses a variant record, declared as type
  71. "intbytes," to read the first four bytes.  Looked at one way, an
  72. intbyte variable is two bytes.  Looked at another way it is an
  73. integer.  This is a powerful feature, not only of Turbo Pascal
  74. but of standard Pascal as well; it allows us to access the same
  75. information in two different ways.  What we do is read two bytes
  76. from the input file, then look at them as an integer representing
  77. the number of records.  Then we read two more bytes and look at
  78. them as an integer representing the length of each record.  We
  79. must convert the integers to reals before multiplying them to get
  80. the logical file length in bytes.  If we did not and the result
  81. were greater than 32,767 (maxint), the program would interpret it
  82. as a negative file length.
  83.  
  84.      Having computed the logical file length in bytes, all we do
  85. is read that many bytes from the input file and write them to the
  86. output file.  An earlier version of this program just read a byte
  87. at a time; using the buffered read routines speeds it up a lot.
  88. However, we must write the output file one byte at a time.  The
  89. point is to write the exact number of bytes so that DOS will get
  90. the file length right.  If we used a buffered write routine, the
  91. output file would be rounded up to a 128-byte boundary, which
  92. would defeat the whole purpose.
  93.  
  94.      This causes a lot of activity on your disk drives.  I
  95. recommend using a RAM disk if possible.  If not, read from one
  96. drive and write to another to minimize head movement.  The
  97. program is slow -- because it has to write the output one byte at
  98. a time -- but you only have to run it once per data file.
  99.  
  100.      I hope this helps others who are converting from CP/M to
  101. DOS!
  102.