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 / CPM / MEX / MXTIMOUT.FIX < prev    next >
Text File  |  2000-06-30  |  2KB  |  38 lines
  1.     When using MEX to receive 1200 baud XMODEM transfers on a Kaypro 4-84, 
  2. I got a "Bad Sector Header" message every 128 records (16K).  I believe this
  3. problem occurs on all floppy-based Kaypros because the disk writes are so 
  4. slow. 
  5.     The MEX file transfer buffer comes installed at 16KB long.  The Kaypro 
  6. takes too long to write this much data, so when the buffer is flushed, 
  7. the sending machine times out and sends the current block again.  This puts 
  8. the two machines temporarily out of synch.  Most of the time, they get back on 
  9. track quickly, so there's no problem except a little wasted time.
  10.     But sometimes the entire file transfer gets cancelled when this error 
  11. occurs.  I assume there's a control character in the transmitted file that 
  12. gets misinterpreted as a command because of the out-of-synch condition. 
  13. This can be very upsetting when it happens near the end of a 96K file, as
  14. it did to me recently.
  15.     The solution is to make the transfer buffer smaller, so that the 
  16. receiving Kaypro can write out the buffer and acknowledge the current block
  17. within the timeout "window."  You can do this by editing, assembling and 
  18. MLOADing MEXPAT22.ASM over MEX.COM. However, this patch file can alter 
  19. previously-made configurations.
  20.     There's a much easier fix.  Just change just one byte with any disk 
  21. editor (PATCH, DU, FU, SUPERZAP, etc.) or even DDT. I'll assume you know how to
  22. use one.
  23.     MEX patch points begin at location 0D00, and the size of the transfer 
  24. buffer (in KB) is in location 0D23.  As supplied, this byte contains the hex 
  25. number 10.  Just change it to 04, and you won't have any more timeout errors.
  26.     I found this location by looking in MEXPAT22.ASM and comparing the 
  27. bytes in MEX.COM with the listing.  I have used this modification on MEX 1.14
  28. over a week now with no problems. The same patch should work on MEX 1.2.  I 
  29. don't know if the patch points are different in other versions.  If you
  30. can't find the hex 10 at location 0D23, just look for the following sequence
  31. of bytes: FF 10 01 28 28 00 00.  The "10" is what you need to change.
  32.     If anybody has any further information on this problem, feel free to 
  33. append it to the end of this file.
  34.                     Peter A. Klein
  35.                     Seattle, WA  
  36.                     2/15/86
  37. ion on this problem, feel free to 
  38. appe