home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / sysv386 / 13729 < prev    next >
Encoding:
Text File  |  1992-08-29  |  2.9 KB  |  64 lines
  1. Newsgroups: comp.unix.sysv386
  2. Path: sparky!uunet!digibd!rick
  3. From: rick@digibd.com (Rick Richardson)
  4. Subject: Re: Avoiding the "8/16 Bit Problem"
  5. Organization: DigiBoard Incorporated, Eden Prairie, MN
  6. Date: Fri, 28 Aug 1992 13:58:13 GMT
  7. Message-ID: <1992Aug28.135813.8382@digibd.com>
  8. References: <18392@polstra.UUCP> <1992Aug26.145710.3533@crd.ge.com> <1992Aug26.233135.11289@chinacat.unicom.com>
  9. Lines: 53
  10.  
  11. chip@chinacat.unicom.com (Chip Rosenthal) writes:
  12.  
  13. >The specific question which needs to be asked is whether the SCSI card
  14. >uses 8-bit or 16-bit BIOS ROM accesses, because that is the only memory
  15. >mapped portion of these cards.  True, UNIX does not use the BIOS, but
  16. >that doesn't matter.  The whole point is that if any card in the 128K
  17. >memory segment wants to do memory transfers 16-bits at a time, then
  18. >every card in that segment must use 16-bit tranfers.
  19.  
  20. >Yes, it's a stupid restriction.  Yes, it's typical IBM engineering.
  21.  
  22. The reason this happens is that at the time that a card has to tell
  23. the bus it wants to do a 16 bit transfer, only enough address bits
  24. are valid to select a 128K window.  Some slick HW types have found
  25. workarounds to this problem, which include:
  26.  
  27.     - Have a SW enable/disable of 16 bit transfers.  Only put
  28.       the card into 16 bit mode during the duration of a
  29.       transfer to it, then return it to 8 bit mode.  Obviously,
  30.       you have to have interrupts off during all such transfers,
  31.       lest some other device driver wake up and try to access the
  32.       same 128k block in 8 bit mode.
  33.       
  34.     - Put in some *really* fast address decode, and hope you have
  35.       enough time decode those low order address bits when they
  36.       finally become valid, but before it is too late to say "I
  37.       want a 16 bit transfer".  I think the success of this
  38.       approach depends greatly on the motherboard design.
  39.  
  40. Of course, any 16 bit board that doesn't have one of these workarounds
  41. is enough to screw an 8 bit board to hell.
  42.  
  43. Like all good workarounds, neither of these is 100% reliable (otherwise,
  44. we'd call them fixes, wouldn't we?).  The best solution* is to
  45. segregate your memory mapped cards - C0000-DFFFF for one size,
  46. E0000-E7FFF for the other.  Disable on board ROMs that aren't used.
  47. So far, I haven't found a system that couldn't be partitioned
  48. in this way (though I suspect that you'd be screwed if you
  49. could find a 386 ISA with ROM Basic).
  50.  
  51. *Actually, had IBM enumerated all the design screw-ups in this
  52. bus in a public marketing compaign at the time the uCHANNEL was
  53. introduced, I suspect they could have moved the world to uCHANNEL,
  54. even with the ridiculous licensing fees (read: closed design).
  55.  
  56. DISCLAIMER: These represent my personal feelings.  I am not a
  57. hardware type, and could be wrong. Etc.
  58.  
  59. -- 
  60. Rick Richardson        Email: rick@digibd.com    This space intentionally
  61. Senior Staff Engineer    Fax:   (612) 943-0803    blank until 1996 elections.
  62. DigiBoard, Inc.        Tel:   (612) 943-5383
  63. Eden Prairie, MN    Radio: N0NMY
  64.