Commander X16

I'm doing a little background research into writing an Autodesk Animator player
(FLI files) for the X16. Some of the Header Data I'm going to be reading
is Big Endian thankfully only 16 bit data most of the Data is byte or ubyte.

Whats the most efficient way to read a Big Endian value to a Little Endian
Value. I've never dealt with it before. Just cast to array(byte) and
Swap the values ??


Some of the values are CHUNK Ids. $AF11 is the ID of the FLI file itself.
I'm guessing I can just swap those in my definitions. i.e. Check for $11AF instead.

When it actually denotes a number of bytes to read or seek into the file
I'm going to have to change those to Little Endian.

I'm also going to have to convert a 24 bit Palette Entry to an appropriate 12 bit Pallette Color.

big/little endian is simply swapping the bytes around, converting 24 bits color to 12 bits is a bit more involved as you need to bitshift the 3 bytes first and then recombine them into 2 bytes (consisting of 3 nibbles + one dummy nibble).

Ok I think I understand what your saying. Does the following Psuedo Code (I'm not fluent in C yet)
Make sense for converting a 24 bit pallette entry to 12 bit.
Thoughts on this possible project.

1. Autodesk FLI's are the simplest of animation formats.
2. Use of partial frame updates gives at least the possibility of an acceptable frame rate
on the X16 (code will have to be highly optimized).
3. I haven't Decided on C or Pascal to start the code. I just got C set up on my system
Yet to have a working Pascal installation.
4. If I get 4 or 5 fps it might still be useful for Cartoonish animations.
5. If I get 10 or greater fps I'll be ecstatic.
6. If I get somewhere close (say 6.5 fps with everything optimized) I might create my own modification of the format say
.FLL (FLI Little Endian) or Maybe .F16 (FLI for X16) In that case I would write a FREEDOS/WINDOWS/LINUX
conversion utilitity to convert the FILE format. (Make all WORDS Little Endian and Preconvert the Pallette Values)

You will want to bitwise OR various nibbles together, not AND.
Also looks that there's too many steps going on and that it can be optimized quite a bit.
You'd want to turn 3 bytes $RR $GG $BB into a 16 bit value $0RGB (which is stored little endian in vera's palette memory so $GB $0R)

This is some prog8 code that converts a 24 bit palette to vera.
It gets passed a pointer to the 24 bit palette array (3 bytes per entry).
@(xxx) is prog8 syntax for get-the-byte-at-this-address.
In C, when using arrays, you can just use array indexing I guess.

sub set_rgb8(uword palette_bytes_ptr, uword num_colors) { ; 3 bytes per color entry, adjust color depth from 8 to 4 bits per channel. vera_palette_ptr = $fa00 ubyte red ubyte greenblue repeat num_colors { red = @(palette_bytes_ptr) >> 4 palette_bytes_ptr++ greenblue = @(palette_bytes_ptr) & %11110000 palette_bytes_ptr++ greenblue |= @(palette_bytes_ptr) >> 4 ; add Blue palette_bytes_ptr++ cx16.vpoke(1, vera_palette_ptr, greenblue) vera_palette_ptr++ cx16.vpoke(1, vera_palette_ptr, red) vera_palette_ptr++ } }

I thought it would be ( $GB,$R0) which is what I think my PSUEDO code ends up with.

So its ($GB,$0R) ???

Your entirely correct about OR vs AND. I was thinking to much +/- vs BIT operations.

yes, see https://github.com/x16community/x16-doc ... md#palette
only the bytes are reversed in big/little endianness, not nibbles

I see. I appreciate you taking the time to write the code. Its absolutely useful.

I don't see myself starting on this project in earnest until at least the end of July.

I have to do.
1. Finish my X16 case build... (I'm going from scratch with Acrylic sheet, and soldering up the LED & switch leads
myself (and I suck at Soldering)...
2. Finish Hangman & Life, Add Mouse Support to LIFE.
3. Also building a Table and doing other Household stuff...

My expectations for the FLI player is to get it prototyped and working in C or PASCAL (leaning towards C at the moment)
Then rewrite most or all of the FRAME decode routines in ASM. 1 procedure at a time.