"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
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
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".
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.