JPH08339262A - External storage device for computer - Google Patents

Abstract

PURPOSE: To transfer data from an external storage device used for a computer game machine or the like to the game machine at a high speed. CONSTITUTION: This external storage device for a computer provided with a nonvolatile semiconductor memory for storing the data and a program and a mechanism for expanding compressed data on the memory is provided with a data structure composed of compressed files grouped and hierarchized by attaching data numbers to the respective compressed data and managing them by tables for the compressed data provided for the respective compressed files.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an external storage device used in a computer game machine using a non-volatile semiconductor memory such as a ROM cartridge.

[0002]

2. Description of the Related Art The basic structure of a computer game machine is a device for inputting data, a device for outputting data, and a computer main body, as in a general computer. The external storage device of the computer game machine is a CD-
ROM, ROM cartridge, IC card, etc. are used. These are sold as external storage media for each game software.

For example, a ROM mounted in an external storage device cannot be written, but a general external storage device has a writable memory (RAM) having a battery backup mechanism as shown in FIG. It is built in, and is devised so that it can memorize the state in the middle of the game and the password for each player.

FIG. 3 shows the basic hardware configuration of the computer game machine body. CPU is a central processing unit,
It is the core of the game console. The programs and data stored in the external storage device are subjected to processing such as program execution, data processing, and transfer by CPU analysis. Image data read from an external storage device or image data created by a program is sent to a VDC (video display controller) and processed (defined) into image data that can be displayed on a display.

Data processed by VDC is temporarily stored in VRAM. The data defined by VDC and stored in the VRAM is divided into background (background image) and sprite (protagonist of motion, etc.), and information such as its display pattern, display position on the display, and display color is added.

A VCE (video color encoder) converts a digital color image signal sent from VDC through a video output port into a CRT analog RGB signal and a video color signal based on color palette information stored in the VCE. , Output to an external video device.

On the other hand, sound information such as music and onomatopoeia analyzed by the CPU is a sound effect integrated with an image by a function of a stereo circuit configuration, a noise generation circuit, a low frequency generation circuit, etc. by a PSG (program sound generator). Is output to the speaker.

In many cases, a computer game machine handles image data including an animation or a photograph. In particular, games incorporating movie images and video natural images have recently come into the limelight. Image data, unlike text data, requires a large amount of memory. The closer it is to a natural picture, the more memory it requires. Also, animations are becoming more multicolored and more precise.

The finer the image to be handled and the more colors it has, the larger the image data amount becomes. Therefore, the external storage device that provides the game is required to be a large-capacity storage medium. However, since increasing the capacity of the storage medium increases the cost, it is difficult to simply apply the same to a home-use game machine that requires low cost.
Therefore, a commonly used method is data compression. There are various methods for compressing data.

By compressing the data, the memory capacity of the external storage medium for recording the data can be saved, but the compressed data cannot be used as it is. When the computer game machine reads the compressed data, it must revert to the original format of the data. This "returning to the original data" is called data expansion, and in a computer game machine using a conventional external storage device, this data expansion is performed by the CPU of the game machine body.

FIG. 4 is an explanatory diagram of a computer game machine using an external storage device having a non-volatile semiconductor memory. The image control means 9 is VDC, VCE, VRAM shown in FIG.
Equivalent to. The voice control means 10 corresponds to the PSG in FIG. The ROM 2 stores programs and data. First, when the power is turned on, the CPU 7 starts reading the program from a certain fixed address on the ROM 2 and analyzes and executes the program according to the logic of the program.

When there is a data read command in the program, the CPU 7 reads the data in the ROM 2 and RA
The data is expanded to M8, or depending on the type of data, the data is directly transferred to the image control means or the audio control means. These image control means and audio control means also operate under the control of the CPU 7.

[0013]

In the conventional computer game machine, if the data in the external storage device contains compressed data, it cannot be used even if it is sent directly to the image control means 9 or the audio control means 10. First, the compressed data is once read into the RAM 8 and then decompressed by the CPU 7 to restore the original raw data. With such compressed data, the CPU 7 had to spend processing time to decompress the data.

As described above, the conventional external storage device for a game machine is merely a storage medium for programs and data. When decompressing the compressed data, the CPU of the main body of the computer game machine must perform the decompression, and the CPU is burdened. Moreover, since the decompressed data was managed at the address, reading the data was complicated and the data management was troublesome.

FIG. 5 shows an example of the structure of a conventional compressed file. The program is stored in the non-compressed data format at the beginning of the ROM, and the compressed data is stored after that. Since the compression rate of compressed data differs depending on the content of the data, the size of each data differs as shown in the figure. In the conventional method, since the reading of data of different sizes must all be performed under this structure, the reading procedure is complicated and the data management is troublesome.

The present invention has found a method for reviewing the compressed file structure for recording compressed data and simplifying the reading procedure, with the goal of facilitating the management of compressed data and complicating the reading procedure. The purpose is to solve the above problems.

[0017]

According to the present invention, in order to solve the above problems, a data processing mechanism is provided so that an external storage device can perform all data handling when a data read command is issued from a CPU to a ROM. Is provided in the external storage device. The uncompressed data can be transferred to the game console as it is for use, but the compressed data requires data decompression. Therefore, the data processing mechanism provided for the external storage device to perform all data handling,
It is necessary to provide a compressed data decompression mechanism.

Up to now, the cause of the problem at the time of reading has been the structure of the compressed data. Therefore, in the present invention,
Related compressed data are grouped (compressed data links) and hierarchized so that the data can be managed easily. The related compressed data is grouped and made into a file, which is called a "compressed file" or a "compressed data file". Further, the compressed files are collectively registered in the ROM (compression file link). A collection of these compressed files is called a "compressed folder".

In the present invention, the ROM is in the form of a compressed folder.
When registering in, the head address of each compressed file is used as the base address, and the compressed files are managed by the base address. Therefore, the compressed file should be accessible at the base address. This alone is not much different from the conventional one just because the compressed data is grouped,
In the present invention, when collecting compressed data into a compressed file,
A data number is assigned to each compressed data, and management is performed with a compressed data table provided for each compressed file. As a result, compressed data can be accessed with this base address and data number.

That is, when the compressed data is accessed by the program, the access can be made by designating the data number by the conventional address-only read method, the reading of the compressed data is simplified, and the data management is facilitated. Of course, in order to enable such access, the data processing mechanism incorporated in the external storage device is provided with a compressed data ROM address generating mechanism for obtaining an address on the ROM from the base address and the data number.

[0021]

DESCRIPTION OF THE PREFERRED EMBODIMENTS As one embodiment of the present invention, the compressed file shown in FIG. In the figure, the length of each data in the compressed data table is 1 byte. The item that manages one compressed data is a data attribute and 1 byte for each of addresses H, M, and L, for a total of 4 bytes. Data attribute is 8 of D0-D7
The lower two bits D0 and D1 represent the data attribute (the type of data such as binary data and image four color data). 24 bits of address H, M, L (= 8
The start address of the actual compressed data is indicated by (bit x 3).

Next, the procedure for creating the compressed file shown in FIG. 1 will be described. FIG. 6 shows a data compression procedure. First, in step 1, data to be compressed is prepared. The data to be compressed is one-dimensional data (text data), four-color data (image data), 16-color data (image data), and the like. In step 2 it becomes compressed data.

However, if this is left as it is, there will be several thousand compressed data for one game, and it will be difficult to manage the data. Therefore, in the next step 3, for example, related compressed data such as background images and characters are linked to be combined into one compressed file. At this time, a compressed data table is created, and each compressed data is managed by a file number. Addresses H, M, and L are created for each file number, and the addresses at which the actual compressed data are stored are known from the addresses H, M, and L. Step 3
There will be multiple compressed files created by.

In step 4, when storing this in the actual ROM, the compressed folder is completed by designating and linking the addresses on the ROM for storing each compressed file. The address at this time is the base address of each compressed file.

A register group as shown in FIG. 7 is prepared as a register group for controlling the functions related to the expansion of the compressed data created as described above. CPU using this register group
To read the compressed data from the ROM, the procedure is as follows. 1. Base address setting 2. Data number setting 3. Decompression data length setting

After performing such processing, the CPU periodically asks the compressed data decompression mechanism, "Is decompressed data ready?" (Contents of the status register),
When the decompressed data is ready, the decompressed data is read. This periodical status check is called polling. After the data is read, compare the data, check the expanded data length register value,
Polling and reading are repeated until the requested number of data is read. FIG. 8 shows a flowchart of this reading process.

That is, as shown in the structure of the compressed file in FIG. 1, if only the base address of the compressed file, the read data number, and the data length when decompressed are set, the compressed data decompression mechanism will be the rest. Will read the compressed data, decompress it, and check the data. It suffices for the CPU to read the contents of the decompression data read register (“read data” in FIG. 7) that returns the decompression result in 1-byte units. In addition, in FIG.
"R" is a register used only when reading,
“R / W” is a register used for both reading and writing.

FIG. 9 shows an example of the structure of a data processing mechanism that supports the compressed data decompression / readout method and data management of the present invention. In the figure, 1 is an external storage device, 3 is a compressed data expansion mechanism, 4 is a compressed data ROM address generation mechanism, 5 is a ROM bank switching mechanism, and 11 is a compressed data storage R.
OM, 12 is a ROM for storing programs, 13 is a ROM interface block, 14 is a CPU interface block, and 15 is a data processing mechanism. The data number decoding block of the present invention is incorporated into the data ROM address generator. The address on the ROM where the compressed data is stored is automatically calculated by the compressed data ROM address generation mechanism from the base address and the data number of the compressed file.

[0029]

In the conventional computer game machine, the decompression of the compressed data is performed by software, and the memory management of the compressed data is performed by the address (address on the ROM). Therefore, in order to read the compressed data, it is necessary to specify the address, and the procedure and management thereof are complicated.

In the present invention, the related compressed data are grouped into a compressed file and the compressed files are grouped into a compressed folder to form a hierarchical structure that is easy to manage. Moreover, each compressed data in the compressed file is assigned a file number so that it can be managed by the data number. As a result, the compressed data can be read by the data number for the data reading, and the reading procedure is not only simplified, but it is not necessary to be aware of the existing position of the compressed data (address on the ROM).

For example, in the conventional method, since compressed data cannot be read unless the address is designated, it is always necessary to set the address of 24 bits (8 bits for each of the address registers L, M, and H). However, if the method of the present invention is used, compressed data can be read out directly by setting the data number in the data number register (8 bits). Since the data number is a simple value such as 1, 2, 3, ..., It is easy to set, and since it is sufficient to manage the compressed data for each compressed file, it is easy to manage the compressed data.

Further, the merit of data number management is
Grouping is easy because the management of the lower layer of the compressed file requires only numbers. Further, even if the size of the data is changed when the compressed data is changed, the change is only made on the ROM, and it is not necessary to change the program part accessing the compressed data by the data number. As a result, the amount of program change can be reduced. That is,
Management of compressed data by data number also has the advantage of improving development efficiency.

[Brief description of drawings]

FIG. 1 is an explanatory diagram of a structural example of a compressed file of the present invention.

FIG. 2 is an external storage device with a battery backup mechanism.

FIG. 3 is a block diagram of a conventional computer game machine.

FIG. 4 is an explanatory diagram of a configuration of a conventional external storage device and a computer game machine.

FIG. 5 is an explanatory diagram of a structural example of a conventional compressed file.

FIG. 6 is an explanatory diagram of a procedure for creating compressed data according to the embodiment of this invention.

FIG. 7 is an explanatory diagram of a compressed data decompression register group according to the embodiment of the present invention.

FIG. 8 is an explanatory diagram of a flow chart of a compressed data reading process in the embodiment of the present invention.

FIG. 9 is an explanatory diagram of a data processing mechanism according to the embodiment of this invention.

[Explanation of symbols]

 1 External Storage Device 2 ROM 3 Compressed Data Decompression Mechanism 4 Compressed Data ROM Address Generation Mechanism 5 ROM Bank Switching Mechanism 6 Computer Game Machine Main Body 7 CPU 8 RAM 9 Image Control Means 10 Voice Control Means 11 Compressed Data Storage ROM 12 For Program Storage ROM 13 ROM interface block 14 CPU interface block 15 Data processing mechanism

Claims (1)

[Claims] 1. A non-volatile semiconductor memory for storing data and programs, and an external storage device for a computer having a mechanism for decompressing compressed data on the memory, wherein each compressed data is given a data number, and compression is provided for each compressed file. An external storage device for a computer, which has a data structure composed of compressed files that are grouped and hierarchized by being managed by a data table.