Method and apparatus for processing an audio video interactive signal

What is claimed is:

1. In an audio video interactive (AVI) receiver receiving a packet service including a plurality of modules, each module having a name and including time multiplexed transmission units, each transmission unit including a header packet containing the name of the module, a method for processing modules comprising steps of:

receiving a request to perform a process on a module identified by a name and inserting in a list of entries an entry containing the received name and requested process;

detecting a header packet in the packet service;

determining if the name in the detected header packet matches a name in an entry in the list;

performing the process in the matching entry if there is a matching entry; and

sending a message indicating that the process has been performed.

2. The method of claim 1 wherein:

the receiving step includes the step of receiving a request to process a complete module; and

the sending step includes the step of removing the matching entry from the list when the complete module has been processed.

3. The method of claim 1 further comprising the step of receiving a request to stop performing a process on a module identified by a name and removing from the list of entries the entry containing the received name and requested process.

4. The method of claim 1 wherein:

each transmission unit further comprises a plurality of data packets associated with each header packet;

the receiving step includes steps of:

receiving a request to process the module by loading the module into a memory; and

allocating a buffer in the memory to contain the module; and

the performing step includes the steps of:

storing each data packet associated with the detected header packet in a respective location in the allocated buffer; and

removing the matching entry in the list when each data packet in each transmission unit in the module has been stored in the allocated buffer.

5. The method of claim 4, wherein:

the plurality of data packets associated with each header packet in a transmission unit contain data in the module located at a respective offset location from the beginning of the module;

the header packet further contains the offset location of the data in the associated plurality of data packets; and

the storing step stores the associated plurality of data packets in the allocated buffer at an offset location equal to the offset location in the header packet.

6. The method of claim 5 wherein:

the packet service continuously and repetitively provides modules carried by successive time multiplexed transmission units containing module data located at sequential offset locations from the beginning of the module;

the detecting step further includes the step of setting a write pointer to the offset location in the detected header packet;

the performing step further comprises the step of saving the offset location in a first detected header packet after a request to load a module has been received as a beginning load location; and

the storing step comprises the steps of:

storing each data packet associated with a detected header packet in the location pointed to by the write pointer;

then updating the write pointer to point to the next sequential location in the allocated buffer after the data packet has been stored;

then comparing the write pointer to the stored beginning load location and performing the removing step when they are equal.

7. The method of claim 6 wherein the detecting step further includes, before the setting step, the steps of:

comparing the write pointer to the offset location in the detected header packet; and

replacing the beginning load location with the offset location in the detected header packet if they are not equal.

8. The method of claim 4 wherein:

each module further includes an embedded error detection code;

the storing step stores the embedded error detection code in the allocated buffer; and

the sending step further includes the steps of:

checking the data in the allocated buffer to detect an error using the embedded error detection code;

sending an error message if an error is detected in the checking step; and

sending a module-loaded message otherwise.

9. The method of claim 8, wherein:

the embedded error detection code is an embedded cyclical redundancy check (CRC) code; and

the checking step calculates a CRC value for the data in the allocated buffer, compares the calculated CRC value to the embedded CRC code and detects an error if they are different.

10. The method of claim 4 wherein

each transmission unit further comprises a plurality of data packets;

the receiving step includes

storing each data packet associated with the detected header packet;

determining if all data packets of a stored transmission unit are error free; and

discarding the entire transmission unit if all data packets of the transmission unit are not error free.

11. The method of claim 1 wherein:

the receiving step includes the step of receiving a request to spy a module in the packet service; and

the performing step includes the step of sending a message whenever there is a matching entry.

12. An audio video interactive (AVI) receiver, comprising:

a source of a packet data stream including a plurality of modules, each module having a name and including time multiplexed transmission units, each transmission unit including a header packet containing the name of the module;

a memory for storing a request queue containing a plurality of entries each including a processing request and a name of a module, and a header packet buffer including a location containing a module name;

request processing circuitry, coupled to the memory, for receiving a request to perform processing on a module identified by a name and storing an entry in the request queue including the name of the identified module and the processing requested;

a header packet memory storage controller, coupled between the data stream source and the memory, for storing header packets in the header packet buffer as they appear in the data stream, and generating a header packet received signal; and

module processing circuitry, responsive to the header packet received signal, for reading the module name from the header packet buffer, comparing the module name to the names in each entry in the request buffer, and if the module name matches an entry name, performing the processing requested in the matching request queue entry, then sending a message.

13. The receiver of claim 12 wherein the module processing circuitry comprises a processor, and the header packet received signal is an interrupt signal for the processor.

14. The receiver of claim 12, wherein the header packet memory storage controller is a direct memory access (DMA) controller.

15. The receiver of claim 12, wherein:

the request processing circuitry receives a request to perform processing on a complete module; and

the module processing circuitry removes the request queue entry after performing the processing requested on the complete module.

16. The receiver of claim 15, wherein:

the memory further stores a module buffer;

the data stream source produces transmission units each further including a plurality of data packets associated with the header packet included in the transmission unit;

the receiver further comprises a module memory storage controller, coupled between the data stream source and the memory, for selectively storing the plurality of data packets from a transmission unit in the module buffer as they appear in the data stream, then generating a data complete signal, in response to an enable signal;

the request processing circuitry receives a processing request to load a complete module, identified by a name, and stores an entry in the request queue containing the identified name and load request; and

the module processing circuitry generates the enable signal if the module name matches an entry name and is responsive to the data complete signal to remove the request queue entry after the complete module is loaded into the module buffer.

17. The receiver of claim 16 wherein:

the data stream source produces each module including an embedded error detection code; and

the module processing circuitry error checks the data in the module buffer after the complete module is loaded into the module buffer using the embedded error detection code, and sends an error message if an error is detected, and a module-loaded message otherwise.

18. The receiver of claim 17, wherein the embedded error detection code is a cyclical redundancy check (CRC) code and the module processing circuitry calculates a CRC value for the data in the module buffer, compares the calculated CRC value to the embedded CRC code and detects an error if they ar different.

19. The receiver of claim 16 wherein:

the data stream source produces successive transmission units containing module data located at sequential offset locations from the beginning of the module, and produces the header packet further containing the offset location of the data in the associated data packets;

the header packet buffer in the memory further includes a location containing the offset location;

the module processing circuitry extracts the offset location from the header packet buffer, and supplies it to the module memory storage controller; and

the module memory storage controller initializes a write pointer with the offset location from the module processing circuitry, loads each data packet into a location in the module buffer pointed to by the write pointer, then updates the write pointer to point to the next sequential location in the module buffer, until all the data packets in a transmission unit have been loaded, then generates the data complete signal.

20. The receiver of claim 19 wherein:

the data stream source continuously and repetitively produces modules;

the memory further contains a beginning load address location; and

the module processing circuitry extracts the offset location from the header packet buffer after the header packet causing a first match has been loaded and saves the offset location in the beginning load address location, and, responsive to the data complete signal from the module memory storage controller, compares the write pointer from the module memory storage controller to the beginning load address location, and sends the message if they are equal.

21. The receiver of claim 20 wherein the module processing circuitry, responsive to the header packet received signal, compares the offset location to the write pointer, and replaces the beginning address location with the offset location if they are not equal.

22. The receiver of claim 16 wherein the module processing circuitry comprises a processor, and the data complete signal is an interrupt signal for the processor.

23. The receiver of 16 wherein the module memory storage controller is a direct memory access (DMA) controller.

24. The receiver of claim 12, wherein the request processing circuitry further receives a request to stop processing of a module identified by a name and removes the entry in the request queue including the name of the identified module and the processing requested to stop.

25. The receiver of claim 12, wherein:

the header packet memory storage controller selectively stores header packets in response to an enable signal;

the request processing circuitry generates the enable signal after an entry is stored in the request queue; and

the module processing circuitry further removes the enable signal after the processing has been performed if there are no entries in the request queue .

Description Submit all comments and votes

The present invention relates to a method and apparatus for receiving and processing an audio video interactive (AVI) signal.

Interactive television systems have been proposed in which a television receiver includes a processor programmable by the broadcaster and capable of responding to data entered by the user, generating on-screen graphic displays overlaid upon the broadcast video, generating sounds combined with the broadcast audio and/or exchanging data with the broadcaster or other outside data processing service. In such a system, the broadcast location includes a computer system for generating interactive application program information, and combining the interactive application program information as an additional component with the video and audio components of the associated television signal. The processor in the television receiver receives the interactive application program information from the broadcaster, executes the interactive application program represented by that information, generating the graphics and sounds to be combined with the television video and audio, and processing user inputs received via a remote control unit.

In a proposed AVI system, the AVI signal from the broadcaster is broadcast in the form of a packet data stream, including a plurality of time multiplexed packet services. Each packet service carries a different signal component of the AVI signal. For example, one service carries the video component, another carries the audio component, and another carries the interactive application program information. There may be still other services carrying stereo and SAP audio channels, and/or closed captioning information, etc. In addition, some packet data streams may include packet services carrying components for more than one AVI program. Each packet service has a unique service component identifier (SCID) associated with it and the packets in that packet service each include that service identifier. See U.S. patent application Ser. No. 08/234,773 APPARATUS AND METHOD FOR FORMULATING AN INTERACTIVE TV SIGNAL, filed Apr. 28, 1994 by Jean Rene Menand, incorporated by reference, for a more detailed description of how such a packet data stream is formed.

Further, in the proposed AVI system, one packet service carries a program guide and includes a predetermined service identifier. The data carried by the program guide packet service associates the components of an AVI program with the service identifiers of the packet services carrying those components. Using this data, the packet services carrying the components of the desired AVI program may be extracted from the packet stream.

The components in the AVI signal packet data stream are carried by one or more transmission units, each consisting of a plurality of packets. A first packet in any transmission unit is a header packet, and the remaining packets in the transmission unit are associated data packets. The header packet contains information about the following data, and the associated data packets carry the data making up that portion of the component. Different transmission units may include different numbers of data packets, and the partitioning of the module into transmission units may be influenced by the timing necessary to deliver complete modules to the viewer locations at desired times, or other real time considerations.

The interactive application program information component consists of one or more code modules (containing executable code), possibly one or more data modules and a directory module which includes data describing the code and data modules making up the interactive application program component. These modules are continuously repeated in the application program component flow. The modules are carried by transmission units, as described above, in which the header packet further contains the location within the module where the data in the following data packets belongs.

A processor in an AVI receiver first extracts the directory module from the data flow, and utilizes the information contained in the directory to determine which code module is first to be executed. That code module is then extracted from the data flow and loaded into a known location in memory. When the initial code module has been completely loaded into memory, the processor begins to execute that code module. During the course of its execution, that code module may request data from data modules identified in the directory module. Those data modules are then extracted and loaded into memory. When the data module has been completely loaded into memory, the requesting code module is notified, and execution continues to process that data. It is also possible for one code module to chain to a subsequent one. In such a case, the current code module issues a request to chain to a new code module listed in the directory module, and its memory space is freed. The requested code module is then extracted from the data flow, and loaded into memory. When it has been completely loaded into memory, it is executed. Other functions are possible, and will be described below.

If the memory has sufficient capacity, more than one code module may simultaneously be stored in respective portions of the memory. In such a case, chaining from one module to another entails simply beginning execution of the new module, obviating the requirement to wait until the new module has been loaded from the flow. It is also possible to load more than one data module in memory, but because data modules may change more often than code modules, it is envisioned that data modules will be extracted from the data flow when they are required by code modules.

A processor in a proposed AVI receiver need not include any mass storage, or preloaded AVI programs. Instead, because the modules carried in the interactive application program packet service are continuously repeated, any module may be extracted from the data flow when it is needed and no mass storage is necessary. Because of this, however, the processor in the AVI receiver must monitor the data flow continuously for required modules. A method and apparatus for efficiently monitoring the data flow, and processing desired modules as quickly as possible is required.

In accordance with principles of the present invention, an audio video interactive (AVI) receiver receives a packet service including a plurality of modules. Each module has a name and includes time multiplexed transmission units. Each transmission unit includes a header packet containing the name of the module. A method for processing modules in such a receiver includes the following steps. First, a request to perform a process on a module identified by a name is received and an entry containing the received module name and requested process is inserted into a list of entries. A header packet in the packet service is then detected. If the module name in the detected header packet matches a name in an entry in the list, packet processing circuitry performs the process in the matching entry. Finally a message is sent indicating that the process has been performed.

Apparatus in accordance with principles of the present invention includes a source of a packet data stream including a plurality of modules, each module having a name and including time multiplexed transmission units, and each transmission unit including a header packet containing the name of the module. A memory stores a request queue containing a plurality of entries each entry including a processing request and a name of a module. The memory also stores a header packet buffer including a location containing a module name. Request processing circuitry receives a request to perform processing on a module identified by a name and stores an entry in the request queue including the name of the identified module and the processing requested. A header packet memory storage controller stores header packets in the header packet buffer as they appear in the data stream, and generates a header packet received signal. Module processing circuitry, responsive to the header packet received signal, reads the module name from the header packet buffer, compares the module name in the header packet to the module names in each entry in the request buffer, and if the module name in the header packet matches an entry name, performs the processing requested in the matching request queue entry.

IN THE DRAWING

FIG. 1 is a block diagram of a portion of an AVI signal decoder, incorporating the present invention;

FIG. 2 is a software structure diagram of the software executed by the processing unit 40 illustrated in FIG. 1;

FIG. 3 illustrates flow diagrams and memory layout diagrams useful in understanding the extraction of modules from the data component in an AVI program;

FIG. 4 is a diagram, partially in block form and partially in memory layout form also useful in understanding the extraction of modules from the data component of an AVI program;

FIG. 5 is a flow diagram illustrating the initialization function of the system loader; and

FIG. 6 is a state transition diagram illustrating the data stream monitoring function of the system loader.

FIG. 1 is a block diagram of a portion of an AVI signal decoder, incorporating the present invention. A decoder as illustrated in FIG. 1 is installed in each viewer location at which it is desired to participate in AVI programs. In FIG. 1, a transport mechanism (not shown) is coupled to an input terminal 5 of the decoder. Input terminal 5 is coupled to an input terminal of a tuner 10. An output terminal of tuner 10 is coupled to a data input terminal of an AVI program component detector 30. A data output terminal of program component detector 30 is coupled to a system bus 416 of a processing unit 40. Processing unit 40 includes a central processing unit (CPU) 410, a read/write memory (RAM) 412 and a read-only memory (ROM) 414 coupled together in a known manner via the system bus 416. A stream I/O adapter 408 is bidirectionally coupled between the system bus 416 and a control terminal of the program component detector 30.

An audio processor 418, coupled to the system bus 416, provides an audio signal to AVI audio output terminal 25, and a video processor 420, also coupled to the system bus 416, provides a video signal to AVI video output terminal 15. Further input and output facilities are provided by an I/O port 422, coupled to a collocated local processor (not shown) via a bidirectional terminal 45; user I/O adapter 424, for receiving data from a user via an input terminal 35; and a modem 426, coupled to an outside computer (not shown) via a bidirectional terminal 55; all also coupled to the system bus 416 in a known manner. Other equipment, e.g. math processors, other I/O adapters, etc., may be coupled to system bus 416 in a known manner. In addition, a bus extender may be included for coupling to other equipment in enclosures external to the decoder enclosure.

In operation, the transport mechanism, which, for example, may be a direct RF satellite link, a cable system feed or a fiberoptic link to the decoder, carries a plurality of AVI signals, any one of which may be selected by the user for viewing. In a direct satellite link, for example, a plurality of AVI data streams may be frequency multiplexed on the transport mechanism by modulating respective RF carrier signals. Each RF carder signal is rebroadcast from a respective transponder in the satellite to the viewer location. Tuner 10 selects a desired RF modulated signal, under the control of processor 40, in a known manner. For example, in the direct satellite system, the RF modulated signal containing the packet services carrying the components of the desired AVI program signal is tuned by a known RF tuner. The output of tuner 10 is a baseband digital packet data stream containing those packet services.

CPU 410 requests desired packet services from the program component detector 30 by writing the desired service identifiers and RAM 412 buffer locations into appropriate service component identifier (SCID) and direct memory access (DMA) controller registers in the program component detector 30 via the stream I/O adapter 408. The program component detector 30 then monitors the packet data stream for the desired packet services. When header packets from any of the desired packet services are received, they are stored in a predetermined header packet buffer in the RAM 412 using known DMA write techniques, and a header packet interrupt is generated. When data packets from any of the desired packet services are received, they are stored in the previously specified buffer locations in the RAM 412 also using known DMA write techniques. When all the data packets in a transmission unit have been received, a data complete interrupt is generated. Reception of header and/or data packets from a packet service may be enabled and disabled under control of the CPU 410. See U.S. patent application Ser. No. 08/232,787 PACKET VIDEO SIGNAL INVERSE TRANSPORT PROCESSOR MEMORY ADDRESS CIRCUITRY, by K. E. Bridgewater et al. filed Apr. 22, 1994 and incorporated by reference, for a more detailed description of the program component detector 30.

For example, when a new RF modulated signal is tuned by the tuner 10, the packet service containing the program guide is requested by the CPU 410 by supplying the fixed program guide service identifier to a service identifier register in the program component detector 30. When the data in the program guide packets has been received and stored in memory, that data allows the CPU to request the packet data services for the desired AVI program.

After packets in the requested packet services are received by the program component detector 30, and are written via DMA into the previously specified buffer locations in RAM 412, the video processor 420 and audio processor 418 read the data from the RAM 412 buffer locations associated with their respective packet services, using known DMA read techniques, under control of the program component detector 30. Video processor 420 and audio processor 418 then decode the compressed and encoded data to produce the AVI video signal at output terminal 15, and the AVI audio signal at output terminal 25, respectively. It is also possible for CPU 410 to cooperate with the video processor 420 and/or audio processor 418 in the decoding process. The data component packet service packets are processed under the control of the CPU 410 in a manner described below.

As described above, whenever a header packet from a requested packet service is received by the program component detector 30, it is stored in a predetermined location in RAM 412 for that packet service, and a header packet interrupt signal is generated for the CPU 410. In response to the header packet interrupt signal, an interrupt handler is executed which analyses the contents of the header packet and either appropriately updates the RAM 412 buffer locations in the DMA registers in the program component detector 30 and enables the DMA transfer, or disables the DMA transfer if the transmission unit is not desired. Once the DMA transfer is enabled, the data in the data packets is then loaded into RAM 412 under DMA control. When the loading of the data packets is completed, the program component detector 30 generates a data complete interrupt signal. In response to the data complete interrupt signal, an interrupt handler is executed to perform "clean-up" functions and prepare for the next header packet.

FIG. 2 is a structure diagram of software 200 executed by the processing unit 40 illustrated in FIG. 1. FIG. 2 illustrates the major software components making up the AVI processing multitasking operating system. In FIG. 2, all the components are stored in the ROM 414, except the application program, indicated by cross-hatching. The application program is carried by the data component of the AVI signal, is received from the broadcast location and is stored in RAM 412. The software components illustrated in FIG. 2 represent executable code and associated constant data. As the code executes, it may generate and access variable data, which is stored in the RAM 412.

In the proposed AVI broadcast system, different decoders may use CPUs using different instructions sets, e.g. from different manufacturers. In this system, the application program is processor independent intermediate code. The software in each decoder includes a component which interprets the intermediate application code (INTERPRETER). This enables the broadcast application program to be executed on decoders containing any type of CPU 410. That interpreter will read the AVI data component instructions in intermediate code from the RAM 412, manipulate memory, and interact with the hardware through other software components via an application programming interface (API). This API, which is basically a list of subroutines available to an application program and the information necessary to call them, is published and may be used by the application programmer to access the decoder elements.

A math library performs all the functions needed to implement integer and floating point arithmetic. A flow operating system controls all the drivers necessary to monitor the data component of the AVI signal, and process requested modules, as will be described in more detail below. A user interface management component handles all the user interaction, and utilizes a graphics library, and an event manager to communicate with the user. The graphics library performs all the generation of graphic images to overlay on the received AVI video, and uses the math library for drawing complex curves.

The different software components of the decoder software communicate with other asynchronously by sending messages to each other. Each program component has a message queue and operates by repeatedly reading the next message from the queue, processing that message, possibly sending a message to another program component, and, if no more messages are pending, waiting for the next message. The event manager manages the communication of these messages among the other software components by properly routing the messages and maintaining the message queues.

Each hardware adapter also includes an associated software driver. The driver performs the actual interaction between the CPU 410 and the registers in the associated hardware adapter via the system bus 416. For example, there are drivers for the modem 426, the external I/O port 422, the stream I/O adapter 408 and the user I/O 424. In addition, separate drivers maintain a software timer and operate the front panel of the decoder. These drivers are closely dependent on the event manager. All of the above components use common functions provided by a multitasking kernel. For example, the kernel maintains process priorities, active task queues, signals, semaphores, preemptive task switching clock ticks, interrupts (hardware and software), and process stacks. In addition, the kernel provides hardware initialization and initiation of the first system task, which is a system loader.

At initiation, the system loader executes API calls to the flow operating system, which in turn calls the stream driver to send the appropriate data to the program component detector 30 via the stream I/O adapter 408. These API calls from the system loader initiate a scan of the data component packet service for the directory module in a manner described in more detail below. When the directory module is found, it is loaded into RAM 412, and checked to see if all of the required resources to execute that program are available. If so, then the system loader initiates a scan of the AVI data component for the first module, termed an autostart module, which will initiate the AVI program. When the autostart module is located, it is extracted from the data component packet service and loaded into RAM 412. This autostart module is in the form of intermediate code, and is executed by being interpreted by the interpreter. The autostart module performs the remainder of the initialization and begins execution of the AVI program. This program may possibly load other code and data modules, and chain to another code module, all via API calls. In this manner, the system loader operates in the same manner as a classic UNIX.RTM.shell.

In addition, the system loader continues to scan the data component packet service comparing transmitted directory modules to the current directory module in RAM 412. If the transmitted directory module is different than that stored in RAM 412, it indicates that the data component packet service has changed, for example, such as when a viewer changes channels, or an interactive commercial is being broadcast. In this case, a message is sent to the application program via the event manager using the API. In response to this message, the application program deallocates all its resources, and maintains only a minimal presence in the processing element 40. For example, the memoryused to store all code and data modules may be freed, and only the execution state of the application kept in RAM 412. When the minimization of the application program has completed, a message is sent to the system loader.

The system loader then allocates the resources necessary to execute the AVI program represented by the new directory module. When a new directory module is detected in the AVI data component packet service, a list of previously minimized applications is searched, and if the application represented by the new directory is present, that application is resumed by reloading the necessary code and data modules from the data component flow, and resuming execution from where it had previously been halted. This may happen at the end of an intervening interactive commercial. This process may be recursive, where a second AVI program may, itself, be interrupted by a third AVI program, and later reactivated.

FIG. 3 illustrates flow diagrams and memory layout diagrams and FIG. 4 is a more detailed block diagram of the program component detector 30 (of FIG. 1) and a more detailed memory layout diagram useful in understanding the extraction of modules from the data component in an AVI program. In FIG. 4, the baseband digital packet stream from tuner 10 (of FIG. 1) is coupled to respective data input terminals of a data DMA controller 32 and a header packet DMA controller 34 within the program component detector 30. Respective data output terminals of data DMA controller 32 and header packet DMA controller 34 are coupled to the system bus 416 of the processing unit 40. The stream I/O adapter 408 is coupled between the system bus 416 and respective control input terminals of the data DMA controller 32 and the header packet DMA controller 34. In operation, stream I/O adapter 408 supplies control information, e.g. buffer location start and end addresses, read and write addresses, and transfer counts, in known manner from CPU 410 (of FIG. 1 to the data DMA controller 32 and the header packet DMA controller 34. Stream I/O adapter 408 may then enable the data DMA controller 32 and/or the header packet DMA controller 34 to transfer data or header packets, respectively, from the packet stream to the buffer in a known manner, or disable such transfers, under control of the CPU 410. When the data DMA controller 32 completes a data transfer, it generates a data complete interrupt for CPU 410. When the header packet DMA controller 34 completes loading a header packet, it generates a header packet interrupt for CPU 410.

Also in FIG. 4, the RAM 412 is represented by a large block, and data structures are represented by smaller blocks within the large block. The blocks in FIG. 4 are schematic only, and are not meant to illustrate either absolute or relative locations or sizes allocated in the RAM 412 for the data structures. In 12, a module request queue 322, a header packet buffer 324, a directory module buffer 326 and a module buffer 328 data structures are illustrated. Fields of information within the data structures are illustrated as horizontal slices containing the name of the type of information contained in that field. These will be discussed in detail below.

FIG. 3 illustrates the procedure followed in extracting a module from the data component packet service and storing it in a buffer in RAM 412. Similar procedures are followed for other module processing, as will be described below. In FIG. 3, actions taken in an application program (or the system loader) are illustrated in the left hand column under the heading "APPLN PROG.". In block 302, the application program, using the API, makes a request to the flow operating system to load a module having the identifier ID from the AVI program component packet service. As described above, API calls are basically subroutine calls to operating system functions. The program execution is, thus, transferred to the flow operating system (FOS). Actions taken by the FOS are illustrated in the next column to the right, under the heading "FOS." Because the request involves the loading of a module, in block 312 the FOS requests a memory allocation from the memory manager of sufficient size to contain the module. For example, if the requested module is a code or data module, the previously stored directory module 326 (of FIG. 4) includes a field containing the length (LENGTH) of the module ID. In this case a memory manager allocates a module memory buffer (328 of FIG. 4) having a starting address START and an ending address END. Then, in block 314, information describing the request, e.g. the identifier ID of the module, the type of request REQUEST (in this case a request to extract and load a module) and the allocated buffer starting address START, and ending address END, are all stored in the entry in the request queue (QUEUE) 322. The header packet DMA controller 34 is then enabled to load header packets into the RAM 412, when they occur in the packet stream.

If the request is for the directory module, its length is not known a priori. In this case a relatively large memory allocation is requested. If this allocation turns out to be too small, the request is repeated, after requesting a larger memory allocation, until either the directory module is loaded, or it is determined that there is insufficient memory to load it, in which case the attempt to run the AVI program is abandoned.

The FOS then immediately returns to the calling application program. The application program is then able to perform other processing, for example issuing requests for other modules, other intializations, etc. When access to the requested module is required, the application program, in block 304, may issue an API call to a wait function in the kernel. This function suspends the execution of the application program until a message indicating the successful loading of the requested module is received by that application program. When such a message is received, the application program is reactivated to process that message. Alternatively, the application program may remain active, e.g. in order to respond more quickly to user inputs, and periodically poll its message queue for the message indicating successful loading of the requested module, and process the message when it is received.

As described above, the header packet DMA controller 34 loads header packets into a header packet (HDR PKT) buffer 324 (of FIG. 4) in the RAM 412 previously allocated by the memory manager, and issues a header packet interrupt to the CPU 410. A portion of the processing performed by the header interrupt handler in the kernel is illustrated in the column headed "HEADER INTR" in FIG. 3. In block 332, the identifier of the module which is being carried in the transmission unit for which this is the header packet, is retrieved from a known location, ID, in the header packet buffer 324. In block 334, request queue 322 is examined to determine if there is a pending request for this module.

If there is a pending request for that module, then, in block 336, the data packet DMA controller 32 in the program component detector 30 is initialized with: the module buffer 328 starting address START and ending address END from the request queue 322; a write address which is the sum of the module buffer 328 starting address START and the transmission unit data offset OFFSET (i.e. START+OFFSET); and a last write address which is START+OFFSET+SIZE (or alternatively, a load count which is the size SIZE from the header packet buffer 324 in place of the last write address). The data packet DMA controller 32 is then enabled.

In block 338, if this is the first header packet received after the load request was made, a pointer to the first write address, FIRST, stored in the request queue 322, is initialized to the write address of this first transmission unit (i.e. FIRST=START+OFFSET). In addition, a pointer to the expected next write address, NEXT, also stored in the request queue 322, is also initialized to the write address of the first transmission unit (i.e. NEXT=START+OFFSET). Other processing is then performed in block 338, which will be described in more detail below. For example, a special pointer to the location in the request queue 322 of the request currently being processed, CURR REQ, is stored in a predetermined location (not shown) in RAM 412. Then, in block 339, the interrupt handler returns (339)