Main Menu/Memory Map

To Main Menu
To Programming Menu

Mapping the Memory of a PC Computer

The contents of this page arose from my curiosity concerning how the memory in my PC computer is being utilized. To conduct my investigation in this matter, I wrote a program to show the contents of my computer's memory. I used the QBASIC computer language, one that used to be included in PC computers over a decade ago. The principal reason I had for using it was its PEEK command, which can be used to look at the contents of any memory location. Years ago, the PEEK command, and it's opposite, the POKE command, were used to make a computer do things that its included programming software was incapable of doing. My program can only look at the first megabyte of memory because of limitations in the QBASIC PEEK command.

Memory addresses and their contents are given here using the hexadecimal (Base 16) Number system, which is normally used by programmers. For those unfamiliar with it, the hexadecimal number sequence is illustrated below. 20 in hexadecimal is equivalent to 32 in decimal.

0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20

The memory of a PC computer is divided into segments, containing 64 kilobytes each (65,536 bytes, to be exact). . A value entered into a segment register in the microprocessor indicates which segment is to be accessed. Acceptable values are the hexadecimal numbers: 0, 1000, 2000, etc. My program is capable of accessing the first 16 segments of a PC's memory. (Totaling one megabyte.) This page, however, is only concerned with the first segment, Segment 0. It is a very important segment, containing memory pointers, device drivers, buffers, input/output ports, and other essential information required by the computer and its operating system.

It is difficult to visualize the contents of computer's memory, because the memory resources required by a computer running Windows are enormous. The contents of the Segment 0 of memory, containing all 65,536 memory addresses, are displayed in two different ways in the figures shown below. Because the numerical values stored at all these addresses are incomprehensible to most people, and would take up 256 screens for a single segment, I chose to design a program that can also represent them graphically in a much more compact format.

The figures below also show how different portions of memory are allocated. The memory allocation information was obtained from the MSDOS "MEM" function, and the System Summary printout that can be obtained through the START>Settings menu in Windows. Others were obtained from the Microsoft QuickBasic Bible.

Figure 1 displays the entire contents of the 64K memory block that makes up Segment 0. Each pixel represents the contents of one memory location. Each horizontal row in the display represents one 256 byte page (100 in hexadecimal). The numerical values (in decimal) indicated by the different colors are shown in Figure 2. Inspection of blue areas indicated that most contained lot of zeros alternating with mostly small numbers. This may be memory set aside that has not yet been put to use. The eight colored blocks located between H4100 and H8000 are probably associated with the 32 buffers that are indicated to be located there. The areas with apparent random color patterns relate to device drivers and hardware extensions, which are actually computer programs. Areas of memory that are white are likely bits of unused memory that still contain the default hexadecimal value of FF (255 in decimal).

. . . . . . . . . . . . . . . . . . . . . . . . . .FIGURE 1

FIGURE 2 . . . . . .

Figures 3 and 4 summarize the entire contents of Segment 0 in a different way. Each colored line contains the mean value of one 256 byte page of memory. Figure 4 is a magnified portion of Segment 0 that shows some important memory locations in the very important first four kilobytes of memory. The colored bands make it easier to see how different portions are allocated for different uses. It is difficult to relate any color directly to this content, but one can make some generalizations, by comparing Figures 1 and 3. For instance, the blue-green and green blocks appear to be for data storage, since the buffers are located there. The gray areas seem to correspond to the areas where machine code is located. The dotted lines in the gray zones are an artifice that resulted from conversion from bitmat to gif format. As mentioned above, the blue areas appear to be allocated memory that is mostly empty. Those who are familiar with genetics will notice that Figures 3 and 4 bear a similarity in appearance and function to a chromosome map.




. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .FIGURE 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FIGURE 4

Figure 5 shows a comparison of the memory contents of PC's with different Windows operating systems. As one would expect, there appears to be a considerable difference in the memory contents of Windows95 and Windows 3.1, since the latter is an MSDOS based program. Surprisingly, there is also quite a big difference between Windows 95 and Windows 98. The blue strips (indicating mostly blank space) may be more prominent on the Windows 98 display, because the laptop computer it was taken from has fewer device drivers installed.


. . . . . . . . . . . . . . . . . . . . . . .FIGURE 5


To Main Menu
To Programming Menu


http://www.nfinity.com/~exile/progmenu.htm
Email: edperley@juno.com
Date created: March 2006