Bringing Multimedia to the Falcon

Do you remember that Atari advert from a few years back? The one with 
the squiggly symbols of an eye, ear and mouth and the copy that read 
something like "If you can understand this you understand the Falcon"? 
Except, of course, that nobody did understand it and therefore didn't 
buy a Falcon. I am reliably informed that what this advert was trying 
to convey was that the Falcon was a good multimedia computer. At the 
time, multimedia was the up-and-coming industry buzz-word and is up 
there still, vying for the top spot with "Internet". So what exactly is 
multimedia? So far there hasn't been a definition that everybody agrees 
with but basically it means conveying a message using a number of 
different methods or media. On a computer this generally means text, 
sound, graphics - both still and moving, and movies: moving pictures 
with soundtrack. It's been around for ages but has only had a name for 
the last few years. To begin with, whilst everybody agreed it was 
pretty neat, nobody could come up with a use for it. These days it has 
found its niche in education and training where it is very effective 
and cheap. It may cost a lot to get a professional company to put a 
multimedia package together for you but once it's done, you can use it 
over and over without having to employ one of those nasty expensive 
human teacher things.
So,  how does the Falcon shape up as a multimedia computer? Compared 
with the 386 PCs that were prevalent at the time of its launch (1993) 
surprisingly well is the answer. Even today, whilst nowhere near as 
fast as the current Pentium's, it can still do a good job. The reason 
is that TOS is a very small and streamlined operating system compared 
to the competition, so where PCs and Macs expend a lot of their energy 
dealing with a monolithic operating system, Atari's' just get on with 
the job. Although they are considerably slower on paper, a bog standard 
Falcon in use feels about as fast as 50 or 60Mhz 486 PC running 
Windows. And if you accelerate it....

The Falcon specification is geared toward multimedia. The sound system 
is as good as any of the sound cards currently available for the PC and 
it comes as standard which means that programmers can rely on it being 
there. The video system is capable of up to 16-bit colour which, whilst 
not in the same league as the 32-bit video cards currently available 
for PCs is still pretty good and in use it is very difficult to tell 
the difference between 16 and 32 bit colour. The DSP chip is a big plus 
too and where it is used to good effect, such as in Apex Media, it is 
simply stunning. All - in-all, the Falcon can hold its head up in the 
company of other computers and say "I can do that and I'm only running 
at 16Mhz."

MultiPlicity, the Concept
It was with the above in mind that I set forth to write MultiPlicity 
about 18 months ago. MultiPlicity, for those who haven't come across 
it, is a multimedia authoring package for the Falcon. It allows you to 
put a multimedia presentation together for whatever purpose you like. 
The presentations are based on a book metaphor. Each presentation is 
called a Book and each screen within that Book is a Page. Once's the 
Book is built, the user simply clicks on an icon on a Page and and a 
multimedia event starts. That event could be a sound sample, a window 
full of text, a picture being displayed or an animation playing. Other 
buttons change to other Pages with even more events within them.

There were a number of reasons I chose to write MultiPlicity and, 
strangely, none of them were money. Firstly, although there were a 
number of programs around that showed that the Falcon was capable of 
multimedia by playing animations, displaying full-colour pictures, 
playing sounds, etc. there was othing available that could pull all 
these threads together into a coherent whole. This is something that 
users of PCs and Macs take for granted with everything from small PD 
and shareware utilities to huge and expensive professional programs 
such as Macromedia Director being available. Secondly I wanted to prove 
that the Falcon was capable of this too. The Falcon as a multimedia 
platform would be a relatively low-cost solution compared to PCs and 
Macs.

I'd like to tell you that these were my only motives in writing the 
program and I am a great philanthropist and an all-round warm and 
cuddly human being. Unfortunately, this isn't true and, if it weren't 
for the third reason, it is doubtful that MultiPlicity would have been 
created at all: As a student studying Computer and Information systems, 
I had to do a computing project for my final year at university.

Of course, that doesn't explain why I chose to do my project on the 
Falcon rather than a PC and therefore improve my job prospects 
somewhat. For that I will have to tell you a little about myself. I was 
not the average 22-year-old undergraduate with no ties. I was just 
about the right side of 40 with a wife and three children. Every day I 
commuted the 25 miles from the family home to university in Brighton. 
All my meagre grant (and more) was taken up with travelling and 
child-care costs so, given the choice of going into university every 
day, battling to get a PC and trying to work in a noisy crowded 
computer room or staying at home and working on my Falcon whilst being 
able to keep an eye on the kids, guess which I chose. From the point of 
view of project quality I believe I made the right decision. 
MultiPlicity took my degree from the 2.1 I was looking at at the end of 
the exams to a 1st I now work as a multimedia programmer on PCs, a job 
I got partly as a result of the interviewers seeing a half finished 
version of MultiPlicity 2 so my choice of platform made very little 
difference in the end.

Putting It Together
What follows is not a definitive guide on how to write software, 
although it does contain some good ideas - sadly few of which are mine. 
It is a brief resume of how I went about creating MultiPlicity. Some of 
the procedures were imposed upon me by the university insisting that I 
hand in documentation as well as the finished product and some of that 
(such as code size estimates) was a complete waste of time and will 
therefore be omitted here.

I began programming in Basic on a Spectrum in 1984 and took my 
knowledge of the language to the ST four years later. I did a fair 
amount of programming on the ST, mostly in STOS and Hi-Soft Basic, 
learned Pascal with the Open University and C under a DOS environment 
during my university placement year. It was during that year I bought a 
second-hand Falcon. I also acquired a reasonably good knowledge of how 
TOS machines worked, having used them extensively since 1988. By the 
time I came to the project I felt I had most of the skills I required 
to succeed except one: GEM.
I had dabbled with GEM programming a little under Hi-Soft Basic but 
never really got into it. I therefore purchased a copy of Clayton 
Walnum's C-manship Complete and spent two weeks going through it 
learning how to program GEM in C. It's rather outdated now. Published 
in 1990 and based on magazine articles even older, it pre-dates the STe 
let alone the Falcon. Nevertheless it taught me a lot. Incidentally, 
it's a good book to begin learning C with too since the first quarter 
is devoted to the basics of the language with no intrusion from GEM. 
Armed with this book, the Lattice C manuals and the Atari Compendium I 
was ready to create my first proper GEM application.

Every article I have ever read on programming tells you that the first 
thing to do is switch off your computer. This one's different. The 
first thing to do is plan what you want your program to do and there is 
no reason why you can't use your computer to help with this. The first 
thing I created was a Requirements Document. This, as its name implies. 
is a document listing what you require the program to do and there's 
every reason for using a word processor to create it. It allows you to 
insert things as you think of them and gives you a nice readable 
document to refer to later and to update eaily as necessary.

The Requirements Document for MultiPlicity had the following main 
headings:
** BL **
* Introduction: where the general intention of what the program is to 
do is outlined.
* Hardware: the minimum hardware requirements for the program to 
operate.
* Functions: for MultiPlicity, this was by far the longest section. It 
listed everything that the two programs should do and included things 
like file and page creation and operational requirements such as the 
ability to save a file to disk and load it back in.
* Constraints: in MultiPlicity's case, this stated that the programs 
should use GEM and that, since a multitasking system was highly 
desirable, it should check for the presence of one and act accordingly.
* Test Data: how the program would be tested.
* Future Enhancements and Developments: things you can envisage being 
in future versions of your program but not the first version. For 
MultiPlicity, this included 16-bit stereo sound (included in version 2) 
and the use of Speedo-GDOS fonts in text windows.
** BL end **

The Requirements Document should set out what the program is to do, not 
how it should be done. So, for example, the Requirements Document for 
MultiPlicity stated the general purpose of the program and that two 
executables would be created. It also said that the user interface 
should fully utilise GEM. One important use for the Requirements 
Document is that it allows you to separate what is necessary, or 
required, for the program to function from would is desirable or nice 
to have. An example of a required function would be the ability to load 
and display text files. A desirable function might be the ability to 
display those files using GDOS fonts. It would look pretty but adds 
nothing to the software's functionality.

Another important function of the Requirements Document is to set the 
scope of the project and define the boundaries. In the case of 
MultiPlicity, this was essential. With a multimedia authoring package 
the sky is more or less the limit as to what can be included. Many of 
the high-end programs incorporate art packages, sound editing modules, 
animation studios, word processors, etc. The introduction to 
MultiPlicity's Requirements Document specifically states that 
MultiPlicity would be a skeletal system with no facilities to create or 
edit elements. There were a couple of reasons for this: the most 
obvious was that I only had 15 weeks to complete the project and 
including all or any of the above would not have been possible in the 
time. The other reason was just as important though. There are plenty 
of dedicated programs around for these tasks that can do the job far 
better than anything I could create. Why reinvent the wheel?

On the subject of not reinventing the wheel, one of MultiPlicity's core 
requirements is to be able to call external programs to run multimedia 
events. So, for example, to display a GIF picture, the Apex GIF viewer 
might be called together with the path of the GIF file. Again, this was 
born out of a ack of time but I think now it is better than using 
built-in routines since it allows more flexibility. If Doug Little 
updates the GIF viewer, the user simply replaces the old version with 
the new. As far as MultiPlicity is concerned, nothing has changed but 
every time a GIF file is displayed the new improved software is used 
instead. By the same token, at the time I wrote MultiPlicity, no decent 
AVI or Quicktime player was available. Now one is (Movie Player) it can 
be utilised within MultiPlicity without me having to change a line of 
code. Movie Player is actually fairly unique in that it allows you set 
switches in the command line passed to it. At the moment MultiPlicity 
doesn't really cater for this but the facility will be added in the 
next version. The use of other programs to perform certain tasks was a 
fairly radical (though not unique) idea when I first made the decision 
to use it.
It's now more commonplace - the Thing desktop is a good example - and I 
suspect it will increase in popularity.
Not everything in MultiPlicity uses external applications. There are 
internal routines for handling IMG graphics files, AVR sound files, and 
ASCII text files. The main reason for this was to give me experience at 
programming using these types of files - one of the learning objectives 
I cited to the niversity in the feasibility study for the project. Of 
these, only the graphics handling is essential since it is needed for 
page backgrounds and icons, although I think the audio part is pretty 
cool too since it utilises the Falcon sound system, something few 
external players do. Both of these routines were improved (to colour 
and 16-bit stereo respectively) in version 2. All this was in the 
Requirements Document and ensured that I didn't accidentally go off and 
code a FLIC movie player or something equally time consuming.
Finally, by listing the actual functions of the program in the 
Requirements Document, these translate almost exactly into menu 
options, which helps greatly with program design. In MultiPlicity, for 
example, part of the Functions section was:
"Operational Requirements
File Operations
Create a new Book
Open an existing Book
Save a Book
Quit"
This translated itself into the File menu which, in the finished 
product, looked like this:
New Book
Open Book
Close Book
Save
Save as...
Quit
As you can see, the menus are derived almost directly from the 
requirements document with a lot of the program's functionality 
deriving from the menus. Two new options have been added here but they 
are a reasonably natural progression from the original requirements. 
They also prove that these things need not be set in stone but merely 
used for guidance.
The Requirements Document is probably one of the most important 
documents you will create and it's worth referring back to at regular 
intervals. It will ensure that you remain on track and that you don't 
miss anything important.
So, ready to start coding yet? Everybody yells "NO" but I say possibly, 
although not the actual project. If, like MultiPlicity, your project 
relies on coding something you are not sure about, it is worth spending 
time now to try out a few idea and see if they work. In MultiPlicity's 
case, it relied n its ability to call other programs to run 
concurrently with MultiPlicity. My original plan was to use Pexec(), 
which is the time-honoured way of calling programs from within others. 
This, though, proved to be not what I wanted since the calling 
application is frozen until the called application quits. I eventually 
used shel_write() which is the method used by desktops and worked well 
under MultiTOS and Geneva - when I started the project a Falcon 
compatible MagiC was not yet available. Once I was sure that this 
essential part of MultiPlicity's functionality could be achieved, I 
felt reasonably confident about the rest of the system too.

Designing the Software
Once you know what the software is supposed to do, it's time to decide 
how it's going to do it. There are lots of different methods for 
designing software and, given that nobody is imposing a method upon 
you, it really comes down to individual taste as to how to go about it. 
One thing I would recommend though is to take a top-down approach. 
Design the software at a superficial level first going into detail 
later. So, for example, if you want to open a window, at the top level 
you would simply write "Open Window". Later you can add the details of 
how this is done. This means that you won't get bogged down with detail 
when you are still trying to work out the program flow.
Personally, I use Thought! from Titan Designs for this. It's a bit 
pricey but makes the whole thing really easy to do. It uses Jackson 
structures so that you can design the software as a diagram. I learned 
about Jackson structures at university but if you haven't come across 
them before they are explained quite well in the manual. At the end of 
the design process, the whole thing can be output to printer either in 
its diagrammatic form or as pseudo code that can be more or less 
directly translated into the language of your choice (assuming that 
your design is detailed enough). Thought! can also be used for planning 
projects other than software. I use it all the time as an outliner for 
writing longish pieces such as the one you're reading now.
The best low-cost solution is to write pseudo code directly using a 
word processor or text editor. Most people have a word processor and if 
you're a programmer, you probably have a text editor too. Pseudo code 
is similar to real code except that you don't have to worry about 
syntax. It works something like this: at the top level you would write:

1	Open Window
Later you would come back and more detail
1.1	Create window
1.2	Open the window
Going down a further level may yield
1.1.1	wind_create( window 1 )
1.1.2	wind_set( title = "Window 1" )
1.2.1	wind_open( window 1 )
At this stage, the commands are almost in C and, apart from fleshing 
them out with the correct parameters (which could be done here) there 
is little else to do but write the actual code.
It's also worth trying to identify parts of the program that could be 
reusable, not just in the current project but future projects as well. 
A good example of this is GEM initialisation. All GEM programs have to 
be initialised and by and large the code is almost identical every 
time. I have written module that can be linked into every GEM program I 
write. It contains stuff like the initialise and shutdown GEM routines 
as well as code for loading and initialising resource files, setting a 
window's title text and info line text and some general window handling 
routines. It's all fairly common stuff and once written need never be 
written again.
Finally, the user interface needs to be designed. For a GEM program you 
can kill two birds with one stone here by designing the interface 
straight into a resource construction program. I used WERCS, which 
comes with Lattice C, for MultiPlicity, but now use Interface 2, which 
I got from Compo before hey went the way of the Norwegian Blue. I'm not 
sure if there is a UK distributor for it any more but it's well worth 
hunting down. Once the interface is designed, it is also ready to plug 
straight into the program code.

Writing the Code
Writing code is a fairly individual thing and what works for me may not 
work for you. However, there are a couple of things that are always 
worth saying. Code should be structured to be as readable as possible. 
Use indenting if your chosen language allows it and don't be afraid to 
leave blank lines n order to separate different parts of a function. 
Always liberally sprinkle your code with comments. I know it's a pain 
but while it may be obvious today what that bit does you can bet it 
won't be next week/year when you need to go back and change it. The 
point here is to make the code as readable nd understandable as 
possible. Try to imagine that someone else is going to take over the 
project at a later date and will need to understand how it works.

For MultiPlicity I used an approach of incremental prototyping. What 
this means is that I would code a part, then compile and test it. On 
paper, this is quite a slow and cumbersome method of programming but in 
practice I found it works really well. You get to see the results of 
your work fairly quickly and there is always something new being added 
to keep your enthusiasm for the project going. Additionally, the 
debugging is kept to bite size chunks rather than trying to wade 
through 5,000 lines of source code trying to find your logic error. It 
also dictates, to a certain extent, the order in which things should be 
done, which saves a bit of thinking. Using this method, the first thing 
that needs to be created is the user interface since you cannot test 
anything else until you can operate it. For a GEM program this is 
fairly straightforward since you will have already constructed the 
resource file (which will undoubtedly change but it's something to work 
with). To begin with only the menus need be implemented and even they 
do not have to point at code that actually does anything, merely a 
dialog box saying something like "Option not implemented yet" just to 
prove to yourself that the menus work. Before you run your program 
shell though, one enu option must be implemented: the "Quit" option. If 
it isn't, you won't be able to get back out of your program. With 
MultiPlicity, from this point, everything else just dropped into place. 
I simply coded and tested each menu option until the package was 
complete.
If your chosen language allows, it's well worth splitting your program 
into modules. If you've never done this before it really isn't that 
hard. There is a slight overhead in administration but it is more than 
made up for by considerably reduced compilation times since only the 
changed module needs o be compiled rather than all the code. 
MultiPlicity's source code consists of a number of modules: a main one 
for each program, graphics, audio, text, one that handles all the 
elements, and a shared module that contains code used by both programs 
as well as the GEM toolbox mentioned earlier that isn't specific to 
MultiPlicity.

Testing
Once the program is complete it's time to move onto testing. You will 
have tested it yourself but you can be sure that someone somewhere will 
do something that you wouldn't have thought of in a million years and 
that something will cause a crash. There's no such thing as bug-free 
software but the more it is tested, the more of the little blighters 
will be eradicated.
Test the whole thing yourself - thoroughly. Do stuff that you thought 
only the village idiot would do on a particularly stupid day. Get 
friends and family to test it. My insurance agent tested MultiPlicity 
one Sunday morning and he bought along his neighbour, a complete 
stranger to me, who tested it too. Get everyone you can to try it out. 
I had about half a dozen bugs manifest themselves this way.
The best way though is to get beta testers. If you're on-line this is 
relatively easy - just ask on your local BBS and send all respondents a 
copy to try. Lots of people are happy to help in this way because they 
like to be involved. The Atari community is brilliant like that. That's 
one of the things that makes it worth writing software for the Atari, 
even if you don't get paid.

Continued Development
No program is ever really finished. There is always more you can add if 
you wish and there will always be bugs to fix. The first complete 
version of MultiPlicity (1.03) was released in May 1996 and I have to 
admit I more or less ignored it for a long time only coming back to it 
at the beginning of this year. The main reason for this was that there 
were two primary things I wanted to include in the next version, 
neither of which I had the foggiest notion how to do. One was to 
upgrade the internal graphic support to include colour and the other 
was to include better support for MagiC. MagiC uses different method to 
MultiTOS and Geneva in order to launch programs concurrently and I 
couldn't find out what it was. MultiPlicity 1.03 uses the AV protocol 
under MagiC for this but that really only works with a good AV server 
such as Thing installed too. Once I had the required information to 
implement both of these features (and more) work began on version 2 of 
MultiPlicity, released about three months ago. The original version was 
functional but, even though I say so myself, the new version is much 
improved and capable of much better results. Up to version 1.03, 
MultiPlicity was free to anyody who wanted to download it. This seemed 
fair to me since I had to write it anyway. Sadly though, version 2 is 
shareware - a bargain at just œ15! This time all the work was carried 
out in my own time with only my own desire to improve it as impetus to 
continue development. I've got to pay for that memory upgrade and 
additional hard disk somehow. Nemesis would be nice too.

Finally, if you are a MultiPlicity user, the e-mail address in the 
documentation for the earlier versions is no longer in use since I am 
no longer at university. You can now contact me with bug reports, 
suggestions, offers of cash, etc. at

mtidd@fffnet.demon.co.uk

** Images **
** 0001.GIF **
New, improved Edit Page Object dialog

** 0002.GIF **
Page backgrounds can be in full colour

** 0003.GIF **
Internal graphics routines can also show images in a window

** 0005.GIF **
Pictures can be enbedded in page backgrounds

** 0006.GIF **
New colour animated icons for both links and objects