home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / amiga / datacomm / 8346 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  3.0 KB

  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!ee!bloc1469
  2. From: bloc1469@ee.ee.uwm.edu (Gregory R Block)
  3. Newsgroups: comp.sys.amiga.datacomm
  4. Subject: Re: Hey, does zmodem work for 2.4a?
  5. Date: 24 Dec 1992 05:26:06 GMT
  6. Organization: Electrical Engineering Dept. University of Wisconsin - Milwaukee
  7. Lines: 54
  8. Distribution: world
  9. Message-ID: <1hbhleINNdo8@uwm.edu>
  10. References: <olsen.7173@sourcery.mxm.sub.org> <1gopsoINNl30@uwm.edu> <olsen.7377@sourcery.mxm.sub.org>
  11. NNTP-Posting-Host: 129.89.2.33
  12.  
  13. In article <olsen.7377@sourcery.mxm.sub.org> olsen@sourcery.mxm.sub.org (Olaf Barthel) writes:
  14. >   No, this is what puzzles me. The callback routines wait nicely for
  15. >any queued serial IORequests, timer requests, etc. There are no
  16. >critical resource accesses which are not protected by proper
  17. >arbitration.
  18.  
  19. Alright, here's where I get really hypothetical.  I've only heard of
  20. the bug happening on 68000 systems.  Now, I was unable to recreate
  21. this on my 3000.  Only on my 68000-based 2000, my "telecommunications"
  22. machine, really.  It's become a kind of "frontend" for my 3000
  23. development system.
  24.  
  25. Anyways, enough banter.  The problem only exists in 68000 systems, so
  26. it's obviously a timing issue.  The problem exists when something else
  27. takes up a large amount of cpu, running at an equal or greater task
  28. level.  "lha" does it every time.
  29.  
  30. If you could get access to a 68000 to try this with, begin a download,
  31. and, from ram, un-lharc a program to ram.  Bang, the download ends
  32. with error count exceeded... and there certainly aren't 20 errors in
  33. that list, for the fraction of a second that the window stays up.
  34.  
  35. >   The file transfer is entirely handled by the `term' main program.
  36.  
  37. I'd forgotten that.
  38.  
  39. >The only transfer-related co-task involved is the window update
  40. >server which should not affect the file transfer as it only reads
  41. >data but does not manipulate any. Besides: the co-task can be
  42. >disabled (has anybody who had problems with the file transfer tried
  43. >this at all?).
  44.  
  45. I did.  No difference.  BTW:  There seem to be some bugs in the window
  46. updating.  Several times the text in the gadgets will be in "reverse
  47. video", a very unusual occurence.  Several times, data isn't even
  48. shown in them.  Something's getting lost.  I don't know if you end up
  49. overwriting random areas of memory with it or not, but it's a
  50. dangerous thought.  Anyways, it's apparently random.  It doesn't
  51. happen when any one program in particular is running, nor does it
  52. happen with any specific type of file downloaded or time of transfer.
  53. I've lost everything on screen, to the point where the only thing
  54. being shown was the time left to transfer.
  55.  
  56. >   I got it, but the escape control codes were filtered out :-(
  57.  
  58. Hopefully, this one will work.  I hope it finds you in good condition.
  59. :)
  60.  
  61. Greg
  62. --
  63. (: (: (: (: Have you overdosed on smileys today?  Why NOT!?! :) :) :) :)
  64. (: "Our father, who art in Iowa, Hollow be thy head, Thy ideas run    :)
  65. (:  Thy will be done, At Commodore as it is at Apple"  -Dan Barrett   :)
  66. (: (: (: (: (: (: (: (: (: (: (: (: () :) :) :) Wubba, the Dark Angel :)
  67.