home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / ibm / pc / hardware / 23858 < prev    next >
Encoding:
Internet Message Format  |  1992-09-09  |  2.6 KB

  1. Xref: sparky comp.sys.ibm.pc.hardware:23858 comp.os.msdos.programmer:9216 comp.sys.ibm.pc.misc:12429 comp.sys.ibm.pc.programmer:396
  2. Newsgroups: comp.sys.ibm.pc.hardware,comp.os.msdos.programmer,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.programmer
  3. Path: sparky!uunet!haven.umd.edu!wam.umd.edu!mts
  4. From: mts@wam.umd.edu ()
  5. Subject: Re: Why does HIMEM.SYS not work with some keyboard chips?
  6. Message-ID: <1992Sep10.033029.17342@wam.umd.edu>
  7. Sender: usenet@wam.umd.edu (USENET News system)
  8. Nntp-Posting-Host: rac2.wam.umd.edu
  9. Organization: University of Maryland, College Park
  10. References: <1992Sep4.023741.3497@leela.cs.orst.edu> <1992Sep4.153652.16199@uniwa.uwa.edu.au> <1992Sep9.044414.29506@qiclab.scn.rain.com>
  11. Date: Thu, 10 Sep 1992 03:30:29 GMT
  12. Lines: 42
  13.  
  14. In article <1992Sep9.044414.29506@qiclab.scn.rain.com> 70465.203@compuserve.com writes:
  15. >It's more like this. 
  16. >
  17. >On an 8088, an attempt to access any address in the FFFF segment would wrap
  18. >around to low ram (FFFF:0000-FFFF:000F was the top 16 bytes of RAM, the 
  19. >rest of the segment was at 0000:0000-0000:FFF0).
  20. >
  21. >On the 286, the accesses *didn't* wrap, they just went on to the first
  22. >64k-16 of RAM above the 1 meg mark. 
  23. >
  24. >Apparently so major applications programs *depended* on the wraparound.
  25. >So if the wrap around couldn't be duplicated, they wouldn't run on the
  26. >AT, and nobody would buy it. But at the same time, The AT needed to
  27. >be able to run protected mode OSes like Xenix. Which required that
  28. >the addresses *not* wrap.
  29. >
  30. >The obvious solution was to put in hardware allowing software selection
  31. >of the hardware for the "wrap kludge". 
  32. >
  33. >I suspect it was tied to the keyboard controller because it was the 
  34. >only "free" toggle. Or at least the easiest one to deal with. Why
  35. >add a chip when you have an unused portion of one that'll do the same
  36. >thing?
  37. >
  38. >The slowness *only* matters if you are toggling modes frequently. Which
  39. >*shouldn't* be happening. The old software that required the kludge
  40. >is gone by now, so the kludge can be disabled and *left* disabled.
  41. >
  42. >Leonard Erickson              leonard@qiclab.scn.rain.com
  43.  
  44.      As I wrote to the original poster, there is an article about this
  45. in either Sept's issue of Compute or Byte.  They say that it has something
  46. to do with the A20 gate being handled by the keyboard BIOS.  Apparently
  47. not all software is gone, because they reported having problems with 
  48. Word Perfect.  It was not a total system lockup, but rather that some
  49. characters were not appearing as they had been typed.  I believe that 
  50. <shift>s were being added to their keystrokes to be exact.  Supposedly
  51. the "machine:" line fixed the problem.
  52.  
  53. Dave.
  54.  
  55.  
  56.