Skip to main content

 "To be immortal you've got to be dead."
                                Gyles Brandreth, "The Joy of Lex"


                     THE PHILIPS CD-i SYSTEM
                       by Stefan Posthuma

 Autumn 1992,  a new system was introduced. It was supposed to be
a  full  multi-media,  CD-based system that would  cause  another
revolution  in the home electronics market.  Multi-media  was  no
longer the territory of the expensive workstations and  souped-up
PCs,  now  you could buy a small box that could do it  all.  Just
hook  it up to your TV,  slip in a disc and off you go  into  the
wonderful world of interactive television.
 The company I work for,  SPC Vision, decided that their time had
come  to plunge themselves into a new  market,  and  maybe,  just
maybe ride on the trail of the comet to fame and fortune...
 Around May of that year,  the plans became serious enough to  do
some  thinking about what exactly we were going to do on  it.  We
didn't  know  anything  about it,  except that  it  had  a  68000
processor.  In  my enthusiasm I told people here  that  providing
there was a way to do straight 68000 on it,  I could do something
interesting.  They  agreed and I organized my buddy Tim  Moss,  a
rather  skilled  68000  programmer.   In  July,  the  first  CD-i
development  system was brought into the office and we  were  let
loose on it.

 So what is it exactly?

 A CD-i is basically a full computer system with an 68000 running
OS/9 as its basis.  The 68000 runs at a not very reassuring speed
of  7Mhz,  mostly  because  the video hardware steals  a  lot  of
cycles.  It has one megabyte of RAM,  this is separated into  two
banks of 500K,  effectively you have 480K free per bank.  It uses
the CD as a read-only hard disk,  and the CD has 650Mb of storage
space. There's a serial port on the back of standard CD-i players
so  you  can  hook it up to a PC or some  serial  device  like  a
printer.
 The most interesting bit of the CD-i is it's video hardware.  It
has  four independent planes,  one background  plane,  one  mouse
plane (both aren't very interesting because there is very  little
you can do with them) and two graphics planes.  These two however
make things interesting.
 Every scanline of the graphics planes has a list of eight  video
instructions associated with it. The video processor has a set of
instructions  that are used to set the various video  parameters,
including   graphics  address,   video   coding   method,   image
contribution factor and a lot of others.
 The  fact  that  you  can set  the  graphics  address  for  each
scanline,  and that there is a byte/pixel mode means that  smooth
scrolling  is  ridiculously  easy.  Just update  a  few  graphics
addresses here and there and things scroll effortlessly.
 It also has quite a few graphics modes.  CLUT7 for example is  a
byte per pixel 128 colour mode.  We use this one for most of  the
games  we  do on CD-i.  But there also is  something  called  Run
Length  7,  128  colour run-length encoded  graphics.  The  video
processor decodes the graphics real-time. This is mostly used for
playing cartoon-like graphics sequences directly off disk.
 Then  there is a mode called DYUV,  where it stores  the  colour
differences between pixels.  This is used to display  true-colour
digitized pictures,  and we did some very interesting 16  million
colour plasmas on it. And the RGB mode stores the direct R, G and
B values for each pixel for even higher quality pictures,  but it
uses  both  planes  so it limits the  possibilities  a  bit.  All
graphic modes use a resolution of 384 * 280 (on PAL) pixels.
 The two plane business is neat too,  one plane can sit in  front
of  another one and with transparency colours and the  fact  that
both planes are totally independent and that every scanline could
have a different graphics mode if you want, you can get some very
nice effects indeed.
 But there are lots of drawbacks too.  For example the kernel  is
very slow.  It's written in C,  we did some disassembling and the
code is horridly inefficient.  This is almost unacceptable for  a
system like this,  but there is no way around it.  If you want to
access the graphics hardware,  you have to go through the kernel.
There are no direct addresses you can modify or  anything.  Also,
the  OS/9  with  its interrupt and  multitasking  structure  sits
between your program and the CD-i, slowing things down even more.
 Also,  the audio is very limited. It's very nice in one way, you
can play Red Track 44.1 Khz stereo CD quality music directly from
the disc without loosing any processor time, but that's about it.
There is one channel for audio,  and unless you revert to complex
and  slow sample mixing techniques,  you have one  channel  only.
Writing a game with both music and sound effects is very hard!
 Also,  the  minimum  sample rate for sound effects  is  18.9Khz,
which comes down to about 10K per second.  Since you only have  a
megabyte of RAM and the average screen quickly takes up 100K  (on
a  typical CD-i game,  you'll use one background screen  and  two
sprite screens that are flipped, there goes another 300K), having
many sound effects in memory is impossible.
 Another major shortcoming is that there is no blitter, no sprite
hardware!  This  means  that  all sprites  have  to  be  software
generated, and this means a lot of CPU goes into drawing sprites.
We  wrote  a highly advanced optimizing  graphics  compiler  that
generates 68000 code, with this it is possible, but sprites still
take up most of the CPU time in a game.
 For  a  while  now,  the Full Motion Video  extension  has  been
available.  It's  basically  an MPEG decoder that reads  an  MPEG
stream  directly off the disc and displays it in  the  background
plane.  MPEG  is an advanced moving video encoding  method,  with
this  it's  possible to play full screen video at 25  frames  per
second  off  disc  at a 150K per second  transfer  rate.  So  the
average  frame size is 6K!  And mind you,  this includes  44.1Khz
sampled music as well!
 This  looks very impressive,  and if the video has been  encoded
well,  the quality is astounding.  You have full control over the
video,  so it's like having a digital video recorder.  The CD can
store  about 70 minutes of Full Motion Video,  and a  few  motion
pictures have been released already.  So you'll have your  movies
on a double CD-i instead of analog video tapes!
 It  is possible to do games with this,  but since the  video  is
non-interactive, it's hard to make a good game. But if you use it
merely as a background, you can make things look very good.
 One  last  drawback  I'd like to mention is the  fact  that  the
standard controller you get with any CD-i player is quite frankly
a  piece  of  shit.  It's a  remote  controlled  analog  joystick
basically  and  it's slow and inaccurate.  We found out  that  it
transmits  a  packet of coordinates about forty times  a  second,
slower than the VBL!
 There  are other devices available like a mouse  and  trackball,
and recently a joypad which is quite good. But any game will have
to be designed with the remote controller in mind.

 The  conclusion of all this is that the CD-i is a  nice  machine
but  its hardware is a bit dated.  It has potential,  but  simply
misses certain crucial things like a fast processor and a  decent
blitter.  The  system is great for interactive applications  like
courseware,  demos  for  exhibitions  and  fairs,  adventure-type
games,   anything  really  that  doesn't  need   high-performance
hardware.
 Here at SPC we write business applications on it, like a driving
test with video instructions,  an exhibition question-and  answer
game,  and  so  on.  But we also write games,  with the  ST  demo
backgrounds of the people that work here,  we can do pretty  well
for CD-i standards.  But it's hard work,  it takes a long time to
write a decent game,  and because there is a wide variety of CD-i
players,  each with their particularities,  the testing phase  of
complex assembly games is long, very long.

 Soooo....what's the bottom line?

 If  you want a nice machine just for games,  forget about  CD-i.
Get  a  Super  Nintendo or something.  Or wait a bit  and  get  a
Jaguar.  But  if  you want something more,  the ability  to  play
digital  video,  and a big range of non-game  applications,  then
CD-i becomes interesting.  Also,  there are some decent games  on
their way, I just finished my "Steel Machine", an "Uridium"-based
shoot-them-up  with  brilliant graphics and  great  music.  Quite
funny, the graphics were done by Niklas Malmqvist (Tanis from the
CareBears),  the  music  by Dave Moss and Marc Palmer  (Spaz  and
Sprog from the Lost Boys) and the coding by myself (also  ex-Lost
Boys).  Furthermore, Tim Moss works here (ex-Lost Boys) and Arjen
Wagenaar  (SOD) is also one of our 68000 coders.  Then  there  is
Michael  Hildenborg (Flying Egg from Omega) who  does  occasional
work  for us.  Loads of Atari demo scene people are  involved  in
CD-i here,  and there are two TTs in this office,  they are  used
for most supporting tasks like map-editors,  graphic  conversions
and our sprite code generator and graphics grabber runs on them.
 SPC also did "Dimo's Quest",  a puzzle game and some more  stuff
is being produced,  a car racing game called "Accelerator" and  a
very ambitious platform game, named "The Apprentice". 

Disclaimer
The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.