home *** CD-ROM | disk | FTP | other *** search
/ No Fragments Archive 12: Textmags & Docs / nf_archive_12.iso / MAGS / SOURCES / ATARI_SRC.ZIP / atari source / AHDI / TESTSPAR / DMAREAD < prev    next >
Encoding:
Text File  |  2001-02-09  |  3.1 KB  |  74 lines
  1. Well, I still haven't found the problem that causes TOS to fail
  2. to be able to read the hard disk after running the recent
  3. versions of SafeTT which talk to SCSI... but I did notice another
  4. problem while looking through the dmaread.s code that Allan sent
  5. me. 
  6.  
  7. After you have successfully selected a SCSI target, you need to
  8. be careful about what you do after a "time-out." Imagine a slow
  9. SCSI device (like our new CD-ROM, the CDAR-505).  It has an
  10. average access time of 350 mS, and a worst case access time of a
  11. little over 1 second.  It will respond to your read command
  12. block, but you will time-out waiting for the first data byte.  At
  13. that point it looks like your code just returns signaling an
  14. error.  But the SCSI device will still be on the bus! Once
  15. selected, SCSI assumes that you trust the target to moderate the
  16. transfer...  to tell you the current bus phase and therefore
  17. control the number of bytes passed.  The target doesn't know
  18. you've lost interest. 
  19.  
  20. I'm not sure that the time-out code is a good idea beyond the
  21. selection phase.  If you do want to have time-outs here to guard
  22. against degenerate cases, I believe you are going to have to
  23. reset the SCSI bus after you detect one of these time-outs.  If
  24. you aren't going to walk through all the SCSI phases
  25. giving/taking bytes as indicated to get the selected target back
  26. to the IDLE state, SCSI RESET is the only alternative.  (And
  27. doing a SCSI RESET is a bit fascist, since you can't be sure it
  28. won't clear some desired state in a different SCSI device.)
  29.  
  30. It might also be a good idea for _resetscsi() to read from the
  31. 5380's reset error/interrupt register (#7) before returning to
  32. clear the SCSI reset interrupt request... should anyone ever want
  33. to use interrupts for watching the 5380.
  34.  
  35.  
  36.  
  37.  
  38. From ajc!jwt Wed Jul 24 02:58:45 1991
  39. Received: by atari.UUCP (4.12/4.7)
  40.     id AA24944; Wed, 24 Jul 91 02:58:36 pdt
  41. Received:  by ajc (UUPC/extended 1.10a);
  42.            Wed, 24 Jul 1991 15:38:20 JST
  43. Date:      Wed, 24 Jul 1991 15:38:17 JST
  44. From: (Jim Tittsler) ajc!jwt
  45. Message-Id: <288d205d@ajc>
  46. Organization: Atari Japan Corp
  47. To: atari!minna
  48. Cc: atari!apratt
  49. Subject:   dmaread.s
  50. Status: RO
  51.  
  52. I believe the cache flushing code at "rw1:" has the wrong
  53. conditional assembly flags guarding it (although admittedly as
  54. currently set up SCSI == TT) and happens more than it needs to. 
  55.  
  56. You only need to flush the cache when DMA input has happened.(1)
  57. DMA output (i.e.  writes) can never cause a loss of cache coherency,
  58. nor can data transferred under processor control (which is how
  59. the SCSI code is handled here). 
  60.  
  61. As dmaread.s is currently set up, the only time you need to flush
  62. the cache is after an ACSI DMA read (on a TT).
  63.  
  64. But, its not the bug I was looking for.  Sigh.
  65.  
  66. ______
  67. (1) Since the 68030's cache controller does not monitor what
  68. other system bus masters do, DMAing into external memory changes
  69. the data there without changing any copies of those locations
  70. that might already be in the internal cache.  "Flushing" the
  71. cache is the quickest way to mark the internal contents as
  72. invalid so stale data can't possibly be used.
  73.  
  74.