The PowerTV Operating System

Typical Environment

The processor on the Explorer 2000 is a 54-MHz microSPARC core. There is 4 MB of flash for the OS and resident application and from 2 MB to 8 MB of DRAM for downloaded applications and data. It is a basic core with no MMU or FPU and only a small L1 cache.

The media processor has an MPEG-2 video decoder and a graphics compositor capable of 16-bit color. There are two tuners. The in-band tuner works from 57 MHz (EIA channel 2) and up, tuning 6-MHz wide bands carrying either legacy analog channels or 27 Mbits/sec. QAM64 modulated data containing MPEG-2 programs or data. The out-of-band tuner works below 57 MHz, tuning channels that are QPSK modulated, carrying 1.5 Mbits/sec. each. Out-of-band is two way and has the advantage that data can be received even when a video program is being watched.

The system includes a smartcard slot, USB port, IR receiver for hand-held remote and wireless keyboard, and 10BaseT Ethernet port -- but no mass storage. The development card has extra serial ports for a monitor and debugger, extra flash for a larger debug version of the OS, and a SCSI disk interface. PTVOS will soon be available on Scientific-Atlanta's Explorer 3000 (twice as fast as the 2000) and on a box for NTL in the U.K. Most boxes planned for the near future have performance from one to four times that of the Explorer 2000.

PTVOS APIs

PTVOS APIs all have a prefix (based on the name of the PowerModule) of two to four characters separated from the main function name by an underscore. For example, pd_NewGrafPort creates a new graphics viewport for the PowerDraw (hence pd) module. Structure names have the first letter capitalized; for instance, Pd_GrafPort; and constant names are preceded by a k, as in kPd_VideoHeap.

The PTVOS is intended for inexpensive 32-bit RISC processors that do not have MMUs so threads do not have private memory space. There are 32 priority levels; threads of the same priority run round-robin. Thread switching is preemptive, but you are encouraged to write event-driven code that calls pk_NextEvent early and often. Applications start with one thread each, but can spawn more as needed. For many applications, the real-time nature of the kernel will not matter. The indirect benefit is that deadline-critical tasks such as setting up new DMA transfers as old ones complete and decoding digital video can steal whatever CPU time they need without application intervention.

Communication between threads and between applications and the OS is done with Pk_Events in Pk_Queues (pk for PowerKernel). Events can be delivered to a single queue or posted to all queues that have registered an interest in events of that type. Events are retrieved from queues with a family of calls. pk_NextEvent() returns control to the kernel. When an event is present in the calling thread's queue or the given timeout has been reached, the thread will be marked ready to run, and will run again according to its priority.

A complete C library is included with the OS, including malloc and free, but the memory manager provides more features if called directly. There are two basic heaps -- system and video -- but applications can create subheaps. They can also allocate memory with handles, which helps prevent fragmentation. Handles are an indirect reference to memory, which must be locked to get a real C pointer to the memory. The handle refers to a small block of memory that contains the real pointer and is fixed in place. While unlocked, the real data can be copied around to facilitate compaction. Compaction is automatically employed when an allocation is about to fail but can also be called explicitly.

Applications are built using GNU's make, C/C++ compiler, and linker, supplied by Cygnus Support (http://www .cygnus.com/success/powertv.html). The OS is called through a dispatch table so applications need not be recompiled for different versions of the OS. Code in the OS may move around, but the entry points in the dispatch table remain constant.

Window Manager and PowerDraw

The Window Manager provides applications with controlled access to the graphics frame buffer that sits on top of the video plane. It also filters user input events. It doesn't enforce a look-and-feel or provide window selection and rearrangement services, but does clip drawing giving the common stacked look to the windows.

Window manager also provides event routing using the window stack. Events are sent to the top window, which can act on an event as necessary. It then either passes it on to underlying windows or consumes it so the other windows never see it.

Windows that are partially or fully covered by other windows are considered obstructed. Drawing to fully obstructed windows is a no-op. Drawing to partially obstructed windows is handled by automatically repeating the drawing operation in each rectangle in a list that represents the visible portion of the window. This is a bit slower than drawing to nonobstructed windows, so you can decide only to update windows when they are on top. When a window does move to the top, it receives an expose event and must redraw all of its content. The exception is private windows, which have an offscreen buffer exactly the size of the window. Drawing goes to the buffer, which is automatically copied on-screen when the window is exposed. They are more convenient at the expense of precious memory.

Another special type of window is the backdrop. This is a window the size of the entire screen, underneath all other visible windows, that determines the color format and resolution of the screen. It also determines the overlay status of the screen. Overlay is a combination of chroma keying (makes one or a range of colors completely transparent) and alpha blending (makes graphics translucent). It must be turned on once you have tuned a channel to see the video.

PowerDraw provides all the basic drawing primitives you expect: lines, rectangles, circles, ellipses, arcs, and polygons. PowerDraw is also used for rendering text through the Font Manager. New font engines can be plugged in, but the included bitmapped font engine and Agfa scalable font engine are usually sufficient.

While PowerDraw uses the concept of a drawing context, containing things like the current brush, linewidth, and antialiased drawing status (on or off), you aren't forced to use it. The context is initialized to a default state of no brush with a line width of one and once you have a Pd_GrafPort to draw into, you are all set. Lifting the floating cursor so it will not mangle graphics and iterating through clipping rectangle lists is handled automatically.

Usually the grafport is obtained with a win_GetGrafPort call, but you might create your own grafports for a couple of reasons. First is creating off-screen grafports as scratchpads to render bits of graphics before blitting them on screen using pd_CopyGrafPort. Second is when you include your own previously rendered graphics. You might have an icon of a frog on a black background that you want to hop around the screen. A 24-bit Windows bitmap of the image is converted to a 16-bit image, then to an initialized const array in a C file using PowerTV tools. You include this in your build and your code can allocate a grafport with no memory attached, then attach the array. Finally, blit the image on screen with the chroma key color set to black so only the foreground appears.

Broadcast Filesystem

Stream Manager provides a uniform way to read and write data from stream devices such as FTP, HTTP, files, and serial ports. Its use is so pervasive through the system that even nonvolatile memory (NVM) and RAM or Flash can be accessed as streams. Streams to be opened are specified using the Uniform Resource Locator (URL) format. Once open, strm_Read, strm_Write, strm_Seek, and strm_Close are similar to their C standard library namesakes. Just like _read or fread, strm_Read takes the ID returned by strm_Open, a pointer to a buffer to stuff data into, and a count of bytes desired. An important difference is that you can choose to call open, read, and write synchronously, which does not return until done, or asynchronously, which returns immediately and delivers an event to the given queue when the operation completes.

strm_Get and strm_Set allow stream devices to have custom parameters. The first and second parameters specify the device and parameter and the third is a void*, allowing any kind of data to be passed or retrieved.

While PTVOS includes a full TCP/IP stack and an RF interface for communicating over the cable to the head end, two-way networking is discouraged. Two-way uses 1.5 Mbits/sec. out-of-band channels. This bandwidth is shared by all subscribers in a neighborhood. While QPSK modulators can be added to a system to divide the subscriber base into smaller groups and provide more effective bandwidth, this is expensive. One-way is preferred except for applications that absolutely require it, like signing on to the system at boot up, buying pay-per-view movies, and sending e-mail.

The downstream bandwidth is so high (27 Mbits/sec. per 6MHz-wide channel or 1 to 2 Gbits/sec. total) that many applications that require two-way on the Internet can use one-way networking in a cable system. A broadcast carousel is a stream of data on a channel that repeats as soon as it finishes. The data is divided into blocks, each with a unique address. Rather than requesting data using FTP or HTTP over TCP/IP, you request the blocks you want and the OS grabs them out of the stream when they come around. There is hardware filtering and DMA to help the OS so it does not have to consider every bit in a 27 Mbits/sec. stream.

This system of simulating choice by snatching pieces of a large database fulfills some of the ideas of push technology that was so hot a while back. Push may not be appropriate for the Internet, but works well on digital cable and on pagers. For instance, all of CNN's current global and national stories and your local newspaper's stories with pictures and weather maps can be rotated through in a few seconds. If the "Digital News" channel gets so large that response time suffers, it can be split into multiple channels.

The problem with a broadcast carousel is that it is a fairly low-level system. To tune a carousel, you must have control of the tuner, know what frequency the carousel is transmitting on, and know the number of the block of data you want. The broadcast filesystem (BFS) is built on top of broadcast carousel to make it look to an application more like a regular disk filesystem.

A listing of all files available through BFS is broadcast periodically with location and version information. The OS does not read the directory for the first time until a little while after it is booted. Applications can be launched before this, so applications should check whether the directory is available before opening BFS files; use strm_Get("bfs:///", kBfs_DirectoryAvailable, (void *) available);, where available is a pointer to a Boolean.

Applications cannot read the BFS directory directly, but the directory typically contains many files that are of no interest to applications such as OS update images and security and configuration information. Filenames must be hard coded into applications, but a file containing the names of files a particular application needs could be part of a carousel. For instance, a news directory file would contain the filenames of all news stories, their associated picture filenames, and English names of the stories for presentation to users.

Files on BFS have version numbers so an application can tell when they change using strm_Get with the value parameter set to kBfs_FileInfo for unopened files or kBfs_StreamInfo for open files. This allows the servers at the head end to passively update files without having to broadcast messages to or process status requests from set tops.

A Weather/Traffic Camera Viewer Application

Interruption of national morning news broadcasts for local news/weather typically happens every half-hour -- and always when I am in the shower or in the kitchen getting breakfast. I commute on a road that snarls often and the weather in Cupertino, California, is often warmer than at my house in Santa Cruz, so I want this information. Booting a computer and dialing an ISP takes too long. What I want is to flip on the TV and get pictures from the local weather and traffic cams with no waiting.

The sample application (see Figure 2) I present here (source code is available electronically; see "Resource Center," page 5) assumes a server at the head end that can retrieve pictures from web servers, scale them for display on TV, convert them to a format PTVOS can deal with, and move them to the BFS server. The app uses PowerTV's proprietary IMG format -- a 16-bit per pixel, uncompressed bitmap with a minimal header. A real-world app would use MPEG-2 I-frames because the hardware can decompress them in less than 1/60th of a second. This app scales well: A picture retrieved once from a web site can be broadcast to thousands of set tops without taxing bandwidth.

The main features of the application are as follows:

• A main loop that handles application, window, system, and user events.
• A periodic update event.

• A state machine per cam window.

• One read thread launched for each cam window.

An application has many responsibilities to be a cooperative member of the set-top society. It must acknowledge "are you there?" events that the Application Manager sends to detect hung threads, its windows must deal with changes to the window stack, and it must be ready to give up resources if they start to run low. This app acknowledges the mandatory events, but to keep it simple, does not cope with things like another application changing the color format.

After the Init function is called, Application Manager calls the main function. The app now has its own thread, but cannot draw to the screen or even create windows until it gains focus. All of the stages of coming on-line are handled by sending the main function events. main ends up being a loop that repeatedly gets an event and dispatches it. Each event causes some work to be done, but there is little simple procedural code.

The state machines keep track of whether a window is idle, reading an image from BFS, or waiting for a newer image to be placed on the server. Some of the state transitions are due to user interface events and some are caused automatically by the update event or a read finishing.

Once the app has come into focus and created and drawn all of its windows, it begins sending itself a periodic update event. This is mainly to know when to recheck the version of all BFS files that are waiting for a new one to appear. However, some state transitions are handled by switching to an intermediate state directly because of a user interface event and moving to the real state when the next update event is received. I could have created a separate thread for updates, but using a periodic event demonstrates how to weave two threads into one using events.

Stream manager functions can be called asynchronously so they return immediately and deliver events when the operation completes or fails, but the update event had already made things complicated and I wanted to demonstrate how easy it is to launch additional threads from an app. A function launched as a new thread must have a particular prototype, but beyond that it can do anything it wants. It can be pending on events from a queue or just run as a loop. When the work is done, the thread function simply returns and the thread context is destroyed.

Conclusion

If you are familiar with UNIX/X, Windows, or Macintosh, the PTVOS should seem familiar with its standard C library, TCP/IP networking, and a simple drawing library. However, things start getting interesting when you write television-centric applications with overlay over video, cable-specific networking, and a nonkeyboard user interface.

DDJ