I noticed that the Empeg/Rio animations reuse frames ... What's the impact of duplicating vs. reusing? Is there a maximum byte limit for the animation? (ani_encode.c references a max _frame_ limit of 32, but I don't see a byte limit) For the first version of the jEmplode animation editor, I was hoping to not have to deal with the UI for frame reuse if I don't absolutely have to.

Mike

If what Mark said is true, and the frames are simply an internal data structure within the kernel (and not their own separate kernel space), then the re-using of frames keeps the kernel from taking up too much flash memory.

They originally intended to actually delta-compress the frames using a Real Man's Algorithm, but ran out of steam somewhere along the path to 2.0...

I seem to recall Rob lamenting that there are still still some unresolved issues with the amount of flash they take up even now.

can we just get rid of the boot-up animation?

i'd be satisfied with my non-animated boot logo...
--
sancho

can we just get rid of the boot-up animation?

Yes. If you wish to do this, you may hack the kernel code directly and recompile your own kernel.

The one "issue" I see with the current animations scheme, is that, unlike the logos, animations are kernel-resident, meaning they take up memory forever, not just at boot time.

Cheers

i'd like to formally request that the animated logos be "hijacked" the heck out of the kernel, then...

get rid of the fluff and give us some more room for "features"...
--
sancho

The one "issue" I see with the current animations scheme, is that, unlike the logos, animations are kernel-resident, meaning they take up memory forever, not just at boot time.

Excuse my kernel n00bie-ness, but can't they just be kfree()'d after the animation is displayed?

No, because they were never "kmalloc'd".

Okay, that would explain it.

(BTW: For those who are keeping score, Mark was about 15 posts behind me less than a week ago, he's now ahead of me by over 100. This is unheard of!)

Do the animations just play too early in the bootup process to be stored externally?

They cannot be stored on the hard drive, if that's what you mean.

But we could store them in flash, separate from the kernel. I just need to have an idea of how large they typically might be first, that's all.

But since nobody has actually created any yet..

Cheers

The waving penguin is right around 14k. I believe the size is
(1024 * uniqueFrames) + (4 * (frameReferences + 1)) bytes with a maximum of 32 unique frames (at least that was the constant that was referenced in the encoder I saw)

Mike

Mmm.. so something a little more complex (or sloppy) could be say 20KB or so. One place we could store this is at the end of the kernel partition in flash, perhaps storing a signature of some kind to indicate whether or not it is present. The Hijack kernel would then just look for it, and play it instead of the stock animation.

To see if this is feasible, we first need to know whether or not we can "seek" to near the end of "/proc/empeg_kernel" and write only the tail of that partition. I suppose this should work just fine, but somebody has to try it and verify. You can seek using either HTTP "Range" or FTP "REST".

Then just read back the entire empeg_kernel, verify that the kernel itself is unmodified (in the usual way), and that the animation got placed at the end.

If that all works, then we just need the "signature" part. I propose this method:

Final eight bytes of kernel partition must contain "x1 x2 x3 x4 A N I M", where "x4x3x2x1" is the offset from the start of the partition (zero) to the beginning of the animation's "offset table".

So, for an animation that totals exactly 16376 bytes (including it's frame offset table), the animation would be written beginning at offset 0x9c000 of /proc/empeg_kernel, followed by "00 c0 09 00 A N I M" in the final eight bytes.

Simple, eh?

Okay, I just tried out the FTP "REST" part of the puzzle, and found a bug in it in all current versions of Hijack. I'll release a v241 that fixes it shortly. But with the fix, it is indeed possible to FTP just to the tail end of the /proc/empeg_kernel flash partition.

So we could easily use this as a mechanism for custom animations. I won't implement it in Hijack until somebody actually needs it, though. In the meanwhile, what do we (all three of us, I suspect) think of the proposal?

Sounds fine to me.

Sounds good to me ... I don't know how much control you have over these things, but would it be possible to just upload to a /proc file and Hijack would look at the length of the animation file and implement the idea you were talking about (writing at the end of the kernel, etc)? If not, I would need some special code for uploading boot animations (which shouldn't be a big deal if it's a pain for you to do the proc impl).

Mike

Yeah, I like the idea of a /proc/empeg_bootanimation one could write to.

We'd need to make sure that we could DELETE an animation from there if we wanted to... Perhaps by deliberately invalidating the ANIM tag, similar to the way you delete a custom logo by invalidating the EMPG tag.

Oh, I just thought of something that might invalidate your spec, Mark.

Since the ANIM tag is at the END of the address space instead of at the beginning of the animation location, what happens if someone uploads an animation that's shorter than the prior one? Then there would be two animation tags sitting there and the software would use the later one?

Or do I not know what I'm talking about?

I suppose if Mark thinks the /proc idea is possible (or if he has time), maybe writing just a 0 (32 bit) to proc/empeg_bootanimation could remove the current logo? The offset table uses a 0000 to denote the end of the table, so if you just write that, then it would imply that you have no frames of animation.

Even if you wrote a shorter animation, it would still be using the exact same final 8-bytes for the offset/signature. So no issue.

And deleting the animation is as simple as overwriting the signature.

-ml

Well, basically there are two choices: implement the complexity in the kernel on the player itself, or in userland on a less-restricted external platform (eg. JEmplode).

I vote for keeping the player's end of the deal simple, and therefore small (saving precious memory), and doing it on the external platform.

Cheers

Fair enough ...

OK -- I got the AnimEdit Hijack uploading code all ready to go (turned out to be really easy -- just had to add support for REST xxx into the FTP library I'm using). Let me know if/when you get a chance to add the Hijack side of it.

Just to be sure, I clear an animation by just overwriting the last 4 bytes of the 655360 block with something other than "ANIM"?

Mike

Yup.

And you can completely test your code with the existing v241 of Hijack. It won't play the animation, but it will allow the uploading and stuff to work (prior versions had a small bug in the "REST" command).

Note that in order to use REST for this specific purpose, the animation file has to appear to be 640KB in size.. If you're dealing directly with sockets, this can be accomplished by writing a bunch of dummy data (like, more than 600KB worth..) to "fill in" below the REST offset.

EDIT: well, not quite.. perhaps the FTP lib you have already takes care if this.. quite likely, I suppose.

Try it, you'll see what I mean. Just try writing to the tail of the empeg_kernel, and then read it back to see if it did what you expected.

Cheers

I'll put out a v242 tonight that looks for animations as discussed. Let me know if it works or not.

Cheers

I believe my FTP client is actually so dumb as to not care about the first 600k .. I basically tell it the offset to start and and then start writing. It's a pretty simple client. I did some tests with a text file and wrote into the middle of it and it seemed to work.. I'm going to do the "download it back off" test to make sure it's working.

Thanks Mark
Mike

I just did a read test and everything is looking good .. I checked the offsets and they APPEAR to be correct. I await 242

Okay, Hijack v242 will be out in about two minutes or so from now.

Cheers

Done.

Just for reference, here is the new kernel code in Hijack v242. It simply looks for "ANIM", backs up 4 bytes, and looks for a valid offset. If that's okay, it blindly goes to that offset for the animation.

Cheers

{

        // look for custom animation at tail end of kernel flash partition:

        unsigned char *p = (unsigned char *)(EMPEG_FLASHBASE + 0x10000 + 0xa0000 - 4);

        if (p[0] == 'A' && p[1] == 'N' && p[2] == 'I' && p[3] == 'M') {

                unsigned int offset = *(unsigned int *)(p - 4);

                if (offset >= 0x90000 && offset < (0xa0000 - (1024 + 8 + 8))) {

                        printk("Found custom animation at offset 0x%x\n", offset);

                        ani_ptr = (unsigned long *)(EMPEG_FLASHBASE + 0x10000 + offset);

                }

        }

}