Okay, I've just put up v19 of my "hijack" patch for voladj + breakout + userland menus.

This patch is much closer to production quality in the menus, has lots of nifty little fixes that you may or may not notice, and now includes a running display/graph of the voladj scale factor performance.

Plus, a new menu item now exists for auto-blanking an inactive screen display to avoid burn-out. The default will be random the first time it's installed, but the menu allows tuning in 30 second intervals. If your screen suddenly goes blank, you'll know you forgot to go into the menu once to set it up (or turn it off). The blanking only happens when a static display persists for the time interval you set, typically at the end of a playlist (where mine sometimes sits for days). Unfortunately, this setting is persistent only on Mk2 players, not Mk1 (no room left in the NV ram area I am stealing from).

The menu code is much cleaner now, and extensible from within. I have not yet added the ioctl()s to allow userland apps to bind into it, but that's next on my list. I'll need somebody to actually code up some userland stuff and test it for me, as I have no intention (at this time) of hacking anything other than my Empeg's kernel.

Anyway, run this one through the usual paces (and then some), and let me know if it breaks anything for you.

http://rtr.ca/empeg/

-ml

Wow. You really are cranking on this stuff. Cool.

Have you hooked up with Drakino to make sure your kernels get put up on the RioCar.Org site? Very important.

Okay, the graph of the volume adjust is pretty darn cool.

>Have you hooked up with Drakino to make sure your kernels get put up on the RioCar.Org site?

Err.. not yet. I have a hard enough time sync'ing my own web server, let alone uploading to another one.

But if anyone else wants to upload / maintain my stuff for RioCar.Org, please do!

-ml

Very nice

Hi,

Haven't tested it (V22) in car yet, but it looks very smooth to me.

I'm considering writing one of the following things as a trial-run for application development on the empeg:
a) car odometer database (so I can see where I've driven to every day)
b) small arcade game, preferably some arcade thing

Which makes me wonder:

How/where do I save data? The disks are RO and possibly spun down.

How do I output sound, when the player is already running?

It would be nice if there was a framework application to work from, it would possibly ease newcomers into development.

>How/where do I save data?

From userland, for most apps, you'll have to use the disks.
They'll spin up if you read from them (I hope, if not we'll fix that).
But yes, they're normally R/O, so you'll need to fix that also.

Global machine settings (eg. voladj, screen blanking, etc..) are better suited to storage in the Flash memory reserved (or stolen ) for such stuff. But this is a very limited resource.

I suppose somebody will need to write a small app to load/save data from a reserved disk sector or something, which could be done without much trouble and which would avoid having to remount the fs rw . Or maybe just bite the bullet and do the rw remount, save data, and then mount ro again.

...

This has always been the most glaring obstacle with user apps.. Where to store data. The player uses /dev/hda3 in some kind of a raw mode, and the Empeg guys have cautioned developers not to use it for other applications because it's extremely undocumented, and the player could very well write anywhere on that partition.

That leaves us with the 32MB /dev/hda2 partition which I'm currently using as my /usr partition. This partition is left alone during an upgrade, which is good. However it seems the upgrade rewrites the partition table, so I don't know if that would screw things up if we used this as our "user app dynamic data" partition.

Does anyone know any reason why /dev/hda2 wouldn't be suitable for this? Sadly I'm not well versed enough in sector-level I/O to understand the implications of this... Like, even though it's not mounted RW, if the app is writing to a sector and the power goes, you're SOL. So I can see a lot of instances where user apps might lose data unless they were very judicious about when they did their writes... Seems all of this could be a big hurdle, no?