JP2007318792A - Television schedule information transmission and utilization system and process - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an interactive television program schedule system and method capable of executing processing with an inexpensive mricroprocessor and memories in subscriber data processing systems. <P>SOLUTION: The television schedule information transmission system includes a central data processing system, a means of providing schedule information data of a television program as to a prescribed territory to the central data processing system, a means for transmitting the schedule information data as to the prescribed territory with a prescribed schedule information transmission format, a plurality of regional data processing systems existing in one region of the prescribed territory, and a plurality of subscriber data processing systems. Each of the subscriber data processing systems respectively includes a means for extracting at least part of the schedule information data, a means for storing the schedule information data, and a means for assembling parts of the extracted schedule information data. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention generally relates to systems and methods for broadcasting, receiving and utilizing television schedule information. More particularly, the present invention provides that television schedule information is broadcast, for example, during a television broadcast vertical blanking interval (VBI), the user's broadcast area or cable system television program schedule is compiled from the broadcast and The present invention relates to a system and method in which a schedule is displayed on a user's television receiver and used interactively. As used herein, the term “broadcast” is used in a broad sense to include transmission modes such as cable and telephone transmission.

  It is known to provide an interactive television program schedule system using broadcast schedule information. For example, such a scheduling system is described in commonly assigned Young's US Pat. No. 4,706,121 dated Nov. 10, 1987, and Young et al., US patent application Ser. No. 08 / 198,538. Is disclosed.

  In such a schedule system configuration, a user device that receives broadcast schedule information, edits a user's broadcast area or cable system schedule, displays the schedule on the user's television receiver, and interacts with the user. Can be offered at a sufficiently low price for mass sales, but only a limited amount of memory and data processing capabilities are provided. This memory and data processing limitation is recognized by Harlenbeck, US Pat. No. 5,038,211 dated August 6, 1991. The solution proposed by Harenbeck splits the schedule information into prioritized classifications and uses the highest priority classification and as many lower priority classifications as possible. It is stored in memory. A significant problem with this solution is that when there are a large number of programs in the schedule and the need for a lot of information is great, little information is given about the programs in the schedule. Therefore, in view of memory and processor limitations of consumer electronic devices. Further development is required.

  When schedule information is transmitted as part of a program broadcast signal and a known subscriber unit collects schedule information from the program broadcast signal, a potential problem occurs when an already broadcast program is recorded and played back on a VCR. Occurs. Known subscriber units lack the ability to distinguish video signals generated from recorded programs from video signals received in real time from broadcasts. As a result, the subscriber unit overwrites the old program schedule information coming from the video tape with the latest program schedule information collected from the real-time broadcast.

  Proposals for transmitting television schedule information along with television broadcast signals often use low bandwidth transmission modes such as one or more lines in the vertical blanking interval (VBI) of the television broadcast signal. The use of such a low bandwidth transmission mode means that the transmission format and management must be carefully planned to avoid practical problems. For example, when a schedule update is to be sent, the worst transmission delay until the update is received and enters the user's subscriber unit reaches 5 hours unless a special configuration is provided for such an update. This is the complete schedule transmission time for one week in an NTSC television broadcast signal using one VBI line for schedule information. If there is a slight schedule change at the end, such a delay is not acceptable.

In the case of a broadcast television schedule system based on a contract, data encryption is important. If the data is not encrypted, schedule information can be collected and used by a pirated user device without paying a contract fee. Conventional solutions for encrypting all schedule information transmissions require a faster and more expensive microprocessor than is suitable as a subscriber unit.

  When implementing a television schedule system on a national or international basis, constructs for different time zones must be created. Adjusting the schedule time for different time zones in the process of sending a schedule adds considerable overhead to data transmission. It is desirable to eliminate the need for such adjustments in transmission.

  In the operation of a television schedule system, it is desirable to provide schedule information embedded in different parts of the television signal in different parts of the system, eliminating the need to impose uniformity across the system. For this reason, it is necessary to provide a way for the recipient of the schedule information to identify it in the television signal.

  In the operation of a broadcast television schedule system, a significant portion of the available microprocessor processing time is spent when collecting new schedule information by a subscriber unit. When old schedule information is deleted and new schedule information is collected, a substantial portion of the new information, such as program titles, should be deleted along with information already in the stored schedule information or old schedule information Duplicate information. Avoiding the deletion of information that forms part of the new schedule information helps to minimize the amount of processor time allocated to the collection of new schedule information.

  Because consumer electronic products have a number of memory constraints, it is necessary to use the memory efficiently to provide the subscriber unit with as much information and as much functionality as possible with the available memory.

  Accordingly, it is an object of the present invention to provide an interactive television program schedule system and method that can be implemented in a subscriber data processing system with a low cost microprocessor and memory.

  Another object of the present invention is to transmit and store television program schedule data so that a subset search of television program schedule data can be performed on a low cost microprocessor suitable for use in mass-produced consumer products. An interactive television program schedule system and method is provided.

  Yet another object of the present invention is to provide a system and method for transmitting television program schedule information in an efficient manner.

  Yet another object of the present invention is to provide a system and method for efficiently collecting television program schedule information by a subscriber data system.

  Yet another object of the present invention is to provide a system and method that allows fast schedule updates to accept schedule updates in a low bandwidth transmission system.

  Yet another object of the present invention is to provide a system and method that allows distinguishing between currently broadcast schedule information and old schedule information included with a recorded broadcast.

  Yet another object of the present invention is to provide a system and method for providing priority processing to schedule update information.

  Yet another object of the present invention is to provide a system and method for selectively encrypting schedule information transmissions.

  It is yet another object of the present invention to provide a system and method that uses a single system time for the schedule information transmission portion of the system and provides local time compensation at the subscriber unit.

  Yet another object of the present invention is to provide a system and method that allows subscriber units to identify schedule information provided at different locations in a television broadcast signal.

  Yet another object of the present invention is to keep a part of the schedule information that has already been collected by the subscriber unit and overlap with the part of the new schedule information, and collect such part of the schedule information again at the subscriber unit. It is to provide a system and method that eliminates the need.

  Yet another object of the present invention is to provide a system and method that uses data compression in a unique manner to make the most efficient use of available memory.

  The above objects and related objects are achieved by using the novel television schedule information transmission and utilization system and method disclosed below. In one aspect, a television schedule information transmission and utilization system according to the present invention includes a central data processing system. Means for providing schedule information data for a given territory to the central data processing system is connected to the central data processing system. The central data processing system comprises means for formatting schedule information data for a predetermined territory into a predetermined schedule information transmission format. Means for transmitting schedule information data for a predetermined territory in a predetermined schedule information transmission format is connected to the central data processing system. A plurality of area data processing systems each arranged in an area of a predetermined territory, means for receiving schedule information data for the predetermined territory, and schedule information data for the area where each of the plurality of area data processing systems is arranged Means for selecting and means for transmitting schedule information data for the area; Each region has a plurality of subscriber data processing systems. Each of the plurality of subscriber data processing systems is received by the means for receiving at least a portion of the schedule information data for the region, means for storing the schedule information data received by the subscriber data processing system, and the subscriber data processing system Means for assembling a portion of the schedule information data for display to a user of the subscriber data processing system; and a display connected to the means for assembling the portion of the schedule information data for displaying the portion of the schedule information data. ing.

  In another aspect of the invention, a television schedule information transmission system comprises a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a subscriber data processing system for the predetermined territory. ing. The system is modified to have a plurality of regional data processing systems each located in a predetermined territory region. Each of the plurality of area data processing systems includes means for receiving schedule information data for a predetermined territory, means for selecting schedule information data for an area in which each of the plurality of area data processing systems is disposed, and the area. Means for transmitting schedule information data to the plurality of subscriber data processing systems in each area.

  As still another improvement of the television schedule transmission system, the means for transmitting the schedule information data for the area in each of the plurality of area data processing systems has the ability to transmit the schedule information data for the area at different positions of the television transmission signal. . Each of the subscriber data processing systems includes means for searching for schedule information data in the television broadcast signal.

  In yet another aspect of the invention, a method of a television schedule information transmission system includes transmitting schedule information data for a predetermined territory to a plurality of regional data processing systems each located in a region of the territory. The schedule information data for each area is selected by the area data processing system. The schedule information data for each area is transmitted by the area data processing system to a plurality of subscriber data processing systems for each area. The portion of the schedule information data received by each subscriber data processing system is assembled for display to the user of each subscriber data processing system. This part of the schedule information data is displayed to the user.

  The method of the present invention further includes causing at least some of the plurality of regional data processing systems to transmit schedule information data in different portions of the television broadcast signal. Each of the plurality of subscriber data processing systems searches for schedule information data in the television broadcast signal.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. This system is improved by providing the central processing data system with means for transmitting television schedule data as commands. The above commands include instructions for a plurality of subscriber data processing systems in the system and television schedule information in a basic format used by these commands in the plurality of subscriber data processing systems to assemble and display a television schedule. Including.

  In yet another aspect of the invention, a method of a television schedule information transmission system includes transmitting a command from a central data processing system to a plurality of subscriber data processing systems. This command includes instructions for a plurality of subscriber data processing systems in the system and television schedule information used by these commands in the plurality of subscriber data processing systems to assemble and display a television schedule. Yes. A television schedule is assembled from television schedule information in each of a plurality of subscriber data processing systems. The television schedule is displayed to each user of the plurality of subscriber data processing systems.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. The system is improved so that the central data processing system has means for transmitting a predetermined character string comprising a portion of the schedule information to a plurality of subscriber data processing systems. Means in each of the plurality of subscriber data processing systems determines whether a predetermined character string has been collected by the subscriber data system. Means in each of the plurality of subscriber data processing systems stores the predetermined character string in the subscriber data system if it has not yet been collected.

  In yet another aspect of the invention, a method of a television schedule information transmission system includes transmitting a predetermined character string comprising a portion of schedule information to a plurality of subscriber data processing systems in the system. It is determined whether a predetermined character string has been collected by a particular subscriber data processing system. If not already collected, the predetermined character string is stored in the subscriber data processing system.

  In yet another aspect of the present invention, the television schedule information transmission system includes a direct broadcast satellite. The central data processing system has means for transmitting television schedule data for direct broadcast satellites directly to the broadcast satellite. The subscriber data processing system has means for receiving television schedule data for a direct broadcast satellite from the direct broadcast satellite. The system is improved so that each of the plurality of regional data processing systems is located in a region of a predetermined territory. Each of the plurality of regional data processing systems has means for receiving schedule information data for a predetermined territory. Means are provided for selecting schedule information data for an area in which each of the plurality of area data processing systems is arranged. Means are provided for transmitting schedule information data for a region to a plurality of subscriber data processing systems in each region.

  In yet another aspect of the invention, a method of a television schedule transmission system includes transmitting television schedule data for a direct broadcast satellite directly to the broadcast satellite. Television schedule data for the direct broadcast satellite is received from the direct broadcast satellite in the subscriber data processing system. The schedule information data for the predetermined territory is received by the area data processing system arranged in the area of the predetermined territory. The schedule information data for the area where the area data processing system is arranged is selected by the area data processor. Schedule information data for the region is transmitted to the subscriber data processing system.

  In yet another aspect of the invention, the television schedule information transmission system includes a central data processing system having means for transmitting television schedule data. The subscriber data processing system has means for receiving at least some of the television schedule data transmitted by the central data processing system. This system is improved by providing a subscriber data processing system that includes a memory for efficiently storing database items of television schedule information. Each data item has a handle as an index into the handle table, which identifies the memory location corresponding to the handle. This allows database items to be moved from one memory location to another for garbage collection. This also recovers database memory holes that are generated and discarded as data age and can be linked to large useful memory blocks. This "freely" trades for expensive memory microcontroller cycles.

  In yet another aspect of the invention, a method of a television schedule information transmission system includes transmitting television schedule data. At least some of the television schedule data is received at the subscriber data processing system as a database item comprising television schedule information. Each data item has a handle. The handle is used as an index into the handle table that identifies the corresponding memory location.

  In yet another aspect of the invention, the television schedule information transmission system comprises a central data processing system for a predetermined territory, which transmits television schedule data for a predetermined territory including updates of already transmitted television schedule data. Means to do. There are a plurality of subscriber data processing systems in a given territory. Each of the plurality of subscriber data processing systems includes a receiver of television schedule data and a memory for storing television schedule data. The memory is connected to the receiver. The system is improved by including in the central data processing system means for specifying transmission priorities for updates of television schedule data already transmitted relative to other television schedule data.

  In yet another aspect of the present invention, a method of a television schedule information transmission system includes a relative method for transmitting television schedule information between an initially transmitted television schedule information update and an initially transmitted schedule information. Including establishing common priorities. Television schedule information is transmitted based on this relative priority. At least some of the transmitted television schedule information is received at the subscriber data processing system.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. Each of the plurality of subscriber data processing systems includes a receiver for television schedule data. A memory for storing television schedule data is connected to the receiver. The system is improved by including in the central data processing system means for identifying transmitted television schedule data in time relative to other transmitted television schedule data. The means of the subscriber data processing system determines whether the television schedule data received by the subscriber data processing system has a time identification that is later than the time identification of the television schedule data stored in the memory.

  In yet another aspect of the invention, a method of a television schedule transmission system includes transmitting television schedule data to identify transmitted television schedule data in time relative to other transmitted television schedule data. The transmitted television schedule data is received by the subscriber data processing system. Television schedule data is stored in the memory of the subscriber data processing system. The television schedule data is then supplied including time-based identification relative to other television schedule data. The identification by time of the television schedule data supplied thereafter is compared with the identification by time of the television schedule data stored in the memory. The stored television schedule data is exchanged with the subsequently supplied television schedule data if the identification by time of the subsequently supplied television schedule data is slower than the identification by time of the stored television schedule data. . The stored television schedule data is maintained in memory when the stored television schedule data is identified later by time than the subsequently provided television schedule data is identified by time.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. Each of the plurality of subscriber data processing systems includes a receiver for television schedule data. A memory for storing television schedule data is connected to the receiver. The system is improved by including in the central data processing system means for encrypting selected portions of the television schedule data required by the subscriber data processing system to assemble and display the television schedule. The The means of the subscriber data processing system encrypts the selected portion of the television schedule data.

  In yet another aspect of the present invention, a method of a television schedule transmission system includes selectively encrypting a portion of television schedule data required to assemble a television schedule for display. Television schedule data including the encrypted part is transmitted. Television schedule data is received at a subscriber data processing system. The encrypted part of the TV schedule data is decrypted. Here, the television schedule data including the decrypted portion is used to assemble the television schedule for display.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. Each of the plurality of subscriber data processing systems includes a receiver for television schedule data. A memory for storing television schedule data is connected to the receiver. This system is improved by including in the central data processing system a real time clock that establishes a single system time for the transmission system. The means for transmitting television schedule data includes means for transmitting a single system time. The receiver includes means for transmitting a single system time. The memory has a stored value to calculate local real time from a single system time.

  In yet another aspect of the invention, a method of a television schedule transmission system includes establishing a single system time associated with real time. A single system time is transmitted to the subscriber data processing system. Television schedule data expressed in a single system time is transmitted to the subscriber data processing system. Values for calculating local real time from a single system time are sent to the subscriber data processing system. This value is used to calculate the local time for the television schedule from schedule data expressed in a single system time.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. Each of the plurality of subscriber data processing systems includes a receiver for television schedule data. A memory for storing television schedule data is connected to the receiver. The system is improved by having means for transmitting television schedule data configured to transmit television schedule data as a daily show list in the television schedule. The subscriber data processing system is configured to maintain the show list as a rolling window of days extending from the current time to a future time.

  In yet another aspect of the invention, a method of a television schedule information transmission system includes transmitting television schedule information as a daily show list in a television schedule. The show list is maintained as a rolling window consisting of multiple days extending from the current time to the future time.

  In yet another aspect of the invention, a television schedule information transmission system includes a central data processing system for a predetermined territory having means for transmitting television schedule data for the predetermined territory, and a plurality of subscriber data processing systems in the predetermined territory. And. Each of the plurality of subscriber data processing systems includes a receiver for television schedule data. A memory for storing television schedule data is connected to the receiver. This system is improved by configuring the subscriber data processing system to store television schedule data in a compressed form in memory. The read only memory of the data processing system stores fixed text for the system. This fixed text is stored in a read-only memory in a compressed form.

In yet another aspect of the invention, a method of a television schedule information transmission system includes storing television schedule data in a compressed form in a system memory. System fixed text is also stored in read-only memory in compressed form.
The above objects and related objects, effects and features of the present invention will be readily apparent to those skilled in the art from the following detailed description with reference to the accompanying drawings.

  The accompanying drawings, in particular FIGS. 1-4, show television schedule information transmission and utilization systems 50A-50D. Systems 50A-50D receive TV schedule data and associated network control messages from various television program providers (providers) 51 (eg, PBS, MTV, or showtime) via video erase intervals (VBI) in TV signals. As a packet. This data is obtained by the StarSight subscriber unit 52 and used to construct an internal database. This internal database can be accessed by the subscriber unit 52 to display the TV schedule for the channels that the user's TV receives.

  Since access to the network systems 50A-50D is via a reservation service, some messages are encrypted by the security computer 53 to prevent non-subscriber access. Although essentially any encryption system may be used with the present invention, the encryption systems disclosed in US Pat. Nos. 4,531,020 and 4,531,021 are preferred.

A packet contains error detection information and system overhead bytes to find the head of one packet. Information embedded in the packet is called a message. A message consists of one or more commands. There are various types of commands, and each type is distinguished by its own code number.
The commands include different types of information necessary to configure and maintain the TV schedule database, time markers, and user approval information.

  Systems 50A-50D are data networks that deliver specially formatted data to subscribers 52 located throughout the United States. This data is used to construct an “on-screen program guide” that allows system subscribers to interactively watch television program listings on their TV screen. Information for this network is derived from a database constructed by a computer program running on a UNIX® computer 54. In order to construct this database, a data supplier (DP) 56 that supplies a computer 54 with a program listing file called a “show list file” is necessary.

  The television program schedule data is generated by a sales company located at 56 and supplied to the star site computer center 54 in a simple compatible format. Information specifying which television program is broadcast on which channel at which time is encoded. This information is received and processed on all channels nationwide for 10 days. If there are any changes in the TV schedule, they are sent as soon as they are available and on demand. The special information and fields contained in the file are described below.

  The show list file uses standard TCP / IP programs, FTP, or other mutually agreed file transfer protocol standards within the computer 54 through a router connected to the DP Ethernet and digital lease line. Electronically transferred to the file system. These files are compressed using a mutually agreed data compression algorithm that is compatible with the UNIX® file system in computer 54 due to the large amount of data transferred. You can ask to do it. The operating speed of the lease line 58 will be sufficient to transfer all data files in a reasonable amount of time.

  As for the file, the file transfer completed by 0800 o'clock PST (Pacific Standard Time) is transferred to the computer 54 every day (7 days a week). This daily file transfer will be made into the home directory corresponding to the login name used to accomplish the file transfer.

  The “main” file download to computer 54 is always for 12 days later. That is, if today is the 10th, the download of today's data starts on the 22nd at 0000 GMT (Greenwich Mean Time).

  Since data files are sent daily, a mechanism must be in place in order to be able to update program listings that have already been transferred. This is accomplished via an “update” file. The “update” file contains a record of all changes made since the last “update” file (which changes some of the data for any data that is still “active”). “Activity” data is defined as the date starting on today's date followed by 11 days (ie everything from today to the date covered by today's “main” file, but not including that date) Is done.

  The last minute schedule change requires a “flash update” that provides “flash update” files within 5 minutes after any change entry, and these files cross the lease line 58 to the computer 54 throughout the day. "Trickle".

  The TV schedule information is processed by the computer 54 and inserted into the master database. During this process, redundant information is removed. For example, if “Ira Blue Sea Show” is aired more than once during 10 days of schedule information, the character string for the title of that show is stored in the master database only once. For each channel and day, information is stored that specifies which show was broadcast at which time during that day. Although not necessary, each show can include a show title and a show description.

  The purpose of the master database is to store all TV schedule data in a relational database in a standardized way to access that data. Data is organized in a way that makes data retrieval efficient.

  A television viewer receives a set of television video signals at the viewing position. Cable television suppliers assign broadcast and satellite program channels to specific channels. All cable companies have their own channel assignments. Every geographic location has a set of broadcast channels that can be received in that region. A subscriber unit must have a listing of program channels and its channel assignments in order to provide the subscriber with TV schedule data associated with that subscriber.

  Each set of unique channel assignments is assigned to a “receiving group”. Associated with each “Receiving Group” is a region name, a receiving group type (cable, broadcast, satellite), a set of postal codes (zip codes) where the program channel of this set can be received, received A list of program channels and channel assignments for these program channels.

  “Reception group” and program channel information are called “lineup”. “Line-up” information comes from many sources, such as commercial companies that gather information, subscribers, cable companies, and analysis of broadcast channel transmission coverage.

  “Line-up” information obtained from a single source is not considered accurate. A variety of processes are used to align data from multiple sources to obtain a database with excellent quality. Once the master database is created, all other “lineup” data is compared against it. When the correction is confirmed, a change is made to the master database. The primary key for joining one “lineup” to another “lineup” is to make sure that the “lineup” zip codes are the same. Upon confirming the zip code, the channel assignments are compared and confirmed by telephone calls to cable companies or subscribers within the area.

  When TV schedule data and “Receiving Group” data are entered into the master database, the computer program processes the data and releases a data stream suitable for transmission over the PBS data network. This data is compressed and organized to be optimal for “station nodes” and subscribers 52. The specific format of the output data stream is described below.

The output data stream is grouped and ordered by data type. Due to the method used within the subscriber unit, it is suitable to order the data in a specific order.
1. Security Key A security key is required to limit access to the data to only those subscribers authorized to receive the data. The portion of the data stream is encrypted using the industry standard “Data Encryption Standard” security key algorithm. A series of messages containing current and future security keys are sent to continue to approve all desired subscriber units and change the keys. The initial set of subscriber unit encryption keys is sent in a network message authorizing the unit to begin collecting data. These keys in this authorization message are encrypted with one key that is unique to the individual subscriber unit.
2. Most TV programs are categorized by theme category and subcategory. The master database includes a set of attributes for each category that indicates whether the TV program is in a particular genre. Each unique combination of genre attributes is assigned a unique theme identification. Each show is assigned a theme identification based on a set of genre attributes. A table is sent that assigns a text description to each theme identification in the theme data block.
3. Daylight Saving Time Change A date is transmitted that specifies the time when daylight saving time begins and ends. Messages specifying the exact time at which daylight saving time begins and the exact time at which it ends are repeatedly sent over the data network. Subscriber unit 52 receives this message and adjusts the local time to compensate for the effect of daylight saving time.
4). Reception Group Data “Reception Group Data” includes the necessary channel lineup data for all unique “Reception Groups”. This data includes the region ID (a unique number associated with the receiving group), the region type (broadcast, cable, satellite), the channel ID (a unique number associated with a particular channel), and the tuning channel number (the channel Channel on which the TV must be tuned to receive). Any particular subscriber unit 52 is assigned a “receiving group” during the approval process. The subscriber unit processes only the data for the “receiving group” that approved it. All other “receiving group” data is ignored by the subscriber unit.
5). Channel Data Each channel reference in any receiving group must have an associated channel data command. The channel data command contains information about the channel: the original channel number (if it is a broadcast channel, the channel to tune to that channel), the station call character, the network affiliation (ABC, NBC, CBS), and the Contains channel name abbreviations. Data for any particular channel is transmitted only once per data cycle.
6). Show List Data Show list data includes a list of TV programs and the duration and date of a particular channel. The command includes the channel ID, the start time of the first program, a list of subsequent programs, and their duration. Each show includes a show ID and an optional description ID. The show ID and description ID are each a unique number associated with the show title or description text. Each show also includes a flag that indicates whether it is a pay per view program.
7). Show Title Data Every unique show title reference in the show list has an associated “show title” command. The “show title” command includes “show ID”, “theme ID”, and show title text. Each unique “show title” is included only once in the data stream and can be used multiple times by the subscriber unit 52. The text in the show title is compressed using Huffman compression technology.
8). Show Description Data Every unique show description reference in the show list has an associated “show description” command. The “show description” command includes a “show description ID”, an MPAA evaluation, a critic's evaluation, and a show description text. Each unique “show description” is included only once in the data stream and can be used multiple times by the subscriber unit 52. The text in the show description is compressed using the Huffman compression technique.
9. Station Node Data Message Each PBS station node receives a block of data that will be retransmitted from that station node. Only the data requested by the subscriber unit in the area served by that station node is sent to that station node. For example, a station node in San Francisco receives only data about cable systems and TV stations received by subscribers in the San Francisco area. Los Angeles data is never received by a San Francisco station node.

  The purpose of the security software for the star site system is to provide conditional access to the star site data stream. Part of the data is encrypted. Access to the schedule data is conditional because the subscriber unit 52 must know its encryption key. Only authorized units can receive encryption keys.

  The conditional access system includes three levels of encryption. Each unit has an RSA public / private key pair at the top. Next, up to 256 batches share a DES key called a batch key. At the bottom, the program guide is encrypted using a DES key (called a program key) shared by all approved units. Program keys that are periodically changed are distributed under the batch key, and the batch key is distributed under the RSA key, resulting in a three-level hierarchy.

Various keys are distributed either at the factory or in a later message as follows.
* RSA private key, as well as a consistent number identifying that unit, are programmed at the factory. The star site holds a copy of the corresponding RSA public key.
* The batch key is distributed in an acknowledgment message encrypted with the unit's RSA public key. The approval message also gives the unit the batch number, the unit number within that batch, the “service type” field, and the current and next program keys. The approval message is typically the first interaction between the star site and the units in that field, but can be sent at any time to reassign the batch. The key distribution message also indicates whether a unit is still approved according to the number of units in the batch.

  Two security system functions are for processing authorization and key distribution messages. The third function is to decrypt the encrypted text using one of the program keys. The text is encrypted in cipher block chaining (CBC) mode.

  Program keys are periodically changed and distributed using key distribution messages. If the subscriber is deauthorized, they will not receive a new key distribution message and therefore cannot decrypt the TV schedule data.

Subscriber unit 52 is a microprocessor based system designed to receive, process and display TV program schedule data. Subscriber unit 52 hardware includes a microprocessor, read only memory, random access memory, security coprocessor, IR blaster coprocessor, on-screen display coprocessor, and power management circuitry. These components are combined by software to realize an “electronic program guide” system.
1. Operating System Execution As described below, a microprocessor has many tasks to perform. Each task must be serviced in real time, but does not necessarily have to be completed at each time slice. A “round robin” execution is used to perform this function. The main loop calls each individual task sequentially. The called task performs its limited function based on its current state. These tasks are required to complete all tasks or subtasks within a predetermined time. In this way, all tasks have the opportunity to execute their limited tasks within a certain amount of time. When the last task finishes performing its function, the first task is executed again.
2. Memory management Television program data is dynamic and constantly changing. The show list, show title, and description are variable length and change from day to day. For this reason, memory management systems that can dynamically allocate and recover data blocks are deployed. The memory is divided into equally sized allocation blocks. A set of memory blocks is called a pool. A handle table is created that references memory blocks in the pool. Application software subroutines can allocate memory by creating entries and storing them in a handle table that references one or more allocation units in the memory pool. Memory can be deallocated by releasing the memory reference in the handle table.

  It is an application requirement to have a contiguous block of memory that exceeds the length of a single memory block in the pool. This is done by allocating multiple contiguous memories when needed.

After many memory blocks are deallocated, the memory pool is fragmented. There will be many blocks of memory of various sizes that are not contiguous. One background task is not to fragment the memory pool. Run a procedure to move the allocated memory block to the lowest possible memory location. As a block of memory moves, the reference to that memory changes in the handle table. Thus, the application program still has a reference to the memory block. As each allocation unit moves, any deallocated blocks between the allocated blocks are collapsed. As a result, all deallocated memory is at the highest possible memory location and all blocks are contiguous.
3. VBI Data Processing VBI data is decoded from the video stream and processed by an 8032 microprocessor. Buffers are used to store data and assemble packets. A comparator is used to detect special synchronization character sequences. As soon as these characters are detected, the buffer is reset and the packet header is assembled. If the correct cyclic redundancy check (CRC) in the packet header is detected, the rest of the packet is assembled. Once the complete packet is assembled, an additional CRC is calculated to verify that the complete packet was received without error. If this is verified, the packet is broken up and individual network messages are passed to the command processor.
4). Command Processor The command processor determines whether the encryption bit is set in the command header. If set, the data is passed to the security module. The security module then decrypts the data and returns it to the command processor. The command processor functions as a dispatcher that sends commands to the correct processing module based on the command function.
5). Database Processing The database processor is responsible for storing and retrieving all TV schedule and channel data. The database processor receives data from the command processor and stores the data in the database. A set of function calls is used to retrieve data about the application program. The organization of the database is described below.
6). Security Processing The security processor has two main functions: key management and data decryption. When a message containing the correct consistent number or batch number is received from the command processor, the security processor receives the message and decrypts the message. In the case of an approval message, the data is decrypted using the RSA private key. The batch number, batch key, and other control information are decoded and stored for future use. In the case of a key management message, the data is decrypted using the batch key and the information is stored for future use. The program key is encrypted and distributed under the batch key.
7). User Interface The user interface receives remote control commands as its main input. The user requests various functions by pressing buttons on the remote control. The user interface receives these commands and responds with the requested display screen. In addition, display commands are generated asynchronously when recording begins or when the unit attempts to collect data.

  The application has over 20 different and unique display screens. Each display screen is associated with a specific state. The screen data and format depend on the previous screen, the time of the day, the contents of the database, and which remote control button was pressed. A steady state is used to limit the screen flow.

  For all limited screens, there is an array of entry functions, exit functions, update functions, and key handling functions. The entry function is called when the state is first entered and all necessary data is collected and the screen is formatted. The exit function is called when the screen memory and data are released. The update function is called once a minute to update the screen time and redraw if any show ends or any recording starts or completes. When in a particular state, the table contains a reference to another software function for each key on the remote control. These functions are performed when the associated remote control is pressed.

  The user interface also manages an array of pop-up windows that appear on the screen and disappear from the screen either in synchronization with key presses or in response thereto. There are over 18 pop-up categories that limit each screen priority (ie, which covers several pop-ups at a time on the screen). These pop-ups can be requests for cursors, show descriptions, error messages, relief messages, or more information. Each pop-up category has its own entry, exit, update and key handling routines similar to those in the main screen state.

In addition, the user interface locks and unlocks the database while the user is interacting with the program guide, maintains program channel selection and order, controls the tuner from the guide screen, and performs theme searches in the database. And is responsible for controlling a daemon that automatically collects schedule data at a predetermined time from the data supplier channel.
8). VCR Recording The purpose of the record manager is to maintain a list of recording requests and then start recording on the correct channel at the correct time. The user interface defines three types of records: once, weekly, and daily. The user can record the show he / she is currently watching or select a specific title from one of the guidance screens. The user moves the cursor to a specific title on one of the guides (grid, channel, or theme) and presses the “record” button if the program records once, weekly or daily .

  When the user confirms the recording request, an entry is made in the recording queue. The record queue contains an entry for each of these types of records. In the case of daily recording, up to five individual entries are made in the work recording queue. A single entry is made for each weekly and one record. The work record queue represents all the records that will be made for the next week, sorted by show start time.

  The recording daemon is called from real-time execution to determine whether it is time to start recording. The top entry in the work record queue is examined to determine whether it is time to start recording. If so, the software function is executed and recording is started. When recording begins, the recording daemon determines whether it is time to end recording. When the stop time is reached, the software function is executed to end the recording.

VCR recording is started and stopped in several ways based on the user's device configuration. When the cable converter is not used, the following operations are performed to start recording.
1. Turn on the VCR power.
2. Tune the VCR to the desired channel.
3. Set the VCR to recording mode.
If a cable converter is used, the following operations are performed.
1. Turn on the VCR power.
2. Tune VCR to channel, 2, 3 or 4.
3. Tune the cable converter to the desired channel.
4). Set the VCR to recording mode.
5). Tells the user interface software which channel is currently in tune.

  To stop recording, place the VCR in stop mode and then turn off the power. In all cases, these commands are accomplished by sending infrared commands to the device.

  Another function of the recording daemon is to examine the weekly queue and the daily recording request and generate a new entry in the work queue. For example, if the current day is Monday morning and a daily recording request is entered for the afternoon program, there are five entries in the work queue: Monday, Tuesday, Wednesday, Thursday, and Friday is made. When the first recording is completed on Monday afternoon, the entry for Monday in the work queue is deleted. The recording daemon examines the recording queue and finds it is time to add a new entry for the next Monday in the work queue. This entry is added to the chronological storage location in the work queue.

  In addition, the daemon maintains an appropriate start time if it changes to daylight saving time. That is, the demon adds one hour to the show start time in autumn and subtracts one hour in spring to prepare for daylight saving time applied to the user's territory.

Record managers handle deletions separately or in various ways, depending on the original type of record.
9. On-Screen Display On-screen display (OSD) is used to display text and graphic information that forms various display screens. A common interface is used to control various devices. Three different devices, ITT TPU 2740, ITT CCD 3005 and Zilog Z89300 can be used. The user interface has a defined set of functions for drawing text, drawing punched rectangles, drawing channel icons, and setting display attributes. A set of software functions is used that translates these comments into the correct functions for a particular device.

  Details of the subscriber unit 52 are shown in FIG. The following description is by a subscriber unit 52 for a TV Receive Only (TVRO) system (see FIG. 4). With appropriate modifications, the subscriber unit 52 can also be incorporated into a cable decoder box used in the cable system. Subscriber units can be integrated into televisions or VCRs or provided as separate stand-alone units.

  This description is for the electronic hardware of the star site broadcast “TVRO subscriber unit 52”. TVRO customers are people with home satellite dishes for watching television. TVRO stands for “TV Receive Only: TV reception only.” TVRO's subscriber unit 52 relays to the customer's TV satellite system, allowing the customer to receive the Star Site Electronic Program Guide service. Unit 52 is a complete self-holding, separating unit installed in series with existing customer TVRO equipment.

  The subscriber unit receives baseband video from the customer's TVRO. The program guide display screen is fused to the customer video at the subscriber unit. The customer has a baseband video out or channel 3/4 RF out.

  The subscriber unit constructs and displays the TV program schedule information superimposed on the TV screen in real time. The TV schedule information is transmitted to one of the vertical blanking intervals (VBI) of a conventional TV broadcast. The subscriber unit stores this information locally on the board memory. This information is displayed in the form of a “grid guide” on the TV screen when the subscriber presses a button on the remote control.

Subscriber unit 52 consists of the following subsections.
Expensive 8-bit microprocessor 100
・ ROM101 of 64K byte code
512K RAM 102 for storing program data
・ Customer gate array 103
Segmented base register 104 for fast memory data manipulation
Security logic 106 for decoding incoming encrypted data
• Serial “IM” bus 108 for display control interface
Serial “Star Sight” bus 110 (ISB) for internal processor communication
-Monitoring timer 112 for error recovery
・ IR input 113
Infrared receiver circuit 114
Infrared transmission circuit 116 for TV and VCR control
・ IR output 117
CRC-32 encoding and decoding logic 118
• On-board power supply 120
・ Power-down RAM data retention ・ Video input 123
・ On-screen display control and hometer 124
Customer color converter 126 for overlay display
RF modulator 127
Selection of baseband video or RF output 128 or 130 The heart of the TVRO subscriber unit 52 is the “8032, 8-bit microprocessor 100”. This microprocessor controls all sections of the subscriber unit. A short description of this processor is given for reference. For more details, please refer to the 8032 data book from Intel or Signatures.

This 8032 has an 8-bit data bus and a 16-bit address bus.
The upper 8 bits of the address bus are always present, the lower 8 bits of the address bus are time multiplexed with the data bus, and an external address latch is demultiplexed (de-multiplexed). The This latch is located inside the DBE 1200 gate array 103. The 8032 has two address spaces, a “decode” space and a “data” space. The data space is further divided into a RAM memory and an I / O area.

  “Decode” refers to all accesses to the program ROM. The program “decode” space is 64K bytes long and the 8032 can only “read” from this space. All code accesses use a “PSIN” (Program Store Enable) line. The -WR and -RD lines are not asserted during "code" access. + ALE is used to demultiplex the address bus. The falling edge of + ALE latches the lower 8 bits of the address. -PSEN asserts to start reading ROM. Current designs have EPROM-CS lines that are always connected to ground. This makes EPRO's “OEACCESS” time a fixed space for ROM reading. According to today's standards, the microprocessor bus timing is very slow, which is possible through the use of expensive ROMs.

“Data” refers to all accesses to the external RAM 102. Special additional hardware is added to TVRO subscribers so that the “data” area extends beyond the 64K address limit. This is done via the “base register” sectioning and will be explained later. The 8032-RD strobe will be asserted for RAM data read and the -WR strobe will be asserted for RAM data write. PSEN is not asserted during data access. RAM data access can only be caused by "MOVX" instructions. Other 8032 instructions do not assert -RD or -WR. Again, + ALE is used to latch the address, and -RD or -WR asserts to initiate data transfer. The read data must be valid until just before disabling -RD.
The write data is valid for the entire time when -WR is asserted.

  Along with the RAM data space, there is also a “64 KI / O space”. This I / O space occupies the same first 64K segment as the data RAM. There is a signal called + DRAM_ENABLE that is used to determine which regions are asserted.

  The I / O space is where the system control registers are located. There are 18 write registers and 13 read registers. These registers are used to control various subsystems in the subscriber unit. Clock frequency selection, serial bus control, I.D. R. The state and control are all controlled by this register set. There are other control registers located on the peripheral chip. The 8032 uses two serial buses for communication and controls these peripheral chips. The “IM bus” 108 is a three wire serial bus used to talk to the transaction processing unit (TPU 2740) 124. The TPU 2740 collects incoming VBI data and formats and displays various star site overlay screens.

  The software serial bus 110 is used to communicate with the secure microprocessor 106 and the IR Blaster chip 116. This is a two-wire bus with a unique serial timing protocol.

The first 64K of the 8032 address space has three separate overlapping functions.
1. If -PSEN is asserted, the decode ROM is accessed.
2. If + DRAM_ENABLE = logic “0”, the I / O register is accessed.
3. If + DRAM_ENABLE = logic “1”, the first 64K of RAM is accessed.
The area above 64K is always RAM, and the total length is 512K bytes.
8032 Signal Summary Table 1 summarizes the input and output signals of the 8032 microprocessor.

テーブルＩ
ベースレジスタ記述
８０３２データアドレス空間は６４Ｋバイトのだけの長さである。しかし、ＴＶＲＯ加入者ユニットはＴＶプログラムデータの６４Ｋバイトより多くを蓄積する必要がある。“読み取りおよび書き込みベースレジスタ”は８０３２が６４Ｋの限界以上の追加のメモリをアクセスすることを可能にする。

Table I
Base register description The 8032 data address space is only 64K bytes long. However, TVRO subscriber units need to store more than 64K bytes of TV program data. The “read and write base register” allows the 8032 to access additional memory beyond the 64K limit.

  8032 uses an internal 16-bit register called “Data Pointer Register (DPR)” to hold the address of the external data location. The base register (located in the DBE 1200 gate array) is actually Holds another 16-bit value added to the data pointer value to form the RAM address, the contents of the base register are shifted 4 bits left with respect to the data pointer so that the RAM address is 20 bits long 20 bits make possible for a total data RAM size of 1 megabyte 8032 can access any 64K byte chunk of external RAM starting at the address written to the base register. Since the source register is shifted 4 bits to the left, the 8032 can access any 64K byte segment starting on an even 16 byte boundary.) There are two base registers so that memory block moves can be done quickly. If the value of DPTR was changed for each read and had to be changed again before writing while the block moved, it is very slow and cumbersome to software. Allows the start address of the read (source) block to be read base register, and the start address of the write (destination) block to be written base address, a software loop that performs subsequent reads by writing to the same DPTR address Is written. Software quickly move a block of data of any locations outside of the RAM.

A facility can also be added to quickly disable the base register. The signal + ENABLE_BASE forces all the outputs of both base registers to zero. This is done without changing the contents of the base register.
This feature provides a quick way to access the first 64K segment of RAM. Both RAM reads and writes go to the same location. Processor related data is stored in the first 64K segments (register image, software counter values, system parameters, etc.). The upper segment is used to store TV program information.

  Table II below attempts to show how DPTR is added to the base register to form a 20-bit RAM address.

Note: The base register Base Reg. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 + 8032 Addr. 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 = 20 bit Addr. 19 18 17 16 15 14 13 12 11 10 9 9 8 7 6 5 4 3 2 1 0 + DRAM_EN must be 1 to access the external memory area.
Table II
As an example:
The read base register is set to 0001Hex.

  The write base register is set to 1080Hex.

  The data pointer (DPTR) is set to 382A Hex.

  An 8032 read (MOVX A, @DPTR) accesses address 0383A Hex (Note: 20 bits!).

  Write 8032 (MOVX A, @DPTR) accesses address 1403A Hex (Note: 20 bits!).

+ DRAM_EN must be 0 to access the I / O area.
Data RAM Description As described above, the data RAM 102 stores TV program guide information. This RAM is currently available in three sizes, 128K, 256K, or 512K bytes. The data RAM uses a “PSRAM” chip. “PS” represents Pseudo Static. PSRAM is a standard DRAM packaged with static RAM pinout. Spare logic is added to simplify DRAM refresh. These PSRAMs also have power-down data retention features that operate down 3 volts.

This product has four modes of PSRAM operation. They are,
1. Sequence up mode 2. Normal data transfer mode Sequence down mode 4. It is a power down data holding mode.

  These two parts have some different pinouts and operate in some different ways. Circuitry is added to compensate for these differences. There is a 1-bit call + 512KRAM that must be set by software depending on which chip is used.

PSRAMs perform “sequence up” after power-on and “sequence down” immediately before power-off.
PSRAM operation (sequence up operation)
After initial power up, PSRAMs must be “sequenced up” before any reads and writes can take place. The “sequence up” procedure is somewhat different for 128K and 512K parts. This procedure is added to ensure that the SPRAM logic and timing specifications are maintained when PSRAMs are in power down data retention mode. Some facilities use large capacitors or batteries so that PSRAMs are powered up when system power is lost. In order to preserve PSRAM data when power is off, some PSRAM inputs must be held in a known logic state. In addition to this, when these pins are put into a known logic state, they must obey defined timing constraints. These pins and logic levels are different for 128K and 512K parts.

For 128K parts:
+ Chip_Enable 2 (Pin 30) and -REFRESH (Pin 1) are both held at logic "0" when power is moved to ensure data retention. When going from data retention mode to normal operation, -REFRESH (Pin 1) must go high at least 225 nS before -Chip_Enable (Pin 30) goes high.

For 512K parts:
-Chip_Enable (Pin 22) must be held at logic "1", and -OE / -REFRESH (Pin 24) is set to logic "0" when power is moved to ensure data retention. Must be retained. When going from data retention to normal operation, it must go high at least 50nS before -OE / -REFRESH (Pin 24) goes high.

There is also a timing constraint on how soon the above sequence can occur after normal PSRAM REFRESH. The sequence up logic in the DBE 1200 gate array controls the above timing. After the Power On Reset (POR) sequence ends, the microprocessor toggles a bit call + SEQUENCE_UP [Wr Addr 7400 Hex, bit 5] (ensures that this bit is always returned to logic “0”). Toggling the + SEQUENCE_UP bit starts a sequence up state machine that waits for the end of the next normal refresh pulse, and as described above, it moves to the forced logic level with the correct timing. A refresh pulse will occur approximately every 11 μS, and the sequence up process will take approximately 1 μS. Need to wait at least 151 μS.
PSRAM operation (normal operation)
Normal PSRAM operation goes very linearly. The refresh is automatic and transparent to the microprocessor. The PSRAM must be refreshed at least once every 15 μS. The refresh address is generated in the PSRAM and is transparent to the user. In order to refresh, the refresh pin on the PSRAM must be held low for a minimum time. To facilitate circuit design, the refresh request is a 24 MHz clock generated by an internal clock divided by 256, which occurs at approximately 10.7 μS.

The refresh pulse to the PSRAM chip must not occur at the same time as the PSRAM read or write. Since the refresh request and any PSRAM access is asynchronous, the -PSEN line is used to initiate a refresh. When a refresh request is detected, the refresh circuit waits until the falling edge (falling edge) of the next -PSEN. -PSEN falls at the beginning of code access to ROM. Code access to the ROM occurs at any time as the 8032 fetches the OP code. During this time, it is impossible for the 8032 to access the PSRAM.
The refresh is very fast and will finish before the fetch of the -PSEN code is complete.

Note: This system has a -PSEN toggling to refresh the PSRAM. In normal operation, this happens every time. Note if you use an 8032 emulator. If you break and stop the emulator, the refresh stops. Most emulators have an option to ensure that -PSEN is still asserted even when its breakpoint occurs.
PSRAM operation (sequence down operation)
Sequence down is the opposite of sequence up. The system has an “Early Warning Power Failure Detector” that will interrupt 8032 before the power supply voltage begins to drop. The 8032 responds to this interrupt by saving any critical PSRAM data and then asserting the + SEQUENCE_DOWN bit. The sequence down will force the PSRAM critical inputs to their correct state, thus ensuring that the timing specifications are maintained. The sequence down logic will not start until the end of the next refresh to ensure proper timing. The SEQUENCE DOWN rule is shown below.
For the 128K portion + Chip_Enable 2 (Pin 30) must go to logic "0" at least 60n seconds before -REFRESH (Pin 1) is forced to logic "0". Since the gate array output will not be defined, the external device should hold these lines at logic "0" after power is extinguished.
For 512K Part-Chip_Enable (Pin 22) is forced to logic "1" at least 50nS before -OE / -REFRESH (Pin 24) is forced to logic "0".
Must be done.
PSRAM operation (power down data possession)
Data will be retained as long as the critical input pins are held at their power down level (see above) and the voltage to the PSRAM chip remains above 3.0 volts.
PSRAM Power Down Latch There is a very low current JK flip-flop that can be powered by the same backup capacitor that powers the PSRAM. This flip-flop informs the software whether the voltage dropped below the minimum voltage specification during the power off period.

  Upon initial power on, this latch should power up to a logic “0”. The microprocessor can read the state of this latch on the + RAMV_OK line. If the latch is “0”, it should be ensured that the voltage drops below the PSRAM minimum data retention specification and that all RAM data is not valid. If the latch is “1”, the data is still valid before power down.

  If + RAMV_OK is a logic “0”, the microprocessor can set it to a logic “1” after the self-test diagnosis has passed. Once this latch is set to a logic “1”, it will remain set until the PSRAM Vdd voltage drops below about 3.1 volts.

Five states are required to set this latch.
1. The PSRAM voltage must be greater than 3.1 volts (this releases the JK flip-flop reset pin).
2. PCB + 5 volt power supply must be greater than about 4.5 volts (this releases system POR)
3. -The ENBLAT line must be set to logic "0".
4). The + BAND0 line must be set to logic “1”.
5). The + LAT_CLK line must be toggled to logic “0” and then to logic “1”.

  The -ENBLAT and + LAT_CLK lines are driven by the 8032 microprocessor PORT pin. These pins will be initialized to POR time by 8032 hardware. The + BAND0 line comes from the DBE1200 gate array and is reset to logic “0” at the POR time.

  By requesting all these states, it is desirable that the latch could not be set by spurious noise glitches at power up. If the latch reads a logic “1”, it would not be a bad idea to have the checksum location in the PSRAM prove that the data is valid (just in this case, the latch is a noise glitch Can be set by:

MC14xx series CMOS devices are selected for the latch circuit. This is because this system guarantees a very low worst current drain.
DBE1200GATE ARRAY 103
The gate array 103 is grouped together in an 84 pin PLCC package. The gate array terminology is slightly different from the PCB terminology. The PCB uses “+” in front of the signal name to display “active high”.
When the signal is “active high”, the gate array drops the “+” and uses only the signal name. The PCB uses “-” in front of the signal name to indicate “active low”. The gate array prepends the letter “X” to the signal name when the signal is “active low”.

Use the following abbreviations for addresses and bits:
(6000W.5) = write to address 6000 hex, bit 5 (6C00R.3) = read address 6C00 hex, bit 3 ADDRESS DECODING Address decoder is shown on pages 1-9 of Appendix A. An 8-decode 74F138 is used with an 8032-RD or -WR strobe used for enable. The output of 74F138 will be valid only when the appropriate address is written or read.

The following table shows the write and read addresses that are decoded. The page number represents the page of the gate array block diagram in Appendix A on which the register can be found. “Gate array name” is the name of the decoded signal on the configuration diagram. Table III below shows the I / O write register decode, and Table IV shows the I / O read register decode.
Plus DRAM_EN must be zero to access these registers.

表ＩＶ ８０３２Ｉ／Ｏ ＲＥＡＤ ＲＥＧＩＳＴＥＲＳＰＳＲＡＭ ＣＯＮＴＲＯＬ
ＰＳＲＡＭ制御ロジックが添付書類Ａの２ページ目に示されている。このロジックは、チップが存在するモードに依存して制御信号をそれらの適当なピンへ向けるような複数の簡単なゲートから成っている。このチップは２つのメモリ・サイズ・モード、即ち、１２８Ｋと５１２Ｋ、を有する。また、シーケンス・アップ・モードとシーケンス・ダウン・モードが存在する。
ＰＳＲＡＭ ＣＯＮＴＲＯＬ ＳＩＧＮＡＬＳ
ＸＲＦＳＨ＿１８（−ＲｅＦｒｅＳＨ、若しくは、アドレス＿ビット＿１８）
これは、ＰＳＲＡＭチップのピン１に結合されるべき二重目的信号である。シーケンス・アップがなされたとき、この信号はモードに依存する。

Table IV 8032 I / O READ REGISTERSPSRAM CONTROL
The PSRAM control logic is shown on the second page of Appendix A. This logic consists of a number of simple gates that direct control signals to their appropriate pins depending on the mode in which the chip is present. The chip has two memory size modes: 128K and 512K. There are also a sequence up mode and a sequence down mode.
PSRAM CONTROL SIGNALS
XRFSH_18 (-ReFreSH or address_bit_18)
This is a dual purpose signal to be coupled to pin 1 of the PSRAM chip. This signal is mode dependent when sequenced up.

  In 128K mode, the -REFRESH signal is directed to this pin.

  In 512K mode, bit 18 from address Mux is directed to this pin.

When sequenced down, this signal is forced to a logic “0”.
XRAM_OE0 (-RAM output / enable 0)
This is a dual purpose signal to be coupled to pin 24 of the lower PSRAM chip. This signal is mode dependent when sequenced up.

  In 128K mode, this is the PSRAM read output enable line for the lower 128K PSRAM chip. This line is for the lower 128K address and can only be asserted (active low) when asserting the 8032-RD line.

In 512K mode, this is the PSRAM read output enable and refresh input. If this signal asserts itself, a refresh occurs.
If it claims-with a chip select pin, a PSRAM read occurs.

When sequenced down, this signal is forced to a logic “0”.
XRAM_WE0 (-RAM write enable 0)
This signal should be coupled to pin 29 of the low order PSRAM chip.
A PSRAM write will be made when this signal claims with valid chip selection. When sequenced up, this signal is a write enable to the PSRAM in both modes.

This signal is don't care when sequenced down.
XRAM_OE1 (-RAM output enable 1)
This is a dual purpose signal to be coupled to pin 24 of the upper PSRAM chip. When sequenced up, this signal is an output enable control for reading from the upper PSRAM chip in 128K mode. This signal is not used in 512K mode. This is because the upper chip is not installed. This signal is don't care when sequenced down.
XRAM_WEI (-RAM write enable 1)
This signal should be coupled to pin 29 of the high order PSRAM chip.
A PSRAM write will be made when this signal asserts with valid chip selection. When sequenced up, this signal is a write enable to the top PSRAM in 128K mode. (Note: the current design does not use the “top” chip in 512K mode) This signal is don't care when sequenced down.
XCE1 (-chip enable 1)
This is a dual purpose signal to be coupled to pin 22 of the PSRAM chip.
When sequenced up, this signal allows the PSRAM chip to read and write in both modes. When sequenced down, this signal is forced to a logic “1”. The 512K PSRAM chip requires this line to be forced to a logic “1” during the power down data retention mode. This line is don't care on 128K PSRAM.
CE2_A17 (+ chip enable 2 or address bit 17)
This is a dual purpose signal to be coupled to pin 30 of the PSRAM chip.
This signal is mode dependent when sequenced up.

  In 128K mode, this signal is combined with + chip enable, which is always a logic “1”.

In 512K mode, bit 17 from address Mux is directed to this pin.
XWRSTROB (-WRITE STROBE)
During writing, this is a shorter version of the 8032 write strobe.
XWRSTROB is a timing signal used for writing to PSRAMS. Data is written to PSRAM at the rising edge of XWRSTROB. This rising edge hits before the 8032-WR rising edge to ensure that any PSRAM data retention time is satisfied.
BASE REGISTERS AND ADDRESS MULTIPLEXER
Pages 3 and 4 of the gate array block diagram in Appendix A show the base register and PSRAM address multiplexer. See above for a description of base register functions. This part processes the circuit.
This base register is shown on the left side of the second page. The outputs of these registers pass through an “AND” gate before going into the adder. With this AND gate, the base register output can be quickly forced to all zeros at the address input.

The adder output is fed onto the MUX. This MUX places the result of READ ADDRES on the PSRAM address pin, most likely due to a failure. -There is no way to know that 8032 is about to write until WR strobe claims. -When WR claims, the flip-flop switches the MUX onto the output of the WRITE ADDER. The read adder is selected for the fault value. This is because RAM reading takes a little longer time than writing. A double adder is provided to stabilize the write address as soon as the -WR strobe is asserted.
I. R. RECEIVE CIRCUIT
I. R. The receive circuit has various modes of operation depending on whether the button on the remote is released or if it is held down continuously. This circuit is on page 5 of Appendix A.

  A valid code is I.I. R. When clocked during RECEIVE DATA REGISTER (0800R), the + IRR_VAL (IR receive valid) bit and the + VALTIRD (VALid TIL RD) bit are set. The + IRR_VAL bit will remain set until the remote button is released. There are two ways to clear + VALTILRDbitto.

  1. I. R. Reading RECEIVE DATA REGISTER clears + VALILRD.

  2. If the remote button is released and then pressed again, + VALILRD is cleared when the button is pressed again.

  + IRR_NC (IR RECEIVER NO CHANGE) R. It will initially set that RECEIVE DATA REGISTER has been read. It will remain set until the remote button is released.

+ IRR_RDY goes to the high state as soon as the remote button is pressed and remains set until released.
SECURITY CLOCK GENERATOR
The security clock generator is below the middle on page 9 of Appendix A. This is a programmable clock generator for the Motorola security chip. The original specification for this clock was 5 MHz. This clock is programmable in order to make it possible to change the oscillation frequency.

  Both the high and low times of this clock interval can be independently programmed by writing to the I / O address 3C00hex. The high time is set using the upper nibble, while the lower nibble sets the low time. This time is a multiple of the input transmission frequency.

This circuit works by loading the program nibble into a 74F169 type counter. These counters are set as “down counters” and only one of them decrements at any time. When one counter reaches 0, the output will toggle, the counter will reload, and then the other counter will decrement. The inverter at the output of the program register sets the initial value to “divide-by-7”.
I. M.M. SERIAL BUS CIRCUIT
I. M.M. The bus is used for transmission to the TPU 2740 chip. I. M.M. A bus circuit is shown in the figure. To describe this bus in detail, I.D. M.M. Refer to the bus specifications. In general, I.I. M.M. The bus is three write serial communication buses. The three lines are I.D. M.M. _CLOCK, I. M.M. _DATA and I.I. M.M. It is called _IDENTIFY. The DBE 1200 gate array always has I.D. M.M. I am a bus master, so I. M.M. Drive the _CLOCK line. I. M.M. The _DATA line is a bidirectional data line (open drain with external pull-up register). I. M.M. The _IDENTIFY line is the output used to identify the “IM address” and to terminate the transfer. “IM BUS WRITE” is a transfer from 8032 to the IM slave. "IM BUS READ" is from the IM slave device into 8032.

I. M.M. A bus transfer always starts with a 1-byte address, and then becomes 1 or 2 bytes of data. A bit called IIBYTE (3000W.0) determines how many data bytes are transferred. Another bit called WXR_BIT (3000W.1) determines whether the transfer is a read or a write. The eleventh page of attachment A is M.M. The counter and the control logic are shown. M.M. Data shift register is shown.
I. M.M. CIRCUIT OVERVIEW
I. M.M. The circuit is operated through control and data registers. Here is an outline.

  I. M.M. BUS ADDRESS REGISTER (2000W 12 pages XL_IM_AD). 8032 writes the 8-bit address of the slave device with which communication is to be established. This address is latched in 74HCT273 in the figure and transferred to the shift register when the transfer starts. If the same address is two consecutive I.D. M.M. If accessed on a transfer, it is not necessary to reload this register. Bytes written to this register are always all I.D. M.M. It will be the first byte written from the gate array for transfer.

  I. M.M. WRITE DATA 1 REGISTER (2400W 12 pages XL_IM_D1). The bytes contained in this register are I.I. M.M. I.D. M.M. The second byte shifted out on the bus. This register must be reloaded after each transfer.

  I. M.M. WRITE DATA 2 REGISTER (2800W 12 pages XL_IM_D2). The bytes contained in this register are I.I. During M writes, however, the third byte shifted out only if the transfer length is set to 2 bytes. This register must be reloaded after each transfer.

  I. M.M. READ DATA BYTE1 (1000R 12 pages XRD_BYT1). After a read transfer, this register contains the input data byte. If it is a 1-byte read transfer, the data will be in this register. If it is a 2-byte read transfer, the received second byte will be present in this register.

  I. M.M. READ DATA BYTE2 (1400R 12 pages XRD_BYT2). After a 2-byte read transfer, this register contains the first input data byte. During a 1-byte read transfer, the output address wraps back with this register and ends. This wrap feature can be used for error checking and diagnosis.

  I. M.M. BUS CONTROL REGISTER (3000W 9 pages XIM_CTRL). Bit 1 of this register determines whether the transfer is a read or a write. Bit 0 of this register determines whether 1 or 2 data bytes are transferred.

  I. M.M. BUS START TRANSFER REGISTER (2C00W page 11 XSTRT_IM). Writing any value to this register causes the I.D. M.M. Will start the bus hardware.

I. M.M. BUS STATUS REGISTER (1800R 6th page XSW_LO). Bit 7 of this register contains the + IM_BUSY line. This line is M.M. High throughout the transfer.

I. M.M. Circuit operation The logic of page 11 is I.I. M.M. Control bus transfers. I. M.M. Both the clock (IM_P_CK) and the 8032 input oscillator are derived from 24 MHz. The 8032 does not specify any timing for the input oscillator, and the specified timing is very loose for a 12 MHz input clock. This is because the start transfer pulses from 8032 and IM_P_CK must be assumed to be asynchronous. The first three flip-flops in the lower left of the figure resynchronize these signals to I.D. M.M. Used to initiate a bus transfer.

  After the transfer has started, the Page 11 74F269 counter will begin to count up from zero. In the EN_IMCK line, IM_P_CK is I.P. M.M. Allows gate out to bus clock pin 14. The first eight clocks clock out the address. M.M. The _IDENTIFY line will assert during this time. When the counter reaches a count of 8, I.D. M.M. The _IDENTIFY line will be invalid.

  I. M.M. If _WRITE is in progress, I.D. M.M. The _DATE line will continue to be an output for the remainder of the transfer. I. M.M. If _READE is in progress, I. M.M. The _DATE line will switch from output to input after the eighth count. The transfer will be interrupted after count 16 or 24 depending on the state of the 11 BYTE (3C00W.0) bit.

After all clocks are complete, M.M. The _IDENTIFY line goes into a low pulse state again for a while to indicate the completion of the transfer. During this entire time, the IM_BUSY bit is asserted and available as status at 8032. IM_P_CLK is generated by dividing the 24 MHz oscillator by 32. This generates a clock edge approximately every 1.3 μS. It takes 32 μS for all clock transfers.
Watchdog Timer The watchdog timer is on page 13 of the gate array schematic in Appendix A.
This timer is EN_WDOG (3000W.7). Can be turned on and off. The watchdog timer is reset in normal operation by writing to address 6400W. The data written at this address is “don” t care ”.

The watchdog timer is 16 bits long and is clocked by the OSC_256 clock. This timer is generated from the synchronous counter clock (1_SCBR) provided by the gate array vendor. The watchdog timer starts from zero and counts up. If overflow is possible, the reset line to 8032 will assert. The power on the reset line to the gate array will also assert. The 8032 reset line will assert approximately 256 clocks before the gate array POR internal reset asserts. 8032 requires a fixed number of clocks to be provided while the reset line is asserted in order to properly reset.
Note: The gate array internal POR line completely resets the chip to a known state, with the exception of the Page 9 OSC divider clock and the Page 12 IM read data register.
CRC32 polynomial circuit The CRC32 polynomial circuit is on pages 15-18 of the gate array schematic. This circuit is used to check or generate a CRC32 polynomial circuit. This polynomial circuit is 4 bytes long and is used to verify the integrity of the data.

  This circuit has two modes of operation: CRC32 on and CRC32 off. Bit X_EN_XOR (6000W.4) determines the mode. When this bit is logic “0”, CRC32 logic is enabled and the data written to the CRC32 register is multiplexed by the CRC32 polynomial circuit. When the bit is a logic “1”, the CRC32 polynomial circuit is disabled and the data shift to the CRC32 register remains unchanged.

The circuit consists of four 8-bit read data registers, one write data register, the control bits and control logic. The outline of the register is described below.
CRC32 read register 3 (7000R)
CRC32 read register 2 (7400R)
CRC32 read register 1 (7800R)
CRC32 read register 0 (7C00R)
CRC32 write data register (6800W)
X_EN_XOR control bit (6000W.4)
CRC32 circuit operation Data is entered into the CRC circuit one byte at a time. This is done by writing the byte to the CRC32 write data register (6800W). After the 8032 completes the write, the hardware state machine fetches a byte and shifts it to the CRC circuit (this shift takes about 1.5 μS if the OSC is 24 MHz). Once all bytes have been shifted, the resulting one can be read from the four CRC32 read registers. The CRC circuit can be turned off to initialize the four registers to known values.

  The CRC32 write data register is on page 18. This is a parallel input serial output shift register. The end of the 8032WR strobe begins shift logic at page 15. This logic will synchronize the start of the shift to the OSC_2 clock. The 3-bit counter counts exactly 8 counts and stops the circuit.

The X_EN_XOR bit can be used to initialize the CRC32 circuit to a known value. Some CRC circuits start with all 32 bits set to zero, while other CRC32 circuits start with all bits set to one. When X_EN_XOR is set to logic “1”, all the exclusive OR gates of the CRC circuit are disabled. This allows the data written to the CRC32 write data register to be put into the unchanged CRC32 flip-flop chain. This feature also allows for breaks in CRC calculations. When a break occurs, software can read the data and store it in the four CRC32 read registers. This data is then reloaded into these registers.
The CRC32 polynomial circuit is as follows:

ＯＵＴＰＵＴ＿１＝４ｍＡ、通常速度（出力ポート制御ビット）
ＯＵＴＰＵＴ＿２＝２ｍＡ、遅い（１０ｎＳ）立ち上がり・立ち下がり時間（ＰＳＲＡＭアドレス出力）
ＯＵＴＰＵＴ＿３＝２ｍＡ、通常速度出力
ＯＵＴＰＵＴ＿４＝４ｍＡ、通常速度出力（クロックに対して使用）
注：出力１および２はグルーブが異なるので、出力ビット電流はグループ間で容易に変えることができる。
ＩＮＰＵＴ＿１＝シュミットトリガ付きＴＴＬ入力レベル
ＩＮＰＵＴ＿２＝ＴＴＬ入力レベル
Ｉ／Ｏ＿１＝２ｍＡ出力ドライバ（アクティブＨが使用可能である）、オープンドレインまたは三状態可能、入力はＴＴＬレベル
Ｉ／Ｏ＿２＝２ｍＡ出力ドライバ（アクティブＨが使用可能である）、入力はＴＴＬレベル（データバス）
テーブルＶ
ＴＰＵ２７４０オンスクリーンコントローラ１２４
ＴＰＵ２７４０は、オンスクリーンディスプレイ（ＯＳＤ）コントローラとして機能し、また、クローズドキャプションデータ（ＣＣＤ）ＶＢＩデータスライサとしても機能する。ＴＰＵ２７４０は、ファーストプロセッサ（ＦＰ）と呼ばれるＲＩＳＣベースのプロセッサを含み、そのプロセッサはＶＢＩデータを収集し、直列バスと通信し、ＯＳＤを制御するために使用される。内部ＴＰＵ２７４０回路の一部は、入力クロック周波数の４倍で動作している（これは、１８ＭＨｚの入力クロックのＴＶＲＯボードについて７２ＭＨｚである）。８０３２とＴＰＵ２７４０との間の通信は３ワイヤＩＭ直列バス１０８を介して行われる。

OUTPUT_1 = 4mA, normal speed (output port control bit)
OUTPUT_2 = 2mA, slow (10nS) rise / fall time (PSRAM address output)
OUTPUT_3 = 2 mA, normal speed output OUTPUT_4 = 4 mA, normal speed output (used for clock)
Note: Since outputs 1 and 2 have different grooves, the output bit current can be easily changed between groups.
INPUT_1 = TTL input level with Schmitt trigger INPUT_2 = TTL input level I / O_1 = 2 mA output driver (active H is available), open drain or tri-state capable, input is TTL level I / O_2 = 2 mA output driver (active H can be used), input is TTL level (data bus)
Table V
TPU2740 on-screen controller 124
The TPU 2740 functions as an on-screen display (OSD) controller and also functions as a closed caption data (CCD) VBI data slicer. TPU 2740 includes a RISC-based processor called a first processor (FP), which collects VBI data, communicates with the serial bus, and is used to control the OSD. A portion of the internal TPU 2740 circuit is operating at 4 times the input clock frequency (which is 72 MHz for an 18 MHz input clock TVRO board). Communication between 8032 and TPU 2740 takes place via a 3-wire IM serial bus 108.

  The TPU 2740 is a complete digital chip and baseband video data must first be digitized before being used by the TPU. A 6-bit analog-digital converter (μPC660) performs this digitization.

  The μPC 660 is shown on page 1 of the TVRO schematic in Appendix A. The input video signal is approximately 1 volt P-P, and this signal must be "clamped" to a known DC level before being digitized. Page 1 “Video Clams and Filters” does this using the “back porch clamp” method. This clamp biases the video signal into the A / D converter so that the “back porch” area is about 3.69 volts DC (the “back porch” is the area where the color burst is present).

The page 1 register network comprised of R15, R16, R17 and R18 sets the voltage level for its clamp and A / D circuit. The A / D upper reference (pin 11) is set to about 4.52 volts and the lower reference (pin 13) is set to about 3.35 volts. If the input video signal back porch region is biased to 3.69 volts DC (pin 12), the maximum peak-to-peak swing of the video signal should always be between the reference pins. The TRU strips VBI closed caption data using only the incoming video signal. There, since the entire 4 MHz video bandwidth is not required, R7 and C6 form a low pass filter that rolls off the TPU video at about 1 MHz. (Note: The clamp voltage ratio is the same as the expected video signal IRE value.)
The TPU network detects vertical and horizontal synchronization from the digitized video. OSD and VBI data slicers use these signals for timing functions. A programmable converter is used to detect vertical and horizontal synchronization. In order for this converter to accurately detect synchronization, it is important that the video clamp function correctly. The FP can read the output of the sync detection circuitry and count horizontal lines, so it can read VBI data from a particular VBI line and start a graphic on-screen display with the correct video scan line. . When a VBI signal containing specific read inframing data is detected, the TPU's VBI network will load the VBI data into an internal register that the FP can read. The FP reads this data and inserts it into the buffer. Thereafter, the VBI data is read by 8032 via the IM bus.

  The TPU requires good digitized video and a stable horizontal timing reference on pin 27. The horizontal rate signal is the + burst gate from MC 1378 and is sent to the TPU at pin 27. If any of these signals disappear or are defective signals, the TPU will not be able to generate a stable overlay.

  The OSD portion of the TPU consists of a cache memory, a character memory, a timing function, and an external 256K × 4 bit DRAM (U9). The FP reads a high level graphic command from the IM bus and stores the graphic information in an external DRAM memory. Along with cache memory, timing circuitry and character generation hardware, the TRU's FP outputs graphic data on the R, G, B and FBLOUT lines. Eight colors are generated using the R, G, and B outputs. The FBLOUT (fast blanking output) signal determines whether the video output contains R, G, B data from the TRU or whether incoming video should be passed.

The TPU has a 256K × 4 bit DRAM (U9) to store the overlay screen and data. This is a fast page mode DRAM and refresh logic is avoided by constantly reading the screen data even when there is no overlay on the screen.
R, G, B color converters Starsight Telecoast graphic displays require eight colors: black, white, gray, yellow, light yellow, light green and red. These colors are not the standard 8 NTSC saturated colors produced by the TPU. A “color converter circuit” is required to convert the TPU saturated digital color to the “feeling” color of the star site graphic display. This circuit is shown on page 2 of the PCB schematic. The color converter is composed of three “8-1 analog switches”. There is one switch for each of the R, G, and B outputs. An accurate voltage divider is provided that produces the desired R, G, B voltages. Analog switches divert the appropriate voltage to their outputs based on the 3-bit digital R, G, B signals from the TPU. The TPU R, G, B outputs are programmed to be open drain, so that all TTL level swings are available for multiplexed analog switches. Page 2 R14 and C18 form an inexpensive RC delay for fast blanking signals to compensate for delays in the R, G, B channels.
Overlay Generator and Video Synchronizer The Motorola MC1378 is used as the main main building block for the video synchronizer. The MC 1378 operates in a remote mode (REMOTE MODE) (Pin 1 is set high). In this mode, external video is needed to generate the synchronization timing signal. Reference is now made to page 3 of the TVRO schematic in Appendix A for the block diagram at 1378.

  The A1 volt peak to peak NTSC video signal must be sent to pin 24 to provide timing information for both 1378 and the TPU.

  The signal at pin 24 is called a remote video signal.

  This signal is clamped internally within 1378, after which the composite sync is isolated. This composite sink is used to isolate the vertical synchronizer (Vertical Sync) and to lock the 4.03 MHz horizontal phase locked loop (Horizontal Phase Locked Loop). Both synthetic sync (pin 39) and vertical sync (pin 38) are available externally for debugging and timing.

  Another synthetic sink is used to lock the 4.03 MHz PLL (using PD1). The VCO in this PLL is formed as a ceramic resonator of about 4.03 MHz. The free-running frequency of this ceramic resonator must be adjusted at C39. The best way to adjust this VCO is to use a frequency counter and further adjust C39 until the frequency is 15,750 Hz at U1-5. This adjustment disconnects the video in signal so that the VCO is free-running.

  The 4.03 MHz VCO output is divided by 256 to obtain the horizontal frequency, and then further decoded to produce “BURST GATE”. The burst gate (MC13778 pin 5) is about 4 uS wide and centered around a 3.58 MHz color burst. This signal is the main timing reference for the overlay display. This is used extensively by both 1378 and TPU 2740. Use TPUHA, Burst Gate to determine when to start overlay. There is a programmable counter in the TPU that sets the delay from the burst gate to the start of overlay. Any of the jetters on the burst gate will cause annoying side to side motion on the overlay.

  Color bursts from remote video are used to lock the 4X color sub-carrier oscillator using PD3WO gated by a burst gate.

The locally generated composite video phase from the encoder section is compared to a similar sub-carrier reference used to lock PD3. This is done by means of PD4 so that the sub-carrier phases of both the local and remote signals are approximately equal.
Outline of operation of phase detector PD1 locks the 4.03 MHz VCO compared to the incoming remote horizontal sink and counted internally. This works fast to follow the VCR source fluctuations. This PLL filter network consists of C24, C38 and R19.
2. PD2 is not used for this design.
3. PD3HA, gated phase detector, locks the crystal oscillator frequency divided into four for incoming remote signal bursts.
4). PD4 controls an internal phase shifter to ensure that the outgoing local color burst is in phase with the incoming remote burst at PD3.
5). PD5 is not used in this mode of operation.
Video path in MC 1378 The remote video is AC coupled and further fed through pin 24 and further clamped to the appropriate DC level (blanking is 0 volts). The clamped video is supplied to a high-speed video switch where the local video and remote video are switched and controlled by an overlay enable at pin 25. The second path leads to PD3 where the remote video burst is compared to the crystal oscillator frequency divided into four. The third path leads to an identity director that determines whether the incoming signal is PAL or NTSC.

  The local video is generated from R, G and B signals that are 1 volt peak-to-peak inputs directly coupled at pins 14, 15 and 16. This is followed by a color difference and a luma matrix that generates BY, RY and luminance Y signals. The BY and RY signals are clamped and further sent to their respective modulators. The modulated BY and RY signals are summed to form a 3.58 MHz NTSC chroma signal, which is provided to pin 18. This chroma signal is filtered by a 3.58 MHz band pass filter consisting of C33, C34, C35, R22, R13 and T1. This filtered chroma signal is fed back at pin 20. At this point, the chroma signal is added to the luminance signal passing through the 400 nS delay line. This delay line is required due to the long path for the chroma signal passing through the modulator and bandpass filter. Similar to the linear group delay, this delay line has good linearity characteristics with a bandwidth of at least 4 MHz and the entire bandwidth. The combined chroma and luma signal becomes a composite NTSC video signal, which is then clamped by a local video clamp, further fed to a high speed video switch, and mixed with remote video at output pin 27. .

  In order to keep the local video amplitude accurately with respect to the remote video amplitude, the two boost amplitudes are compared with an ACC detector, using a variable gain ACC amplifier in the locally generated chroma path, Set equal.

The absolute boost amplitude of the remote signal is detected by a kill detector and the locally generated signal chroma is turned off when the remote boost drops below a predetermined level. This kill level can be adjusted by changing the value of the resistor R3 of the pin 31. 470K kills with a remote boost of about 10-20 mVp-p. A normal boost is 286 mVp-p.
Power supply This system requires 5VDC digital, 5VDC analog, and possibly 12VDC analog (for some RF modulators).

  The current conditions are as follows.

5VDC digital 550mA
5VDC analog 150mA
12VDC analog 80mA
It is important that the microprocessor (PWRBAD line) be set to zero at least 10 mS before the 5VDC digital supply drops below 4.75 volts. As a result, the microprocessor can complete the processing of the database in operation and can stop the DRAMs in order. This is done by monitoring irregular power using a Seiko S80731AN power supervisor IC (U2). After the irregular power supply drops below about 8 volts, this S80731AN asserts PWRBAD. This causes an interrupt in the microprocessor to start subroutine power down. U3 monitors the 5VDC supply and controls the RESET line into DBE 1200. This generates a clean reset signal while the power is rising and falling.
Transmitter 116
The function of the IR transmitter 116 is performed by the MC68HC05C9 microprocessor. The microprocessor is programmed to interface with the software serial bus 110 for communication with 8032. This microprocessor, for most VCR's, can generate pulses on their output pins that simulate the IR signal. The ROM in the MC68HC05C9 includes executable programs, codes and sequences, and controls the VCR via infrared. Port B on the MC68HC05C9 is used to set the serial address to which it corresponds. The clock signal is generated by a programmable clock divider in the DBE 1200 gate array.

  FIG. 6 shows how the packet 300, message 302, and command 304 are related. FIG. 7 shows the packet 300 in more detail. Unless otherwise indicated, all fields are binary 2's complement numbers. All unset bits in the field are reserved and initially set to zero. Multibyte variables are the most important byte first stored (big endian format) unless otherwise indicated, with the exception that the CRC16 and CRC32 fields are reversed. Least significant byte first (small endian format) stored in the order of.

All visible text strings consist of only printable characters, where printable means an ASCII value in the range of 32 (20H) to 122 (07AH). It is a character defined in. Both upper and lower case letters are supported. All fixed fields that contain ASCII symbol strings that do not fill the field are padded with a NULL (ASCII value 0) character. Unless otherwise specified, symbol strings that do not fill a field do not end with NULL.
Packet 300
Packet 300 consists of error detection information and information manipulated by the subscriber unit. The packet field shown in FIG. 7 has the description shown in Table VI as follows.

テーブルＶＩ
メッセージ３０２
メッセージ３０２は、パケット３００の情報保持部分である。図８に示すように、これらは、１又はそれ以上のコマンド３０４から成っている。メッセージは、整数個のコマンドを含み、さらに、コマンドはメッセージ間で分離されていない。パケット・ヘッダーのサイズ・フィールドは、いつ全てのコマンドが処理されたかを判定するために使用される。メッセージ・フィールドの最適サイズは、２５０バイトかそれ以下である。２５０バイトよりも大きなコマンドは、１つのパケット内で単独に含まれるべきである。最後のコマンド内の最終バイトに続くバイトは、常に、ＣＲＣ３２フィールドの最初のバイトである。
コマンド３０４
コマンド３０４は、ＴＶスケジュール・データベースを作り、１日の最新時間を保持し、さらに、ユーザー・オーソリゼイション及びセキュリティー問題を取り扱うための、スターサイト・データ・トランスミッション・ネットワーク（ＳｔａｒＳｉｇｈｔ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｎｅｔｗｏｒｋ）のエレメントである。

Table VI
Message 302
The message 302 is an information holding part of the packet 300. As shown in FIG. 8, these consist of one or more commands 304. A message contains an integer number of commands, and the commands are not separated between messages. The size field in the packet header is used to determine when all commands have been processed. The optimum size of the message field is 250 bytes or less. Commands larger than 250 bytes should be included alone in one packet. The byte following the last byte in the last command is always the first byte of the CRC32 field.
Command 304
Command 304 creates a TV schedule database, maintains the latest time of day, and handles Star Authorization Data Transmission Network (StarSight Data Transmission Network) to handle user authorization and security issues It is.

Different commands are distinguished by a special value known as "Cmd type". It is contained in the least significant 6 bits of the first byte of the command. A total of 64 special command types are possible. The second field is “Cmd length”, which is used to determine the byte size of the command. This size includes fields of “Cmd type” and “Cmd length”. The “Cmd length” field may be one or more bytes. Table II shows all commands and specifies the size of the “Cmd Length” field. This table contains the encryption offset for the command.
This concept is explained in detail in the section following this table.

  A subscriber unit that does not recognize the command type (which will occur in the future when a new command is executed) must calculate the command length and skip over / ignore the command (Command).

  The most significant bit (MSB) of the first byte of the command is a flag that signals whether the command is encrypted. If set, the command is encrypted and if cleared, it is not encrypted. It is ensured that the only commands passed to the subscriber unit in the encrypted format are the Show List command, the Authorization command, and the Key Distribution Command. However, the subscriber unit should be adjusted to decrypt any command.

The start offset of the encrypted part of the command is also listed in the preceding table. Most commands leave part of their contents in the clear, so that the network entity that processes the packet stream filters out unnecessary commands without decrypting the command gut. (Note that the encryption offset for a future command can be changed when the command is actually executed.)
The second upper bit (second MSB) of the first byte of Command indicates which of the two program keys should be used when decrypting the command. When this bit is cleared, decryption program key 0 is used, and when set, key 1 is used.

  Because the initialization vector and pad characters need to be added, the process of encrypting the command increases the amount of memory required to store the command. The initialization vector is an 8-byte field that is always prepended to the start of the encrypted byte stream. Pad operations are added to the byte stream before it is encrypted. The purpose of the pad operation is to help the security module determine whether the encrypted data has been “tampered”. Sufficient pad characters are added to make the length of the raw data stream a multiple of eight. If the length is a multiple of 8, 8 pad characters are added. The value of the pad character is the number of fill bytes added. For example, if 3 extra bytes are appended to the command, each fill byte has the value 3. The encrypted data of the command (Command) is stored as shown in FIG.

  Future revisions of this command set will add field definitions to existing commands. The command processor should be adjusted to ignore all data after the last recognized field.

Some commands are addressed to specific units or specific unit groups. Units are addressed using a logical address composed of two parts: a 4-byte batch number and a 1-byte unit number. The batch number is used as a group address for sending commands to unit groups sharing the same batch number. A batch number of zero has reserved meaning and addresses all units.
All other possible batch numbers are valid addresses. (For example, a command transmitted with the number of batches = 0 is scheduled as a system wide-area broadcast (system wide broadcast), and a command having a batch address 23456 is sent to a unit having only the batch group 23456. (Batch group units should ignore the latter command.)
The unit number is used to identify a specific unit of the batch group. Preferably up to 255 units are contained in one batch group. A unit number of zero has a reserved meaning to address all units in a 1-byte group. (For example, a logical address with batch number 23456 and unit number = 0 is directed to all units of batch group 23456.)
The commands required to build the subscriber unit database are typically sent repeatedly in the order shown in Table VIII.

                              Table VIII

他のメッセージは、この周期的ストリームにおいて、必要とするときのランダムな基準で、散在している。伝送エラーによって、メッセージの喪失を生じて、コマンドが順序を外れて受取られることがあることに注意されたい。特に、ショウリストにギャップができることに注意されたい。加入者ユニットはメッセージの喪失と順序外れを取扱うことができねばならない。

Other messages are scattered in this periodic stream on a random basis as needed. Note that transmission errors can cause messages to be lost and commands received out of order. Note in particular that there is a gap in the show list. Subscriber units must be able to handle message loss and out-of-order.

The following sections describe each command. Although the command is shown in its unencrypted form, the reader should understand that the above modifications can be made to any command by encryption.
Time Command (Time command)
Time Command (time command: FIG. 10) specifies the current time and date. These are sent periodically at a predetermined rate. Subscriber unit 52 (FIGS. 1-4) resets the current time and date to match the value received in this message. The time command field shown in FIG. 10 is described in the table IX.

                            Table IX

Ｄａｙｌｉｇｈｔ Ｓａｖｉｎｇ Ｔｉｍｅ Ｃｈａｎｇｅ Ｃｏｍｍａｎｄ（日光節約時間（夏時間）変更コマンド）
夏時間変更コマンド（Ｄａｙｌｉｇｈｔ Ｓａｖｉｎｇ Ｔｉｍｅ Ｃｈａｎｇｅ Ｃｏｍｍａｎｄ）は、次の夏時間変更が生じるときを定め、これによって、これらの変更を含む時間についてのスケジュールデータの表示が、正しく調整されたローカル時間を示すことができる。加入者ユニットは、（オーソライゼーションコマンドから得られた）タイムゾーンオフセットを追加して、そのローカル変更時間に対応する変更に対してグリニッジ標準時間を計算せねばならない。ショウリストは、この計算したグリニッジ標準時間が近づく夏時間に影響を受けるタイムオフセットによって示されるであろう後にエントリされる。図１１に示される夏時間変更コマンドのフィールドは、テーブルＸに定義されている。

Daylight Saving Time Change Command (Daylight saving time (daylight saving time) change command)
Daylight Saving Time Change Command determines when the next daylight saving time changes will occur, so that the display of schedule data for the time that includes these changes can indicate the correctly adjusted local time . The subscriber unit must add the time zone offset (obtained from the authorization command) and calculate the Greenwich Mean Time for the change corresponding to its local change time. The show list is entered after this calculated Greenwich Mean Time will be indicated by a time offset affected by daylight saving time approaching. The fields of the daylight saving time change command shown in FIG.

                            Table X

Ｒｅｇｉｏｎ Ｃｏｍｍａｎｄ（領域コマンド）
領域コマンドは、スターサイトデータ（Ｓｔａｒ Ｓｉｔｅ Ｄａｔａ）が利用可能であり且つ所与の領域の加入者ユニットによって受取ることが可能である全チャンネルを識別する。１つの領域コマンドは、データプロバイダステーションによって受取られるエリアの各領域に対して送られる。例えば、各ケーブルシステムのチャンネルラインナップが１つの領域を構成する。オーソライゼーションコマンドが領域ＩＤを送る。領域ＩＤが分かると、その領域の各チャンネルに対するチャンネルデータがチャンネルデータコマンド（Ｃｈａｎｎｅｌ Ｄａｔａ Ｃｏｍｍａｎｄ）から獲得される。

Region Command (region command)
The region command identifies all channels for which star site data (Star Site Data) is available and can be received by subscriber units in a given region. One region command is sent for each region of the area received by the data provider station. For example, the channel lineup of each cable system constitutes one area. The authorization command sends the region ID. If the area ID is known, channel data for each channel in the area is obtained from a channel data command.

  The channel ID of this command is not required by the subscriber unit after acquiring channel data for each channel in the user area. However, the channel ID and version must be retained in case the channel data is lost (e.g., power is stopped) or changed and must be reacquired.

  The channel ID entries are listed in a default order in which the subscriber unit should display the channel ID entries until the user changes the sequence using the setup screen. The order of the channels is somewhat numerical, and all the channels such as HBO and DISNEY are given as the number of natural channels = 1 and are arranged in alphabetical order by the “Name Affiliation” field.

  Only the base channel is sent to the region command (see Duplicate Channel Command). The area command (Region Command) shown in FIG. 12 is defined in the table XI.

                            Table XI

テーブルＸＩ
チャネルデータコマンド チャネルデータコマンドが、種々のディスプレイに有用なチャネル情報を与える。チャネルデータコマンドは、データプロバイダステーション（ＰＢＳステーションノード）によりサービスを提供される全ての領域の各チャネルに送られる。加入者ユニットは、領域リストの１つに一致するチャネルＩＤエントリを含むチャネルデータコマンドを用いる領域において、全てのチャネルの情報を収拾する。

Table XI
Channel Data Commands Channel data commands provide useful channel information for various displays. Channel data commands are sent to each channel in all regions served by a data provider station (PBS station node). The subscriber unit collects information for all channels in the region using the channel data command that includes a channel ID entry that matches one of the region lists.

Only the base channel is sent to the channel data command (see dual channel command). The field of the channel data command shown in FIG. 13 is defined in the table XII.

テーブルＸＩＩ
ショーリストコマンド
ショーリストコマンドが、任意のチャネルに１日のスケジュールデータを提供する。ショーリストコマンドは、（チャネルが放送されていない時であっても）スケジュールの空隙を有しない。ショーリストコマンドは、システムの全ての領域におけるチャネル全部に送られる。ショーリストコマンドは、多重のショースロットエントリを含み、各々のエントリは、チャネルのスケジュールにおける１つのショーに対応する。

Table XII
Show List Command The show list command provides daily schedule data for any channel. The show list command does not have a schedule gap (even when the channel is not broadcast). Show list commands are sent to all channels in all regions of the system. The show list command includes multiple show slot entries, each entry corresponding to one show in the channel schedule.

  The show list command represents schedule data for at least 24 hours. The first entry for the show list begins at midnight, Greenwich Mean Time. Programs that straddle the boundaries between successive show lists are represented only once in the show list to which their start times belong. The next show list represents the time during which the program from the previous show list overruns it with a dummy show entry. These fill character entries are recognized using “dum flg” and are found at the end of the previous day's show list when the set indicates a show entry in this time slot. Only the first entry in the show list can have a “dum flg” set. Dummy show entries function in the same way as valid show entries, except that their title and descriptive text are replaced with their label as a fill character entry. If the start time of the program is exactly the same as the show list boundary time, it will be represented only once in the next show list.

When the show list command is encrypted, encryption of the show list command starts at byte 11 in the above diagram (ie, starts in the “nbr show slot entries” field). If the show list command is not appropriate for the area of the subscriber unit or has already been received, the show list command can be discarded. Ignoring unnecessary show lists can save subscriber unit data processing throughput as it saves time for encryption. The fields of the show list command shown in FIG. 14 are defined in the table XIII.

テーブル１３
ショータイトルコマンド
ショータイトルコマンドはプログラムのネーム（例えば、ＣＯＳＢＹ ＳＨＯＷ）およびテーマ検索において用いられるいくつかのプログラム属性を含む。ショータイトルは、通常ホフマンエンコーディングスキームを用いて圧縮される。

Table 13
Show Title Command The show title command includes the name of the program (eg, COSBY SHOW) and some program attributes used in the theme search. Show titles are usually compressed using a Hoffman encoding scheme.

  An uncompressed show title must be 1 to 86 bytes in length. Titles with lengths greater than 38 bytes were omitted due to the limited display capabilities of the subscriber units.

  If there is a show in the show list for at least one channel in the subscriber area, the show title command must be saved in the database. All other show title commands must be ignored. The required show title can be found by matching the SID number in the show list with the SID number in the show title command. A field of a show title command as shown in FIG.

テーブル１４
ショー記述コマンド
ショー記述コマンドは、プログラムのエピソードの記述とテーマ検索に用いたいくつかのプログラム属性とを含む。ショー記述は、通常ショータイトルに関して用いられたのと同じホフマンエンコーディングスキームを用いて圧縮される。

Table 14
Show description command The show description command includes a description of the episode of the program and some program attributes used for the theme search. Show descriptions are usually compressed using the same Hoffman encoding scheme used for show titles.

  An uncompressed show description must be between 1 and 162 bytes in length. Since the display capability of the subscriber unit is limited, descriptions with a length of 120 bytes or more are omitted. A show description command is sent for every show that has a description of all the areas served by the data provider. If the DID is referenced in the show list for at least one channel in the subscriber's domain, the show description command must be saved in the database. All other show description commands must be ignored. The required show description can be found by matching the DID number in the show list with the DID number in the show description command. A field of a show description command as shown in FIG.

テーブル１５
テーマカテゴリーコマンド
テーマカテゴリーコマンドは加入者ユニットのテーマ機能内に表示された主なカテゴリーを特定する。これらのカテゴリーはヒエラルキーテーマ検索機能内の第１のインデックスを形成する。各主なテーマカテゴリに対して、特定の８ビットＩＤ番号とテキストストリングが特定される。このテキストストリングはカテゴリーのエントリーを名づける。このエントリーは、指示された公開順にコマンド内で順次リストされる。

Table 15
Theme category command The theme category command identifies the main categories displayed within the theme function of the subscriber unit. These categories form the first index within the hierarchical theme search function. For each major theme category, a specific 8-bit ID number and text string are specified. This text string names the category entry. The entries are listed sequentially in the command in the order of release indicated.

  The command includes a version number that is incremented each time the theme category command is changed. The subscriber unit must replace the version present in the command recorded in memory when a command with a different version number is transmitted. The fields of the theme category command as shown in FIG. 17 are defined in the table 16.

表１６
テーマ・サブカテゴリ命令
テーマ・サブカテゴリ命令は、加入者の単位デーマ機能で示されたサブカテゴリを特定する。これらは、使用者が主テーマ・カテゴリを選択した後、表示される。各主テーマ・カテゴリは、１又は２以上のサブカテゴリを有しており、そのサブカテゴリは、階級をなすサーチスキーム（ｓｅａｒｃｈ ｓｃｈｅｍｅ）の第２のレベルを形成する。各サブカテゴリには、親カテゴリの８ビットＩＤ、固有の１６ビットテーマＩＤ数、及び入力を名付けるテキストストリング（ｔｅｘｔ ｓｔｒｉｎｇ）が含まれている。入力は、提案される表示順序の命令内に直列に列挙される。

Table 16
Theme / Subcategory Instruction The theme / subcategory instruction specifies the subcategory indicated by the subscriber's unit dema function. These are displayed after the user selects the main theme / category. Each main theme category has one or more subcategories, which form a second level of the search scheme that makes up the class. Each subcategory includes a parent category 8-bit ID, a unique 16-bit theme ID number, and a text string naming the input. Inputs are listed in series within the proposed display order instructions.

  The instruction includes a version number, which is increased each time the theme subcategory instruction is changed. The subscriber unit replaces the current version of the instruction stored in memory when an instruction with a different number of versions is sent. All subscriber units store these subcategory names when they do not have an entry that includes the same theme category ID, subcategory ID, and version number. The fields of the theme subcategory instruction shown in FIG. 18 are defined in Table 17.

表１７
加入者ユニットリセット命令
加入者ユニットリセット命令によって、星観測制御センタが選択された加入者ユニットをリセットする。異なるタイプのリセットを送ることも可能である。図１９に示されるように、加入者ユニットリセット命令のフィールドは表１８に定義される。

Table 17
Subscriber unit reset command In response to the subscriber unit reset command, the star observation control center resets the selected subscriber unit. It is also possible to send different types of resets. As shown in FIG. 19, the fields of the subscriber unit reset command are defined in Table 18.

表１８
認可命令
認可命令は、加入者ユニットがスケジュールデータを収集し、表示するように認可する。加入者が星観測サービスを求めるときに、その命令は送信される。

Table 18
Authorization Order The authorization order authorizes the subscriber unit to collect and display schedule data. When the subscriber requests a star observation service, the command is sent.

  Until the authorization command is received, the subscriber unit does not know which region it is in, and thereby does not know which channel it should collect data on. Similarly, the subscriber unit does not have the decryption key necessary to decrypt various commands until an authorization command is received.

  The authorization command addresses individual subscribers using a serial number given to the customer service representative during the authorization process. The first originating subscriber unit is limited to support two separate VBI lines in a single region and the same tuning frequency. The fields of the authorization command are defined in Table 19 as shown in FIGS.

表１９
長期割当ＩＲコード命令
長期割当赤外線コード命令は、特定の周辺装置を制御するために、加入者ユニット普遍遠隔制御チップによって使用される制御コードを特定する。このコードは、ＩＲブラスタ（ｂｌａｓｔｅｒ）言語を記載しており、この言語は、ＵＲＣチップの内部データベースにない装置にたいして選択的に送出される。顧客サービス代表が星観測と言われる使用者と接触しているとき、伝送は通常発生する。なぜなら、それらが、加入者ユニットマニュアルにおけるＶＣＲ／ケーブルボックス／ＴＶ用のコード群を発見しなかったからである。

Table 19
Long-term assignment IR code command The long-term assignment infrared code command specifies the control code used by the subscriber unit universal remote control chip to control a particular peripheral device. This code describes the IR blaster language, which is sent selectively to devices that are not in the internal database of the URC chip. Transmission usually occurs when a customer service representative is in contact with a user called star observation. This is because they did not find the code group for VCR / cable box / TV in the subscriber unit manual.

  The IR code is addressed to a specific unit via a serial number, or to a unit having a predetermined production code, device type (eg, VCR) and device ID. These instructions are sent once or repeatedly for a user request when addressed to a SU group. As shown in FIG. 23, the fields of the long-term assignment IR code command are defined in Table 20.

表ＸＸ
キー分配コマンド
キー分配コマンドは、暗号化コマンドを解読するために使用されるべき現在及び次のプログラムキーを与える。加入者ユニットは、バッチ番号を含むキー分配コマンドに対するデータストリームを観察する必要がある。コマンドが見つけ出された時、それは、許可ビットマスク、両方のキー、及び承認データフィールドを、スターサイトセキュリティープロセッサに送る必要がある。加入者ユニットユニット番号に対応する許可ビットマスク内のビットが０の場合、加入者は、不許可になり、データ収集を保留する必要がある。図２４内に示されるキー分配コマンドのフィールドは、表ＸＸＩ内に定義されている。

Table XX
Key Distribution Command The key distribution command gives the current and next program key to be used to decrypt the encryption command. The subscriber unit needs to observe the data stream for the key distribution command including the batch number. When a command is found, it needs to send a permission bit mask, both keys, and an authorization data field to the Starsight security processor. If the bit in the permission bit mask corresponding to the subscriber unit unit number is 0, the subscriber is disallowed and needs to suspend data collection. The fields of the key distribution command shown in FIG. 24 are defined in Table XXI.

表ＸＸＩ
加入者ユニットコマンド
このコマンドは一つ以上の加入者ユニットにデータバイトを送信するために使用される。フォーマット及び内容の定義は、加入者ユニットに対してプライベートである。ネットワークは、データに割り込む試みはしない。

Table XXI
Subscriber unit command This command is used to send data bytes to one or more subscriber units. Format and content definitions are private to the subscriber unit. The network does not attempt to interrupt the data.

  This instruction provides a hook for sending commands and initialization data to the subscriber unit during development without having to define separation, format, and network messages. The large of these messages can be temporary in nature. The fields of the subscriber unit command shown in FIG. 25 are defined in Table XXII.

表ＸＸＩＩ
以下は、加入者ユニット５２データベースエンジンの内部データ構造を記述している。加入者ユニットデータの一般的な特徴は、階層的である。データ構造のスケジュールデータ階層は降順での次の通りである。

Table XXII
The following describes the internal data structure of the subscriber unit 52 database engine. The general feature of subscriber unit data is hierarchical. The schedule data hierarchy of the data structure is as follows in descending order.

テーマのカテゴリー及びテーマのサブカテゴリーが、観るショーを選択するのに使用される。それらは、テーマカテゴリー／サブカテゴリー対と一致するショーを抽出するのに使用される共通のデータ値（テーマインデックス）を共有する。降順でのテーマデータ階層は、以下の通りである。

The theme category and theme sub-categories are used to select the show to watch. They share a common data value (theme index) used to extract shows that match a theme category / subcategory pair. The theme data hierarchy in descending order is as follows.

加入者ユニットによって受信されたネットワークコマンドの記述に対して、インサイトデータ転送ネットワークプロトコル記述（ＩｎＳｉｇｈｔ Ｄａｔａ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ ｄｅｓｃｒｉｐｔｉｏｎ）を見る。
データベースメモリプール概欄
メモリマネージャー（Ｍｅｎｏｒｙ Ｍａｎａｇｅｒ）は、サブスクライバユニットの適用部分によって要求されるメモリブロックを割当て且つフリーにする。アプリケーションソフトウエアーハンドル（ＨＡＮＤＬＥ）を介してメモリブロックを参照する。メモリブロックのハンドルは、プールインデックス（ＰＯＯＬ ＩＮＤＥＸ）を含むテーブルエントリに対するインデックスである。プールインデックスは、メモリブロック（ＭＥＭＯＲＹ ＢＬＯＣＫ）のアドレスに翻訳されるスケールされたアドレスである。このハンドル法は、システムオブジェクトが歳を取り、そして死んでいく場合に、アプリケーションデータ構造の特定の更新を要求することなしに、メモリブロックが、再配置されることを可能にする。

View the insight data transfer network protocol description against the description of the network command received by the subscriber unit.
Database Memory Pool Summary The Memory Manager allocates and frees the memory blocks required by the application part of the subscriber unit. A memory block is referenced through an application software handle (HANDLE). The memory block handle is an index to a table entry including a pool index (POOL INDEX). The pool index is a scaled address that is translated into the address of a memory block (MEMORY BLOCK). This handle method allows memory blocks to be relocated without requiring specific updates of application data structures as system objects age and die.

  The memory manager periodically performs unnecessary information collection process to collect unused memory blocks and recombine them into large blocks. Since the application uses the handle to reference the memory block through the handle table, the memory block can be relocated by a specific update of the application data structure. In addition, the memory pool is temporarily locked to prevent block relocation during the critical period.

Each memory block includes the memory block size and object form (OBJTYPETYPE) as the first element. This helps memory block relocation and merging.
The object form is divided into two main groups. A small object that can be defined in less than 16 blocks of memory. Currently, each block of memory is 16 bytes long. A small object has an object form encoded in the first NIBBLE and a length in the block encoded in the second NIBBLE of the first byte of the memory block. A long object has the coded object form as the first byte of the memory block and the number of units assigned as the second byte of the memory block.

If the first byte of the memory block is bitwise 0xCO and ANDed to 0, this is a large object, otherwise it is a small object.
Database Memory Pool Access Method An illustrative representation of the database memory pool access method is shown in FIG. Further details are as follows.
Handle Table The handle table is a fixed allocation table as shown in FIG. 27 and includes two forms of entries, a free entry and an in-use entry. Free entries always have 2 MSB sets so that they are not confused with busy entries.

The in-use entry includes a handle, eg, an index into the pool for the database item referenced via the show title entry. The handle of a database item is an index into the handle table. The pool index of a database item can be changed to collect unnecessary information in the pool, but its handle does not change as long as the corresponding item exists in the database. Items removed from the database return their handles to the top of the free list.

  Handle table entry 0 is always the head of the free list. The table is initialized for all free entries, each entry containing the index of the next entry.

  The size of the handle table limits the number of database items that can be kept in the pool. Systems with different channel numbers require different handle table sizes.

Field Description Index to the pool for the first pool block that contains the Poll entry.

Database Schedule Access Overview The database show schedule is shown in FIG. Channel data maintained in an internal database engine data structure called a channel data table. The channel data table selects a channel accessed by a certain area. The channel data table is constructed by the system command processor from the area command and the channel data command. Channel related information is extracted from the area command and placed in the channel data table.

  The used area ID is extracted from the permission command. The area ID is key information for the occurrence of a show schedule. Region ID selects the region command processed by the subscriber unit, defines the channel ID to be accessed, defines the channel data table, defines the show list, selects the show title and show description, and Browse theme categories and theme subcategories. Once the channel data table is defined, the channels are referenced directly via the channel data table.

  Each lower level table in the show schedule is accessed via a handle. The handle is translated by the handle table into a pointer in the memory channel data table.

  As shown in FIG. 29, the channel data table includes information for each channel in the area. This data is used to access the schedule data (show list) for channels, tuning and display on the channel banner, for channel glyphs, and during setup.

Field Description Type / Nbr Blks Pool entry type and number of blocks needed to hold this pool item. This form value indicates that this is a 2-byte field because the length is very long due to the number of channels in the region. Channel data table format = 1
Nbr Channel Number of channel entries in user area (including inactive channels)

Table XXIII
Channel entry
There is one channel entry for each channel in the region (see also FIG. 29).

表ＸＸＩＶ
チャネル複製表（Ｃｈａｎｎｅｌ Ｄｕｐｌｉｃａｔｅｓ Ｔａｂｌｅ）
チャネル複製表（図３０）は、基本チャネルの複製である領域（Ｒｅｇｉｏｎ）の各チャネル上に情報を含む。このデータは、有料視聴（ｐａｙ−ｆｏｒ−ｖｉｅｗ）型チャネルのブロック（Ｂｌｏｃｋｓ）のディスプレイを調整するために用いられる。チャネルの全ては、共通基本チャネル・ショー・リスト（Ｃｈａｎｎｅｌ Ｓｈｏｗ Ｌｉｓｔ）を共有するが、基本チャネルのショー・リストのオフセットに開始時間を追加する。基本チャネルＩＤ（Ｂａｓｅ Ｃｈａｎｎｅｌ ＩＤ）は、構成に記憶されない。その代わり、構成は、チャネル・データ表（Ｃｈａｎｎｅｌ Ｄａｔａ Ｔａｂｌｅ）のチャネル・エントリによるハンドル（Ｈａｎｄｌｅ）と呼ばれる。チャネル・エントリが複製チャネルを有しているならば、複製チャネル・ハンドル（Ｄｕｐｌｉｃａｔｅ Ｃｈａｎｎｅｌ Ｈａｎｄｌｅ）フィールドは、それによって表をアクセスするためのハンドル番号を有する。更なる詳細は、表ＸＸＶに供給される。

フィールド 説明
Ｔｙｐｅ／Ｎｂｒ Ｂｌｋｓ このプール項目を保持するために必要なプール・エントリ型（Ｐｏｏｌ Ｅｎｔｒｙ Ｔｙｐｅ）及びブロックの番号。型値は、長さが領域のチャンネルの数により非常に大きくなることができるので、これが２バイト・フィールドであるということを示す。
Ｎｂｒ Ｃｈａｎｎｅｌｓ （インアクティブ・チャネルを含んでいる）ユーザの領域の複製チャンネル・エントリの数。

Table XXIV
Channel Duplication Table (Channel Duplicates Table)
The channel duplication table (FIG. 30) includes information on each channel in the region (Region) that is a duplication of the basic channel. This data is used to adjust the display of the pay-for-view channel block. All of the channels share a common channel show list, but add a start time to the offset of the basic channel show list. The basic channel ID (Base Channel ID) is not stored in the configuration. Instead, the configuration is referred to as a handle by the channel entry in the channel data table. If the channel entry has a duplicate channel, the Duplicate Channel Handle field has a handle number for accessing the table thereby. Further details are provided in Table XXV.

Field Description Type / Nbr Blks Pool entry type and block number required to hold this pool item. The type value indicates that this is a 2-byte field because the length can be very large depending on the number of channels in the region.
Nbr Channels Number of duplicate channel entries in the user's region (including inactive channels).

Table XXV

Channel Duplicate Entries (Channel Duplicates Entry)
There is one channel replication entry for each replication channel in the region. Further details are provided in Table XXVI.

表ＸＸＶＩ
ショー・リスト・ハンドル表
ショー・リスト・ハンドル表（図３１）は、週の毎日に対するショー・リストへのハンドルを含む。この表は、チャネル・データ表に配置された“ショー・リスト・ハンドル表”ハンドルによって指示される。この表を介して、計画するに値する週（ｗｅｅｋｓ）を表しているショー・リストをアクセスすることができる。更なる詳細は、表ＸＸＶＩＩに供給されている。

Table XXVI
Show List Handle Table The show list handle table (FIG. 31) contains handles to the show list for each day of the week. This table is indicated by a “show list handle table” handle located in the channel data table. Through this table, you can access a show list representing the weeks that are worth planning. Further details are provided in Table XXVII.

表ＸＸＶＩＩ
ショー・リスト ショー・リスト（図３２）は、所与のチャネルに対する計画の２４＋時間を含む。それが計画の２４時間以上を実際に含む唯一のときは、放送している間にプログラムが現行の日で開始しかつ２４時間ラインを横切るときである。全てのショー・リストは、毎日同じ時間で常に始まる。ダミー・スロット（Ｄｕｍｍｙ Ｓｌｏｔ）は、必要ならば前日からのオーバフローを処理するために生成される。計画の完全な組に対して、７つの個別ショー・リストが所与の加入者装置（Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）によって支持される全てのプログラム・オリジネータ（Ｐｒｏｇｒａｍ Ｏｒｉｇｉｎａｔｏｒ）に対して要求される。ショー・リストへのアクセスは、週の所与の日に対するショー・リスト・ハンドラ表を介してである。更なる詳細は、表ＸＸＶＩＩＩに供給される。

Table XXVII
Show List The show list (FIG. 32) contains 24+ hours of planning for a given channel. The only time it actually contains more than 24 hours of planning is when the program starts on the current day and crosses the 24-hour line while broadcasting. All show lists always start at the same time every day. Dummy slots are created to handle overflow from the previous day if necessary. For a complete set of plans, seven individual show lists are required for all Program Originators supported by a given Subscriber Unit. Access to the show list is through the show list handler table for a given day of the week. Further details are provided in Table XXVIII.

表ＸＸＶＩＩＩ
ショー・エントリ
チャネルの計画は、ショー・エントリの順序付けられたシーケンスによって与えられる。これらのエントリは、ショーの持続時間、表題、及び可能にはエピソードの説明を与える。エントリは、ショーが説明及び／又はグループＩＤを有するか否かにより４、６または８バイト長のいずれかである。

Table XXVIII
The show entry channel plan is given by an ordered sequence of show entries. These entries give the show duration, title, and possibly an episode description. The entry is either 4, 6 or 8 bytes long depending on whether the show has a description and / or group ID.

  Finding an entry corresponding to a given start time in turn requires an entry to be scanned from the start of the list and adds a duration value. There should be no gaps in the show list. Further details are provided in Table XXIX.

表ＸＸＩＸ
ショー表題
ショー表題（図３３）は、ショー表題の通常圧縮されたテキストを含む。各自のショー表題毎に一つのエントリが存在する。
ショー表題は、プール基本項目である。エントリは、加入者装置がショー表題を既に有していないＳＩＤを含む（加入者装置がデータを収集しているチャネルに対して）ショー・リストが受け取られるときにはいつでも生成される。エントリが生成されるときに、ハンドルは、それに割り当てられかつ“Ｎｅｅｄ Ｉｔ（それが必要である）”フラグは、ショー表題ハンドル表エントリにセットされる。
エントリの大きさは、表題の長さによって決定される。単一プール・ブロックは、新しいＳＩＤがショー・リストで受け取られるときに（ヌル表題ストリングを含んで）保存される。エントリは、適切なショー表題メッセージが後続して受け取られときに充填されかつ“Ｎｅｅｄ Ｉｔ”フラグがクリアされる。その時には、エントリは、再配置されかつ多重プール・ブロックに拡張されうる（が、しかし、そのハンドルは、同じのままである。）更なる詳細は、表ＸＸＸに供給される。

Table XXIX
Show Title The show title (FIG. 33) contains the normally compressed text of the show title. There is one entry for each show title.
The show title is a pool basic item. An entry is created whenever a show list is received (for channels for which the subscriber device is collecting data) that includes a SID for which the subscriber device does not already have a show title. When an entry is created, a handle is assigned to it and the “Need It” flag is set in the show title handle table entry.
The size of the entry is determined by the length of the title. A single pool block is saved (including the null title string) when a new SID is received in the show list. The entry is filled when the appropriate show title message is subsequently received and the “Need It” flag is cleared. At that time, the entry can be relocated and expanded to multiple pool blocks (but its handle remains the same). Further details are provided in Table XXX.

表ＸＸＸ
データベース・ショー表題ハッシュ表アクセス・スキーム
データベース・ショー表題ハッシュ表アクセス・スキームは、図３４に示される。
ショー表題ハンドル表
ショー表題ハンドル表（図３５）は、ショー表題が必要であるかどうかまたはそれが既に受け取られたかどうかを決定するために用いられるプール・ベース表である。ＳＩＤがハッシュすることができる各可能な値に対して一つのショー表題ハンドル表が存在する；即ち、２５６の表。

Table XXX
Database Show Title Hash Table Access Scheme The database show title hash table access scheme is shown in FIG.
Show Title Handle Table The show title handle table (FIG. 35) is a pool-based table used to determine whether a show title is needed or whether it has already been received. There is one show title handle table for each possible value that the SID can hash; that is, 256 tables.

  A show title handle table entry is made for every unique SID received in every show list message for the channel that is the data that the SU is collecting. The particular table in which the entry is made is determined by the hash value of the SID; that is, the lower 8 bits of the SID.

  These tables must be updated when the SID is deleted from the database. The show handle table walker background task is turned on, assesses these tables at regular intervals, and checks them against the Reference Counts that went to zero. Walker looks for an entry that can be deleted. Further details are provided in Table XXXI.

表ＸＸＸＩ
ショー表題ハンドル表エントリ
ショー表題ハンドル表は、多重エントリを含む。これらのエントリのそれぞれは、次のフィールドを含む。

Ｆｉｅｌｄ 説明
Ｎｅｅｔ Ｉｔ Ｆｌａｇ ショー表題テキスト・ストリング・メッセージがこのＳＩＤに対して受け取られたかどうかを示しているフラグ。０＝ショー表題が受け取られた、１＝受け取られていない。

ショー表題ハッシュ表
ショー表題ハッシュ表（図３６）は、各可能なＳＩＤハッシュ値に対するプール・インデックスだけを含んでいる、固定された大きさの、予め割り当てられた表である。ＳＩＤハッシュ値は、この表の中のインデックスである。ｎ番目のエントリの値は、これまでｎに対してハッシュされた受け取った全てのＳＩＤｓを含んでいるショー表題ハンドル表に対するプールの中のインデックスである。更なる詳細は、表ＸＸＸＩＩに供給される。

Table XXXI
Show Title Handle Table Entry The show title handle table includes multiple entries. Each of these entries includes the following fields:

Field Description Need It Flag A flag indicating whether a show title text string message has been received for this SID. 0 = show title received 1 = not received

Show Title Hash Table The Show Title Hash Table (FIG. 36) is a fixed size, pre-allocated table that contains only the pool index for each possible SID hash value. The SID hash value is an index in this table. The value of the nth entry is an index in the pool for the show title handle table that contains all received SIDs that have been hashed for n so far. Further details are provided in Table XXXII.

表ＸＸＸＩＩ
ショー説明 ショー説明（図３７）は、ショーのエピソード説明の（普通に）圧縮されたテキストを含む。固有のショー説明毎に一つのエントリが存在する。ショー説明は、プール・ベース項目である。エントリは、ＳＵがショー説明を既に有していないＤＩＤを含む（ＳＵが収集しているデータに対するチャネル）ショー・リストが受け取られるときにはいつでも生成される。即ち、“ｎｅｅｄ ｉｔ”フラグがショー説明ハンドル表エントリにセットされている。

Table XXXII
Show Description The show description (FIG. 37) includes (usually) compressed text of the show episode description. There is one entry for each unique show description. The show description is a pool-based item. An entry is created whenever a show list is received that includes a DID for which the SU does not already have a show description (channel for data the SU is collecting). That is, the “need it” flag is set in the show description handle table entry.

  The size of the entry is determined by the length of the description. A single pool block is reserved (including a null description string) when a new DID is received in the show list. The entry is filled when an appropriate show description message is subsequently received and the “need it” flag is cleared. The entry can then be relocated and expanded to multiple pool blocks (but its handle remains the same). Further details are provided in Table XXXIII.

表ＸＸＸＩＩＩ
データベース・ショー説明アクセス概要
図３８は、データベース・ショー表題ハッシュ表アクセス・スキームを示す。
ショー説明ハンドル表
ショー説明ハンドル表（図３９）は、ショー説明が必要であるかどうかまたはそれが既に受け取られたかどうかを決定するために用いられるプール・ベース表である。ＤＩＤがハッシュできる各可能な値に対して一つのショー説明ハンドル表が存在する；即ち、２５６の表。

Table XXXIII
Database Show Description Access Overview FIG. 38 shows the database show title hash table access scheme.
Show Description Handle Table The Show Description Handle Table (FIG. 39) is a pool-based table used to determine whether a show description is needed or whether it has already been received. There is one show description handle table for each possible value that the DID can hash; that is, 256 tables.

  A show description handle table entry is made for every unique DID received in every show list message for the channel on which the SU is collecting data. The particular table in which the entry is made is determined by the hash value of the DID; that is, the lower 8 bits of the DID.

  These tables must be updated when the DID is deleted from the database. When the Show Handle Table Walker background task is turned on and the DID is erased, for example, when these reference counts become 1, these tables are always accessed. This Walker looks for entries that can be deleted. Further details are available in table XXXIV.

テーブルＸＸＸＩＶ
Ｓｈｏｗ Ｔｉｔｌｅ Ｈａｎｄｌｅ Ｔａｂｌｅ
エントリー Ｓｈｏｗ Ｔｉｔｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｈａｎｄｌｅ Ｔａｂｌｅ は複数のエントリーを含む。これらの各エントリーはテーブルＸＸＸＩＶ に示されたフィールドを含んでいる。

Table XXXIV
Show Title Handle Table
Entry The Show Title Description Handle Table includes a plurality of entries. Each of these entries includes the fields shown in Table XXXIV.

テーブルＸＸＸＶ
Ｓｈｏｗ Ｄｅｓｃｒｉｐｔｉｏｎ Ｈａｓｈ Ｔａｂｌｅ
このＳｈｏｗ Ｄｅｓｃｒｉｐｔｉｏｎ Ｈａｓｈ Ｔａｂｌｅ（図４０）は固定サイズであり、各可能性のあるＤＩＤＨａｓｈ値に対するインデックスのみを含む予め割り当てられたテーブルである。ＤＩＤ Ｈａｓｈ 値はこのテーブルへのインデックスである。ｎ 番目の値は、ｎ までの現在までに受信された全てのＤＩＤを含むＳｈｏｗ Ｄｅｓｃｒｉｐｔｉｏｎ Ｈａｎｄｌｅ Ｔａｂｌｅ に対するＰｏｏｌへのインデックスである。詳細は以下の通りである。

Table XXXV
Show Description Hash Table
The Show Description Hash Table (FIG. 40) is a pre-assigned table that has a fixed size and contains only indexes for each possible DIDHash value. The DID Hash value is an index into this table. The nth value is an index into the Pool for the Show Description Handle Table that includes all DIDs received up to n so far. Details are as follows.

Field Description Pool Index The Pool Index for the first block of the Show Description handle table for the DID to this entry offset from the beginning of the e-table from the Hash. A value of 0 means that there is no DID (in the channel's Show list) from the Hased to the current entry.
Theme category table The theme category table (FIG. 41) contains the theme definitions downloaded to the subscriber unit. Each theme category is used to find a specific type of show. Each theme category includes one or more theme subcategories. Each theme category in each theme category table has a theme subcategory associated with it. Further details are shown in Table XXXVI.

テーブルＸＸＸＶＩ
テーマカテゴリーエントリー 各テーマカテゴリーに対する１つのテーマカテゴリーエントリーがある。さらに詳細が、テーブルＸＸＸＶＩＩに示されている。

Table XXXVI
Theme category entry There is one theme category entry for each theme category. Further details are given in table XXXVII.

テーブルＸＸＸＶＩＩ
テーマサブカテゴリーテーブル テーマサブカテゴリーテーブル（図４２）はテーマカテゴリーに含まれるテーマサブカテゴリーについての情報を含む。各テーマサブカテゴリーテーブルは１つのテーマカテゴリーエントリーよって参照される。各テーマサブカテゴリーエントリーはネーム、クオリファイヤ（ｑｕａｌｉｆｅｒｓ）およびテーマインデックスを含む。ショータイトルおよびショー説明におけるテーマインデックスはテーマサブカテゴリーのテーマインデックスに対して一致している。テーマインデックスは一致するとき、どのショーがテーマサブカテゴリーのメンバであるかを特定する。
さらなる詳細は、テーブルＸＸＸＶＩＩＩにしめされている。

Table XXXVII
Theme subcategory table The theme subcategory table (FIG. 42) includes information on the theme subcategories included in the theme category. Each theme subcategory table is referenced by one theme category entry. Each theme subcategory entry includes a name, qualifiers, and a theme index. The theme index in the show title and show description matches the theme index of the theme subcategory. The theme index, when matched, identifies which shows are members of the theme subcategory.
Further details are given in Table XXXVIII.

テーブルＸＸＸＶＩＩＩ
テーマサブカテゴリーエントリー
リジョンの中に各チャンネルについて１つのテーマサブカテゴリーが存在する。テーマサブカテゴリーエントリーのさらなる詳細は、テーブルＸＸＸＩＸに示されている。

Table XXXVIII
Theme subcategory entry There is one theme subcategory for each channel in the region. Further details of theme subcategory entries are shown in Table XXXIX.

テーブルＸＸＸＩＸ
このセクションは、加入者ユニット５２における全てのプロセッサの間で送られるメッセージを説明している。何人かの加入者ユニット設備はすべては使用しないかもしれないし、要求されないかもしれないが、すべてのメッセージが説明されている。メッセージのそれぞれのフィールド説明につづいてメッセージのフォーマットを示すダイヤグラムが示されている。グレーのフィールドは現在使用されていないフィールドを示している。しかしこのフィールドのビットは０にセットされて将来の設備との互換性を維持するようになっている。すべてのフィールドは特に指示しないかぎり、２の補数である。

Table XXXIX
This section describes the messages sent between all processors in the subscriber unit 52. Some subscriber unit facilities may not be used or required, but all messages are explained. A diagram showing the format of the message is shown following each field description of the message. A gray field indicates a field that is not currently used. However, the bit in this field is set to 0 to maintain compatibility with future equipment. All fields are two's complement unless otherwise indicated.

  The database engine-I / O processors are connected by a 1M bus that runs at 1Mbit / s. The I / O processor receives the data transmission network data via one or more specific vertical blanking interval lines and, when requested by the data engine processor, obtains the raw bytes obtained. Send. The database engine controls the tuning channel and identifies a particular vertical blank interval (VBI) line to use.

  The database engine also generates a graphic display command to the I / O processor, such as filling a rectangle with a predetermined color, and saves or re-stores the pixel count of the predetermined rectangle on the screen. All subscriber unit screens are composed of such graphic display commands.

  The database engine issues commands to the I / O processor in a packet (FIG. 43) that includes a packet length field followed by one or more commands. The I / O processor transfers all packet bytes to the RAM command buffer, and when this transfer is complete, executes the commands in the order in which they were received in the packet. The I / O processor sets a status flag indicating that it is in use until all commands are executed. The packet size is the first two bytes received in any command sequence issued to the I / O processor. Only one command packet can be sent to the I / O processor at a time.

Graphic Commands The following commands define the basic gufix operations necessary to depict the television set system display screen connected to or incorporated into the subscriber unit 52.

The screen coordinates are based on (0,0) in the upper left corner of the screen. TPU 2740 allows for a height of 503 in the X coordinate. The system maximum X is 251. This allows the system to maintain the X coordinate in a single byte and to include “system pixels” in two pixels of different colors.
Therefore, (251, 207) is the lower right corner of the screen, and the X coordinate received in the command must be doubled at this 2740.

  All colors in the following commands consist of TPU2740 colors in the nibbles above and below the color byte. By using two separate colors in a single system pixel, the number of colors that can be displayed can be increased. Actually setting the system pixel is related to setting two consecutive 2740 pixels along the X coordinate using the two colors in the color byte. Once the area is filled, these colors must be dithered. That is, the color used for successive 2740 pixels along the X coordinate is alternated between the two colors given in the appropriate color byte. An even column begins with color 1 and an odd column (eg, the Y coordinate is an odd number) starts with color 2 and alternates between the two colors for successive pixels along the X coordinate.

  The graphic routine of 2740 outputs a clip when the X coordinate or Y coordinate exceeds the limit of the screen (clip output). That is, the graphic does not wrap when the coordinates of the operation are out of (0, 0) and (251, 207).

Parameter values that violate the rules are ignored. The “cmd type” field that was in compliance with the specification causes all subsequent commands in the packet to be ignored. That is, this IOP ends with a packet that detects a command type that meets the specification.
Graphic commands have a higher priority than VBI processing.
Set Graphic Default The set graphic default command (FIG. 44) causes the I / O processor (IOP) to reset all graphic variables to their initial values. This command is used when the database engine is in a reset state and is turned on. This IOP initializes the following values:
-Shadow width = Shadow height = 3
-Shadow color = Black
・ Small Font Delta X = 6
・ Small Font Delta Y = 10
・ Large font delta X = 8
・ Large font delta Y = 15
Highlight = White, Underline 1 = Gray, Underline 2 = Black Further details are given in Table XXXX.

表ＸＸＸＸ
消去スクリーン 消去スクリーン・コマンド（第４５図）は、Ｉ／Ｏプロセッサによってスクリーンを空白にさせ、すべてのディスプレイ・バッファ画素を指定された「透明」カラーにセットさせる。これ以上詳しい点は表ＸＸＸＸＩにある。

Table XXXX
Erase Screen The erase screen command (FIG. 45) causes the I / O processor to blank the screen and set all display buffer pixels to the specified “transparent” color. More details can be found in Table XXXXI.

表ＸＸＸＸＩ
矩形描画
指定されたディザード・カラーの矩形を描画する。コマンドにセットされた対応するフラグ・ビットに基づいて一回の操作で矩形を塗りつぶしたり、輪郭強調したり、エンボス処理したりすることができる。これらの操作は、各々、他の操作から独立して行うことができる。たとえば、空白の矩形を、「アウトライン」フラグ・ビットをセットするだけで描くことができる。

Table XXXXI
Rectangle drawing Draws a rectangle with the specified dithered color. Based on the corresponding flag bit set in the command, the rectangle can be filled, the contour is emphasized, or embossed with a single operation. Each of these operations can be performed independently of other operations. For example, a blank rectangle can be drawn simply by setting the “outline” flag bit.

  In the case of a solid color, the filled rectangles, ie, “fill color 1” and “fill color 2” must both have the same value. The rectangle must be filled and embossed, then contoured and shaded. More details can be found in FIG. 46 and Table XXXII.

表ＸＸＸＸＩＩ
第４７Ａ〜４７Ｅ図に矩形の例が示してある。
矩形保存
スクリーン上の指定された矩形の画素内容を一時バッファに保存させ、矩形復元コマンドによって後に復元できるようにする。これ以上の詳しい点は第４８図および表ＸＸＸＸＩＩＩにある。

Table XXXXII
Examples of rectangles are shown in FIGS. 47A to 47E.
Save Rectangle Saves the pixel contents of the specified rectangle on the screen in a temporary buffer so that it can be restored later with the restore rectangle command. Further details are in FIG. 48 and Table XXXIII.

表ＸＸＸＸＩＩＩ
矩形復元
矩形保存コマンドで先に保存された矩形をスクリーンに復元する。復元すべき矩形はその「ポップアップＩＤ」フィールドによって認識される。復元座標により、先に保存された矩形をスクリーン上の異なった位置に戻すことができる。たとえば、これは或る種のカーソルまたはアイコンを移動させる場合に対応する。
これ以上の点は第４９図および表ＸＸＸＸＩＶにある。

Table XXXIII
Restore rectangle Restores the previously saved rectangle to the screen using the rectangle save command. The rectangle to be restored is recognized by its “pop-up ID” field. The restored coordinates allow the previously saved rectangle to be returned to a different position on the screen. For example, this corresponds to moving some kind of cursor or icon.
Further points are in FIG. 49 and Table XXXIV.

表ＸＸＸＸＩＶ
矩形縦方向移動
矩形縦方向移動コマンド（第５０図）は、スクリーン上で矩形を効果的に移動させて指定された矩形の画素内容をディスプレイ・メモリ内の別の場所に複写させる。このコマンドは縦方向移動のみを扱う。指定されたスクロール・サイズが達成されるまで、矩形を一行ずつスクロールアップあるいはスクロールダウンする。
これ以上の詳しい点は表ＸＸＸＸＶにある。

Table XXXXIV
Rectangle Vertical Movement The rectangular vertical movement command (FIG. 50) effectively moves the rectangle on the screen and copies the specified rectangular pixel content to another location in the display memory. This command only handles vertical movement. Scrolls the rectangle up or down line by line until the specified scroll size is achieved.
Further details are in Table XXXXV.

表ＸＸＸＸＶ
書き込みＡＳＣＩＩ ストリング
ＡＳＣＩＩ ストリングをスクリーンに出力する。このストリングの第１キャラクタの出発座標はキャラクタの上左コーナーに一致する。引き続くキャラクタは、ＡＳＣＩＩ キャリッジ・リターン・キャラクタに遭遇するまで、一本の横方向ライン上にある。それ以降のキャラクタは、スクリーンの下方にあり、当初のＸ座標で再開する出力「データＹ」（たとえば、各フォントについてセット・グラフィックス・デフォルト・コマンドにおいて指定されている）画素である。不法なキャラクタはそれぞれの場所で「？」を出力する。

Table XXXXV
Write ASCII string Outputs an ASCII string to the screen. The starting coordinates of the first character of this string coincide with the upper left corner of the character. Subsequent characters are on a single horizontal line until an ASCII carriage return character is encountered. Subsequent characters are the output “data Y” pixels (eg, specified in the set graphics default command for each font) that are below the screen and resume at the original X coordinate. An illegal character outputs a “?” At each location.

  The character may be output in one of the two fonts. Large fonts only support uppercase characters. Further details can be found in FIG. 51 and Table XXXVI.

表ＸＸＸＸＶＩ
チャネル・アイコン描画
指定された座標でチャネル・アイコンを描画する。このアイコンの座標は、もしそれが１または２のキャラクタ・チャネル・ネームを保持している場合にアイコンを正確に収容するだろう矩形の上左コーナーを表す。これらの座標は、「ＡＳＣＩＩ チャネル・ネーム」フィールドが２キャラクタよりも長い場合には調節されなければならない。この場合、ＩＯＰはこのコマンドにおいて送られるＸ座標を３＊だけ減分しなければならない（チャネル・ネーム長−１）。チャネル・ネーム・ストリングがまったくキャラクタを含んでいない場合には空のチャネル・アイコンが描画される（すなわち、バイト５＝０の場合、１−２キャラクタ・サイズの空のアイコンが描画される）。これ以上の詳しい点は第５２図および表ＸＸＸＸＶＩＩにある。

Table XXXVI
Draw channel icon Draw a channel icon at the specified coordinates. The coordinates of this icon represent the upper left corner of the rectangle that will correctly contain the icon if it holds a 1 or 2 character channel name. These coordinates must be adjusted if the "ASCII channel name" field is longer than 2 characters. In this case, the IOP must decrement the X coordinate sent in this command by 3 * (channel name length-1). If the channel name string contains no characters at all, an empty channel icon is drawn (ie, if byte 5 = 0, an empty icon of 1-2 character size is drawn). More details can be found in FIG. 52 and Table XXXVII.

表ＸＸＸＸＶＩＩ
チャネル・アイコンの例が第５３Ａ〜５３Ｃ図に示してある。
透明カラー使用禁止
透明カラー使用禁止・コマンド（第５４図）は、カラー・コード番号がまったく透明画素を表示しないことを指定する。このコマンドは、カラーをなんら透明にしてはならないときにそれを示すのに用いられ、フルスクリーン・ディスプレイが描画される毎に送られなければならない。これ以上の詳しい点は以下の通りである。

Table XXXVII
Examples of channel icons are shown in FIGS. 53A-53C.
Transparent Color Use Prohibited The Transparent Color Use Prohibited command (FIG. 54) specifies that the color code number does not display any transparent pixels. This command is used to indicate when no color should be transparent and must be sent each time a full screen display is drawn. Further details are as follows.

Field Description cmd type Command ID number for identifying this as a transparent color use prohibited command = 9

Network Data Acquisition and Control Interface System data is received via a PBS network, MTV, Showtime, or other communication source on one or more Vertical Blanking Interval (VBT) lines. The I / O processor gets data from each line (if it is multiple lines) and stores it in a separate input buffer. Data is stored in the input buffer of the IOP even if the framing code is incorrect for a given field. In this case, 2 bytes of 03s are stored. Data is transferred only to the database engine processor if the command pocket contains at least one command that requires a response.

  If a response to the database requires, the I / O processor transfers as many bytes as possible below the number of requested data bytes. If the input buffer is full, the I / O processor begins to damp data until the buffer is empty or a reset is issued. A full buffer causes the database engine to send an “ovfl” flag to be sent in the next response.

  The I / O processor can handle up to 2 VBI lines of system data, or it can handle one line of system data from line 21 and closed caption data. Data is always obtained from both fields for each system data VBI row. Closed caption data is also obtained from both fields.

The I / O processor responds to any command that requires a response within 10 milliseconds.
Stop VBI The VBI stop command (FIG. 55) causes the I / O processor to initialize internal variables related to VBI processing. All VBI buffer counters are cleared and any acquired data is lost. VBI data acquisition is stopped until a set VBI control parameter or a flash VBI buffer command is received. Further details are as follows.

Field Description cmd type Command ID number for identifying this as a VBI stop command = 16.
Set VBI Control Parameter This set VBI control parameter command (FIG. 56) allows the database engine to specify parameters that control the acquisition of VBI data. This command (i.e., the flash VBI buffer command) must be issued after the VBI stop command to allow VBI data acquisition.

  Parameters must be sent for all VBI lines (up to 2 lines). Each new set VBI control parameter command replaces all preceding parameters. Parameters must be ordered by line number, starting with the lowest VBI line. More details can be found in Table XXXVIII.

表ＸＸＸＸＶＩＩＩ
ＶＢＩ読み込みステータス
ＶＢＩ読み込みステータス・コマンド（第５７図）はＩ／Ｏプロセッサに指定されたＶＢＩライン・バッファ上にステータス情報を戻させる。これ以上の詳しい点は表ＸＸＸＸＩＸにある。

Table XXXVIII
VBI Read Status The VBI read status command (FIG. 57) causes status information to be returned on the VBI line buffer designated by the I / O processor. More details can be found in Table XXXIX.

Field Description cmd type Command ID number for identifying this as a VBI read status command = 18.
VBI line number for which the status is being requested. If this is 0, it means a status return for all active VBI lines.

The returned status is formatted as shown in FIG. 58 and is further described in Table I.

ｒａｔｅ このＶＢＩラインについてのデータ・レート。０＝テレキャプション・レート、１＝フルレート。

rate Data rate for this VBI line. 0 = telecaption rate, 1 = full rate.

Table L
“Read VBI Buffer”
The “Read VBI Buffer” command (FIG. 59) causes the I / O processor to restore a predetermined number of data bytes from the buffer of a predetermined VBI row. The actual number of return data bytes is less than the requested number of bytes. Details are shown in Table LI.

表ＬＩ
復帰されたデータは図６０のフォーマットを有している。詳細は表ＬＩＩに示してある。

Table LI
The restored data has the format of FIG. Details are given in Table LII.

表ＬＩＩ
“Ｆｌｕｓｈ ＶＢＩ Ｂｕｆｆｅｒ”
“Ｆｌｕｓｈ ＶＢＩ Ｂｕｆｆｅｒ”コマンドによって、Ｉ／Ｏプロセッサは、特定のＶＢＩバッファ内に存在する全てのデータを転送するか、データ収集を停止せずに、特定のＶＢＩ行のＶＢＩ処理をリセットする。最後の“Ｓｅｔ ＶＢＩ”コマンドによって送信されたパラメータによって、ＶＢＩ処理が再度使用可能になる。このコマンドは、“Ｓｔｏｐ ＶＢＩ”コマンドによって延期されたＶＢＩ処理を再度使用可能にする。
もしデータが転送される場合は、“Ｒｅａｄ ＶＢＩ Ｂｕｆｆｅｒ”コマンドの場合と同じ応答フォーマットになる。詳細は表ＬＩＩＩに示してある。

Table LII
“Flush VBI Buffer”
The “Flush VBI Buffer” command causes the I / O processor to transfer all the data present in a particular VBI buffer or reset the VBI processing for a particular VBI row without stopping data collection. The parameter sent by the last “Set VBI” command enables VBI processing again. This command re-enables the VBI processing postponed by the “Stop VBI” command.
If data is transferred, the response format is the same as that of the “Read VBI Buffer” command. Details are given in Table LIII.

表ＬＩＩＩ
受信グループ
受信グループ（またはＲＧ）は、結合チャンネルラインナップを有する、名前が呼ばれるエンティティである。受信グループは、大別すると、地上、有線および衛星の３種類に分類される。その例が表ＬＩＶに示してある。

Table LIII
Receiving Group A receiving group (or RG) is a named entity with a combined channel lineup. The reception groups are roughly classified into three types: terrestrial, wired, and satellite. Examples are shown in Table LIV.

表ＬＩＶ
いくつかのＲＧ、特に有線ＲＧは、関心を引くとともに、マーケティングやその他の業務にも役立つかもしれない関連情報を入手することになる。
そのような情報の若干の例：
連絡名
電話番号
ファックス番号
ＡＤＩ
ＤＭＡ
各ＳｔａｒＳｉｇｈｔ加入者ユニットが、「メンバー」、つまり、いわゆる唯一のＲＧであると考えられる。運用が開始された場合には、加入者ユニットには、どのＲＧに所属しているのかが知らせられなければならず、その結果、そのＲＧに相応しいラインナップが表示されることになる。ラインナップの説明
ラインナップは、特定のＲＧで受信されるチャンネルの実際のリストである。事実、いつでも、ＲＧおよび活動中ラインナップの１対１マッピングが行われる。各ＲＧについて活動中ラインナップはたった１つであり、各活動中ラインナップについてＲＧはたった１つである。２つのＲＧが時々同じ受信チャンネルリストを有する可能性がある。また、一方のリストが変更され、もう一方のリストが変更されない可能性も同じようにある。この理由から、各ラインナップはＲＧ専用である。ラインナップは、通常は、物理的な地図（テレビ局および有線システムの視聴範囲を示す地図）を見ることによって得られる情報の記述であると考えることができる。そこには、そのラインナップがカバーすることのできる物理的エリアで利用可能なチャンネルに関する情報が含まれている。ラインナップの目的は、特定のＲＧのどのチャンネルがデータによる支援を必要としているのかを定義することにある。

Table LIV
Some RGs, especially wired RGs, will get relevant information that may be of interest and may also be useful for marketing and other operations.
Some examples of such information:
Contact name Telephone number Fax number ADI
DMA
Each StarSight subscriber unit is considered a “member”, ie, the so-called only RG. When the operation is started, the subscriber unit must be informed of which RG the user unit belongs to, and as a result, a lineup suitable for the RG is displayed. Lineup Description The lineup is the actual list of channels received on a particular RG. In fact, there is always a one-to-one mapping of RG and active lineup. There is only one active lineup for each RG, and only one RG for each active lineup. It is possible that two RGs sometimes have the same received channel list. There is also the possibility that one list will change and the other list will not change. For this reason, each lineup is dedicated to RG. The lineup can be thought of as a description of information usually obtained by looking at a physical map (a map showing the viewing range of a television station and a wired system). It contains information about the channels available in the physical area that the lineup can cover. The purpose of the lineup is to define which channels of a particular RG need data support.

  Because the physical areas of cable and terrestrial television are well defined, the channels that can be received by television viewers in those areas are well known. These channels constitute the lineup required to know what listing data is transmitted for a particular RG.

  In the case of multiple lineup maps, it is possible to cover or overlap the same area. As an example of this, it may be considered that two adjacent homes, one receiving a television with a home antenna, and the other watching a cable television. In this case, since the wired TV subscriber receives many different channels by wire, it belongs to a different RG from the neighbor of the non-wired subscriber. In the above case, the StarSight data for both RGs is transmitted from one PBS station, and each subscriber unit views the data defined in the subscriber unit.

In the case of terrestrial television, a specific RG may include one to several tens of channels, and may include a weak-wave station in the fringe area. In the case of wired systems, the lineup is very well defined and is the same for all subscribers of the wired system. The lineup for satellite viewers may be slightly different on the east and west coasts, but is almost the same for viewers across the United States, with one group covering the entire continental area of the United States. I can say that.
File Layout Specification The station list consists of records with each record identifying and recording the basic characteristics of one ground station or satellite feed.
To handle non-editing stations and rebroadcasting stations, fields are used to specify where, if any, station schedule information is available. If the station is not currently being edited, the value in this field is set to zero. If schedule information is provided using a different station ID (ie, this station is a rebroadcast station), this field will contain the IDs of other stations. If the station is handled normally (schedule is edited and data is provided by its ID), this field is left empty.

  The station list may include an input corresponding to each station or feed that the seller provides data to StarSight on behalf of, whether or not the feed is in the lineup provided to StarSight by the seller. Required. This is because StarSight sometimes confirms the need for data for the station for a show or test. In such a case, StarSight may internally create a lineup that includes this station and ask the seller to provide only schedule information.

  Generally, the seller shall provide data to StarSight for all US fixed ground stations and feeds as well as specific designated local feeds. The station list must include an entry identifying each of these, an entry for all aliases for them, and an entry for all feeds that appear in the lineup provided by the seller to StarSight.

The other fields indicate the station call character or satellite feed name, the normal abbreviation of the name, the effective date and the expiration date (related to changing the station call character).
Lineup list The lineup list consists of the following two types of records.
RG record The RG record describes details about one RG, such as contact name, location, type of service, daytime discount time, etc.
Lineup Record Each lineup record describes one of the channels received by that RG. The sum of all currently valid records describing a channel within a particular RG constitutes the RG lineup. There may be records that are not currently valid, either because the date and time that they become effective are in the future, or because the date and time they expired were in the past. Each record contains enough information to clearly identify the associated RG and channel and (with knowledge of the current date and time) determine whether the record is currently valid. Furthermore, information that enables the configuration of the composite channel is also included.

  The lineup list can be updated in an incremental manner by transmitting a lineup list update consisting only of RG lineups that have been modified since the complete lineup list was last transmitted. Note that if you update a specific RG lineup, you must do a full update. That is, the lineup list update may only update a portion of the RG, but the updated RG must be updated by transmitting all lineup information about that RG.

The entire lineup list will be transmitted weekly and the lineup list update will be transmitted daily.
File Naming Rules File names for stations and lineup lists shall be assigned as follows. The basic name of each file consists of 6 characters indicating the date. The basic name shall be separated from the suffix by a period, and the suffix shall indicate the type of file according to Table LV below.

表ＬＶ
ファイル内容
これらのファイルは、２０〜７Ｅ ｈｅｘの範囲を含むＡＳＣＩＩテキストから構成された記録を含むことになる。この唯一の例外は、ＡＳＣＩＩラインフィードである、記録ターミネータＯＡ ｈｅｘの端である。
ファイル転送
局およびラインナップファイルは、復帰改行終了記録からなるパイプ区切りフォーマット（ＰＤＦ）ＡＳＣＩＩファイルである。これらのファイルはＳｔａｒＳｉｇｈｔに電子的に転送しなければならない。
複合チャンネル
複合チャンネルの発行はラインナップを通じて取り扱われる。もし単独同調可能チャンネルが複数の番組源から定期的に番組を放送している場合は、そのチャンネルが複合チャンネルとして知られている。（例：有線チャンネル４１が１日のある部分はＶＨＩを放映し、１日の別の部分にはＨＢＯを放映することがある）。

Table LV
File contents These files will contain records composed of ASCII text containing the range of 20-7E hex. The only exception to this is the end of the recording terminator OA hex, which is an ASCII line feed.
The file transfer station and lineup file are pipe-delimited format (PDF) ASCII files consisting of a carriage return end record. These files must be transferred electronically to StarSight.
Composite channel Issuance of composite channels is handled through the lineup. If a single tunable channel regularly broadcasts programs from multiple program sources, that channel is known as a composite channel. (Example: The wired channel 41 may broadcast VHI on one part of the day and HBO on another part of the day).

The lineup is the same “tuned channel” for each feed that becomes a composite channel
Deal with this by assigning. Start and stop times can be used to determine what data is compiled into the composite.

  Composite channels are rarely seen on terrestrial television or satellite, but it is quite common for wired providers.

Each record in the station file list file consists of fields defined in Table LVI. Each field is separated from the next by an ASCII “pipe” (7C hex) character. If no data is available, a field with a specified default size of 0 may be left empty. A field with a non-zero minimum size is required. Note: To inform StarSight that the station list entry is being deleted, the station list record contains the data in the "Station ID" and "Last Modified Date / Time" fields, and all other fields are empty. Is transmitted. This tells StarSight to stop performing internal processing for that station.
Station list recording format

表ＬＶＩ
ステーションリストレコードフォーマットの詳細な説明は、表ＬＶＩＩに与えられている。

Table LVI
A detailed description of the station list record format is given in Table LVII.

表ＬＶＩＩＩ
ステーションリストレコードの例は、表ＬＶＩＩＩに与えられている。

Table LVIII
An example of a station list record is given in Table LVIII.

表ＬＶＩＩ
上に述べたデータを含む記録は以下の通りである：

Table LVII
The records containing the data mentioned above are as follows:

ラインアップリスト ラインアップのデータベースは、各ＲＧの現に有効である各チャンネルのための一つの記録を含み、各ＲＧの将来のラインアップも含むかもしれない。“チャンネル”は、分離されて定期的な供給である。複合チャンネルは複合の各部分に対する分離した記録を使用して説明される。

Line-up list The line-up database contains one record for each channel currently valid for each RG and may also contain the future line-up for each RG. “Channels” are separate and periodic supplies. Composite channels are described using separate records for each part of the composite.

  Several agreements must be observed to minimize the StarSight ("StarSight" s) processing load.

  1. Each field is bounded by the ASCII “pipe” (7C hex) character from: If no data is available, a field with a special false dimension of 0 remains empty, and a field with a non-zero minimum dimension is mandatory.

  2. 0 in the “Lineup Record Count” field and normal observation RG, except to include a special date / time to expire in the “Expiration Date / Time” field to signal the starlight that the RG will be excluded Records are communicated. All other fields are formatted for this specification. This signals the star site and stops doing internal processing combined with this RG at special days / hours. Note: Due to the inherent delay in processing this type of information, it is not a good idea to reuse this RG number to identify a new RG. To ensure that there are no such property issues, RG numbers should never be reused.

  3. The lineup must always be described globally, with the RG recording immediately followed by all lineup recordings combined with this RG.

  4). When there are both current and future lineups that define an RG, it is first communicated with the RG record with the earlier of the two valid data, and then followed by all of the current lineup Subsequently, another RG record having future valid data is followed by all of the line up records for the future line up.

  5. If any lineup data is provided for a given RG, the entire lineup for the RG (including all currently valid and all that are enabled periodically) must be provided.

  6). All records that handle a given RG must be adjacent in the file. For example, it is not allowed to have a record that handles RG 100, then handles RG 101, and then handles RG 100 in the same file.

7). Lineup information is sorted in ascending order for the next key value.
a. RG number b. Valid data c. Power supply d. Tuning channel #
8). By providing this information in any field of this name in the RG record, an “expiration date / time” for the information in a given lineup can be clearly scheduled.

  9. Changes to any record in the lineup must be reflected by updating the “Lineup Information Last Date / Time Correction” in the RG record for that lineup.

  10. Note that there is no field in the lineup record for "Last Date / Time Correction". This is handled by updating the “Lineup Information Last Date / Time Correction” in the RG record. Updating the “lineup information last date / time correction” field means that the entire lineup for the RG has been updated and changed.

11. Note that there is no field in the lineup record for “valid days / hours”. This is handled by updating the “effective date / time correction” in the RG record. The value of the “Valid Date / Time Correction” field means that the entire list of lineup records following this RG record is valid (or valid) for that date and time.
The RG recording format is shown in Table LVIII.

表ＬＶＩＩＩ
ＲＧフィールドの説明
フィールド＃
１．記録タイプ（１バイト）
このフィールドは常に、上方の場合のＡＳＣＩＩ文字”Ｒ”または”Ｓ”の一方を包含し、この記録がＲＧ記録であるということを特定しなければならない。
もし記録タイプが”Ｓ”ならば、この記録は特別な衛星を述べるために使用され、あるフィールドの意味は再定義（以下に詳細に述べる）される。両方の記録のタイプは同じ数のフィールドを持つが、記録タイプが”Ｓ”であるときは、幾つかのフィールドは常に空である。
２．ラインアップ記録計数（１−４バイト）

ラインアップ記録の小数はこの記録を追従する。すなわち、次の記録の数はこのＲＧのラインアップを完全に定義するために使用される。
３．ＲＧ番号（８バイト）
この数はこのＲＧの独特の十進法８桁のＩＤである。ＲＧ番号は再指定されることはできない。一度ＲＧ番号が指定された場合でも、（例えば、会社がビジネスから外れることによって）、結局使用から外れるかもしれない。しかし、この場合であってもそのＲＧ番号は再使用されるべきでない。
４．ＲＧグループタイプ（１バイト）
ラインアップタイプはこのＲＧがどんなタイプのサービスを目標としているかを定義する：
０＝ＴＶ放送、これは従来のＴＶチャンネルＲＧである。

Table LVIII
RG field description field #
1. Recording type (1 byte)
This field always contains one of the ASCII characters "R" or "S" in the upper case and must specify that this record is an RG record.
If the record type is "S", this record is used to describe a particular satellite and the meaning of certain fields is redefined (detailed below). Both record types have the same number of fields, but when the record type is “S”, some fields are always empty.
2. Lineup recording count (1-4 bytes)

The decimal of the line-up record follows this record. That is, the next number of records is used to completely define this RG lineup.
3. RG number (8 bytes)
This number is the unique decimal 8 digit ID of this RG. The RG number cannot be redesignated. Even if an RG number is specified, it may eventually be removed from use (eg, by the company leaving the business). However, even in this case, the RG number should not be reused.
4). RG group type (1 byte)
The lineup type defines what type of service this RG is targeting:
0 = TV broadcast, which is a conventional TV channel RG.

  1 = Standard cable system, which is a conventional cable frequency plan.

2 = IRC cable (IRC is a modified cable frequency plan)
3 = HRC cable (HRC is another modified cable frequency plan)
4 = Cable system, unknown frequency plan 5 = Satellite RG name (if record type is “R”) (Up to 120 bytes)
Satellite name (if the record type is “S”)
Use a redundant description of up to 120 characters to describe the RG or satellite as unambiguous as possible. If cable RG, use the MSO name field if appropriate. The RG name should uniquely identify a legal entity that can have its own lineup. For example, each head end of a cable system can have its own lineup, even if it is a single number or even a unique combination of cable system name and number, Should have a unique name.

6). Cable system name (if record type is “R”) (up to 120 bytes) Satellite abbreviation (if record type is “S”)
If a cable, this may be a system operated by a multiple system operator (MSO). If so, give it a name commonly used by the community to identify this cable system. If it is a satellite, name it with the usual letter / number combination, eg G3 for Galaxy3.
7). MSO name (if the recording type is “R”) (up to 120 bytes)
Satellite operator (if record type is “S”)
If a cable, this may be a system operated by a multiple system operator (MSO). If so, give it a name commonly used by the community to identify this cable system. If satellite, this may be a system operated by a multiple system operator (MSO). If so, name the MSO. If it is a satellite, name the satellite operator.
8). RG local contact (0 to 120 bytes)
8. Name of local contact at cable company Contact phone number (up to 20 bytes)
Name of local contact person of cable company10. Highway address (up to 120 bytes)
10. Address of local contact person of cable company City (up to 120 bytes)
Name of the city where the contact is located 12. State (0-2 bytes, alpha)
This is a two-letter shortening of the state's US postal service.
13. Zip code (0-10 bytes)
The zip code is formatted as 5 bytes,-(dash) 4 bytes. In rare cases, only the first 5 bytes can be used.
14 DMA name (when record type = "R") (up to 120 bytes)
Orbit position (when record type = "S")
What is the name Nielsen uses to indicate the DMA with this RG?
15. DMA rank (always empty when record type = "S") (3 bytes, number)
16. ADI name (always empty when record type = "S")
(Up to 120 bytes)
What name does Arbitron use to indicate the ADI with this RG?
17. ADI rank (always empty when record type = "S") (3 bytes, number)
18. Community Served (Empty when record type = "S")
(Up to 300 bytes)
A comma-separated list of towns, circles, communities, communities, districts, or counties supplied by this RG. This list should be as concise and accurate as possible on the side containing too many but not too many names, if not all, but wrong.
19. Comment (up to 300 bytes)
Any special information that will help distinguish this RG from those close to the person performing the data entry fields or others, especially when this is related to an attempt to determine which RG the new subscriber is in should be noticed Important for star sites.
20. RG General Information Last Modified Data / Time (10 bytes, numbers)
GMT data and time. This record was last modified.

Format yymmddhhmm. For example, 9307110514
21. RG lineup information Last modified data / time (10 bytes, numbers)
GMT data and time. Any lineup associated with this RG was last modified. Format yymmddhhmm. For example, 9307 110514 Note: The value “0000000000000” is reserved and has the special meaning “no lineup available for this RG”.
22. Valid data / time (10 digits)
GMT data / time. The following lineup is valid. Used to designate line-up information that is idiomatic or not yet valid, but is valid with known future data and time. This field specifies the data and time at which the information was valid or valid.
23. Expiration data / time (empty or 10 digits)
GMT data / time. This field specifies future data and time when the lineup information for this piece is no longer valid. Assuming this clarified data / time does not include the last minute, it means that the lineup ends at the beginning, not the last minute.
An example of an RG record is given in Table LIX.

表ＬＩＸ
上記指定されたデータを含むサンプルレコードは以下の通りである。

Table LIX
The sample record containing the specified data is as follows.

ラインアップレコードフォーマットを以下に表ＬＸに示す。

The lineup record format is shown in Table LX below.

表ＬＸ
ラインアップレコードの詳細な説明は以下のとおりである。
１．レコードタイプ（１バイト）
「Ｒ」＝ノーマルラインアップレコード、「Ｔ」＝サテライトＴＶＲＯラインアップレコード
２．ＲＧナンバー（８数字）
３．チューナブルチャンネル（１〜３バイト）
これは、このプログラムを受信するため貴方が調整することになるチャンネルである。これは、（レコードタイプが「Ｌ」であるときには）ケーブルシステムの、また、（レコードタイプが「Ｔ」であるときには）ＴＶＲＯのトランスポンダーナンバーのケーブルチャンネルナンバー又はレターである。
４．ソース（レコードタイプ＝「Ｔ」であるときにはエンプティー）
幾つかのケーブルシステムは、２又は３以上の別々のケーブルの中から選択する能力を有する、すなわち、これがこのようなシステムであるときには、どのケーブルを使用するのかを指定する。これがシングルソースシステムである場合にはエンプティのままにする。
５．チャンネルＩＤ（１２バイト）
これは、このチャンネルのスケジュールインフォメーションを確認するのに使用される唯一の（ユニーク）ナンバーである。これは、そのユニークなスナヒションＩＤを使用する、ステーションリストに構成されたステーションのうちの一つに関する。
６．チャンネルタイプ（１数字）
これは、いかなる種類のチャンネルか（ケーブル及びＴＶＲＯラインアップに適用する）
ａ 知らない
１＝ ベーシック
２＝ エクステンディッドベーシック
３＝ プレミアム
４＝ ＰＰＶ
ｂ ベンドウズリクエストの決められた意味である７．デイ（０〜７バイト）
これらは、このフィードが使用される曜日である。非コンポジットチャンネルに関しては、曜日は１２３４５６７であろう。非コンポジットケースに関しては、これは非常に一般的なケースであるから、フィールドをエンプティのままにしておくことは七日すべてを指定することに等しいことを定義する。七日までの如何なる組合せをこのフィールドで指定することができる。

Table LX
The detailed description of the lineup record is as follows.
1. Record type (1 byte)
“R” = normal line-up record, “T” = satellite TVRO line-up record RG number (8 numbers)
3. Tunable channel (1-3 bytes)
This is the channel that you will adjust to receive this program. This is the cable channel number or letter of the transponder number of the cable system (when the record type is “L”) and TVRO (when the record type is “T”).
4). Source (Empty when record type = "T")
Some cable systems have the ability to choose between two or more separate cables, i.e., when this is such a system, it specifies which cable to use. Leave it empty if this is a single source system.
5). Channel ID (12 bytes)
This is the only (unique) number used to confirm this channel's schedule information. This relates to one of the stations configured in the station list that uses that unique snahtion ID.
6). Channel type (1 number)
This is what kind of channel (applies to cable and TVRO lineup)
a Don't know 1 = Basic 2 = Extended Basic 3 = Premium 4 = PPV
b The defined meaning of the Bends request. Day (0-7 bytes)
These are the days of the week on which this feed is used. For non-composite channels, the day of the week will be 1234567. For non-composite cases, this is a very common case, so defining that leaving the field empty is equivalent to specifying all seven days. Any combination up to 7 days can be specified in this field.

  These numbers are single bytes with the following meanings:

1 = Sunday 2 = Monday 3 = Tuesday 4 = Wednesday 5 = Thursday 6 = Friday 7 = Saturday Thus, the “day of week” field of 257 specifies Monday, Thursday and Saturday.
8). Start time (4 bytes)
This is the start time (GMT) and from this data this channel should be used. For non-composite channels, the start time is always 0000 hours GMT.

Stop time (4 bytes (4 bytes))
This is the stop time (GMT) for data from this station. For non-composite channels, the stop time is always 0000 hours GMT. Data / time identification means that the last minute is assumed to be non-inclusive, meaning that the lineup expires at the beginning rather than at the end of this minute.

End of record ASCII line feed (0AHex) or carriage return (0Dhex)
Example: Lineup containing current and future data for a two-cable system The following virtual lineup shows a system that uses only two channels for each of the two cables, whereas the current and future lineup Is present. This data is sorted as described above, ie currently valid information for source A is given first (sorted in ascending order by channel number), followed by information currently valid for source B. Is then given future information for source A and finally future information for source B. The bold or boldface record is the only record that actually differs between the two lineups, and channel 2 of cable B is given again. However, it should be noted that future lineups are given as a whole.

例：ＲＧを削除
下記のこの例は、上述した例、０４００ＧＭＴで１９９４年１月１５日有効、で説明したＲＧをどのように削除するかを示す：

Example: Delete RG This example below shows how to delete the RG described in the example above, 0400 GMT, effective January 15, 1994:

これは、ファイルされた満了データ／タイムを備えた、ただの、通常のＲＧレコードであることに留意されたい。通常のケースとは異なり、“ラインアップレコードフィールド”で０で示されるように、引き続くラインアップレコードがない。

Note that this is just a normal RG record with filed expiration data / time. Unlike the normal case, there is no subsequent lineup record as indicated by 0 in the “lineup record field”.

Glossary The following terms are used as described below. Terms not listed in this glossary are known to those in the listing data industry and related industries.

CAC: Community Access Channel Channel: separate frequency bands assigned to the TV station Composite Channel: one channel, two or more POs time-sharing programming DP: data provider (program Listing data provider)

Data Provider: TV program listing data supplier Field (FIELD): Record subpart (Record is made up of multiple fields.)
GMT: Greenwich Mean Time (World Standard Time)
HRC: Cable System Frequency Transfer Standard StarSight: Starsite Telecast Incorporated IRC: Cable System Frequency Transfer Standard Local: Television Broadcasting Station Within 35 Miles from Cable Provider Map (MAP): Receiving Reference to the physical area of the group (RG) MPAA (Motion Picture Artists Association): Filmmakers Association (appropriate guidelines for viewers)
MSO (Multiple System Operator): Multi-system operator (operates two or more cable systems)
PO: Program organizer (TV station, TV cable provider, satellite video provider)
Prime time: Evening hours when the highest audience rating time is considered Program organizer: (see PO)
PST: Pacific Standard Time (West Coast Time)
Record: A defined set of ASCII characters in the file. RG: Reception group, TV channels available in a clear geographic region. Runtime: Show or movie length in minutes. Service Provider ): Television broadcast station that carries program data of the head end and star site of the cable system Show list: Pipe delimit format (Pipe) containing schedule listing information as described in this specification A file that contains a record of the Deliminated Format. Start Time: Local time when the show starts (hour-minute)
SU: Used for decoding subscriber unit abbreviation (subscriber unit) and starlight data.

SyndEx: Syndicate Exclusivity
TCP / IP: Transmission Control Protocol, that is, Transmission Control Protocol / Internet Protocol (Transmission Control Protocol / Internet Protocol)
Specific zone: a predetermined distance or area from the broadcast station. Summary of this description The following description details the requirements of a data provider in connection with sending TV listing data to a star site lettercast. . This defines the format of the show list (pipe delimiter file) in detail. The format of each record in these files is also specified in detail.

  Details of the electronic transfer of these files to the star site and the special file requirements and details required by national program oddities such as SyndEx are also outlined.

  The format of the show list records used to create the Starsite Electronic Database is highly aggregated in our database program, and these formats are not outlets written by Starsite Telecast. No need to change or change. If the syntax and meaning of the fields used are previously documented, the use of a Vendor-Defined Field (described below) is allowed.

File Transfer Specifications File Transfer Media and Speed Show list files are stored in standard TCP / IP programs, FTP, through DP Ethernet (digital) and digital leased lines connected to routers. Will be sent electronically to the Starsite Telecast's UNIX® file system. The operating speed of the lease line is sufficient to transfer all data files in a reasonable time.

File Transfer Protocol and Compressed Data is transferred to the Starsight Telecast UNIX file system using the TCR / IP file transfer protocol or other file transfer protocol standards that are mutually agreed. Because this file is bulky in transferred data, our UNIX file system needs to be compressed using compatible and mutually agreed data compression algorithms.

File Transfer Details Files are transferred to the star site daily, seven days a week, with file transfer completed by 0800 RST. Daily file transfers are in the home directory corresponding to the LOGIN name used to perform the file transfer.

The “main” file download to the star site is always 12 days ahead. Thus, if today is the 10th day, today's data download is during the start time starting at 0000 GMT on the 22nd day.
(See GMT specification below)
Since data files are sent daily, some mechanism is needed to update the program listings that have already been transferred. This is accomplished by an “Update” file. Since the latest Update file is created, this Update file includes a record of all the changes that have been made, and changes all the data that is still “active”. “Active” data is defined as the day that starts on today's date and continues for the next 11 days, ie, from today to today's “Main” file and spans all days that do not include that date.

  The service class that is plugged in requires "Flash Updates", and this service class provides the "Flash Updates" file within 5 minutes after entering all changes. Such files are “trickled” through the lease line to Starside throughout the day.

Show List File Introduction Star Sight Telecast transfers specially formatted data to Star Sight subscribers throughout the United States. This data is called a star site and is used to create an “on-screen program guide” that allows subscribers to interactively display television program listings on the television screen. The information for this network comes from a database created by a computer program running on our UNIX computer. In order to create a database, the data provider is required to provide the star site with a program listing file called a show list file.

GMT
A show list file is a set of chronological records of a television program listing. The star site needs a show file list in which the first record has a start time of 0000 hours GMT or the first show that starts after 0000 hours GMT. Thus, the first record in each show list file is for the first show at or after midnight, and the last record in the show list file is for the last show beginning before 2400 o'clock GMT. It is.

  In other words, a given Main file contains all the records related to PO for a day, with the day starting at 0000 GMT and ending at 2400 GMT. Conversely, the Main file must contain a show for all POs of the day.

  Since the “start time” field of every show list record is always given by GMT, the data provider is warned that it must consider daylight saving time twice a year. That is, once is when summer time is introduced in the spring and once again when it returns to standard time in the fall. This time change must be made for all program data and all POs unless the PO lives in a state or country where there is no daylight saving time. With daylight saving time, DP will collect or transfer records to a PO file that has been modified by a one hour advance adjustment in the spring and a one hour delay in the fall.

It should be noted that when the program time is adjusted to GMT, the program listing record should always follow immediately without gaps or duplication, even for daytime saving transition data.
SyndEx and network exclusivity According to FCC rules, TV cable providers may block local TV broadcaster programs and programs that collide directly in both time and content (at the request of local stations). Desired. This allows the cable provider to replace the program on that channel during the collision time. In order to display the correct schedule for the slot during the block time, StarSight must be informed about Syndex block within 24 hours prior to this block.

Sports Deletion According to the FCC rules, if a predetermined percentage of tickets are not sold within 24 hours of a sporting event, the sporting event can be deleted from the local TV broadcast. The star site asks for information about this deletion.
Mixed Channels Some cable providers may divide a cable channel into many program segments and insert programs from two or more program creators on one channel at another time. The DP is required to provide the star site with information that clearly explains what services are performed on such channels at a given time. This information is defined in the PO list for the channel on which the hybrid program occurs.

A lot of PO information for the hybrid channel is dealt with in the above-mentioned "RG List Format Specification".
Community Access Channel The FCC requires each cable provider to support at least one Community Access Channel (CAC) for public use. Private citizens can seek program time on this channel for such public perspectives, public information or approved public programs. The star site requests a program list along with program information for each CAC, and the CAC program list name is bound to the name of each cable system.
Low power station LPTV
Low-power (mostly privately owned) TV broadcast stations exist in many areas of the United States. Some of these low power stations will require program list support by DP. This is processed for each station based on the program list file for each LPTV.

The exact format in data for syndex, network exclusivity, sports removal, hybrid channels, public access channels, low power stations should be determined.
Definition of Program List File The program list file is composed of a number of records including a television program list. This program list record has a predetermined number of fields. Most fields are of a predetermined size with several fields of variable size. This gives a minimum and maximum bit size to the program listing record. (See definition of program list record field for exact minimum / maximum size).

Except for the end of the record terminator, that is, 0A hex (line feed), the program list file contains only ASCII symbols and those in the range of 20 hex to 7 hex before and after. This prevents the control code, new line code or record code from becoming part of the program listing file.
Program list file names Three types of files are described in this description. They all have the same record format, but they are used somewhat differently. These are called “main” file, “update” file, and “fresh” file for predetermined data. The main file contains only data relating to certain data. The main file corresponds to the initial loading of all data relating to such data. The update file includes information for revising the program list data provided on the early day. This update file contains several days of comprehensive data, depending on the new information entered. The fresh file contains the updated information entered.

  The name of the main file consists of the characters “MAIN”, followed by four numbers representing the date, a period and a suffix “DAT”. For example, when “MAIN0812”, MAIN0812. DAT is a valid main file name.

  The update file name is composed of characters “UPDT”, followed by four numbers representing the date, a period, and a suffix “DAT”. For example, when “UPDT0812”, UPDT0812. DAT is a valid main file name.

  The fresh file name consists of the characters “FLSH”, followed by four numbers representing the date, and optionally a period and a suffix “DAT”. For example, when “FLSH0642” is set, FLSH0642. DAT is a valid update file name.

  The file naming change is chosen to work with virtually all existing computer operating systems, as it provides an interface to different types of computers. Alphabetic characters in file names are either all upper cases or all lower cases, and mixed cases are not allowed.

Each PO data has a portion of the file itself that is specified by specifying the PO in the first field of each record for that PO. This ID number (not exceeding 12 bytes) consists of ASCII digits 0-9 and is specified by the station ID number assigned to this PO in the station list file, which is specified in another document.
Program List File Length Each file contains a program list record specified in any of these documents.
This file contains records that are required to fill 24 hours a day.
Each record in a given file has a program length as defined by an “execution time” field and a “start time” specified in the start time field of the program listing record. With this start time and execution time, the contents of the file are continuous 24 hours a day with no gaps in time order.
Consecutive Files All “main” file records have continuous start and execution times without any time gaps, such as daily and weekly.

  The format of the program list record is shown in Table LXI.

表ＬＸＩ
エンド・オブ・リコード・マーカーおよびエンド・オブ・ファイル・マーカーは、単一のラインフィード（ＯＡ ｈｅｘ）および／またはキャリッジ・リターン（ＯＤ ｈｅｘ）となる。

Table LXI
The end-of-recode marker and end-of-file marker are a single line feed (OA hex) and / or a carriage return (OD hex).

  Show types for general programming are shown in Table LXII.

表ＬＸＩＩ
注：
ショータイプ指示子は、つねに、一定の３キャラクタ長を有している。必要があれば、さらに、指示子を追加して用いてもよい。

Table LXII
note:
The show type indicator always has a certain three character length. If necessary, an indicator may be additionally used.

  The types of shows for sports programming are shown in Table LXIII.

表ＬＸＩＩＩ
注：
ショータイプ指示子は、つねに、一定の３キャラクタ長を有している。必要があれば、さらに、指示子を追加して用いてもよい。

Table LXIII
note:
The show type indicator always has a certain three character length. If necessary, an indicator may be additionally used.

  Detailed show list field class description.

The show list record field is divided into four classes. They are the data field that contains program information, the delimiter field that separates the data fields, the end of the recode terminator and the file terminator that terminates and separates the recoding.
A description of the field class.

Note that all fields in the following specifications have a minimum and maximum size expressed in bytes. Many fields have a fixed length and should not change from a predetermined length. Other fields have variable minimum and maximum lengths, but a few are defined as minimum or maximum. Even if the fixed length field contains meaningless data, it must be packed to the minimum length with the appropriate characters. The maximum field length must also be attached and no field is allowed to exceed that maximum length.
Data field text No text contained in any field contains a control code and all fields contain only ASCII characters set within a hexadecimal value range including 20-7E. Yes.
delimiter

は、ショー・リスト・リコードの異なるフィールドを分け、ショー・リスト・リコード内で一意的であり、デリミタとして以外には、ショー・リスト・リコード内で使用されない。等しい数のデリミタとデータフィールドがある。ショー・リスト・リコードは、フィールド、デリミタ、・・・，・・・，フィールド、デリミタ、エンド・オブ・リコードのパターンを有している。デリミタは、各リコードの最後のデータフィールドに続いている。
エンド・オブ・リコード
全てのリコードは、ショー・リスト・リコード内の最後のデータフィールドの最後のデリミタに続くエンド・オブ・リコード・ターミネータで終了する。このターミネータは、ラインフィード（ＯＡ ｈｅｘ）用のＡＳＣＩＩ コード、あるいは、キャリッジ・リターン（ＯＡ ｈｅｘ）、あるいは、いずれかの順序の双方である。

Separates the different fields of the show list re-record, is unique within the show list re-record, and is not used within the show list re-record other than as a delimiter. There are an equal number of delimiters and data fields. The show list recode has a pattern of field, delimiter,..., Field, delimiter, and end of recode. The delimiter follows the last data field of each record.
End of Recode All recodes end with an end of recode terminator following the last delimiter of the last data field in the show list recode. This terminator is either an ASCII code for line feed (OA hex), a carriage return (OA hex), or either order.

End of file The end of file terminator is defined as the text string “ZZZZZOF”. There must be an end-of-file terminator up to the signal that all the data has been transferred after the last data recode of the Show list file.
Detailed data field description.
field#
1. Station ID
(1-12 bytes) Station ID is used to indicate the origin of this program (TV station, cable channel or satellite provider) (specified by the data provider (see Station List Recode Format)) ) A unique number. It must not exceed 10 decimal digits. Other characters are not allowed.
2. Start data (8 bytes) An 8-byte number indicating the GMT data when the program is broadcast (year, month, day). This data must be the same for all recodings in a given file. 1 to 4 bytes define the current year, for example 1991.

  3 to 4 bytes define the month, 01 for January and 12 for December.

The 5th to 6th bytes indicate the day from 01 to 31.
3. Start time (4 bytes) The number of 4 bytes is the program broadcast time GMT, which is input as a military time.

  1 and 2 bytes are the time in GMT time when the program is aired.

(Example: 6:00 am = 06,
Noon = 12,
6pm = 18,
Midnight = 00)
3 and 4 bytes are for the program to be broadcast.
(Example: 1 minute past = 01, 1 minute ago = 59)
4). Program length in runtime (4 bytes). The minimum show runtime length is 0005 minutes and the maximum length is 9999 minutes. (The Starsight database program breaks a show into multiple shows that are 240 minutes long with a runtime greater than 240 minutes.) Runtime data is shown in Table LXIII.

表ＬＸＩＩＩ
上記ショー・リスト・リコード・フィールドのサンプル・フラグメント
５９６３２１５｜１｜９９１２３１｜０９００｜００６０｜

フィールド＃
５．クローズド・キャプション
（１バイト）ショーが終わると、このフィールドには、“Ｙ”（ｙｅｓ）の見出しがつけられ、そうでないときは、”Ｎ”（ｎｏ）の見出しがつけられる。
６．ステレオ
（１バイト）ショーがステレオのとき、このフィールドは“Ｙ”（ｙｅｓ）となり、そうでないときは、”Ｎ”（ｎｏ）となる。
７．カラー
（１バイト）ショーがカラーのとき、このフィールドは”Ｃ”（ｃｏｌｏｒ）となり、そうでないときは、”Ｂ”（ｂｌａｃｋ ＆ Ｗｈｉｔｅ））となる。
８．タイプ
（３バイト）映画、スポーツ、ニュース、トーク・ショーなどを示すプログラムを示す簡略記号。
（表ＬＸＩ、ＬＸＩＩ参照。）
９．映画番号
（０ないし１０デシマルデジット）この一意的数は、データ・プロバイダにより、ショーに対する一意的数として与えられ、放映された各ショーや映画のタイトルにより異なっている。一旦、この数が使用されると、そのタイトルを示すものとしてロックされて残る。

これらのフィールドの例は、表ＬＸＩＶに与えられている。
表 ＬＸＩＶ

Table LXIII
Sample fragment of the above show list recoded field 5963215 | 1 | 9912331 | 0900 | 0060 |

field#
5). When the closed caption (1 byte) show ends, this field is labeled with a “Y” (yes) heading, otherwise it is labeled with a “N” (no) heading.
6). Stereo (1 byte) If the show is stereo, this field will be "Y" (yes), otherwise it will be "N" (no).
7). Color (1 byte) If the show is color, this field will be "C" (color), otherwise it will be "B" (black & White)).
8). Type (3 bytes) A mnemonic that indicates programs that show movies, sports, news, talk shows, and so on.
(See Tables LXI and LXII.)
9. Movie number (0 to 10 decimal digits) This unique number is given by the data provider as a unique number for the show and varies with the title of each show or movie aired. Once this number is used, it remains locked as an indication of the title.

Examples of these fields are given in Table LXIV.
Table LXIV

上述のショーのリストのレコードフィールドのサンプルフラグメントは、次のとおりである。

A sample fragment of the record field of the above show list is as follows.

Y | N | C | MOV | 1234567890 |
Field # 10. Group ID
(5 bytes) The number of 5 bytes ranges from 00000 for no program link to 65535 for unique program links from 65,535. This number takes into account a unique grouping of two or more special programs (programs) or shows that need to be linked together for the purpose of recording. Linking or grouping of these programs is required for successive recordings of programs that do not have the same title name, as in ROOT1 and ROOT2. These fields will be 00000 if there is no program link and a unique decimal number up to 65,535 if there is a link.
This unique number is retained until the linked programming is complete and any show related to this number has gone out of the database. After that time, this number is returned to the state before the operation started and can be used again. There is no provision for permanently locking the group ID number of any show.

  The upper bound of 65,535 is necessary because this number is converted by Star Star to a 2-byte binary number and sent to the SU in this way.

If there is no incompatibility in recording time, this number crosses the channel boundary and is used to link together as a set of two or more shows on two or more different channels.
11. Title (0 to 50 bytes) This field contains the title of the program, ie the name of the sports team, talk show, etc.

Examples of these fields are given in Table LXV.
Table LXV

上述のショーリストのレコードフィールドのサンプルフラグメントは次のとおりである。

A sample fragment of the record field of the show list described above is as follows.

0000 | People fly |
The following four program description fields should be different when used. Multiple descriptions are not intended to be multiple copies of the same description. The description must enter the smallest field in which it fits perfectly. If there are four different program descriptions, insert the descriptions into the appropriate length field in a decreasing order.

  Field 12-19: description, criticism, episode title, production year and director.

  12 Program description 1 (0 to 300 bytes) This is the longest description of a program, show, sporting event, etc.

  13. Program description 2 (0 to 200 bytes) This is a shortened description of programs, shows, sports competitions, etc.

  14 Program description 3 (0 to 100 bytes) This is a shortened description of programs, shows, sports competitions, etc.

  15. Program description 4 (0 to 50 bytes) This is the shortest description used to describe programs, shows, sports competitions, etc.

  16. Criticism (1 byte) Criticism for rating movies. This is "0" if there is no critique, or 1, 2, 3 or 4 with 4 being the highest, depending on the quality of the movie.

  17. Episode (0 to 50 bytes) This prepares for the description of a series of show episodes.

  18. Year (0 or 4 bytes) This is the year that the movie or show was produced.

19. Director (0 to 25 bytes) Name of the movie director.
Examples of these fields are given in Table LXVI.

                    Table LXVI

上述のショーリストのレコードフィールドのサンプルフラグメントは次のとおりである。

A sample fragment of the record field of the show list described above is as follows.

Wings in people, fly south in winter, help foreign population | People in wings, fly south in winter, help country | Wings in person, help country | People fly and help the country | 4 | People who fly | 1999 | John Filmmaker |
Field 20-25: Name of the star Last name of Star 1 (0 to 25 bytes) Last name of the first actor.
21. Name of star 1 (0 to 25 bytes) Name of first actor (middle name).
22. Last name of Star 2 (0 to 25 bytes) Last name of the second actor.
23. Name of star 2 (0 to 25 bytes) Name of second actor (middle name).
24. Last name of Star 3 (0 to 25 bytes) Last name of the third actor.
24. Name of star 3 (0 to 25 bytes) Name of third actor (middle name).
Examples of these fields are given in Table LXVII.

                            Table LXVII

上述のショーリストのレコードフィールドのサンプルフラグメントは次のとおりである。

A sample fragment of the record field of the show list described above is as follows.

Falls | Joe | Floats | Mary | Soars |
Genre byte field: fields 26-49
The genre byte field is divided into three categories. The first category is the THEME category, which provides for a general description of the type of show. Starlight uses theme information to divide programs into distinct categories when theme searches are performed. The second category is the MPAA grade, which is used to inform the movie viewer of the movie industry grade of the appropriate age of the viewer of the show. This grade is usually only valid for movies. The third category further explains the MPAA rating.

  The 24 data fields below describe the theme type of the program. Of these 24 fields, the maximum of 5 fields are set as “T” for any one program. Some are incompatible with each other and are not set to "T" at any time.

field#
26. Action 27. Adventure 28. Biography 29. Classic 30. Comedy 31. Dance 32. Documentary drama (docudarama)
33. Documentary 34. Drama 35. Fantasy 36. History 37. Horror 38. Martial arts 39. Musical 40. Mystery 41. Opera 42. Romance 43. Caricatures 44. Science 45. Science fiction 46. Suspense 47. Thriller 48. Western drama 49. Situation Comedy
An example of a record fragment containing the above fields is given in Table LXVIII.

                          Table LXVIII

上記番組リスト記録フィールドのサンプルフラグメントは以下のとおりである。
Ｔ｜Ｔ｜Ｆ｜Ｆ｜Ｔ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｔ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜ Ｔ｜Ｆ｜Ｔ｜Ｔ｜Ｆ｜Ｆ｜Ｆ｜
ＭＰＡＡ 指定：フィールド５０−５６
フィールド ♯
５０． Ｇ（１ バイト）一般聴衆．
５１． ＮＣ１７（１ バイト）１７未満の子供なし．
５２． ＮＲ（１ バイト）指定なし．
５３． ＰＧ（１ バイト）親のガイダンス．
５４． ＰＧ（１ バイト）１３歳未満の親のガイダンス．
５５． Ｒ（１ バイト）制限．
５６． ＡＯ（１ バイト）アダルトオンリー．最も厳しい指定．
これらのフィールドの例は表ＬＸＩＸに示される。

Sample fragments of the program list recording field are as follows.
T | T | F | F | T | F | F | F | F | T | F | F | F | F | F | F | F | T | F | T | T | F | F | F |
MPAA designation: Field 50-56
Field #
50. G (1 byte) general audience.
51. NC17 (1 byte) No children under 17.
52. NR (1 byte) is not specified.
53. PG (1 byte) Parent guidance.
54. PG (1 byte) Guidance for parents under 13 years old.
55. R (1 byte) limit.
56. AO (1 byte) Adult only. The strictest specification.
Examples of these fields are shown in Table LXIX.

表ＬＸＩＸ
フィールド５０−５６のサンプルフラグメントは以下のとおりである。
Ｔ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜Ｆ｜
ＭＰＡＡ 指定：フィールド５７−６２
フィールド ♯
５７． 冒涜（１バイト）
５８． 裸（１バイト）
５９． バイオレンス（１バイト）
６０． アダルト シチュエーション（１バイト）
６１． アダルト テーマ（１バイト）
６２． アダルト ランゲージ（１バイト）
６３．ＰＰＶ イベント：フィールド６３．
（１バイト）この番組がペイ−パー−ビュー−イベントであることを表示する場合には“Ｔ”に設定、そうでなければ“Ｆ”、わからなければ空白．
これらのフィールド場のサンプルは表ＬＸＸに示される。

Table LXIX
Sample fragments for fields 50-56 are as follows:
T | F | F | F | F | F | F |
MPAA designation: field 57-62
Field #
57. Blasphemy (1 byte)
58. Naked (1 byte)
59. Violence (1 byte)
60. Adult situation (1 byte)
61. Adult theme (1 byte)
62. Adult language (1 byte)
63. PPV event: field 63.
(1 byte) Set to “T” to display that this program is a pay-per-view event, “F” otherwise, blank.
Samples of these field fields are shown in Table LXX.

表ＬＸＸ
フィールド５７ ６３のための記録フラグメントは以下のとおりである。
Ｔ｜Ｆ｜Ｔ｜Ｆ｜Ｔ｜Ｔ｜Ｔ｜
フィールド ６４ および それ以上：売主の規定するフィールド
”ＰＰＶ イベンド”以降のすべてのフィールドは、（記録読み終わり暗号の義務的な末端を除いて）選択的である。これらのフィールドの最小数および最大数は指示されておらず、これらのフィールドのいずれにおいても文字数については特別の制限は強制されない。

Table LXX
The recording fragment for field 5763 is as follows:
T | F | T | F | T | T | T |
Field 64 and above: All fields following the seller's prescribed field "PPV event" are optional (except for the mandatory end-of-record-reading encryption). The minimum and maximum numbers of these fields are not indicated, and no special limit is imposed on the number of characters in any of these fields.

The seller can use this portion of the record to provide additional data related to the program that makes it difficult or impossible for the specified format to be escorted.
Each seller-defined field must be used to prescribe one data element.

  The contents of the field are in a free format, but with the restriction that all data must be transferred as printable ASCII text, as described above, Vertical Bar (hex 7C), Carriage Return (hex 0D). And Linefeed (hex 0A) are not generated as data. The reason is that these characters have the meanings of “Field Delimiter” (Vertical Bar) and “End-of-Record” (Carriage Return and Linefeed), respectively.

  The intent is to let the seller describe the program as freely as possible. Additional information about the program type, genre, category, sub-category, etc., as well as other types of information not currently expected can be placed in these fields. In order to use these fields, the seller must provide the Star Site with a separate document that specifies how well the seller will use these fields.

The example shown below does not prescribe a fixed format, but merely illustrates one possible way that the seller defined field may be able to supplement the record with other information. In this example, assume that the seller allows categorization for sports programs beyond what is prescribed in the normal format. The seller must document the field separately from the data itself: For example, suppose seller XYZ provided a document containing the following information to the star site:
Field name Description or meaning SPNAME Sports name SPENV “Indoor” or “Outdoor”
SPS “Professional”, “Amateur” or “Pro-Amateur”
SPLIVE If present, the game is live.
SPTEAM If present, this is a team sport.
Note on syntax in seller-supplied fields supplied by seller XYZ: "Field name" is an uninterrupted ASCII string (spaces and tabs are not allowed) from the above list. The presence of a field name in some cases means a “true” state, and in other cases values beyond the field name are also specified. If a value is specified, the field name is followed by a single space or tab, and everything else in the field constitutes the value.

In the case of this information, the seller XYZ can transmit to the star site a record with the fields specified by the seller as seen in the following example:
Field specified by the first seller 64 SPNAME Hockey Field specified by the second seller 65 SPS Field specified by the third seller 66 SPENV Field specified by the fourth indoor seller 67 SPTEAM
Field defined by the fifth seller 68 SPLIVE
Note that in this record, SPENV may be specified, for example, in any seller defined field, even though it is specified in field # 66, and may not be mentioned at all. . The same caution applies to the fields defined by all sellers. This is true because of the method used in this example of giving field names as data. If the seller chooses to stick to the rigid convention of having all fields always present, whether or not there is data for that field, the name or usage of each field will be entirely position dependent. Could be individually documented, thus eliminating the need to transmit field names with data. Either method is possible, and if the seller has another method he likes, it is probably possible if it is within the rules described above.

  Sample fragments of the program list recording field are as follows.

SPNAME Field Hockey | SPS Professional | SPENV Indoor | SPTEAM | SPLIVE End of Recording (LINEFEED hex 0A) and / or (CARRIAGE TURN hex 0D)
Marks the end of the record.
After the last data record of the file, the seller must attach a special end-of-file record, which starts with the text string "ZZZZZEOOF" and then (if Is defined as a record followed by an End-of-Record (with a field defined by the seller). Starlight software will encounter this text string when expecting a call sign value. The value reading is tested against this stored value. If they match, Starlight software stops reading the file.

  More importantly, this text string is also used for testing file transfer completion. If a new file appears in the data entry index, the input software examines the last record in the file for this symbol. If the symbol is not found, the data transfer has either been aborted halfway or has not yet been completed. In either case, it is still not appropriate to start loading data.

Note that the definition of this record is that this record begins with ZZZZZEOOF and ends with End-of-Record. The remainder of the record can be defined by the seller within normal constraints on the seller defined fields. The compulsive information useful here is a count of the number of records in the file, the data / time of creation, a list of stations where the problem occurred, or other summary information that the seller considers relevant.
Special note:
The format of the program listing records used to launch the Starlight Electronic Database is highly integrated in our database program, and these formats can be modified in any way without the written consent of Starlight Telecast. Must not. The use of seller-defined fields is permitted provided that the syntax and meaning of the fields used are clearly documented prior to use. The PO name used in the program list file is queried by the star site database application, so the PO name must be unique and constant. If the PO name is changed without proper adjustment with the star site, a data mismatch will occur in the star site database.

  It should now be readily apparent to those skilled in the art that a novel television schedule information transmission system and method has been provided that can achieve the foregoing objects of the present invention. The system and method can be implemented by a low cost microprocessor in a bab scriber data processing system. In this system and method, television program schedule data allows the use of low cost microprocessors suitable for use in mass produced consumer products to perform a subset search of television program schedule data. Transmitted and recorded in a manner. Television program schedule information is transmitted to and acquired by the subscriber data processing system in an efficient manner in the system and method. A rapid schedule revision that accommodates schedule changes may comprise a low bandwidth transmission system and method. The system and method can distinguish between the current broadcast schedule information and the old schedule division contained for recorded broadcasts. This system and method provides schedule revision information priority handling. Schedule information transmission is selectively encoded in this system and method. In the schedule information transmission part of this system and method, a single system time is employed and the local time is corrected at the subscriber unit. In this system and method, subscriber units can specify schedule information provided at different locations of a television broadcast signal. The portion of the schedule information that has already been acquired by the subscriber unit and duplicated the new schedule information portion is retained in this system and method so that such schedule information portion does not need to be acquired again by the subscriber unit. Data compression is employed in a unique manner to make more efficient use of the memory obtained in this system and method.

  It will be more readily apparent to those skilled in the art that various changes in the form and details of the invention shown and described can be made. Such modifications are intended to be included within the spirit and scope of the claims appended hereto.

An aspect of the present invention is summarized as follows.
(Supplementary note 1) A television schedule information transmission system comprising: a central data processing system; and means connected to the central data processing system for providing schedule information data to the central data processing system for a predetermined area And the central data processing system includes means for formatting the schedule information for the predetermined area into a predetermined schedule information transmission format, and further, in the predetermined area in the predetermined schedule information transmission format. Means connected to the central data processing system for transmitting schedule information data to the central data processing system;
A plurality of regional data processing systems respectively located in one area of the predetermined area, wherein the plurality of regional data processing systems include means for receiving schedule information data for the predetermined area; Means for selecting schedule information data for an area where each regional data processing system is located; means for transmitting schedule information data for the area; and a plurality of subscriber data processing in the area System and
Each of the plurality of subscriber data processing systems includes means for receiving at least a part of the schedule information data of the region, means for storing schedule information data received by the subscriber data processing system, and the subscriber data Means for assembling a portion of the schedule information data received by the subscriber data processing system for presentation to a user of the processing system; and means for assembling the portion of the schedule information data, wherein the portion of the schedule information data is A television schedule information transmission system comprising a display for display.
(Supplementary note 2) In a television schedule information transmission system, schedule information data for a predetermined area is transmitted to a plurality of regional data processing system transmission systems respectively located in the area of the area, and each area data processing system is used to The schedule information data for a region is selected, and the schedule information data for each region is transmitted to a plurality of subscriber data processing systems in each region using the region data processing system, to the users of each subscriber data processing system. A method comprising assembling a portion of schedule information data received by each subscriber data processing system for viewing and presenting the portion of the schedule information data to a user.

1 is a block diagram of a television schedule information transmission and utilization system according to the present invention. FIG. 1 is a block diagram of a television schedule information transmission and utilization system according to the present invention. FIG. 1 is a block diagram of a television schedule information transmission and utilization system according to the present invention. FIG. 1 is a block diagram of a television schedule information transmission and utilization system according to the present invention. FIG. 1 is a block diagram of a television schedule information transmission and utilization system according to the present invention. FIG. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 shows a message format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS. FIG. 6 is a diagram showing a data structure, a flowchart, and a display format used in the system of FIGS.

Explanation of symbols

50 Television Schedule Information Transmission and Utilization System 51 Television Program Supplier 52 Subscriber Unit 54 Computer 56 Data Supplier 58 Lease Line

Claims (1)

A television schedule information transmission system,
A central data processing system;
Means for providing schedule information data to the central data processing system including date, time and channel of a television program for a predetermined territory connected to the central data processing system;
The central data processing system comprises means for formatting the schedule information data for the predetermined territory into a predetermined schedule information transmission format;
The television schedule information transmission system further includes:
Means for transmitting schedule information data for the predetermined territory in the predetermined schedule information transmission format connected to the central data processing system;
A plurality of area data processing systems each located in one area of the predetermined territory,
Each of the plurality of region data processing systems is
Means for receiving schedule information data for the predetermined territory;
Means for selecting schedule information data for the region where each of the plurality of region data processing systems is located;
Means for transmitting schedule information data about the area by a television signal,
The television schedule information transmission system further includes:
Each of the areas comprises a plurality of subscriber data processing systems;
Each of the plurality of subscriber data processing systems includes:
Means for extracting at least a portion of schedule information data for the region from the television signal;
Means for storing schedule information data extracted by the subscriber data processing system;
Means for assembling a portion of the schedule information data extracted by the subscriber data processing system for display to a user of the subscriber data processing system;
A display connected to the means for assembling the portion of the schedule information data and displaying the portion of the schedule information data to the user so that the user can select a television program to receive using the portion; A television schedule information transmission system comprising:

Images