🚀 go-pugleaf

norbert_h@et.tudelft.nl writes:
: 
: 
:   I am involved in programming CDI using BALBOA version 1.2x, but I
:   never saw any complete (and working) examples made by experienced
:  programmers. We work on a SUN platform, using a C cross-compiler for
:                       the OS-9 (CD-RTOS) system.
:
:                I am interested in examples concerning:
:
The best I can give is some hints on how some of what you are asking for
works and a few things to be avoided. You don't say how much you know about
CD-I. I apologise if I am repeating things you already know.

:                1: audio channel switching during a play

Sorry, can't help you on this one. The main problem is getting the channel
switch seemless, that requires playing all audio through memory and is not
something we have done here.

:               2: usage of records within real time files

The best usage of records in real time files is to guarantee that a real
time file play stops at a particular point. You do this by specifying the
number of records to play and once that number of end of records have happened
the play is stopped automatically by the device driver. This number of records
is the rec_count parameter on the pml_play function call.

Otherwise the end of record ( EOR ) marker and the trigger marker are very 
similar. Generally it is a good idea only to use either triggers or EORs
and not both since nasty things can happen if you get lots of signals
flying around. 

The reason for this is fairly deep. If you are interested the problem is
that at the CDRTOS level the same signal number is generated for both 
triggers and EORs. The only way for the application / Balboa to tell which 
happened is to read a field in the play control block. This field is 
over-written each time a new sector comes in from the disc. So if the signal 
for a trigger or EOR is delayed more than 1 sector time ( 1/75th second ), 
the bits in the status field which show what happened may have been 
overwritten and the application / Balboa won't be able to tell why the
signal was generated.

:                           3: usage of mattes

Look on pages 6-38 and 6-39 of the Programmer's Guide, volume 1 for some
example code for static mattes. What isn't obvious from the manual is that
after using static mattes, you need to use ma_disable() before you can start
using the video effects library since the two uses of mattes are just 
incompatible.

:        4: management of large hotspot structures (dynamical ?)

I haven't got any example code for this. If you look at the latest Philips
CD-I player based design tools, they have use a user interface manager which
is based on Balboa and depending on the tool, can ( and do ) use large, 
complex and dynamic hot spot structures.

:                              5: animation
:                6: usage of run-length encoded pictures

One of the most common forms of animation is playing run-length encoded
cartoons from the disc ( like the Cartoon Jukebox disc ). There are many
ways of doing this. The only source code I have lying around is for the
previous version of Balboa. The best I can do is some comments on some
of the basic principles of the simplest possible approach to this.

The simplest case is where all the frames of the animation have been
padded out to be the same size. To play this, start with 3 buffers each
big enough to hold the standard frame size. Each buffer should have a
callback on it ( the userfunc parameter on pml_add_buffer ) so that you
know when that buffer has been loaded. That callback will handle the 
displaying of that frame of the animation.

The 3 buffers need to be an integer multiple of the CD sector size, 2324. 
These 3 buffers could be Balboa pictures, created via pi_create() or parts of 
one or more full screen pictures which are used elsewhere in the application 
( this is a good idea since it reduces the risks of memory fragmentation ). 
To declare these buffers to the play manager, use pml_add_buffer().

For the video side, the simplest case is where the cartoon will take the full
screen area. In this case the best way to display each frame is using the
CDRTOS dc_wrli() call. The Balboa video manager call vs_update() is far too
general purpose for this.

Before you display the first frame, you need to get the display setup in
runlength mode. There are a number of ways to do this depending on what your
creative people want the transition into the cartoon to look like. The simplest
one is a straight cut to the cartoon as soon as the first frame is ready. The
best way of doing this is to display a transparent run-length picture using
vs_update() and then turn off the transparency when the first frame of
the cartoon is loaded using another call do dc_wrli().

To force a picture to be always transparent, use this code fragment and then
call vs_update();
	
	PICTURE *picture;

	pi_settrans( picture, TC_ALWAYS );
	

That vs_update() call should be made before calling any of the following ....

To find the parameters for the two dc_wrli() calls, something like this should 
work :-

	VS *vidscreen; /* the video screen you are using for your application */
	DSEG *dseg;    /* structure describing screen layout */
	short lctid,lctline; /* two of the parameters for dc_wrli() */
	short lctida,lctlinea; /* parameters for disabling transparency */
	int   transparency;    /* ditto */

	dseg=vs_find_segment(vidscreen,100);
	if( cartoon_playing_in_plane_A ) /* substitute your own test here */
	{
		lctid = temp->ds_lct0;
		lctline = temp->ds_line0;
		transparency = (dseg->ds_tci & 0xfffffff0) | TC_NEVER;
	}
	else
	{
		lctid = temp->ds_lct1;
		lctline = temp->ds_line1;
		transparency = (dseg->ds_tci & 0xfffff0ff) | (TC_NEVER<<8);
	}
	lctida = temp->ds_lct0;
	lctlinea = temp->ds_line0;

You should pre-compute the instruction to write to the LCT before you
start. You will need one of these for each of the buffers. These instructions
are generated by using the CDRTOS macro, cp_dadr() on the first address of
the buffer. If you were using 3 pictures, this could look like :

	PICTURE *pics[3];
	int instructions[3],x;
	for( x = 0 ; x< 2; x++ )
		instructions[x]=cp_dadr(pics[x]->pi_pstart);


The actual call to dc_wrli() in the buffer full callback handler should
look like :-

dc_wrli( vm_vidpath, lctid, lctline, DSEG_INS_DADR, instructions[x] );

The transparency disabling could look like :-

dc_wrli( vm_vidpath,  lctida, lctlinea, DSEG_INS_TCI, transparency );

:                          7: anything else ...
: 
:      Thank you for reading this help request and see you later...
: 
:                          Norbert Hofmeester.

And now disclaimer time .....

These comments are a personal opinion and do not represent Philips in any
way. 

There are almost certainly better ways of doing some of these things. The
ways I describe are merely the first ones which come to mind.

I don't have the time to answer support questions like this one other than
very occasionally, so don't ask otherwise you will probably be disappointed.

Enjoy

Jon Piesing