Hey,

What would be the possibility of writing a program that would, on startup, init and copy a random bootup animation from a directory to the bootup animation location, before the player software had had time to initialise? In effect giving a random different bootup animation each time the payer is started.

Anyone feel like a challenge?

Cheers,

A.

...and boot logos

I don't think you could do it exactly the way you describe, because the hard disk isn't spun up when you see the animation. Therefore it can't copy the animation into place before the animation starts.

However, there's nothing to stop someone from writing a program to flash a new animation AFTER the player is booted, therefore providing a randomized animation for the NEXT boot. The end result would appear to be the same from where you're sitting.

The problem is that the process for flashing the RAM is slow, and you will corrupt the flash if you interrupt the flashing process (for example, if you cycle the power in the middle of the process, or it reboots cause you were starting your engine or whatever.) So there'd have to be some safeguards in place. Also, the flash is a limited resource that can only be burned X number of times before it doesn't work any more, so anything to reduce the wear and tear on the flash bytes is good, anything that increases it, is bad.

I'm not sure if the player can keep playing while things are being flashed or not...

what is the flash chip goes bad, is it just s standard flash chip and u can replace it or, dose it have super powers and can only be replaced by empeg? i do alot of messing with the player, and serveral flashes a month. just kinda looking into the future

To minimise flash wear, you could select the new animation only when the music partions get mounted read-only - IOW, once per sync. This would deal with the partial-write problem, as you shouldn't be pulling the power while syncing anyway.

Perhaps a timestamp would be useful for people like me who tend to sync several times when installing a bunch of new music (once after uploading with emptool and several times with jEmplode as I copy tracks into all the relevant playlists). Then, you could install the new logo only if the old one is more than a {day, week, etc} old.

Well. I think it's a standard flash chip but if you count soldering SMD parts with lots of legs as a super power then yes If you do replace it then you'd probably want to get the same model number as the flash driver in the kernel sends commands for that specific brand/model.

- Trevor

I could probably hack together a small Hijack app which lets you select a new animation and then flash it. Anybody want this? I've already written the code for displaying it and loading them anyway.

- Trevor

If you were to replace the flash, I think you'd also need to program the protected area (with the initial pump code)...

Hmm. Good point. I forgot about the protected bootloader.

So if you wanted to replace your flash then you'd need to download the bootloader from another empeg, flash it into the new chip, unsolder the old chip, solder in the new one and finally flash the new kernel. I think the easiest option is to not wear out your flash

- Trevor

A quick google suggested that '96 era flash chips had a write-count expectancy of ~100,000. So if you were flashing your kernel/updating boot animations 3 times a day, it should still last about 90 years, and I imagine that (as great as it is) the empeg may just be obsolete by then.

Of course, I didn't bother to check the actual flash chip used in the empeg, so this figure may be wrong. I'll leave that as an exercise for somebody else

haha well in that case i dont think ill have to worrie about it, in 90 years i dont even know if this planet will be around.

Yeah, but I plan on willing my empeg to my children

>Also, the flash is a limited resource that can only be
>burned X number of times before it doesn't work any more

A random animation selector (something I suggested here months ago) would not be an issue in that regard. The flash savearea is updated far more often than the animation ever would be, and the savearea will be the first to go, by a longshot.

The slight worry of messing things up with a sudden powerfail while writing a new animation is a minor issue. We don't really care if the animation gets corrupted, and we could add a checksum or crc to them for Hijack to examine before "trusting" the table of offsets at the start of each animation.

But a bigger powerfail issue is that, if the player is busy writing the animation, then it cannot update the savearea. Again, probably a non-issue, since this will be immediately at power on, before the player runs, and therefore before the player can modify the savearea buffer (Hijack might change it, but no big deal there).

So, if we added a CRC to the animation, I don't see an issue here.

Cheers