Comment corrections

This commit is contained in:
Jeff Parsons 2015-10-19 15:56:28 -07:00
commit 6029f8ab9a

View file

@ -211,15 +211,15 @@ function Memory(addr, used, size, type, controller, cpu)
* *
* Originally, the Debugger always went through the Bus interfaces, and could therefore modify ROMs as well, * Originally, the Debugger always went through the Bus interfaces, and could therefore modify ROMs as well,
* but with the introduction of protected mode memory segmentation (and later paging), where logical and * but with the introduction of protected mode memory segmentation (and later paging), where logical and
* phsycial addresses were no longer the same, that is no longer true. For coherency, all Debugger memory * physical addresses were no longer the same, that is no longer true. For coherency, all Debugger memory
* accesses now go through the X86Seg and X86CPU memory interfaces, so that the user sees the same segment * accesses now go through X86Seg and X86CPU memory interfaces, so that the user sees the same segment
* and page translation that the CPU sees. However, the Debugger uses special "fSuppress" flags to prevent * and page translation that the CPU sees. However, the Debugger uses a special probeAddr() interface to
* those X86 interfaces from triggering segment and/or page faults when invalid or not-present segments * read memory, along with a special "fSuppress" flag to mapPageBlock(), to prevent its memory accesses
* or pages are accessed. * from triggering segment and/or page faults when invalid or not-present segments or pages are accessed.
* *
* These types are not mutually exclusive. For example, VIDEO memory could be allocated as RAM, with or * These types are not mutually exclusive. For example, VIDEO memory could be allocated as RAM, with or
* without a custom controller (the original Monochrome and CGA video cards used read/write storage that * without a custom controller (the original Monochrome and CGA video cards used read/write storage that
* was indistiguishable from RAM), and CTRL memory could be allocated as an empty block of any type, with * was indistinguishable from RAM), and CTRL memory could be allocated as an empty block of any type, with
* a custom controller. A few types are required for certain features (eg, ROM is required if you want * a custom controller. A few types are required for certain features (eg, ROM is required if you want
* read-only memory), but the larger purpose of these types is to help document the caller's intent and to * read-only memory), but the larger purpose of these types is to help document the caller's intent and to
* provide the Control Panel with the ability to highlight memory regions accordingly. * provide the Control Panel with the ability to highlight memory regions accordingly.