this description pertains to televisions with the capability to run java ( or similar ) applets and display output from the java applets to the television display . standard java does not support multi - plane graphics , which can be highly desirable in a television where multiple concurrently executing applets may be necessary and / or the system itself may need to create java output . as used herein , a television primarily functions to display video from one or more external video sources . the television embodiments described herein still retain this primary function , but have added capabilities to run applets that can create graphical output that overlays ( or supercedes ) a video source . as televisions generally do not possess the voluminous processing and storage resources of a computer , are expected to fit in a clean form factor similar in size to the display itself , and preferably are operable by persons with less technical expertise than computer users , using simpler interface devices , running applets on a television presents particular challenges that are addressed herein . in particular , newer lcd and plasma televisions tout their thinness and lightness as selling points , and thus have little room for the bulky heat - generating components of a fast computer . conventional televisions offer a fixed set of pre - loaded graphical applications , typically limited to configuration menus for the television . the embodiments below can include a richer set of pre - loaded applets / applications , for instance voice messaging , timers , media players / recorders / time shifters and media locator / selectors , etc . the embodiments also offer a viewer the capability to select other applets — not preloaded on the television — and run the applets on the television . in addition to new or upgraded applets developed specifically for the television platform (“ platform - aware ” applets ), the embodiments preferably also allow a viewer to run applets that are platform independent , such as games or other applets that are typically available to computer users . because platform - independent applets are currently developed without use by a television viewer as a primary consideration , the television embodiments herein preferably allow such applets to run as expected , while still allowing the television to function as expected . to allow a viewer to provide new applets to the television , the television contains a removable device port , which supports media , as well as other removable devices , in some embodiments , the removable device port comprises one or two pcmcia ( personal computer memory card international association ) pc card ports . the pc card and its ports are described in a series of standards dating back to the 1980s — see , for instance , pc card standard 8 . 0 release — april 2001 . the pc card interface was developed for laptop computers and other computers that do not provide the large internal card bays ( e . g ., for peripheral component interconnect cards ) of desktop and tower servers . pc cards manufactured today provide ethernet network interfaces , modems , wireless network interfaces ( e . g ., ieee 802 . 11x ), mass storage with micro disk drives or flash memory ( compactflash ), and compactflash adapters for other flash formats such as memory stick , multimedia card , secure digital , smartmedia , and xd . in some embodiments , applets can be provided to the television by loading the applets to a mass storage device , e . g ., from a computer , or purchasing a mass storage device with the applets preloaded , and then connecting the mass storage device to the pc card port . alternately , with a wireless network interface card inserted in the pcmcia port , applets stored on a personal computer on the same wireless network can be accessed at the television . additionally , the television may accept and support other pcmcia - compatible devices . fig1 contains a block diagram for a liquid crystal display ( lcd ) television capable of operating according to some embodiments of the present invention . television 100 contains an lcd panel 102 to display visual output to a viewer based on a display signal generated by an lcd panel driver 104 . lcd panel driver 104 accepts a primary digital video signal in ccir656 format ( eight bits per pixel yc b c r , in a “ 4 : 2 : 2 ” data ratio wherein two c b and two c r pixels are supplied for every four luminance pixels ) from a digital video / graphics processor 120 . a television processor 106 provides basic control functions and viewer input interfaces for television 100 . television processor 106 receives viewer commands , both from buttons located on the television itself ( tv controls ) and from a handheld remote control unit ( not shown ) through the ir port . based on the viewer commands , television processor 106 controls an analog tuner / input select section 108 , and also supplies user inputs to the digital video / graphics processor 120 over a universal asynchronous receiver / transmitter ( uart ) command channel . television processor 106 is also capable of generating basic on - screen display ( osd ) graphics , e . g ., indicating which input is selected , the current audio volume setting , etc . television processor 106 supplies these osd graphics , when activated , as a tv osd signal to lcd panel driver 104 for overlay on the display signal . analog tuner / input select section 108 allows television 100 to switch between various analog ( or possibly digital ) inputs for both video and audio . video inputs can include a radio frequency ( rf ) signal carrying standard broadcast television , digital television , and / or high - definition television signals , ntsc video , s - video , and / or rgb component video inputs , although various embodiments may not accept each of these signal types or may accept signals in other formats ( such as pal ). the selected video input is converted to a digital data stream , dv in , in ccir656 format and supplied to a media processor 110 . analog tuner / input select section 108 also selects an audio source , digitizes that source if necessary , and supplies that digitized source as digital audio in to an audio processor 114 and a multiplexer 130 . the audio source can be selected — independent of the current video source — as the audio channel ( s ) of a currently tuned rf television signal , stereophonic or monophonic audio connected to television 100 by audio jacks corresponding to a video input , or an internal microphone . media processor 110 and digital video / graphics processor 120 provide various digital feature capabilities for television 100 , as will be explained further in the specific embodiments below . in some embodiments , processors 110 and 120 can be tms320dm270 signal processors , available from texas instruments , inc ., dallas , tex . digital video / graphics processor 120 functions as a master processor , and media processor 110 functions as a slave processor . media processor 110 supplies digital video , either corresponding to dv in or to a decoded media stream from another source , to digital video / graphics processor 120 over a dv transfer bus . media processor 110 performs mpeg ( motion picture expert group ) coding and decoding of digital media streams for television 100 , as instructed by digital video / graphics processor 120 . a 32 - bit - wide data bus connects memory 112 , e . g ., two 16 - bit - wide × 1 m synchronous dram devices connected in parallel , to processor 110 . an audio processor 114 also connects to this data bus to provide audio coding and decoding for media streams handled by media processor 110 . dotted line 116 divides the media processor subsystem from the host processor subsystem . media processor 110 cannot directly access the devices on the right ( host ) side of dotted line 116 . digital video / graphics processor 120 can access media processor 110 and memory 112 directly , however , and thus indirectly provides connectivity between media processor 110 and flash memory 126 or pcmcia cards 128 . digital video / graphics processor 120 coordinates ( and / or implements ) many of the digital features of television 100 . a 32 - bit - wide data bus connects memory 122 , e . g ., two 16 - bit - wide × 1m synchronous dram devices connected in parallel , to processor 120 . a 16 - bit - wide system bus connects processor 120 to media processor 110 , an audio processor 124 , flash memory 126 , and ports for removable pcmcia cards 128 . flash memory 126 stores boot code , configuration data , system executable code , and java code / class files for graphics applications and applets , etc . pcmcia cards 128 can provide extended media and / or application capability , such as the java applets explained herein . digital video / graphics processor 120 can pass data from the dv transfer bus to lcd panel driver 104 as is , but processor 120 can also supersede , modify , or superimpose the dv transfer signal with other content . for instance , processor 120 can generate java application / applet graphics that overlay or supercede the dv transfer signal , system graphics that display messages over all underlying content , or decode media from pcmcia cards 128 , e . g ., in a “ time - shifting ” mode where media processor 110 is coding a program to the pcmcia card and processor 120 decodes and displays a time - shifted version of the same program , allowing the viewer to pause , rewind , or skip through the program . multiplexer 130 provides audio output to the television amplifier and line outputs ( not shown ) from one of three sources . the first source is the current digital audio in stream from analog tuner / input select section 108 . the second and third sources are the digital audio outputs of audio processors 114 and 124 . these two outputs are tied to the same input of multiplexer 130 , since each audio processor is capable of tri - stating its output when it is not selected . in some embodiments , processors 114 and 124 can be tms320vc5416 signal processors , available from texas instruments , inc ., dallas , tex . at system powerup , digital video / graphics processor 120 creates an executable image for itself in memory 122 and for media processor 110 in memory 112 . flash memory 126 stores the elements of this image as default system code for processors 110 , 114 , 120 , and 124 . this code includes : a system manager , a java engine , which may contain any combination of a just - in - time java compiler , a java interpreter , or precompiled java code , and a java manager that manages java applets for processor 120 ; audio codecs for processors 114 and 124 ; and video codecs for processors 110 and 120 . the system manager provides low - level functions for communication with the other devices attached to processor 120 , and communicates system events to the java manager and other processes . the java engine interprets and executes java code for the java manager , and java applets when applets are loaded . referring to fig2 , processor 120 works at various times with up to three display planes : a system display plane 30 , an applet display plane 40 , and a video and still image plane 50 . the rearmost plane 50 can contain digital video received at the dv transfer port from processor 110 or decoded mpeg video or jpeg images , as well as images originally stored in other formats . the middle plane 40 is active when a java applet 95 has focus , or when the java manager displays graphics on the middle plane . the front plane 30 is used , typically infrequently , to display alert and status messages from the java manager . these messages can include message requests from a platform - aware java applet 90 that does not have focus . to create the digital video stream for the display , software mixer 200 and hardware mixer 70 combine information from display planes 30 , 40 , and 50 . software mixer 200 combines information from display planes 30 and 40 , as will be explained in further detail below . a look - up table ( lut ) is used in block 60 to convert the output of software mixer 200 to the yc b c r color space of video plane 50 . the output of lut color conversion block 60 is combined with video plane 50 in hardware mixer 70 . fig3 shows internal detail of software mixer 200 . applet plane graphics are rendered to applet display buffer 210 . system plane graphics are rendered to system display buffer 220 . although it is possible to merge graphics from these two planes in a fairly mindless fashion for each video frame , display artifacts would be visible to a viewer from time to time , and a significant percentage of available processing resources would be consumed merely to perform the merge . mixer 200 , however , takes advantage of the observations that system graphics are displayed a small percentage of the time and usually occupy a small region of the viewable area to provide visually acceptable mixing while consuming far less resources . the output of software mixer 200 is taken at a multiplexer 280 . multiplexer 280 can take input from one of three buffers : applet display buffer 210 , system display buffer 220 , or an anti - flicker display buffer 270 . the multiplexer select signal is generated by region manager 290 , and the select criteria will be explained below . to summarize , however , if only one of the applet and system display planes is active , mixing is bypassed to save resources , and two switches 240 and 245 remain open . only when both display planes are active are switches 240 and 245 closed to cause mixing to occur . further , even when both display planes 210 and 220 are active , mixing is only performed as needed . region manager 290 tracks which regions of buffers 210 and 220 are being updated , and controls a mux control block 230 , a multiplexer 250 , and the addressing of a composite display buffer 260 and the anti - flicker display buffer 270 to mix only the updated regions . in order to intelligently control mixing , region manager 290 receives two types of notifications : system graphics section registration ( and unregistration ) notifications from the java manager ; and paint region notifications for both display buffers from the java engine . the region manager 290 can be implemented , wholly or partly , within the java engine . referring to fig4 , when the java manager 300 desires to paint system graphics to a region of the display , it calls a java engine api ( application programming interface ) to register a rectangular section of the display bounding the desired region ( the system graphics need not be rectangular , but the registered section is preferably rectangular for simplicity ). for instance , fig4 shows two registered section of the system display plane . section 1 is described by the parameters ( x 1 , y 1 , w 1 , h 1 ), which respectively specify the section &# 39 ; s left boundary with respect to the left edge of the display , the section &# 39 ; s upper boundary with respect to the top edge of the display , the section &# 39 ; s width , and the section &# 39 ; s height . section 2 is described by similar parameters ( x 2 , y 2 , w 2 , h 2 ). a second api allows the java manager to unregister a previously registered section . in some embodiments , region manager 290 maintains a linked list of registered system graphics areas , with the head of the list maintained by a pointer systemgraphics section head that is initially a null pointer . when the java manager requests registration of section 1 , a node is added to the linked list containing the parameters ( x 1 , y 1 , w 1 , h 1 ) and a next pointer that is initially null . when the java manager subsequently requests registration of section 2 , a second node is added to the linked list containing the parameters ( x 2 , y 2 , w 2 , h 2 ) and a next pointer that is initially null . the next pointer of the first node is modified to point to the second node to create the linked list shown in fig4 . when the java manager unregisters a region , the corresponding node is removed from the linked list . whenever systemgraphics section head is not null , region manager 290 assumes that system graphics are active . note that region manager 290 can in some embodiments choose to merge two linked list nodes to a single bounding rectangle node , particularly if the regions overlap . the second type of notification received by region manager 290 is a paint region notification . whenever an applet with focus or a component of the java manager calls a routine to draw to applet display buffer 210 , the draw or paint routine notifies region manager 290 that a rectangular bounding region for the routine has been modified . whenever the java manager draws to system display buffer 220 , the draw or paint routine sends a similar notification to region manager 290 . region manager 290 uses paint region notifications to create a second linked list similar to the system graphics section linked list . as shown in the flowcharts of fig5 - 7 , region manager 290 uses the paint region linked list to control mixing when both buffers 210 and 220 are active . returning briefly to fig3 , mux control 230 controls the mixing operation of multiplexer 250 . mux control 230 causes multiplexer 250 to operate on the portions of buffers 210 and 220 that are newly added to the paint region linked list . if a newly - painted section does not overlap a current system graphics section , switch 245 is kept open and the paint region is copied to the composite display buffer . when a system graphics section is overlapped , mixing is required . in that case , mux control 230 looks for a hard key in the pixel data coming out of system display buffer 220 : when the hard key is not set for a particular pixel , the current pixel in buffer 220 is copied to composite display buffer 260 ; when the hard key is set for a particular pixel , the current pixel in buffer 210 is copied to composite display buffer 260 . in some implementations , the hard key is a pixel value of zero , which indicates a transparent pixel . fig5 shows the high - level mixing control operation of region manager 290 . the output of mixer 280 depends on whether system graphics are enabled and whether an applet ( or the java manager ) has focus . when both of these conditions are false , region manager 290 disables hardware mixing and multiplexer 280 need not produce any output . when system graphics are disabled but an applet has focus , the applet display buffer 210 output is selected for hardware mixing with video . when system graphics are enabled and an applet does not have focus , the system display buffer 220 output is selected for hardware mixing with video . and when system graphics are enabled and an applet has focus , software mixing is required . when software mixing is required , region manager 290 determines whether the status of the system display or applet display has changed since the last time region manager 290 performed this analysis . in particular , if mixing was not performed on the immediately preceding frames , the anti - flicker display buffer 270 likely is not current and should be initialized before multiplexer 280 switches to accept output from buffer 270 . in this instance , region manager 290 sets the whole display area as an update region before initiating mixing . during software mixing , the output of buffers 210 and 220 is mixed to composite display buffer as shown in fig6 , and the anti - flicker display buffer is updated as shown in fig7 from the composite display buffer on a frame interrupt to prevent frame tearing . once the anti - flicker display buffer is stable , region manager 290 selects the anti - flicker display buffer for hardware mixing . fig6 shows the software mixing process . when no newly painted regions have been added to the paint region linked list since the last mixing operation , no software mixing is required and the routine returns . otherwise , the first region in the paint region linked list is selected . region manager 290 determines whether the paint region overlaps a system region in the system graphics section linked list : when the regions overlap , the output of buffers 210 and 220 are merged into composite display buffer 260 , as previously described , for the paint region ; when the paint region does not overlap any registered system region , the corresponding region of applet display buffer 210 is copied to composite display buffer 260 . once the composite display buffer has been updated for a paint region , the corresponding node in the paint region linked list is modified to indicate a status of “ mixed .” region manager 290 then traverses to the next node in the paint region linked list . when the next region is null , the end of the list has been reached and the software mixing routine exits . when the next paint region is not null and has not been mixed already , the software mixer loops back up and processes the new region as described for the first region . fig7 shows the anti - flicker display buffer update process . preferably , an anti - flicker display buffer update routine is called on frame interrupt so that updates are synchronized with the display sequencing . region manager 290 determines whether any paint regions in the paint region linked list have been marked as “ mixed .” when no newly mixed regions have been added to the paint region linked list since the last mixing operation , no anti - flicker display buffer updates are required and the routine returns . otherwise , the first region in the paint region linked list is selected . region manager 290 determines whether the first paint region has been mixed yet to the composite display buffer ; when it has , the region is copied from the composite display buffer to the anti - flicker display buffer and the region is removed from the paint region linked list . when the first paint region has not yet been mixed , processing is bypassed for that region . region manager 290 then traverses to the next node in the paint region linked list . when the next region is null , the end of the list has been reached and the anti - flicker display buffer routine exits . when the next paint region is not null , the routine loops back up and processes the new region as described for the first region . the java engine allows multiple java applets to run concurrently with each other and with the java manager . as just described , however , only one applet at a time can have the “ focus ” of the viewer &# 39 ; s remote control or other input device and perform updates to the applet display buffer . platform - aware applets can be written to understand what it means to receive and lose focus , but no such assumption can be made when the viewer is allowed to load platform - independent java applets from the pcmcia port . thus the television embodiments are designed to cope with two types of java applets : platform - aware applets , which are coded specifically to interoperate with the java manager and platform - specific apis , and platform - independent applets , which are not . generally , the applets that are factory - loaded into flash memory 126 are platform - aware applets , while applets accessible through pcmcia cards can be either platform - aware applets or platform - independent applets . platform - aware applets have access to platfonn - specific apis to perform such functions as channel and volume changes , picture - in - picture functions , jpeg and mpeg4 display , etc . the java manager includes a class ( the application manager ) that functions as a java applet browser / launcher . the application manager can be assigned to a specific key on the viewer &# 39 ; s remote control and / or can be activated from a menu . the application manager maintains a list of currently - available java applets that are available to the viewer . this list will typically include some of the java applets stored in flash memory 126 ( some may only be available to other java applets and not to the viewer ) and any applets found using pcmcia cards 128 . preferably , the application manager locates descriptor files and icons for each available applet and can then present the applets to a viewer in an easily - comprehended graphical format . note that if a pcmcia card 128 provides wireless connectivity to multiple “ shares ,” where a share is a shared resource located on a computer or other wireless device , applets available on each share can be arranged in the graphical format by share . assume for the following example that the application manager 310 is the described application manager and a platform - aware applet b 320 is an mp3 player . in addition , assume that the application manager has located two platform - independent applets , an applet c 330 and an applet d 340 , which could be for instance a solitaire game and a checkers game , respectively . fig8 a - 8h illustrate applet / manager function as a viewer navigates between the application manager , these various applets , and the video function of the television . an applet that is currently not loaded to memory 122 is depicted with a dashed border ; an applet that is loaded to memory 122 is depicted with a solid border ; and an applet that has focus is depicted with a bold solid border . in fig8 a , the viewer selects application manager 310 from a remote control . the java manager 300 is notified of the viewer selection and directs focus to the application manager class . the java engine is notified that the application manager class will now receive focus and receives a request to begin executing the class files for the application manager if they were not executing already . the application manager locates the applets available to the viewer in flash memory and through a pcmcia card and creates a browse / launch display in applet display buffer 210 . the viewer may then use remote control buttons to navigate and select one of the displayed applets , with the application manager modifying its display according to the navigation commands in order to interact with the viewer . when a user selects one of the displayed applets , the application manager notifies java manager 300 that the viewer has requested the launch of an applet . for instance , in fig8 b , the viewer selects applet b , the mp3 player . the java manager 300 calls the java engine to launch applet b . application manager 310 loses focus and can no longer paint to the applet display buffer . the java engine is notified that applet b will now receive focus and receives a request to begin executing the class files for the mp3 player . applet b may provide to the viewer , for instance , playlists or individual mp3 file lists for mp3 files accessible through the pcmcia cards 128 . the viewer may then use remote control buttons to navigate and select an mp 3 file , files , or playlist and hit “ play ” to begin playing the selected mp3 media through audio processor 124 . although the application manager has now lost focus , it still runs in a background mode . when a new pcmcia card is inserted or removed from the television , or new shares appear or disappear from the wireless lan , the application manager can be programmed to notify the viewer that the list of available applets has changed . for instance , on pcmcta card removal , all running processes receive a broadcast message that the card has been removed . upon receiving this message , since the application manager does not have focus , it can signal another section of the java manager to request a transient system message , e . g ., “ some applets no longer available — press applets key to view current list ”. java manager 300 requests a system graphics section for the message and displays it to system display buffer 220 . referring now to fig8 c , the viewer now selects a video mode , causing applet b to lose focus . java manager 300 asks applet b whether it can be killed . in this example , applet b responds “ no ,” at which time applet b is notified that it has lost focus and can no longer paint to the applet display buffer . the java engine is notified that applet b has lost focus , but applet b can continue to play mp3 files in a background mode . like the application manager , applet b can use the java manager to display status messages , such as a song name when a new song starts , on the system display buffer . in fig8 d , the viewer presses a button to return focus to the application manager . the java engine is notified that the application manager now has focus , the application manager is notified that it has focus , and the application manager once again draws its applet browser display to applet display buffer 210 . in fig8 e , the viewer selects a platform - independent applet c ( the solitaire game ) and launches it , causing a series of events similar to those described for fig8 b . the solitaire game class files are loaded from the pcmcia card to memory 122 and applet c is launched . whereas applet b registered as a platform - aware applet when launched , applet c has no such registration function , and thus the java manager 300 and java engine know that applet c has no internal provision for receiving and losing focus . applet c output is directed to the applet display buffer and the viewer can operate the applet using remote control buttons . since the applet display buffer requires no special api controls , platform - independent applets can write to it without problem . the java engine and software mixer allow the platform - independent applets to function in a manner that is compatible with the television platform . in fig8 f , the viewer once again selects the application manager to regain focus . applet c cannot continue to run because it does not have the ability to direct its output anywhere but the applet display buffer , and thus would interfere with the output of the application manager . applet c can either be killed or “ paused ,” i . e . remain in memory but not receive any calls , as a design choice . if paused , applet c can potentially be resumed by reselecting it from the application manager . the kill or pause decision can also be based on other criteria , such as memory usage . thus if memory usage is high , the oldest “ paused ” applets can be deleted from memory . fig8 g illustrates a case where the viewer selects a different platform - independent applet d to run . before applet d class files are loaded , applet c can be killed to free memory , and then applet d can be launched and run in similar fashion to applet c . finally , in fig8 h the viewer once again selects a video mode , causing the java manager to pause ( or optionally kill ) applet d . although optional , the application manager could allow other applet - related activities . for instance , applets could be copied from a network share to pcmcia mass memory . or , a “ favorite applet ” could be designated and saved to flash memory 126 . one of ordinary skill in the art will recognize that the concepts taught herein can be tailored to a particular application in many other advantageous ways . in particular , those skilled in the art will recognize that the illustrated embodiments are selected from many alternative implementations that will become apparent upon reading this disclosure . the particular functional block groupings used herein present one possible functional grouping , but functions can be subdivided and / or combined in many other combinations that fall within the scope of the appended claims . although java applets have been described , the described embodiments can be used with other object - oriented coding schemes . the removable device port can be a port other than a pcmcia port . for instance , a firewire ( ieee 1394 ) or usb ( universal serial bus ) 2 . 0 port can be used to connect a removable device . ports that directly accept memory stick , multimedia card , secure digital , smartmedia , and / or xd flash devices can also be used . two java buffers have been described , but more can exist and be integrated into the described mixing schemes . mixing with a single hard key has been described , but more complicated mixing schemes are possible . such minor modifications are encompassed within the embodiments of the invention , and are intended to fall within the scope of the claims . the preceding embodiments are exemplary . although the specification may refer to “ an ”, “ one ”, “ another ”, or “ some ” embodiment ( s ) in several locations , this does not necessarily mean that each such reference is to the same embodiment ( s ), or that the feature only applies to a single embodiment .