JP4858720B2 - Emulator, emulation method, program, and recording medium - Google Patents

Description

  The present invention relates to an emulator, an emulation method, a program, and a recording medium.

  As part of operations on server devices, installation assistance and execution of maintenance tools using FD (Floppy (registered trademark) Disk) have been generally performed. There are still many scenes where FD is used for security setting keyword information, application parameter information, simple device information setting and storage, and firmware updating.

  In recent years, there is a tendency that FD drives and older generation IO interface devices called legacy devices are not mounted. Improvements such as replacement of a tool operating on an operating system (also referred to simply as OS in the present application) and use of a remote virtual FD at a network destination have been made.

  However, improvements have not been made on all devices and applications. OS variations such as the rise of Linux (registered trademark) spread, it is difficult to prepare tools that can handle all OSs used by users, and there are cases where the OS itself fails or the network cannot be used. In such a case, there is no environment where a maintenance tool or the like can be executed. Therefore, as an indispensable option, there is a large cost burden on the user side, such as defining a Universal Serial Bus (USB) FD drive or preparing a separate USB FD drive. On the other hand, for the development side, there is a work burden of developing an online tool that operates on a rich OS and an offline operation maintenance tool that needs to handle both the presence and absence of the FD drive. Since multiple development is required, there is a negative effect that leads to an increase in development man-hours.

  In this way, work is not only troublesome, such as time and effort to continuously support operations with legacy interfaces, end user environment construction, and development vendors' increased development burden.

  Japanese Patent Laying-Open No. 2006-155673 (see Patent Document 1) describes an invention of an emulation device. This emulation apparatus causes a program for a target machine, which is a computer having an architecture different from the architecture of the execution machine, to be executed on an execution machine, which is a computer including at least an arithmetic processing unit, a storage unit, and an input / output unit. . The hard disk emulation unit of the emulation apparatus includes a first conversion unit, a second conversion unit, a system management information conversion unit, and a physical access processing unit. The first conversion means converts the physical address of the access position to the hard disk in the target machine into a logical address using information relating to the hard disk configuration of the target machine. The second conversion means converts the logical address into a physical address of the access position of the hard disk of the execution machine using information on the hard disk configuration of the execution machine. The system management information conversion unit converts system management information on the hard disk of the execution machine into system management information for the target machine. The physical access processing unit accesses the hard disk of the execution machine using the physical address and system management information converted by the second conversion unit.

  As described in Patent Document 1, the present invention mainly provides an environment for emulating a hard disk drive in a virtual PC environment. In addition to the high cost, which requires a separate hard disk drive emulator, the virtual disk implementation method is unique and the threshold is high. That is, the first problem in the invention of Patent Document 1 is that a relatively expensive system is required. This is because special hardware and applications are required. The second problem is that it is not possible to provide the same function as the conventional FD operation. This is because it is simply a hard disk emulation and cannot be replaced as a series of FD operation operations from startup. The third problem is lack of flexibility. This is because the apparatus does not assume remote virtual image reading and writing control.

  Japanese Patent Laid-Open No. 11-312127 (see Patent Document 2) describes an invention of an emulation method for external storage connected to a line. In the present invention, in a computer system in which a computer having an external storage device is connected via a line, a mode for emulating the external storage device of the other computer via a line is set in one computer. When there is a request to use the external storage device on the computer, the request is hooked and the data is requested to the external storage device of the other computer. It processes the request on the computer and responds to the requesting computer via the line.

JP 2006-155673 A Japanese Patent Laid-Open No. 11-312127

  An object of the present invention is to emulate a virtual FD that can be used even in the case of a failure of a standard OS installed or in a case where a network cannot be used.

  An emulator according to a first aspect of the present invention includes a virtual FD data storage unit and a virtual FD emulation unit. The virtual FD data storage unit stores virtual FD data that is the contents of the virtual FD. The virtual FD emulation unit emulates a virtual FD. The virtual FD emulation unit is generated when a computer executes an instruction code stored in a BIOS (Basic Input Output System), and the virtual FD data stored in the nonvolatile memory is converted into an operation memory by executing the instruction code. The virtual FD data storage unit is generated in the operation memory.

  The emulation method according to the second aspect of the present invention includes starting, memory expansion, and emulation. Starting starts execution of a predetermined instruction code stored in the BIOS. The memory expansion expands the virtual FD data stored in the nonvolatile memory to the operation memory by executing the predetermined instruction code. Emulation emulates a virtual FD containing virtual FD data as a result of execution of the predetermined instruction code.

  The program according to the third aspect of the present invention causes a computer to execute a starting procedure, a memory developing procedure, and a emulation procedure. The starting procedure starts execution of a predetermined instruction code stored in the BIOS. In the procedure for expanding the memory, the virtual FD data stored in the nonvolatile memory is expanded in the operation memory by executing the predetermined instruction code. The emulation procedure emulates a virtual FD containing virtual FD data as a result of execution of the predetermined instruction code. The computer-readable recording medium according to the fourth aspect of the present invention records this program.

  According to the present invention, it is possible to emulate a virtual FD that can be used even in the case of a failure of a standard OS installed or in a case where a network cannot be used.

  One of the best modes for carrying out the present invention will be described in detail with reference to the drawings. Referring to FIG. 1, a computer system using an emulation method in one embodiment of the present invention is shown. This computer system has a BIOS 102a that stores an instruction code for emulating a virtual FD. The BIOS 102a is known to have a hardware initial diagnosis function, a basic standard input / output interface function, a setup setting function, and the like. The BIOS 102 a is stored in the flash ROM 102. The flash ROM 102 is connected to the bus 100. The bus 100 includes a processor 101, a CMOS (Complementary Metal Oxide Semiconductor) 103 for storing hardware setting information, a LAN interface 104 connected to an external network, a CRT 105 which is a standard display device, and a standard input device. A keyboard 106, a main memory 107, which is a standard operation memory, an HDD 108, which is a standard external storage device, and the like are also connected. There is no physical FD drive in this computer system. The flash ROM 102 has a capacity of about 2 megabytes in order to secure an area for storing virtual FD data that is the contents of the virtual FD to be emulated.

  The BIOS 102a includes an instruction code for generating a virtual FD emulation unit that emulates the virtual FD. The virtual FD emulation unit reads virtual FD data from the flash ROM 102, expands the memory in the main memory, and stores the contents of the virtual FD. An instruction code for generating a virtual FD data storage unit for storing certain virtual FD data is included. The virtual FD emulation unit realizes basic functions and various additional functions of the virtual FD. The virtual FD data storage unit holds virtual FD data that is the contents of the virtual FD.

  The virtual FD emulation unit has a function of reading / writing virtual FD data in the flash ROM 102 from a remote terminal through the LAN interface 104 as an additional function. Thereby, virtual FD data can be replaced from a remote terminal. The display device 105 displays a POST (Power On Self Test) execution process of the BIOS 102a. When the user performs a hot key (HotKey) operation from the input device 106 at this timing, the virtual FD emulation unit and the virtual FD data storage are displayed. It is possible to instruct generation of a copy and activation of a virtual FD. Of course, an activation function can be given from a remote terminal at the network destination through the LAN interface 104 by an additional function.

  A method for starting the virtual FD will be described with reference to FIG. In FIG. 2, when POST of the BIOS 102a starts (flow 01), the hardware initialization phase is entered. When the hardware initialization phase ends normally (flow 02), it is confirmed whether there is a read request or a write request for virtual FD data stored in the flash ROM 102 from the remote terminal (decision 01). This confirmation can be performed by setting and referring to the read request flag and the write request flag of the virtual FD. If the read request flag is set from the remote terminal (determination 02: No), the virtual access data can be acquired on the remote terminal side by sending the virtual FD data from the flash ROM 102 by the network access module of the BIOS 102a. Yes (flow 04). If the write request flag is set (judgment 02: yes), the virtual FD data received from the remote terminal is written to the flash ROM 102 in the same network access module (flow 03), and the virtual FD data is updated.

  In FIG. 2, immediately before the end of POST, it is confirmed whether or not the virtual FD is instructed from the local (decision 03). This confirmation can be performed by referring to a virtual FD activation instruction flag that is set when the user presses HotKey or the like during POST. If there is a virtual FD activation request (determination 03: YES), the virtual FD data is expanded in the memory area reserved for the OS (flow 05). The memory area reserved for the OS is a memory area hidden from the OS. Subsequently, a handler (int13h) which is a runtime routine of the FD interface is hooked (flow 06). That is, the standard FD handler is for virtual FD access and is replaced with the corresponding interrupt vector address. Here, the address to the FD handler is a chain hook, and the int 13h processing other than the virtual FD is processed by a normal standard FD handler. As described above, when POST ends (flow 07), when the virtual FD is activated, the FD can be handled as if there is an FD that does not exist.

  The virtual FD emulation operation will be described in detail with reference to the flowchart of FIG. According to the flow of FIG. 2, when a hot key operation is performed, the virtual FD is activated from the time of OS activation. For example, it is assumed that a compatible DOS (registered trademark) system is activated from the virtual FD following the activation of the virtual FD.

  At this time, if there is a read access to the virtual FD, an FD interrupt (int13h) is generated (flow 11). By hooking int13h, the processing shifts to handler processing by the virtual FD handler (flow 12). First, since it is read access, it is determined that handler processing by the virtual FD handler is necessary (determination 11: yes). The virtual FD handler performs a read operation using the virtual FD data expanded in the main memory 107 (flow 13). Thereafter, the interrupt process is terminated and the process returns to the normal process (determination 12: No, flow 16).

  On the other hand, when there is a write access to the virtual FD, an FD interrupt (int13h) is generated (flow 11). By hooking int13h, the processing shifts to handler processing by the virtual FD handler (flow 12). First, since it is a write access, it is determined that handler processing by the virtual FD handler is necessary (determination 11: yes). The virtual FD handler performs a write operation using the virtual FD data expanded in the main memory 107 (flow 13). Subsequently, in order to update the virtual FD data in the virtual FD data storage unit, the flash ROM write-back flag is set to ON (determination 12: YES, flow 14). Thereafter, the interrupt process is terminated and the process returns to the normal process (flow 16).

  During normal OS operation, the user also goes through the virtual FD handler when starting a maintenance tool or the like recorded in the virtual FD (flows 11 and 12). When the maintenance tool in the virtual FD is activated, it is determined that handler processing by the virtual FD handler is necessary (determination 11: YES), and the maintenance tool is activated (flow 13). Thereafter, the maintenance tool can access the virtual FD via the virtual FD handler. That is, a file saving process, a changing process, and the like are executed in the virtual FD data storage unit generated by expanding the virtual FD data of the flash ROM 102 in the main memory 107 (flows 11, 12, and 13). When the maintenance tool performs a process with a write operation such as saving the result of the maintenance work (determination 12: YES), the virtual FD handler sets the flash ROM write-back flag to ON (flow 14), and the normal Return to processing (flow 16).

  The virtual FD data saving process will be described with reference to the flowchart of FIG. First, it is determined whether or not there is a request to write back the virtual FD data expanded in the memory to the flash ROM 102 (determination 21). If there is no write-back request (determination 21: no), it is determined whether there is a request to end the operation of the virtual FD (determination 22). If there is no termination request (determination 22: no), it is determined whether there is a software power-off (DC-OFF) or reset request (determination 23). If there is no power-off request and reset request (determination 23: no), the process returns to normal operation processing as it is (flow 21).

  When there is a write-back request (determination 21: yes), when there is an operation termination request (determination 22: yes), or when there is a power-off request or reset request (determination 23: yes), flash It is confirmed whether or not the ROM write-back flag is on (decision 24). As shown in the flow 14 of FIG. 3, when there is a change in the virtual FD data expanded in the memory, the flash ROM write-back flag is on. Using the detection of turning on of the write-back flag as a trigger (determination 24: YES), the virtual FD data stored in the flash ROM 102 is replaced with the virtual FD data developed in the memory (flow 22). Then, the virtual FD data saving process ends (flow 21).

  With the implementation of the BIOS 102a in this embodiment, even in an environment where an FD drive cannot be physically prepared, the OS can be activated and operated by a function equivalent to the OS activation by the physical FD. Therefore, a tool or the like that assumes FD use can be used even in the latest personal computer / server environment that does not have a physical FD drive. Thus, even if a network or OS failure occurs, the diagnostic tool can be executed alone.

  Further, not only can the virtual FD data stored in the flash ROM 102 be fixedly used, but also reading and writing to the flash ROM 102 can be performed by two means: normal use and use over a network. The latest virtual FD data can be acquired from another personal computer / server by using the network.

  Further, since virtual FD data storing a maintenance tool is stored in the flash ROM 102 from the time of shipment, the virtual FD data is stored in another partition of an HDD (Hard Disc Drive) or prepared on another medium such as a CD (Compact Disc). It is possible to provide value-added functions without having to In addition, the latest version can always be distributed through maintenance via the network, which can contribute to cost reduction.

    When a physical FD device (A: drive (or C: drive)) is connected locally, the virtual FD image can be used as a secondary FD drive (B: drive (or D: drive)). Functions can also be added. In this case, if there is an access to a physical FD device, as shown in FIG. 3, it is determined that the handler processing by the virtual FD handler is not necessary (determination 11: No), and normal FD handler processing is executed (flow). 15). A file can be moved or copied between the virtual FD and the local physical FD.

  In addition, an interface means for accessing the flash ROM of the network destination via the network can be provided when remote connection is performed by a BIOS unique network module during POST execution. As a result, reading and writing of virtual FD data can be realized regardless of local / remote. Therefore, even if the specification stores the virtual FD data in the flash ROM, it is possible to provide a function that is as convenient as or better than using a physical floppy (registered trademark) disk drive.

  The first effect of the present embodiment is that a computer system without a physical FD can be operated as if it has an FD. This is because the additional function of the BIOS provides a virtual FD and can emulate the FD operation alone. The second effect is that the virtual FD data stored in the flash ROM can be used as a removable disk in the same way as a normal FD, and the changed data can be used continuously after the next activation. The reason is that as an additional function of the BIOS, there is a function of writing updated virtual FD data back to the flash ROM. The third effect is that execution of various device configuration tools and the like can be instructed from a remote terminal. The reason is that a function for changing or taking over the virtual FD for activation from the remote is added to the BIOS.

  The fourth effect is that the cost can be reduced. The reason is that the virtual FD data is stored in the flash ROM and the virtual FD is controlled by the BIOS so that only the case where the FD is mounted is necessarily assumed, and other extra HW is unnecessary. It is. The fifth effect is that a more flexible usage method can be added than the case in which the actual FD is mounted. The reason is that a function capable of replacing virtual FD data from the remote terminal is added to the BIOS, and the activation utility can be switched from the remote terminal by operation. The sixth effect is to lower the failure rate. The reason is that a physical FDD device having a motor is not required and a virtual FD is realized by BIOS emulation, so that the risk of failure is minimized. A seventh effect is that a compatible solution using FD that has been conventionally provided can be provided even in a chipset configuration in which a legacy interface is excluded. This is because the virtual FD emulation unit generated by the BIOS is mounted by the BIOS so that there is no difference from the application operating on the OS.

  The present invention requires a higher level of maintainability in a PC / server system that has a hardware configuration in which an old interface such as an FD is not mounted because of the specifications of the latest chipset function and the like. Applicable. In particular, it is useful in the server field that requires an environment where it is necessary to continue to use the old FD unit, and in the server field that is expected to continue to implement the existing maintenance specifications.

FIG. 1 is a diagram showing a computer system using an emulation method according to an embodiment of the present invention. FIG. 2 is a flowchart for explaining a virtual FD activation method. FIG. 3 is a flowchart for explaining the virtual FD emulation operation. FIG. 4 is a flowchart illustrating the virtual FD data saving process.

Explanation of symbols

100 bus 101 processor 102 flash ROM
102a BIOS
103 CMOS
104 LAN interface 105 Display device 106 Input device 107 Main memory 108 External storage device

Claims (25)

A virtual FD data storage unit that stores virtual FD data that is the contents of a virtual FD (Floppy (registered trademark) Disk);
The instruction code of the BIOS stored in the nonvolatile memory (Basic Input Output System) computer is generated by executing the by the execution of the instruction code, expand the virtual FD data stored in the nonvolatile memory in the operation memory A virtual FD emulation unit that generates the virtual FD data storage unit in the operation memory and emulates the virtual FD ;
The virtual FD emulation unit is an emulator that switches between a virtual FD handler for the virtual FD data and a standard FD handler for a real FD based on access to the FD . The virtual FD emulation unit
The emulator according to claim 1, wherein a virtual FD handler that controls access to the virtual FD is hooked to a standard FD handler of the BIOS. The virtual FD emulation unit
The emulator according to claim 2, wherein the emulator is generated in response to a predetermined operation for requesting activation of the virtual FD. The virtual FD emulation unit
The emulator according to claim 3, wherein an access request is received from a remote terminal via a network by executing the instruction code. The virtual FD emulation unit
The emulator according to claim 4, wherein when the access request is a write request, virtual FD data is acquired from the remote terminal and the virtual FD data stored in the nonvolatile memory is updated. The virtual FD emulation unit
The emulator according to claim 5, wherein when the access request is a read request, virtual FD data stored in the nonvolatile memory is transferred to the remote terminal. The virtual FD emulation unit
When the FD is accessed, the virtual FD handler is activated,
The emulator according to claim 6, wherein reading or writing of virtual FD data stored in the virtual FD data storage unit is controlled. The virtual FD emulation unit
The emulator according to claim 7, wherein when the access to the FD is not a virtual FD but an access to a real FD, the processing of the virtual FD handler is canceled and the standard FD handler is started. The virtual FD emulation unit
When writing to the virtual FD data stored in the virtual FD data storage unit is detected, the write back flag is set to ON,
When the write-back flag is referred to at a predetermined timing and the write-back flag is set to ON, the virtual FD data stored in the virtual FD data storage unit
The emulator according to claim 8, wherein virtual FD data stored in the nonvolatile memory is updated. The virtual FD emulation unit
10. The predetermined timing is at least one of a write-back request command input, a virtual FD shutdown request command input, a computer system shutdown operation, and a computer system reset operation. Emulator. The virtual FD emulation unit
The emulator according to claim 10, wherein the virtual FD data stored in the nonvolatile memory is expanded in a memory area hidden from an operating system to generate the virtual FD data storage unit. Starting execution of a predetermined instruction code of the BIOS stored in the non-volatile memory ;
By executing the predetermined instruction code, the method comprising: memory deploy virtual FD data stored in the nonvolatile memory in the operation memory,
Emulating a virtual FD containing the virtual FD data by executing the predetermined instruction code ;
The emulation is
An emulation method including switching between a virtual FD handler for the virtual FD data and a standard FD handler for a real FD based on access to the FD . The emulation is
The emulation method according to claim 12, further comprising hooking a virtual FD handler that controls access to the virtual FD to the BIOS standard FD handler. Said starting is
The emulation method according to claim 13, further comprising: starting with a predetermined operation requesting activation of the virtual FD. The emulation is
The emulation method according to claim 14, further comprising receiving an access request from a remote terminal via a network. The emulation is
The emulation method according to claim 15, wherein when the access request is a write request, virtual FD data is acquired from the remote terminal and the virtual FD data stored in the nonvolatile memory is updated. The emulation is
The emulation method according to claim 16, wherein when the access request is a read request, virtual FD data stored in the nonvolatile memory is transferred to the remote terminal. The emulation is
Activating the virtual FD handler when there is access to the FD;
The emulation method according to claim 17, further comprising controlling reading or writing of virtual FD data expanded in the operation memory. The emulation is
The emulation according to claim 18, further comprising: canceling the processing of the virtual FD handler and starting the standard FD handler when the access to the FD is not a virtual FD but an access to a real FD. Method. The emulation is
When writing to the virtual FD data expanded in the operation memory is detected, setting a write-back flag on;
When the write-back flag is referred to at a predetermined timing and the write-back flag is set to ON, the virtual FD data stored in the operation memory is stored in the virtual memory stored in the nonvolatile memory. The emulation method according to claim 19, further comprising updating FD data. The emulation is
The virtual FD is defined as at least one of the predetermined timing as a write-back request command input, a virtual FD shutdown request command input, a computer system shutdown operation, and a computer system reset operation. The emulation method according to claim 20, further comprising updating data. The memory expansion is
The emulation method according to claim 21, further comprising: expanding the virtual FD data stored in the non-volatile memory into a memory area hidden from an operating system. A procedure for starting execution of a predetermined instruction code of the BIOS stored in the nonvolatile memory ;
By executing the predetermined instruction code, a step of memory deploy virtual FD data stored in the nonvolatile memory in the operation memory,
A program for causing a computer to execute a procedure for emulating a virtual FD including the virtual FD data by executing the predetermined instruction code ,
The emulation procedure is as follows:
Including a procedure of switching between a virtual FD handler for the virtual FD data and a standard FD handler for a real FD based on access to the FD
Program . The emulation procedure is as follows:
The program according to claim 23, comprising a procedure of hooking a virtual FD handler that controls access to the virtual FD to the BIOS standard FD handler.   A computer-readable recording medium on which the program according to claim 23 or 24 is recorded.

Images