home *** CD-ROM | disk | FTP | other *** search
/ 8bitfiles.net/archives / archives.tar / archives / genie-commodore-file-library / Information / DATA-BITS.ARC / DATA-BITS-INFO.T
Encoding:
Text File  |  2019-04-13  |  6.8 KB  |  143 lines
  1.  ************
  2. Topic 27        Wed Jul 25, 1990
  3. H.HERMAN1                    (Forwarded) 
  4. Sub: A place to ask lingering questions...  
  5.  
  6. Here's the place to ask those lingering questions, that you've always wanted
  7. answers for, but were afraid to ask...
  8. 9 new messages.
  9.  ************
  10.  ------------
  11. Category 8,  Topic 27
  12. Message 1         Wed Jul 25, 1990
  13. H.HERMAN1                    (Forwarded) 
  14.  
  15.  A  few  questions  for  the  Sysops....    And, everyone else....    About
  16.  things I've been wondering about:                                         
  17.  
  18.  [1]   7-E-1  seems  to work here, as well as the recommended 8-N-1.  Simce
  19.  7-E-1  uses one bit less, wouldn't this actually speed up transmissions by
  20.  1/8th, or about 12%?                                                      
  21.  
  22.  [2]   A  file after being transferred by modem probably has acquired added
  23.  padding.  One  dose  of  "padding" can't add too much, but if the file has
  24.  seen its way through a few transfers, it may grow considerably larger than
  25.  its  original.  Before releasing files are they first stripped of possible
  26.  accumulated extra padding?                                                
  27.  
  28.  [3]   I  sent  a check to the author of a 128 mode shareware term.  It has
  29.  now  been upgraded for SwiftLink, and the new release is also shareware. I
  30.  do not know if I am supposed to pay again.                                
  31.  
  32.  Howie                                                                     
  33.  
  34.  P.S.   That  128  mode  term  is  actually  in  pre-release  form only for
  35.  purchasers  of SwiftLink.  It will be made available generally, very soon,
  36.  with some more additions.                                                 
  37.  ------------
  38. Category 8,  Topic 27
  39. Message 2         Wed Jul 25, 1990
  40. ED.BELL [* sysop *]          (Forwarded) 
  41.  
  42. If you strip the hi bit of your transmissions, the only thing you  would have
  43. is 7 bit values.  That MAY be ok for text files, though
  44.  *I* wouldn't do it (especially for PETSCII files), but for any kind of
  45. executable file, you would end up with garbage.
  46.  
  47. As for padding, Xmodem protocols pad to some multiple of 128 bytes. Under a
  48. worst case scenario, the most accumulation of padding that could occur is 1027
  49. bytes.  If you upload a file with Xmodem and it is padded out to the nearest
  50. 128 bytes, then download it using Ymodem, the 128 byte rounding could do 1 of
  51. 2 things.  It could end up on an even 1K boundary, in which case the Ymodem
  52. would add no more (GEnie only, I'll explain in a moment) or it could lap 1 or
  53. more 128 byte blocks into an even 1K block.  make sense.  If it  lapped, the
  54. most cumulative padding that could ever occur would be 1024 bytes - 128 bytes
  55. * number of blocks lapped.  Check this out...
  56.  
  57. XXXXX      5 Block file uploaded in Xmodem  X's are 128 byte packets O------- 
  58. Same file downloaded with Ymodem.  The O's are the actual Ymodem packets.  The
  59. '-' characters represent what those packets cover in terms of Xmodem packets. 
  60. With this example, you can see another 3 128 byte packets could be added to
  61. the original file.  Some terms do strip this stuff.  I don't because the way
  62. most terms do it (Desterm, Novaterm, Wizard) are using an assumption that is
  63. contrary to Ymodem specification and under certain circumstances could strip
  64. away valid file data.  Here on GEnie, Chuck Forsberg chose not to step down
  65. block size for the last 7 blocks of a file, meaning more padding for most
  66. transfers than necessary.  But the scenario you mention has a limit. If all
  67. terms in the picture use only Xmodem, even if none of them strip padding, the
  68. program can get no bigger than the original upload.  In the diagram above, the
  69. first 4 X's are all file data, and the 5th one would most likely be part file
  70. data and part file padding.  So a Ymodem download would add its padding to
  71. this, but that would be the extent of the padding added, because in all cases,
  72. the file would now be an even  multiple of 128 bytes.
  73.  
  74. As for the Shareware, I don't think the author expects you to register twice. 
  75. Registered users (Desterm) are automatically sent the next release.  I think
  76. Matt asks $10 if you would like a laser printed manual.
  77.  ------------
  78. Category 8,  Topic 27
  79. Message 3         Thu Jul 26, 1990
  80. H.HERMAN1                    (Forwarded) 
  81.  
  82.  Ed,  Thanks  for  the  explanations.   I  quess  that  I just had a lot of
  83.  mis-information about those things.                                       
  84.  
  85.  Howie                                                                     
  86.  
  87.  ------------
  88. Category 8,  Topic 27
  89. Message 4         Thu Jul 26, 1990
  90. DIGITAL.DOC                  (Forwarded) 
  91.  
  92. Howie,
  93.    Perhaps I have the answer to the 7-E-1 verses 8-N-1 question.  I don't
  94. think you would see any speed up at all.  In both cases, you  are effectively
  95. dealing with 9 bits.  7-E-1 will send 7 data bits  plus 1 parity bit plus 1
  96. stop bit:  total 9.  8-N-1 will send 7 data  bits, no parity bit, and 1 stop
  97. bit:  total 9.  To see the possible speed up you suggest, you would have to
  98. deal with 7-N-1, which would be 8 bits and should transfer data in 8/9 of the
  99. time. (Subject to the problems you would find dealing with program files) 
  100. <Grin>
  101.        <Doc>
  102.  ------------
  103. Category 8,  Topic 27
  104. Message 5         Fri Jul 27, 1990
  105. ED.BELL [* sysop *]          (Forwarded) 
  106.  
  107. I believe that 8N1 is actually 10 bits/byte, making baud rate in terms of
  108. bytes a multiple of 10's.  I believe there is a bit you are not counting in
  109. there, but overall, the only place it could be factored is in things like the
  110. BB, where at worst you would lose  your capital letters.  In file transfers,
  111. you would be in a lot more trouble, except, again, for text files.
  112.  
  113.  ------------
  114. Category 8,  Topic 27
  115. Message 6         Fri Jul 27, 1990
  116. WC.COLEMAN [*Sysop*]         (Forwarded) 
  117.  
  118. In both cases you are dealing with 10 bits - Doc forgot about the start bit!
  119. The only real difference between 8N1 and 7E1 is that 7E1 trades in the high
  120. bit for a parity bit - now that's what I call a waste!  -WC
  121.  ------------
  122. Category 8,  Topic 27
  123. Message 7         Fri Jul 27, 1990
  124. ED.BELL [* sysop *]          (Forwarded) 
  125.  
  126. I didn't know about the 7e1, but I  did know it was 10 for 8n1.  Thanks  Bill!
  127.  ------------
  128. Category 8,  Topic 27
  129. Message 8         Fri Jul 27, 1990
  130. WC.COLEMAN [*Sysop*]         (Forwarded) 
  131.  
  132. All RS232 bytes have 1 start bit, x stop bit(s), x data bits, and an optional
  133. parity bit.  So 8N1 is 1+1+8+0 = 10 and 7E1 is 1+1+7+1 = 10.
  134.  ------------
  135. Category 8,  Topic 27
  136. Message 9         Sat Jul 28, 1990
  137. R.RANDALL5 [Zeroy]           (Forwarded) 
  138.  
  139. It is only because of the serendipitous fact that most asynch transmissions
  140. are 10 bits per character that the term "bps" is equivalent to "baud".
  141.  ------------
  142.  
  143.