A VII.2  CD-I Peripherals

2.1   General


2.1.1 Scope


This appendix on CD-I peripherals gives a functional specification of  the 
input and output devices of CD-I systems.

Sections A VII.2.1 - 2.4 deal with a CD-I system configuration beyond  the 
Base Case  called  CD-IX  (A  VII.2.2),  the  general  aspects  of    CD-I 
peripherals (A VII.2.3) and gives details on the use of the  Configuration 
Status Descriptor (CSD, A VII.2.4).

The CSD has a major function in CD-I systems as it allows applications  to 
ascertain the actual hardware configuration.

Section A VII.2.5 gives the functional specification of  particular   CD-I 
peripherals and section A  VII.2.6 lists the code  assignments, and    the 
particular meanings  of device  dependent parameters,  for each  of    the 
functional devices.  These two sections will be added  to as new   devices 
are defined.

The major  goal  of  this  functional  specification  is  to  provide    a 
consistent approach for extended CD-I configurations.  In this    respect, 
the Configuration  Status  Descriptor (CSD)  is  an essential  tool    for 
application designers.


2.1.2 Introduction


A CD-I Base Case  can be, for purposes  of discussion, broken  down   (see 
Figure A  VII.1)  into a  CD-I  Base Case  decoder  and  CD-I Base    Case 
peripherals.  The CD-I  Base Case  decoder is the  nucleus of  any    CD-I 
system.  It  comprises the  microprocessor, the  audio processor,    video 
processor, memory and the CD-I control unit. CD-I  peripherals are   input 
and output devices that can be used in connection with the CD-I Base  Case 
Decoder.

Following the  above  interpretation,  the  Base  Case  CD-I  system    is 
configured as a CD-I  Base Case decoder with  CD-I Base Case   peripherals 
such  as  a  monitor  and  a  pointing  device.    The  Base  Case    CD-I 
configuration and the use  of the Configuration Status  Descriptor   (CSD) 
are mandatory.

A basic  principle for  extendability as  given here  is  that any    CD-I 
peripheral is considered  independent of  the availability of  any   other 
peripheral  device.   As   such,  all   peripherals  are  specified     as 
self-contained.  Clearly, this approach  will lead to a  high number    of 
configurations.   For  this  reason,  preferred  configurations  can    be 
proposed for certain application areas.

One such configuration for  a personal information system  is   designated 
CD-IX and  specified  in  A  VII.2.2.   CD-IX will  always  include    the 
functionality of  the CD-I  Base Case.   This proposed  configuration   is 
fully compatible, independent of whether it is available as an  integrated 
system or if it is assembled from the individual peripherals.

The relationship between the different CD-I configurations is    indicated 
in Figure A VII.1 below.


 Figure A VII.1

External                      Audio                         ______________                     
_
                         __________________
__________________________----------------_______________________
_      CD-IX             _                _                     _
_  _______________________----------------___________________   _ _   _    
CD-I  Base  Case     _                 _                  _    _  _      _ 
____________________----------------___  ___________  _   _
_  _  _Base Case Decoder _                ______Audio Set_  _   _
_  _  _   ___________  _ _   Audio        _ _  ___________  _   _
_  _  _   _   MPU   ______   Processing   _ _               _   _
_  _  _   ___________  _ _   Sub-System   _ _  ___________  _   _
_  _  _                _ __________________ _  _Pointing _  _   _
_  _  _                _________________________ Device  _  _   _
_  _  _                _                    _  ___________  _   _
_  _  _  _____________ _     ____________   _  ___________  _   _
_  _  _  _ Memory    _________CD Control________CD-Player_  _   _
_  _  _  _ - RAM     _ _     _   Unit   _   _  ___________  _   _
_  _  _  _---------  _ _     ____________   _  ___________  _   _
_  _  _  _ - ROM     _ _                    _  _ Display _  _   _
_  _  _  _  (CD-RTOS)_ _   _______________  _  _ (Normal _  _   _
_  _  _  _____________ _____    Video    _______  Res.)  _  _   _
_  _  _                _   _ Processing  _  _  ___________  _   _
_  _  _                _   _ Sub-System  _  _               _   _
_  _  _                _   _. Normal Res._  _               _   _
_  _  _                _   _. Double Res._  _               _   _
_  _  _                _   _             _  _               _   _
_  _  ______________________-------------____               _   _
_  _________________________-------------____________________   _
_        __________    _   _             _     ___________      _
_        _Keyboard______   _             _______ Display _      _
_        __________    _   _             _     _ (Double _      _
_        __________    _   _             _     _  Res.)  _      _
_        _   FDD  ______   _             _     ___________      _
_        __________    _   _             _                      _
____________________________-------------________________________
          __________    _   _             _  _____________________
          _ Modem  ______   _ . High Res. ____Display (High Res.)_
          __________    _   _______________  _____________________
         __________    _      _
         _ Printer______      _
         __________    _    External Video         _______
                       _____________________________Other_
                       _     _____________         _______
                       _______ Hard Disk _
                             _____________
2.2  CD-IX

This section describes the CD-IX configuration and the devices which  this 
includes.  Functional specifications for CD-IX and extension devices   are 
given in A VII.2.5 and will be added to as and when required.


2.2.1  Objective


A  Base  Case  CD-I  system  can  be  expanded   to  include    additional 
input/output devices and hardware options.  The result can  be a   package 
which may be, for example, a personal information  system, an   electronic 
publishing system, or a car navigation system.

In  order  to  make  application  software  development  efficient     and 
non-hardware specific, developers of software for extended CD-I    systems 
need to know the  minimum level of functionality  that can be    expected. 
They   also   require    standardized   interface    definitions     (i.e. 
virtualization) of the various options which may exist.

The purpose of  this CD-IX  specification is to  ensure an  orderly    and 
compatible development of  extended CD-I  systems.  Systems meeting    the 
requirements of this specification are designated 'CD-IX'.



2.2.1.1  CD-IX Configuration


The basic configuration for the CD-IX system is given below.  All  devices 
need be  present  for a  system  to be  used  as  a CD-IX  system.     The 
manufacturer must provide the necessary hardware decoding capability   and 
interfaces as well as software managers and drivers in accordance with   A 
VII.2.3 and 2.4.

      
      CD-IX Configuration

      -    The CD-I Base Case Configuration.
      -    Double Resolution display.
      -    Full alphanumeric keyboard.
      -    One 3.5 inch Floppy Disk Drive.


2.2.1.2  CD-IX Extension Options

The following options are those which can be immediately supported by  the 
system software of CD-IX, and, therefore, may be  provided as a   hardware 
manufacturer's option.  Any  combination of  options may be  used.    Each 
option can be built-in to CD-IX or installed later as a plug-in option.

All necessary software  modules (e.g.  device drivers, etc.),  needed   to 
support any  device  must  be  provided  with  the  necessary     hardware 
interfaces.

      CD-IX Extension Options
      -    RAM extension module
      -    Hard disk drive
      -    Printer
      -    Modem
      -    MIDI interface
      -    Co-processors
      -    Local Area Network

An overview of the  above mentioned configurations is  given in Figure   A 
VII.2.

Figure A VII.2
_________________________________________________________________
_Device            _ CD-I        _ CD-IX    _ CD-IX             _
_                  _ Base Case   _          _ Extensions        _
_________________________________________________________________
_RAM size          _ 1 MB        _ 1 MB     _ further expansions_
_Clock Calendar    _ yes         _ yes      _ yes               _
_Co-processors     _ no          _ no       _ yes               _
_                  _             _          _                   _
_Display Type      _ Normal      _ Double   _ High              _
_Pointing device   _ yes         _ yes      _ yes               _
_Keyboard          _ Application_ yes      _ yes               _
_3.5 inch FDD      _ no          _ yes      _ yes               _
_Printer           _ no          _ no       _ yes               _
_Modem             _ no          _ no       _ yes               _
_Hard disk         _ no          _ no       _ yes               _
_MIDI              _ no          _ no       _ yes               _
_LAN interface     _ no          _ no       _ yes               _
_________________________________________________________________
2.2.1.3  CD-IX Future Options


CD-IX has,  in accordance  with the  extension philosophy  of  CD-I,   the 
possibility of further extendability  covering a broad range  of   present 
and future  devices.   This document  describes  devices which  can,    in 
principle, be supported  now as  well as how  additional devices  may   be 
supported in the future.   Compatibility is facilitated by  the   inherent 
modularity of CD-RTOS and the use of the Configuration Status   Descriptor 
(CSD) mechanism.


2.2.2  CD-IX Configuration

2.2.2.1  CD-I Base Case

CD-IX includes the CD-I Base Case system's functionality.  The   following 
Base Case devices are supported by the CD-RTOS file managers (see VII.2)

-     CD-Control Unit
-     Audio Processor
-     Video Processor
-     Non-volatile RAM
-     Pointing Device
-     Keyboard (optional)
      
It is up  to each  manufacturer to include  additional file  managers   to 
CD-RTOS to support the additional CD-I peripherals.  CD-RTOS    compatible 
file managers for certain  groups of devices are  the OS-9 file   managers 
for serial character files,  random block files and  serial block    files 
(see Appendix VII.1).


2.2.2.2  Display System

The CD-I Base Case is capable of Normal  and Double Resolution.   However, 
the CD-I Base  Case display  is a Normal  Resolution display.   A   Double 
Resolution display is required for CD-IX.



  2.2.2.3  Keyboard


A full  alphanumeric keyboard  is required  for a  CD-IX    configuration. 
Limited functions can be  obtained by the use  of smaller keyboards    and 
keypads.  Different keyboards will  be required for different    alphabets 
and writing systems.   In particular  keyboards for Latin  alphabets   and 
Kanji will have very different capabilities.



2.2.2.4  Floppy Disk Drive (3.5 inch FDD)


Floppy Disk Drives (FDD) give CD-IX systems a means to permanently   store 
a reasonable amount of user data.

A single medium and format standard is necessary in order to ensure   disk 
interchangeability between different models and brands of CD-IX   systems. 
At least one 3.5 inch FDD is required.  The standard OS-9 disk format   is 
specified (see A VII.1).   However, the system shall  also be capable   of 
reading files,  writing  files, and  accessing  directories on    standard 
MS-DOS format 3.5 inch Floppy Disks.

It should be  noted that  CD-I real-time files  cannot be  'played'   from 
magnetic media due to the different capabilities and  characteristics   of 
the two media.





2.2.3  CD-IX Extension Options


2.2.3.1  Printer

CD-I will  be a  medium with  very high  non-textual  visual   information 
content.  Therefore, printers which  support only a character  mode   will 
not be able to provide a reasonable hard-copy of images presented on   the 
video display.   This  also  causes  problems  for application    software 
developers, who effectively have  to design two presentation  modes,   one 
for video displays and one for hard-copy.

On the other  hand, printers  with full image  writing capabilities    can 
provide (with the appropriate  virtual interface) a direct  image of   the 
video display with mixed text and pictures. Printers with this  capability 
range from  low  cost dot-matrix  types  up to  high  performance    laser 
printers.

Image printers  can use  the various  font styles,  sizes,  and   national 
character sets inherently provided  by the CD-I display  system.  Use   of 
image printers is  widely acknowledged  as a requirement  for   electronic 
publishing, which is a potential CD-I application.

CD-IX Extension will only support image printers.



2.2.3.2  Modem

Data communications  capabilities  provide important  features,  such   as 
access to videotex on-line information services, home shopping and   other 
similar capabilities.

This  interface  should  provide  a  full  RS232  serial,    bidirectional 
interface   with    control    signals   suitable    for    control     of  
auto-answer/auto-dial modem.

The baud  rate  must  be  user-selectable  and  capable  of    reversible, 
split-rate operation for videotex type systems.








2.2.3.3  Hard Disk Drive

Various types and sizes of magnetic hard disks  may be used with    CD-IX. 
The following points apply to hard disks:

-     capacity: no restriction
-     standard OS-9 logical file format

The type of hardware interface used is up  to the hardware   manufacturer. 
The file manager and file format are specified in A.VII.1.



2.2.3.4  RAM Disk

A specialized driver, controlled  by the random block  file manager   (see 
A.VII.1), allows RAM memory to be used as very high speed temporary   file 
storage, which is typically used to hold small working files.

Memory allocated for RAM  disk is not available  for use by   applications 
programs as general purpose working storage. However, the user can  choose 
whether or not to use memory for this function.



2.2.3.5  MIDI Interface

MIDI (Musical Instrument Digital Interface) hardware may be  provided   as 
an option.  MIDI allows computers to interface to synthesizers and   other 
electronic music devices.  The MIDI interface is considered as a de  facto 
standard interface for musical instruments.

The available OS-9 MIDI driver module will permit real-time recording   of 
instruments/devices,  real-time  playback   of  up   to  16    instruments 
simultaneously, and  block storage/retrieval  of MIDI  data to    external 
devices.  Specifications  are based  on the  current International    MIDI 
Association (IMA) documents.








2.2.3.6  Graphics Co-processor


The use of a specialized graphics co-processor can provide a  considerable 
increase in  system speed  and performance  with only  modest   additional 
cost.  Experience has shown the speed improvement to  be in the order   of 
five to ten times for the basic operations involved.  The overall   system 
improvement is application dependent.

Due to the modular architecture of CD-RTOS, this  options can be used   to 
replace software routines while  applications programs remain   compatible 
and automatically benefit from the performance gain.

A graphics co-processor provides  high-speed drawing primitive   functions 
which substitute for some  or all the software  routines included in   the 
UCM and video display driver modules (see VII.2.3).   The functions of   a 
particular co-processor  must  match  CD-I  screen  resolution  and    UCM 
primitive functions.


2.2.3.7 Arithmetic Co-processor


An arithmetic co-processor provides high speed floating point   arithmetic 
operations.  A CD-RTOS 'Math' module which implements these routines   can 
be replaced with an equivalent module which utilizes a co-processor.   Any 
co-processor which supports the single and double precision formats  given 
in the IEEE Standard  for Binary Floating Point  Processors (Task    Group 
P754) may be used.


2.2.3.8  Local Area Network


Local Area Network  (LAN) is  a capability which  must be  available    to 
penetrate educational and certain semi-professional and office  automation 
markets.  A CD-RTOS compatible LAN subsystem called Network File   Manager 
(see A.VII.1) is available.

NFM combines the individual file systems of each processor into a   single 
logical file system.  This  permits any system on  the network to   access 
files and devices on other systems as if  they were local.  The    network 
system is  completely  transparent  to  CD-I  applications software.     A 
security mechanism is provided.


2.3  Implementation Aspects of CD-I Peripherals


2.3.1  General


Essential for each CD-I peripheral is that it  has to make available    to 
the system its own Device Status Descriptor (DSD), device driver and  file 
manager.

There are several methods for implementing an extended CD-I system.    The 
three methods  described  here  are  not  exclusive  to  CD-I,  but    are 
well-known from other computer configurations.  The methods can  be   used 
in any combination.  Only  these three are mentioned  here because   these 
are being considered as standard methods supported by CD-RTOS modules  for 
CSD compilation.

The standard methods are:

(1)   'Built-in' peripherals;
(2)   System bus based peripherals; and
(3)   Interface based peripherals.

Although it is technically feasible to restrict oneself  to one of   these 
methods, it is  likely that  a CD-I system  may deal  with a  mixture   of 
methods.



2.3.2  'Built-in' Peripherals


From a system point of view, this is the easiest method to implement.

The  additional  system  software  modules  for  these  peripherals    and 
information from which the required DSDs are compiled  have to reside   in 
system ROM.

When a CD-I peripheral is built-in, it is  completely up to the   hardware 
manufacturer how to integrate  the CD-I peripheral into  his design,    as 
long as care is taken with respect to  the requirements of the CSD.     As 
such this system  is essentially  a closed system  and is  acquired as   a 
ready-to-use unit.





2.3.3  System Bus Based Peripherals


System bus based peripherals are CD-I peripherals that are designed to  be 
plugged into extension slots of the system bus.  A characteristic of  this 
type of extension is that the CD-I Base Case has direct control over   the 
CD-I peripherals.

The additional system software modules for operation of  the   peripherals 
and information  from which  the DSDs  are compiled  have  to reside    in 
separate ROM associated with the system bus based peripheral.

Mechanical and electrical specification of a system bus slot interface  is 
up to each hardware manufacturer.



2.3.4  Interface Based Peripherals


Interface based peripherals refer  to peripherals that are  connected   to 
the CD-I system through  the use of (de  facto) standard or    proprietary 
interfaces.  A major difference between interface based peripherals    and 
the 'built-in' or system bus based peripherals is the non-direct   control 
of the peripherals.

These interfaces include the  RS232 interface, the Centronics    interface 
and the SASI/SCSI interface.

Compared to the preceding  methods, this method is  a rather   complicated 
one to handle.   This is  so because the  interface is  built-in and   the 
peripheral is external without its own ROM.  In general, such   interfaces 
are  well   defined   in   their   mechanical   design  and     electrical 
characteristics.  Although these  interfaces are  mostly designed for    a 
well-defined objective,  in  practice  they  are  often used  for    other 
purposes: e.g. an RS232 modem communication interface is often used as   a 
printer interface or as a port to a data processing system.

These interfaces require that the supporting software modules,   including 
information from which the DSDs are compiled, reside in the system ROM  as 
for the built-in peripherals.  However, this will lead to restrictions  on 
compatibility of certain functional  extensions of different brands    and 
different models.




2.4   Hardware Configuration Status Descriptor


2.4.1  General


It is important for an application program to  be able to determine    the 
configuration of a CD-I system.  To facilitate this CD-RTOS provides   the 
Configuration Status Descriptor (see VII.1.3) which provides   information 
about each device on the system whether it  is a Base Case device or    an 
extension beyond the Base Case.  Each device is represented in the CSD  by 
its Device Status Descriptor (DSD).

The CSD is stored  in non-volatile RAM (see  VII.1.3.2) in a  file   named 
"CSD".  Application programs may  access the CSD information  by   opening 
and reading this file.

The formats  for  each field  in  the DSD  are  further  specified in    A 
VII.2.4.2 and completed with the actual coding for  typical devices in   A 
VII.2.6.


2.4.2  Device Status Descriptors

Each Device  Status  Descriptor  (DSD)  corresponds  to one  device    and 
comprises three fields.

Device Type             :This field contains an integer representing  the 
                     general class of functional  devices to which   this 
                     device belongs.   Examples might  be: optical   file 
                     storage devices,  hardcopy printer,   communications 
                     device, magnetic disk,  pointing device,   keyboard, 
                     sensor, etc.

Device Name             :This field contains the name used to access  the 
                     device.

Device Parameters             :     This  field  is  used  to    provide 
                        complete information to  identify the   functional 
                        performance of  the  device.   The  contents   are 
                        specific to a particular device type.

Each DSD comprises  bytes with  values in the  range $20  to $7E  and   is 
terminated by a carriage return ($0D) character.

2.4.2.1  Device Type Field

The device type field is a string of numeric characters (0-9)   terminated 
by a colon (":") to identify the function of the device.

The device codes are allocated according to the following rules:


      Device Type Code Meaning

      0 to 9        : Base Case devices
      10 and above    :Extension devices



2.4.2.2 Device Name Field

The device name field  is a string of  characters terminated by  a   colon 
(":").

For most devices the device name will be  used by CD-RTOS to access    the 
relevant CD-I  device.   This will  be  the actual  name  of  the   device 
descriptor and  will  begin  with  the  "/" character.  This  allows    an 
application to determine the name of a device from the device type.    For 
others, not controlled by  CD-RTOS, the name only  identifies the DSD   to 
the application.  These device  names are unique, even  if more than   one 
type of a particular device is connected.

The only Device Name which is defined in this specification is "/nvr"  for 
the NVRAM (see VII.2.4.2).

2.4.2.3 Device Parameter Field

The device parameter field contains an open-ended list  of parameters   to 
identify and/or to set the functional behaviour of the device   identified 
by its device type.  These parameters are interpreted  by an   application 
or driver and are  unique to each device.   The format is  designed   such 
that it can handle a multitude of parameters and does not restrict  future 
enhancements.  The parameter definitions  are in readable format,    using 
the ISO 8859-1 character set (codes $20 to $7E)






Each entry in the Device Parameter Field has  one of the following   three 
formats:

1)          Two character Parameter Identifier used as a boolean flag  to 
     indicate one of two particular capability options.

     For example a monochrome display device would be defined as such  by 
     the parameter field "MO".

2)          Two character Parameter Identifier followed by the "#"  ($23) 
     character and a numeric parameter value.  The value  would  comprise 
     a variable length string of characters in the range $30 to $39.

     For example, for a  video processor capable of  displaying 2   image 
     planes, the relevant parameter field would be "PL#2".

3)          Two character Parameter Identifier followed by the "="  ($3D) 
     character and an alphanumeric string.

     For example, "KG="ALL"" in the Keyboard DSD would indicate that  all 
     Key groups were present.

Each parameter entry is terminated by a colon (":", or $3A).

Where, for any parameter, two or more values can be present these can   be 
separated by a comma ("," or $2C).

The Parameter Identifier for  all three formats must  comprise two   upper 
case alphabetic characters ($41 to $5A).


2.4.2.4 Multiple Presence

It is possible for more than one device  of the same type to be    present 
within the  same  hardware configuration.   These  will be    individually 
identified by unique device names.

     

2.4.3  CSD Access

The CSD is maintained in a file in NVRAM called "csd".  It is made up   of 
the set of DSDs merged together.  Each DSD is terminated with a   carriage 
return ($0D).  To access an individual DSD, it is recommended to open  the 
file and parse through the entries using I$ReadLn.   (I$ReadLn will   read 
up to the  next carriage  return).  When the  appropriate DSD  entry    is 
found, the file should be closed.

To alter a parameter in a DSD, it is recommended to read the entire   file 
into memory, make the appropriate changes and then to rewrite the   entire 
file, setting the new file size.


2.4.4 Adding New Devices to the CSD

There are several ways  that new devices may  be added to  the CSD.    The 
appropriate manner depends upon the features of the device. If the  device 
is added as a bus peripheral, the DSD  for that device could be   included 
in ROM on the board.  When CD-RTOS searches  ROM for modules at   startup, 
it would find this module and add it to the DSD entries in the "csd"  file 
in NVRAM.


If the  peripheral  is  added  as  an interface  based  peripheral,    the 
manufacturer may supply a disc with the device  which contains a   program 
to configure the CSD for the device.2.5Functional Specification  of   CD-I 
Peripherals

2.5.1 Pointing Devices

The pointing device allows the user to control the position of the  screen 
graphics cursor (V.5.12) via the application.  It is  the   responsibility 
of the application to position the cursor using the coordinates   provided 
by the pointing device.  Every Base Case player must include at least  one 
pointing device.


2.5.1.1  Classes of Pointing Device

There are four classes of pointing device:

a.   Absolute screen pointing devices

     Pointing devices  which are  used directly  on the  screen   include 
     light pens and touch screens.  The screen position  given by   these 
     pointers is tied directly to the display screen.

b.   Absolute coordinate pointing devices

     Pointing devices that deliver absolute coordinate positions for  the 
     screen pointer  include graphics  tablets and  absolute   coordinate 
     mice.  The output of  these devices are the  absolute positions   of 
     the pen in relation to the grid and its resolution.

c.   Relative coordinate pointing devices

     Pointing devices that deliver relative coordinate positions for  the 
     screen pointer include mouse and trackball devices. The  output   of 
     these devices  provides incremental  values for  both   coordinates, 
     relative to the last readout.

d.   Manoeuvring pointing devices

     Pointing devices that deliver control information to manoeuvre   the 
     screen pointer  to its  desired position  include joysticks.     The 
     output of these devices gives the direction into  which the   cursor 
     has to be moved with a fixed, or  optionally, a variable   velocity. 
     At least 16 different  directions, equally spaced around  the   full 
     360 degrees, must be available.

The class of pointing device in use is defined by the DSD.

2.5.1.2  Pointer Coordinates

Each pointing  device  via  the  associated  driver  must  output     high 
resolution UCM coordinates  to the  application.  The resolution  of   the 
device must be at least equivalent to normal resolution over the   reduced 
screen area.

The pointer origin is,  by default, at the  top left corner  of the   full 
screen display.  It is the responsibility of the  application to set   the 
origin for the coding format for which the disc is coded.  This   provides 
full compatibility when, for example, 525 line images are displayed  using 
a 625 line format or vice versa.

2.5.1.3  Pointer Buttons

The pointing device will have two buttons or  switches.  The function   of 
these is  application dependent.   The position  and type  of  button   or 
switch will  vary  from device  to  device.  Where  appropriate,  it   is  
recommended that the buttons be labelled as follows:
                 _______
     button 1 :   _  o  _
                 _______
                 _______
     button 2 :   _ o o _
                 _______

Furthermore it  is  recommended  that  where  the  two  buttons  have    a 
left/right orientation, the left  button is to be  button 1.  Where    the 
buttons have a front/back  or top/bottom orientation, the  front or    top 
buttons are recommended to be button 1.

For light pens and tablets where switches are  built into the pen    these 
switches will be identified as follows:

     Switch 1 : in tip of pen

     Switch 2 : on side of pen

The two switches 1 and 2 are equivalent to buttons 1 and 2 respectively.

2.5.1.4  Pointer Input Functions

The following input functions are provided in UCM.  For more details,  see 
VII.2.3.5.

PT_Coord          returns  pointer coordinates  and pointer  and   button 
            states

PT_SSig           defines  the signal  number to  be returned  when   the 
            pointer is moved or either button is depressed

PT_Relea    releases the pointer driver from the PT_SSig function

PT_Pos            sets the position  of pointing devices for  classes  c. 
            and d. only.  This has no effect for classes a. and b.

PT_Org            sets the pointer origin to a new  position relative  to 
            the default position (see A VII.2.5.1.2).

2.5.2  Keyboard for Latin Alphabets

The keyboard  provides  the user  an  alternative means  of    controlling 
applications or of text and data entry.  This  specification is   intended 
for keyboards for use in countries for which  the CD-I default   character 
set (which conforms to ISO 8859-1) is appropriate.


2.5.2.1  Keygroups

The keys on the keyboard are divided into the following groups:

Programmable Function Keys

This group comprises eight (8) keys, labelled F1, ..., F8, which must   be 
interpreted by the application.  These keys will generate 32 unique  codes 
when used in conjunction with the special keys (see below).

Cursor Control Keys

The cursor is a  screen pointer that indicates  the "active" position   on 
the screen for data input.  The cursor control keys can, depending on  the 
application,  be  regarded  as  a  crude  manoeuvring  pointing    device. 
Depressing these keys does not automatically cause the specified   action, 
it is up to the application to interpret these codes and cause the  proper 
action to occur.
Key Label (recommended)
                                                        _____
Cursor Up     - move the cursor one unit* upwards        _ _ _
                                                        _ _ _
                                                        _____
                                                        _____
Cursor Down - move the cursor one unit downwards       _ _ _
                                                        _ _ _
                                                        _____
                                                        _____
Cursor Left - move the cursor one unit left            ___ _
                                                        _____
                                                        _____
Cursor Right - move the cursor one unit right           _ ___
                                                        _____
*     The size of  a unit  is application dependent,  but typically   may 
    represent one character position for text, or a  pixel for   graphics 
    applications.



These keys may be used in conjunction with  the special keys to    produce 
different codes, which may  be used by the  application, for example,   to 
move the cursor a greater distance than one unit.

Alphanumeric Keys

This group comprises a  minimum of 48 keys  (including space bar),   which 
together with  the special  keys produce  all alphabetic,  numeric,    and 
punctuation characters and special symbols, as defined in ISO 8859-1.

All keys in this group must be labelled both with the characters  produced 
in normal and shifted modes and, if not included already, all   characters 
with codes in  the range  $21 to $7E  in the  ISO 8859-1  character   set. 
Alphabetic keys need only be labelled with the upper case character.

Special Keys

These keys do not generate any codes when depressed.  Instead they  modify 
the code produced by other keys, when used in conjunction with them.   The 
state of these  keys is  returned by the  driver when  requested    (using 
KB_Stat).  This group includes:

Key Label
    
    Shift - this key  while depressed instructs the  keyboard driver   to 
    generate code values according to the shift mode.
    
    Caps - this optional  key selects upper case  (shift) mode for    the 
    alphabetic characters.   This  effect  should  also  extend to    the 
    supershift state.  Pressing  this key  a second time  selects   lower 
    case (normal) mode.

    Supershift - this key while depressed instructs the  keyboard  driver 
    to generate code values according to the supershift  mode and may  be 
    used in conjunction with the shift key.  This  allows the   selection 
    of characters that  are not  accessible from the  normal or   shifted 
    mode.

    Control - this key  when used in conjunction  with other keys,   will 
    produce codes in the range $00
  to $1F.  When used  also with supershift the  codes   $80 to  $9F   are 
generated.


 ______
 _ _  _
 ______


 ______
 _CAPS_
 ______



 ______
 __ _ _
 ______



 ______
 _CTRL_
 ______

These keys are used in conjunction with the other keys and each other   to 
produce the remaining codes in the character set.

Formatting KeysKey Label

    Return - this key is used to mark  the end of an input string.     It 
    may also be used as "enter" or "select".


    Tab - this  key is  used to signal  to the  application to  move  the 
    cursor to the next tabulator position.


    Delete - this key is used to signal to the application to delete  the 
    character before the cursor position and backspace the cursor.

    Escape key - this key generates the escape code.



Labelled Function Keys

The following keys are optional for all classes of keyboard:

    Help - this key  signals to the application  that the user   requires 
    more information at the current point in the application to proceed.

    Menu -  this key  signals to  the application  to  pause itself   and 
    return to a main menu to allow the  user to resume, pause, or    quit 
    the application.

    Home - this key signals to the application to, for example,  position 
    the cursor at the top left of the screen.

Note that either the recommended icon should be used as key label or  text 
as defined in the DSD.





 ______
 _ ____
 ______

 ______
 ______
 ______
  or
 ______
 _TAB _
 ______
 ______
 _DEL _
 ______

 ______
 _ESC _
 ______






 ______
 _ ?  _
 ______

 ______
 _MENU_
 ______


 ______
 _HOME_
 ______
Numeric Keys

This optional group comprises the numeric keys 0 to 9, which may be   used 
to duplicate the same keys in the alphanumeric group.

2.5.2.2  Classes of Keyboard

Keyboards may have different formats from small keypads with limited  keys 
to full alphanumeric  keyboards.  The  following table lists  the 7    key 
groups and  defines  a minimum  configuration  for a  full    alphanumeric 
keyboard needed to meet the CD-IX specification.  The key groups used  are 
defined in the DSD for each CD-I decoder.

_________________________________________________________
_                              _ Number _   Keyboard    _
_                              _   of   _ Configuration _
_Key Groups                    _  keys  _   for CD-IX   _
_________________________________________________________
_1  Programmable function keys _   8    _       M       _
_                              _        _               _
_2  Alphanumeric keys          _ 48 min _       M       _
_                              _        _               _
_3  Special keys               _ 3 or 4 _       M       _
_                              _        _               _
_4  Cursor control keys        _   4    _       M       _
_                              _        _               _
_5  Formatting keys            _   4    _       M       _
_                              _        _               _
_6  Labelled function keys     _ 1 to 3 _       0       _
_                              _        _               _
_7  Numeric keys               _   10   _       O       _
_________________________________________________________
    M : Mandatory
    O : Optional

2.5.2.3 National Versions

Different versions  of the  keyboard may  be needed  to  suit   particular 
national requirements.   This may  result in  the following    differences 
between keyboards:

(1) Differences in the physical layout of alphanumeric keys.

(2)   Certain alphanumeric character codes in the range $21 to $7E   will 
    not be available except  in Supershift mode and  some codes in    the 
    range $A0 to $FF will be available in normal and shifted modes.

It is recommended that  the alphanumeric keys should  always be   labelled 
with characters whose codes are in the range  $21 to $7E even when   these 
are generated in Supershift mode.  This may require up to four   character 
legends for some keys.

2.5.2.4  Code Assignments

The code assignments  for the  keys defined in  A VII.2.5.2.1  are   given 
below.  The code value returned to the application  for each key is,    in 
general, modified by combining it with one or more of the special keys.

Code Assignments (hex codes)
_________________________________________________________________
_              _                 Mode                     _
_    Key group      _____________________________________________
_                   _  Normal  _  Shift  _Supershift_  Control  _
_________________________________________________________________
_Programmable       _          _         _          _           _
_   Function Keys   _          _         _          _           _
_                   _          _         _          _           _
_ F1    _   80     _   88    _    90    _    98     _
_ F2                _   81     _   89    _    91    _    99     _
_ F3                _   82     _   8A    _    92    _    9A     _
_ F4                _   83     _   8B    _    93    _    9B     _
_ F5                _   84     _   8C    _    94    _    9C     _
_ F6                _   85     _   8D    _    95    _    9D     _
_ F7                _   86     _   8E    _    96    _    9E     _
_ F8                _   87     _   8F    _    97    _    9F     _
_________________________________________________________________
_Control Keys       _          _         _          _           _
_ Left              _   08     _   11    _    15    _    02     _

_ Down              _   0A     _   12    _    16    _    03     _ _ Up 
_   0B     _   13    _    17    _    04     _ _ Right             _   0C 
_   14    _    18    _    05     _ 
_________________________________________________________________ 
_Formatting Keys    _          _         _          _           _ _ 
Return            _   0D     _   0D    _    0D    _    0D     _ _ Tab 
_   09     _   19    _    19    _    19     _ _ Delete            _   7F 
_   0F    _    0F    _    1F     _ _ Escape            _   1B     _   1B 
_    1B    _    1B     _ 
_________________________________________________________________ 
_Function Keys      _          _         _          _           _ _ Help 
_   1C     _   1C    _    1C    _    1C     _ _ Menu              _   1D 
_   1D    _    1D    _    1D     _ _ Home              _   1E     _   1E 
_    1E    _    1E     _ 
_________________________________________________________________ Other 
combinations of these keys with special keys (except caps) will return 
the normal value.

The code assignments for the alphanumeric keys are as defined by the   ISO 
8859-1 code  table.   These keys  used  in conjunction  with  Shift    and 
Supershift generate the codes $20 to $7E and $A0 to $FF.  The  combination 
of keys  needed to  produce certain  codes may  depend  on the    national 
version.  In  general, however,  supershift will  be needed  to   generate 
codes in the range $A0 to $FF.

Those alphanumeric keys,  which in  shifted mode generate  codes in    the 
range $40 to $5F, can be used with Control and without Shift to   generate 
codes in the range $00 to $1F.

The same keys  used with  Control and Supershift  generate codes  in   the 
range $80 to $9F.

Note that  these  rules apply  whatever  national version  is  used.   For 
example, even if the  code $5E requires supershift  to be depressed   then 
code $1E must be generated when used with Control and $9E when used   with 
Supershift and Control.


2.5.2.5  Keyboard Driver

The driver  converts the  direct keyboard  output into  the  code   values 
defined in  A  VII.2.5.2.4.  In  addition,  it must  meet  the   following 
requirements:

1.    Key up/down events must be detected by the driver even when   other 
    keys are down at the same time.  This includes determining the  state 
    of the special keys.

2.    Auto repeat for all  keys except special keys,  labelled   function 
    keys, programmable function keys and the Escape key. The auto  repeat 
    latency and  frequency  can be  defined  by the  application.     The 
    application may read  the DSD  for the user's  preferred values    or 
    define them to suit the application.

3.    All key  up/down and  auto repeat events  must be  queued by    the 
    driver.  The  queue buffer  must hold  at least  256  events.    When 
    I$Read is used  to read  the input from  the keyboard,  auto   repeat 
    events are converted to keydown events (i.e. a string of  characters) 
    corresponding keyup events are ignored and removed from the queue.

For information on the UCM Driver interface see VII.3.2.3.


2.5.2.6  Keyboard Input Functions

The following keyboard input functions are provided by  UCM.  For a   full 
specification see VII.2.3.6.

I$Read- Read a character string

KB_Ready    - Check for Data Ready

KB_Read  - Read Keyboard Event

KB_SSig  - Send Signal on Keyboard data ready

KB_Relea - Release device

KB_Repeat- Set Keyboard Latency and Repeat Times

KB_Stat  - Determine Status of Keyboard



2.6  Device Status Descriptors

2.6.1 General

This section defines the DSD codes for Base  Case and extension   devices. 
It will be added to from time to time for new devices.
If any parameter is missing from the DSD the default value is assumed.

2.6.2  Base Case Devices

This section defines the Device Type codes and Device Parameters for   the 
Base Case devices which are controlled by CD-RTOS.  The Device Names   are 
defined by CD-RTOS.

2.6.2.0 System

Device Type Code   0

Parameter String   Description        Default

RV = "X.Y"         CD-RTOS(No default)
        revision level
        e.g. 1.0

2.6.2.1 CD-Control Unit

Device Type Code  1

Device Parameters

Parameter string  Description            Default

    SP#nSector data processing
      delay in ms = n   27

2.6.2.2 Audio Processor

Device Type Code  2

Device Parameters

Parameter string  Description           Default

    AM      Audio Mixing Unit presentnone present

    AD#nAudio Processing delay
      in ms = n  27
2.6.2.3  Video Output Processor


Device Type Code  3

Device Parameters

Parameter string  Description            Default

    EV      Capable of synchronizing to
      external video (extended case)Not capable

    PL#nNumber of planes = n2

    CM     Continuous mosaic (Pixel repeat
      factor may be any value 2-255)2,4,8,16
           only

    CS#NH,NV Cursor horizontal (NH) and
      vertical (NV) size in pixels16, 16

    HS  Capable of high scanNormal scan

    HI  High resolution display forNo High
      all display modesResolution
    
    LS  Line Sequential scanInterlace

    LI=StringNumber of lines given by string(No default)
        string = "525" : 525 lines
        string = "625" : 625 lines

    TV  Television displayMonitor


2.6.2.4  Non-volatile Random Access memory (NVRAM)


Device Type Code  4

Device Parameters

Parameter string  Description            Default

    SZ#nSize in kbytes given by n8 kbytes







2.6.2.5  Pointing Device


Device Type Code  5

Device Parameters

Parameter string  Description            Default

    CL=stringClass of pointing device given(No default)
      by string:
      "a": Absolute screen pointer
      "b": Absolute coordinate pointer
        "c":Relative coordinate pointer
      "d": Manoeuvring pointer

    HI  Capable of high resolutionNormal
        Resolution



2.6.3  Base Case Peripherals

This section defines the DSD Device Type codes and Device Parameters   for 
Base Case devices which are not controlled by CD-RTOS


2.6.3.1 CD-Player

Device Type Code   6

Device Parameters

Parameter string  Description            Default

    SK#nMax. seek time = n sec3 sec

    ND#nn = number of discs for multi-
      disc changer1 disc

    




2.6.3.2  Audio Set


Device Type Code  7

Device Parameters

Parameter string  Description            Default


    

2.6.3.3  Display Monitor


Device Type Code  8

Device Parameters

Parameter string  Description            Default

    MO     Monochrome displayColor

    RS=stringResolution defined by stringNormal
      "D" = Double
      "H" = High

    LI=stringNumber of lines defined by string(No default)
      String = "525" : 525 lines
      String = "625" : 625 lines
      String = "525, 625" :
        525 or 625 lines
        for a multi-standard
        display monitor

    HS  High scanNormal scan

    LS  Line sequentialInterlace

    





2.6.4  Base Case Device "Pipe"

This section defines the Device Type Code for the Base Case device  "Pipe" 
which is controlled by CD-RTOS.  The Device Name is defined by CD-RTOS


2.6.4.1  Pipe device

Device Type Code    9

Parameter string   DescriptionDefault



2.6.5  Peripheral Extensions

This  section  defines   the  DSDs   for  peripheral  extensions.      New 
devices/peripherals will be added from time to time.


2.6.5.1  Keyboard


Device Type Code  10   

Device Parameters

Parameter string  Description            Default

    KG=stringKey groups defined by string:(No default)
        "1":Programmable function keys
      "2"  :Alphanumeric keys
      "3"  :Special keys
      "4"  :Cursor control keys
      "5"  :Formatting keys
      "6"  :Labelled function keys
      "7"  :Numeric keys
      "ALL":All keygroups

    AN=LA1 StringAlphanumeric keygroup according "LA1"
      to Latin Alphabet/1

    HE=StringHelp key present; label defined
      by stringNo Help key

    HE  Help key present; label is iconNo Help key

    ME=StringMenu key present, label defined
      by stringNo Menu key

    HO=StringHome key present; label defined
      by stringNo Home key

    RE=StringReturn key label identified byIcon or blank
      string

    LA#nAuto Repeat latency in ms (No default)
      given by n 

    RP#nAuto Repeat interval in ms(No default)
      given by n 
     en by n -



Appendix VII.3  Real-time File Handling


      3.1 General overview

      3.2 Application 1: Multiple Audio Channels

      3.3 Application 2: Video Animation

A VII.3  Real-time File Handling


3.1  General Overview


A CD-I application is  made up of a  set of real  time and non-real   time 
segments.  Typically, the non-real time segments are used for  interaction 
with the user to determine the next real time segment to play, although  a 
real time segment may also contain provisions for interaction.

In order  to  play a  real  time record  on  disc,  an application    must 
initialize several structures and  set up an intercept  routine to   parse 
incoming signals.  The signals sent to an application will include   those 
indicating End-of-Record, End-of-File, Buffer Full and the presence of   a 
trigger bit in a  sector.  These signals may  be used to  synchronize   an 
audio/visual effect or to  simply let the application  know the state   of 
the "play".

There are two primary structures that an application will need to set   up 
and one connecting structure that ties the two together. The two   primary 
structures are the Play Control Block and the  Play Control List.    There 
is only one Play Control Block for each  Play operation.  A Play   Control 
List is created for each channel of Audio,  Video, or Data sectors   which 
will be transferred to memory.  Audio sectors transferred directly to  the 
Audio processor do not need an associated PCL.   Since the PCB has    only 
one field each for Audio, Data and Video sectors, the third structure,   a 
CIL, is used to create an array of  pointers to PCL's for the PCB.     The 
channel number of the sector is used as an index into the CIL to find  the 
appropriate PCL.

In general  it is  recommended to  group non-real  time  sectors at    the 
beginning of real time  records.  This type of  data may be    information 
about the file organization,  CLUT values, premastered LCT's  or   program 
data.  This type of data should be protected  using mode 1 sectors    with 
ECC.  In addition, the data should be duplicated where possible.

Real time sectors contain Audio, Video and Program  Data that are to    be 
played back synchronously.   Audio data  can be output  directly to    the 
audio processor or can be transferred to memory.  Video and program   data 
are always transferred to memory.

Each sector is coded with a channel number  that can be used to   identify 
related sectors.   There  are 16  audio  channels and  32  channels    for 
video/program data.  The application controls which sectors are   accessed 
using two flags in the Play Control Block.  PCB_Chan is used to   identify 
which channel numbers  are significant.   PCB_AChan is used  to   identify 
which audio channels will be sent to the audio processor.  Each of   these 
flags is a bit-mapped value, i.e. each bit represents a channel.


In a typical application, a real time record would contain an audio  sound 
track accompanying a series  of images.  When a  video buffer is   filled, 
the associated image is displayed and a second buffer is used to load  the 
next image.  We will now look closely at two specific applications   which 
demonstrate some  simple  Real  Time  Record  handling    mechanisms.3.2   
Application 1: Multiple Audio Channels


This application is a multi-lingual real time record.   While images   are 
viewed on the display, a sound track explains  the images.  At any   time, 
the user may  select one  of three languages  to listen  to.  The   change 
should be instantaneous and seamless.

This is implemented using  one video channel and  three audio    channels. 
The video data is placed in channel 0.  Channels 1, 2 and 3 are used   for 
audio data.  Since audio data must appear at a constant rate, the   layout 
of audio sectors is determined first. If B level stero ADPCM data is  used 
for all three  sound tracks  the initial sector  layout would  appear   as 
follows:


 _A1_A2_A3_  _A1_A2_A3_  _A1_A2_A3_  _A1_A2_A3_  _A1_A2_A3_  _
 _____________________________________________________________


The video data would just have to fit in every fourth sector:


 _A1_A2_A3_V0_A1_A2_A3_V0_A1_A2_A3_V0_A1_A2_A3_V0_A1_A2_A3_V0_
 _____________________________________________________________


This would allow loading of a full screen DYUV image every 2-2.5  seconds, 
depending on  the  image encoding  format  (PAL/NTSC). The  formula    for 
determining this is

           ((width * height * pixel depth)/2324)*(13ms * 4).

The Chan and AChan masks are set initially to transfer audio channel 1  to 
the audio processor.   When the user wishes to  change the language,   the 
application sets the Chan and AChan masks to transfer either channel 2  or 
3 to the audio  processor.  The video always  stays in channel  0 and   is 
always transferred to memory.

No PCL's are needed for the audio sectors since none are ever  transferred 
to memory, but two will be used for the video data. They are set up in   a 
circular list each pointing to the other, so  that they will be   accessed 
alternately.  One will contain a pointer to a  drawmap for plane A,    and 
one will contain a pointer to a drawmap  for plane B.  As each buffer   is 
filled, the application  will get  a signal indicating  to display    that 
image.



             _______
                  _  P  _____ Chan  = $0000 0003
             _     _
             _     _____ AChan = $0002
             _  C  _
             _     _               ______     ______
             _     _____ Data _________________P   _
             _     _                          _ C  _
             _  B  _                          _  L _
             _     _                          ______
             _     _____ Audio = Null
             _     _
             _     _               ______     ______    ______
             _     _____ Video ________________P   _    _P   _
             _     _                          _ C  _    _ C  _
             _     _                       ____  L ______  L __
             _     _                       _  ______    _______
             _______                       ____________________

                    3.3  Application 2: Video Animation


The focus of  this second  application is video  animation.  There  is   a 
single audio  channel  and two  interleaved  video channels.  One    video 
channel contains DYUV images  loaded into plane B  as backgrounds.     The 
second video channel contains runlength images which are updated   rapidly 
in the foreground  plane. If  all of the  runlength images  use the   same 
CLUT, then the CLUT  would be placed in  a Mode 2  Form 1 non-real    time 
sector of the beginning  of the Real Time  Record.  If a  unique CLUT   is 
needed for an image, it should be placed  in a Mode 2 Form 1 real     time 
data sector immediately preceding the associated run length  image   video 
data.

In this example, there are two types of  data which need to be spaced   at 
specific intervals.  The audio data will require regular spacing and   the 
run length video data will need to be spaced evenly to give the  animation 
a smooth flow.

If the sound  quality level  is B mono  and the  run length  images   were 
between 1 and 4  sectors in length, you  might see a  sector layout   like 
this:


     _A0_D0_V1_V1_V1_D0_V1_V1_A0_V1_D0_V1_V1_V1_V1_V0_
     _________________________________________________......
                  T              T              T

     _A0_D0_V1_V1_V0_D0_V1_V1_A0_ 
.....____________________________
               T              T


This allows the video to be updated at 15 frames per second.  By   placing 
a trigger bit in every 5th sector, the  application can be notified   when 
it is time to display a new image.  By updating a smaller portion of   the 
image or updating at a slower frame rate, the application can allow   more 
room in the  Real Time  Record for background  video data  or larger   run 
length images.

If a single runlength picture is greater in  size than the allowed    four 
sectors, it might have to be put into a different channel, thus   allowing 
the application to put  one or more of  the sectors into  an empty   space 
where another image used less than 4 sectors.

The PCB_Chan  mask  in this  specific  example would  be  set  to   access 
channels 0 and 1.  AChan would reference channel 0.

             _______
           _  P  _____ Chan  = $0000 0003
             _     _
             _     _____ AChan = $0001
             _  C  _
             _     _____ Audio = Null
             _     _               ______     ______
             _  B  _____ Data _________________P   _
             _     _                          _ C  _
             _     _                          _  L _
             _     _                          ______
             _     _
             _     _               _______     ______    ______
             _     _____ Video _____  0  _______P   _    _P   _
             _     _               _______     _ C  _    _ C  _
             _     _               _  1  __ ____  L ______  L __
             _     _               ________ _  ______    _______
             _______                      _ ____________________
                                          _    ______    ______
                                          ______P   _    _P   _
                                               _ C  _    _ C  _
                                            ____  L ______  L __
                                            _  ______    _______
                                            ____________________