JPH05265763A - Memory controller for personal computer - Google Patents

Abstract

PURPOSE:To reduce the residence value of a device driver in a main memory and to expand a free memory for a personal computer which uses an MS-DOS as an OS by securing the correspondence between the RAM mounted on an extended interface board and an extended ROM area and adding a function to the device driver to transfer its execution part to the extended ROM area. CONSTITUTION:A device driver 20 has a structure decided by an MS-DOS and consists of a main memory resident part including a driver head 21, a strategy routine 22, and an interruption routine 23 of only a jump table having the memory occupancy value of several tens to hundreds of bytes, an initializing program 24 which has a transfer function and disappears by its own erasing function after the initialization, and a device driver execution program 25 which has only a command processing function and is transferred to a RAM set on an extended interface board.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention reduces the memory occupancy of a resident program resident in the main memory in a personal computer adopting MS-DOS as an operating system to reduce the free area of the main memory. The present invention relates to a memory management device for a personal computer, which is to be expanded.

[0002]

2. Description of the Related Art In recent years, personal computers, which have become widespread not only for business use but also for personal use, are operating worldwide as MS-operating systems (OS).
The majority of models adopt DOS (operating system developed by Microsoft Corporation in the United States; registered trademark). The hardware of the personal computer is a CPU from Intel 8086 (registered trademark; or its equivalent, the same applies below) as a CPU with the progress of semiconductors.
With the adoption of the 80286, 80386 and 80486, the MS-DOS version was also upgraded in response to such higher CPU functionality, and in 1991 MS-DOS ver5 was announced.

In order to maintain the compatibility, the personal computer adopting the above MS-DOS inherits the initial technical limitation of adopting the Intel 8086 as a CPU, and the memory management is one of them. .. That is, the CPU basically starts from the lowest address no matter how many memories are mounted on the personal computer.
Only 640 KB area memory (hereinafter referred to as main memory) can be managed. Due to this restriction, if a large number of resident programs such as device drivers (programs for placing devices such as a printer, mouse, hard disk, etc. connected to a personal computer under the control of the OS) in the main memory are made resident, a free area in the main memory In other words, if the free memory decreases and the application program you want to run is large (for example, 500 KB), it may not start.

As a countermeasure against this, a technique for reducing the amount of memory used by other than the application program in the main memory is demanded, and one of them is EMS (Expanded).
Memory Specification) was proposed. The EMS is composed of a program resident in the main memory and an EMS-Window configured outside the main memory, and when receiving an instruction from the program by bank switching, the EMS is used.
By looking inside the address corresponding to S-Window, the operation is performed as if the memory amount was increased. However, the EMS is suitable for storing data because it looks in the address corresponding to the EMS-Window only when the above-mentioned program instructs, but the MS-DOS as the OS is suitable.
It is not suitable for resident device driver, which needs to be resident in main memory so that it can be searched anytime from.

Therefore, the MS-DOS announced in 1991
By adopting ver5 as the OS and a model equipped with 80386 or later as the CPU, D in the main memory
A UMB (Upper Memo) at a higher address (640 KB or later) than the main memory is issued by a command from the OS shell.
A technique for transferring a device driver or the like to an extended ROM area (usually unused) called a ry block has been proposed. With this technique, the free memory of the main memory can be increased to improve the operating environment of the application program. In addition, each C when using MS-DOS ver5
The memory map in PU is shown in FIGS. 8 (a)-(c).

[0006]

Since the technology using UMB cannot be realized without combining MS-DOS ver5 and 80386 or later, it is currently used as a CPU.
A user who owns a model equipped with 80286, 8086, 8088, V30, etc. cannot use the technology to increase the free memory of the main memory by UMB unless the personal computer is replaced, and MS-DOS ver5
Also has to be purchased, and the financial burden on the user is extremely large.

It is an object of the present invention to provide a memory management device for a personal computer which realizes a free memory expansion function equivalent to the above UMB in a model equipped with 80286, 8086, 8088, V30 etc. as a CPU.

[0008]

To this end, a memory management device for a personal computer according to the present invention is a personal computer which employs MS-DOS as an operating system, and which comprises a main memory and an external device. In an external device interface expansion area provided inside or outside a personal computer, an expansion interface board mounted in the external device interface expansion area and equipped with a random access memory and an expansion interface circuit, and the expansion interface circuit. A program for driving, which has a function of transferring part or all of an execution part of the program to the random access memory, and is stored in the main memory. Is characterized in that comprising comprises a ram.

[0009]

According to the present invention, when an external device such as a hard disk is connected to a personal computer adopting MS-DOS as an operating system,
An extension interface board equipped with a random access memory and an extension interface circuit is mounted in an external device interface extension area provided inside or outside the personal computer, and a program for driving the extension interface circuit is stored in the main memory. However, since the program is provided with the function of transferring a part or all of its execution part to the random access memory, the memory amount of the resident program resident in the main memory is reduced, and the free of the main memory is reduced. The operating environment of the application program can be improved by increasing the memory.

[0010]

Embodiments of the present invention will now be described in detail with reference to the drawings. FIG. 1 is a diagram showing the configuration of a first embodiment of a memory management device for a personal computer according to the present invention.
10 indicates a CPU. The personal computer of this example is an MS-DOS version earlier than MS-DOS ver5.
The following description will be developed assuming that (for example, ver3.x) is installed, but it goes without saying that it can also be applied to the case of MS-DOS ver5. As CPU10, 80286, 80
Use 86, 8088, V30, etc. The CPU 10, via the system bus 11, memory 12, keyboard 13, display
14, a floppy disk device (FDD) 15 and a hard disk device (HDD) 16 are connected, and an external device 18 is further connected via an expansion interface board 17 and a SCSI bus 19.

As shown in FIG. 2, the expansion interface board 17 has a SCSI protocol controller (hereinafter referred to as S
17a and random access memory (RA
M) 17b and an address decoder 17c having a circuit for allocating the SPC 17a and the RAM 17b to a predetermined address of the memory 12 of the personal computer, and the SPC 17a and the address decoder 17c constitute an extended interface circuit. In the personal computer of this example configured as a desktop type, the expansion interface board 17 is mounted on an expansion interface board (not shown) which is an external device interface expansion area provided therein.
If the personal computer is configured as a notebook, no expansion interface board is prepared, so an external device interface expansion provided outside the personal computer via an expansion bus connector, adapter, etc. (neither is shown) Attach to the area.

SPC17 of the expansion interface board 17
SCSI bus 19 is connected to a.
An external device 18 is connected to the bus 19. As the external device 18, a SCSI such as an auxiliary floppy disk device, an auxiliary hard disk device, or a magneto-optical recording / reproducing device (MO) is used.
A device conforming to the standard shall be used.

Next, the device driver 20 used in this example will be described. Generally, the device driver is a program for placing devices such as a printer, a mouse, and a hard disk connected to a personal computer under the control of the OS, and is a resident program resident in the main memory. The device driver 20 of this example is arranged on the memory 12 as follows. That is, FIG. 3 in which only the portion according to the present invention of the memory 12 in which each region is divided into the configuration shown in FIG. 8A or 8B according to the mounted CPU is shown in FIG.
In the main memory, an OS (MS-DOS) is arranged in a predetermined area from the lowest address, and in the resident program area of the higher address, the resident portion of the device driver 20 of this example together with other resident programs and the like. 20a is placed.

The resident section 20a accommodates only a jump table to the device driver execution section 20b. Based on a command from the resident section 20a, the resident section 20a executes the main memory as described later in detail. The execution unit 20b transfers the data to the expansion ROM area secured outside. The expansion ROM area is the UM in the above-mentioned MS-DOS ver5.
This expansion ROM area originally needs to be rewritten by changing the hardware of the personal computer in the ROM BIOS located near 1 MB shown in FIGS. 8 (a) and 8 (b). Since it is an area secured so that a new ROM BIOS can be stored when it occurs, it is normally unused (empty). The RAM 17b corresponds to the address corresponding to the expansion ROM area by mounting the expansion interface board 17 on an expansion interface board (not shown). Therefore, actually, the execution unit 20b is transferred to the RAM 17b. The expansion ROM area is used.

Next, the configuration of the device driver 20 of this example will be described in comparison with a conventional (normal) device driver. First, explaining from the conventional device driver 30,
Since the device driver is generally not recognized as a device driver unless it has a structure (format) defined by MS-DOS, the conventional device driver 30 is shown in FIG.
It has a structure shown in (b) and comprises a driver head 31, a strategy routine 32, an interrupt routine 33 and an initialization program 34.

In the driver head 31, when a plurality of device drivers are loaded, a link pointer indicating the address of the device driver of the lower adjacent address, attribute data indicating the type of the device driver, an entry pointer of the strategy routine, and an interrupt routine. The entry pointer, the name of the device, and the number of units are described. Strategy routine 32 is MS-DO
S receives an address storing a data packet for giving an instruction to the device driver. The interrupt routine 33 is an execution program for actually processing a device driver command. The initialization program 34 is a program that initializes the device driver itself and its operating environment. This device driver 30 initially loads all areas (31) shown in Fig. 4 (b).
+32 +33 +34) is the memory occupancy in the main memory, but it is initialized when the initialization program 34 is executed in the first processing and initialization (for example, checking the type of external device 18, connection status, etc.) is completed. Program
Since 34 is deleted from the main memory, the resident amount in the main memory is (31 + 32 + 33). The self-erasing function of the initialization program is realized, for example, by designating the resident final address of the device driver after the initialization is completed.

On the other hand, the device driver 20 of this example is shown in FIG.
As shown in (a), a driver head 21 and a strategy routine 22 (which are exactly the same as the above-mentioned driver head 31 and strategy routine 32), which are parts (structure) defined by MS-DOS, are provided. It is the same as the device driver 30 except that interrupt routine 2
3. The device driver 30 differs from the device driver 30 in that the configuration of the initialization program 24 is changed and the device driver execution program 25 is independent. That is, the initialization program 24 has a device driver execution program (having the command processing capability of the device driver) 25 in addition to the original initialization function as an extension interface board.
It is also configured to have a function of transferring to the RAM 17b on the memory 17. Therefore, the device driver execution program 25 is separated from the interrupt routine 23, and a jump for transferring control to the device driver execution program 25 transferred to the RAM 17b on the expansion interface board 17 is performed in the interrupt routine 23. Only tables (only tens to hundreds of bytes occupy memory) are stored. The driver head 21, the strategy routine 22 and the interrupt routine 23 are the resident section 20a shown in FIG.
Device driver execution program 25
Corresponds to 20b.

When the device driver 20 of this example is loaded, the entire area (21 + 22 + 23 + 24 + 25) shown in FIG. 4 (a) becomes the memory occupancy on the main memory. When it is executed and initialization is completed, the initialization program 24 is erased from the main memory, and the device driver execution program 25 is transferred to the outside of the main memory by a command from the initialization program 24. The resident amount is (21 + 22 +
23), which is significantly reduced, and the free area of main memory is increased accordingly.

Next, the operation of the device driver 20 of this example will be described in comparison with a conventional system or the like. First,
When a conventional device driver is used in a conventional system (for example, a system that uses MS-DOS ver3.x as an OS in a personal computer equipped with an 8086 CPU), a file name required for CONFIG.SYS of MS-DOS is specified, for example. By writing in the following format (for example, DEVICE = a), the device driver is sequentially loaded into the resident program area of the main memory from the lower address as shown in FIG.
When 30a, 30b, and 30c are arranged in a chain, the link pointer of each device driver stores the start address of the device driver on the lower address side, so when searching for the desired device driver, first The device driver 30c on the higher-order address side is searched, and the device drivers 30b and 30a are sequentially searched as indicated by arrows in the drawing. If the device driver of the external device to be connected is found by this search, the execution program of the device driver is executed. In this conventional system, all the device drivers are resident in the main memory, so the resident amount is the largest.

In a personal computer equipped with a CPU of 80386 or later, MS-DOS is used as the OS.
When a conventional device driver is used in a system configuration that uses ver5, for example, a file name required for CONFIG.SYS of MS-DOS ver5 has a predetermined format (for example DEVICE =
a, DEVICEHIGH = b), the device drivers 30a and 30c are sequentially arranged from the lower address in the resident program area of the main memory as shown in FIG. 6, and the device driver is placed in the expansion ROM area (UMB).
When 30b is placed, the link pointer of each device driver stores the start address of the device driver on the lower address side, so the same search as above is performed.
The execution program is executed. Although the resident address of the device driver is different between the conventional system and the system using MS-DOS ver5, it is necessary to load and manage the device driver at that address.
It is common in that DOS does.

On the other hand, when the device driver 20 of this example is used in the above conventional system, for example, CONF of MS-DOS is used.
Enter the file name required for IG.SYS in the specified format (for example, DE
By writing with VICE = a), when device drivers 30a, 20 and 30c are sequentially arranged in a chain from the lower address to the resident program area of the main memory as shown in FIG. If the other device drivers are the conventional device drivers, the conventional device drivers 30a and 30c reside in the main memory as in the conventional device driver.
20 is a resident part (driver head 21, driver head 21) by the transfer function and the self-erasing function of the initialization program 24 described above.
Only the strategy routine 22 and the interrupt routine 23) reside in the main memory, and the device driver execution program 25 that occupies most of the device driver 20 is the expansion ROM.
It is transferred to the area and resides there.

In this resident state, the MS-DO
The appearance as seen from S is a chained device driver arrangement similar to the above-described conventional system. Therefore, with the MS-DOS, as in the above conventional system,
The device driver is searched and executed by the start address of the device driver on the lower address side stored in the link pointer of each device driver, and compatibility is ensured even if the version of the MS-DOS concerned is different. ..

The system using the above MS-DOS ver5 is common to this example in that the device driver resides in the same memory address space (extended ROM area), but the following points are different from this example. First, the MS
-In the system using DOS ver5, the device driver is directly loaded in the expansion ROM area because MS-DOS ver5 itself has a transfer function. In this example, the device driver itself once loaded in the main memory executes its execution unit. Transfer only to the expansion ROM area. Second, MS-DO
Since Sver5 uses a device driver of the same structure as the conventional one, MS-DOS ver5 manages the device driver. However, in this example, a device driver of a different structure is used, so the main body (execution unit) of the device driver is managed by MS-DOS. It can reside outside of memory.

The present invention is not limited to the above-mentioned embodiments, and various modifications and changes can be added. For example,
Even in the case of resident programs other than device drivers, the structure is divided into a main memory resident section that has only a jump table that has a jump function and an extended ROM area resident section that has only an execution program that has a command processing function. If so, the main memory resident amount is reduced. In addition, the required device driver
If the device driver having the structure of this example is used as much as possible within the range that can be stored in the area, the resident amount of the main memory is further reduced.

[0025]

As described above, according to the present invention, a program for driving an expansion interface circuit of an expansion interface board having a random access memory corresponding to a memory expansion area provided inside or outside a personal computer is provided. Since it is stored in the main memory and a part or all of its execution part is transferred to the random access memory, the memory amount of the resident program resident in the main memory is reduced, and the main memory is free. The operating environment of the application program can be improved by increasing the memory.

[Brief description of drawings]

FIG. 1 is a diagram showing the configuration of a first embodiment of a memory management device for a personal computer according to the present invention.

FIG. 2 is a diagram showing a configuration of an extension interface board used in the same example.

FIG. 3 is a diagram for explaining a memory configuration in the same example.

FIG. 4A is a diagram showing a configuration of a device driver used in the same example, and FIG. 4B is a diagram showing a configuration of a conventional device driver.

FIG. 5 is a diagram for explaining the operation of the device driver of the same example.

FIG. 6 is a diagram for explaining the operation of a conventional device driver in a system using MS-DOS ver5.

FIG. 7 is a diagram for explaining the operation of a conventional device driver in a system using MS-DOS ver3.x or the like.

8A, 8B, and 8C are diagrams for explaining a memory configuration for each system configuration.

[Explanation of symbols]

 10 CPU 11 System bus 12 Memory 17 Expansion interface board 18 External device 19 SCSI bus 20 Device driver 21 Driver head 22 Strategy routine 23 Interrupt routine 24 Initialization program 25 Device driver execution program

─────────────────────────────────────────────────── ───

[Procedure amendment]

[Submission date] April 20, 1992

[Procedure Amendment 1]

[Document name to be amended] Statement

[Correction target item name] 0004

[Correction method] Change

[Correction content]

As a countermeasure against this, a technique for reducing the amount of memory used by other than the application program in the main memory is demanded, and one of them is EMS (Expanded).
Memory Specification) was proposed. The EMS is composed of a program resident in the main memory and an EMS-Window configured outside the main memory, and E is issued when a command is received from the program by bank switching.
By looking inside the corresponding address of MS-Window, the operation is performed as if the memory amount was increased. However, the EMS is suitable for storing data because it looks in the corresponding address of the EMS-Window only when the program instructs it, but the MS-DO as an OS is suitable.
It is not suitable for resident device driver, which needs to be resident in the main memory so that it can be searched anytime from S.

[Procedure Amendment 2]

[Document name to be amended] Statement

[Correction target item name] 0006

[Correction method] Change

[Correction content]

[0006]

Since the technology using UMB cannot be realized without combining MS-DOS ver5 and 80386 or later, it is currently used as a CPU.
A user who owns a model equipped with 80286, 8086, 8088, V30, etc. cannot use the technology to increase the free memory of the main memory by UMB unless the CPU or personal computer is replaced.
-It is necessary to also purchase DOS ver5, and the financial burden on the user is extremely large.

[Procedure 3]

[Document name to be amended] Statement

[Correction target item name] 0015

[Correction method] Change

[Correction content]

Next, the configuration of the device driver 20 of this example will be described in comparison with a conventional (normal) device driver. First, explaining from the conventional device driver 30,
Since the device driver is generally not recognized as a device driver unless it has a structure (format) defined by MS-DOS, the conventional device driver 30 is shown in FIG.
It has a structure shown in (b) and comprises a driver header 31, a strategy routine 32, an interrupt routine 33, and an initialization program 34.

[Procedure amendment 4]

[Document name to be amended] Statement

[Correction target item name] 0016

[Correction method] Change

[Correction content]

In the driver header 31, when a plurality of device drivers are loaded, a link pointer indicating the address of the device driver of the lower adjacent address, attribute data indicating the type of the device driver, an entry pointer of the strategy routine, and an interrupt routine. The entry pointer, the name of the device, and the number of units are described. Strategy routine 32 is MS-DO
S receives an address storing a data packet for giving an instruction to the device driver. The interrupt routine 33 is an execution program for actually processing a device driver command. The initialization program 34 is a program that initializes the device driver itself and its operating environment. This device driver 30 initially loads all areas (31) shown in Fig. 4 (b).
+32 +33 +34) is the memory occupancy in the main memory, but it is initialized when the initialization program 34 is executed in the first processing and initialization (for example, checking the type of external device 18, connection status, etc.) is completed. Program
Since 34 is deleted from the main memory, the resident amount in the main memory is (31 + 32 + 33). The self-erasing function of the initialization program is realized, for example, by designating the resident final address of the device driver after the initialization is completed.

[Procedure Amendment 5]

[Document name to be amended] Statement

[Correction target item name] 0017

[Correction method] Change

[Correction content]

On the other hand, the device driver 20 of this example is shown in FIG.
As shown in (a), the driver header 21 and the strategy routine 22 (which are exactly the same as the driver header 31 and the strategy routine 32 described above), which are the parts (structure) defined by MS-DOS, are included. It is the same as the device driver 30 except that interrupt routine 2
3. The device driver 30 differs from the device driver 30 in that the configuration of the initialization program 24 is changed and the device driver execution program 25 is independent. That is, the initialization program 24 has a device driver execution program (having the command processing capability of the device driver) 25 in addition to the original initialization function as an extension interface board.
It is also configured to have a function of transferring to the RAM 17b on the memory 17. Therefore, the device driver execution program 25 is separated from the interrupt routine 23, and a jump for transferring control to the device driver execution program 25 transferred to the RAM 17b on the expansion interface board 17 is performed in the interrupt routine 23. Only tables (only tens to hundreds of bytes occupy memory) are stored. The driver header 21, the strategy routine 22 and the interrupt routine 23 are the resident section 20a of FIG.
Device driver execution program 25
Corresponds to 20b.

[Procedure Amendment 6]

[Document name to be amended] Statement

[Correction target item name] 0021

[Correction method] Change

[Correction content]

On the other hand, when the device driver 20 of this example is used in the above conventional system, for example, CONF of MS-DOS is used.
Enter the file name required for IG.SYS in the specified format (for example, DE
By writing with VICE = a), when device drivers 30a, 20 and 30c are sequentially arranged in a chain from the lower address to the resident program area of the main memory as shown in FIG. If the other device drivers are the conventional device drivers, the conventional device drivers 30a and 30c reside in the main memory as in the conventional device driver.
20 is a resident portion (driver header 21,
Only the strategy routine 22 and the interrupt routine 23) reside in the main memory, and the device driver execution program 25 that occupies most of the device driver 20 is the expansion ROM.
It is transferred to the area and resides there.

[Procedure Amendment 7]

[Document name to be amended] Statement

[Name of item to be corrected] Brief description of the drawing

[Correction method] Change

[Correction content]

[Brief description of drawings]

FIG. 1 is a diagram showing the configuration of a first embodiment of a memory management device for a personal computer according to the present invention.

FIG. 2 is a diagram showing a configuration of an extension interface board used in the same example.

FIG. 3 is a diagram for explaining a memory configuration in the same example.

FIG. 4A is a diagram showing a configuration of a device driver used in the same example, and FIG. 4B is a diagram showing a configuration of a conventional device driver.

FIG. 5 is a diagram for explaining the operation of the device driver of the same example.

FIG. 6 is a diagram for explaining the operation of a conventional device driver in a system using MS-DOS ver5.

FIG. 7 is a diagram for explaining the operation of a conventional device driver in a system using MS-DOS ver3.x or the like.

8A, 8B, and 8C are diagrams for explaining a memory configuration for each system configuration.

[Explanation of symbols] 10 CPU 11 System bus 12 Memory 17 Expansion interface board 18 External device 19 SCSI bus 20 Device driver 21 Driver header 22 Strategy routine 23 Interrupt routine 24 Initialization program 25 Device driver execution program ────── ────────────────────────────────────────────────

[Procedure amendment]

[Submission date] April 20, 1992

[Procedure Amendment 1]

[Document name to be corrected] Drawing

[Name of item to be corrected] Figure 3

[Correction method] Change

[Correction content]

[Figure 3]

[Procedure Amendment 2]

[Document name to be corrected] Drawing

[Name of item to be corrected] Fig. 4

[Correction method] Change

[Correction content]

[Figure 4]

Claims (1)

[Claims] 1. MS- as an operating system
A personal computer employing DOS, comprising a main memory and an external device, wherein an external device interface extension area provided inside or outside the personal computer and attached to the external device interface extension area An extension interface board equipped with an access memory and an extension interface circuit, and a program for driving the extension interface circuit, having a function of transferring a part or all of an execution part of the program to the random access memory. A memory management device for a personal computer, comprising: a program stored in the main memory.