Okay, the BreakOut game shows a methodology for us users to take control of the Empeg UI while the player continues to run in the background. This is done by intercepting buttons and display updates within the kernel itself (nothing really wrong with that, other than non-pageable memory for the code/data).

The kernel currently has no fonts or other stuff for outputing text, building menus, etc.. but with a little effort we could overcome that, and implement some user-added menus for controlling neat stuff on our players.

For example, the various detailed parameters for the VolAdjust hack could be placed on slider controls on a menu screen, similar to the equalizer stuff.

So the questions are:
What else would we want to put on such menus?
What would be a nice menu structure to use once we've hijacked the UI as per the BreakOut example?

Cool idea.

I would like to have an option so that you could call an external program, or several. It would be nice if one could use config.ini to name the menu's.

Maybe an options if the player should continue to play, or stop playing.

TommyE

We could also add a UI for changinf Logos directly from the Empeg.

With a menu Logos, browse a list on the hard drive

Menu
(Settings)
(Logos)
(My Logo Name 1)
(My Logo Name 2)
(My Logo Name 3)

You validate and it changes the logo ...




Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

Since the functionality of the user menu isn't (I don't think?) available until after the player's started, then the disks are sure to be up by the time it's invoked. So you could theoretically start adding new syntax to config.ini. Do stuff like execute thirdparty software from the menu such as:

[UserMenu]
Menu1="Run Tetris"
Command1=/drive0/var/emptris

Since we can now edit config.ini from Emplode, that would rock.

___________
Tony Fabris

>I would like to have an option so that you could
>call an external program, or several.

That's easy enough, done in reverse. The hacked kernel could provide ioctl() calls for any userland app that wants to bind into the "hijacked" UI for button presses, display output, etc..

I suppose that way the fonts and stuff could also be out in userland, easing the non-pageable footprint somewhat.

I suppose that way the fonts and stuff could also be out in userland, easing the non-pageable footprint somewhat.

Don't worry about non-pageable space: the swap is not active in 'player mode', anyway (it only gets activated during syncs, and, of course, if something user-written activete it explicitly). It seems that guys@empeg consider R/W disk while driving (including swap) a bad idea.

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Paging, not swapping. Linux still pages user-space executables even in the absence of swap. "Paging" here means discarding lesser-used static (code) pages to free up RAM, and perhaps later refetching some of them as needed from the original executable files. Thus very large programs can fit into smaller memory sizes, so long as there is reasonable locality of reference within the code.

Cheers

Edited by mlord on 20/10/01 11:15 PM.

Ah, we are talking code and read-only data using original executable file, not swap space! I feel stupid . My UNIX sysadm skills (mostly AIX and long ago Interactive SVR3.2) are becomming rusty....


Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

We don't even page; the player app is mlock()'ed into memory as the drives stay spun down until we spin them up - if we paged, then we'd get a thread blocking on a read from disk, which ends up taking about 5 seconds as the drive was spun down at the time.

Hugo

>We don't even page;

True, but our userland extensions could page in/out to keep their memory footprint small, and the player shouldn't be impacted by that.

True, but our userland extensions could page in/out to keep their memory footprint small, and the player shouldn't be impacted by that.

Would that interfere with player's explicit control of disk spin up/down? (I presume 'page out' means throwing a R/O page not in working set from the memory, not writing it anywhere to disk; filesystem partitions are R/O in normal use.)

Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

Since we can now edit config.ini from Emplode, that would rock.

OK. I am dense. How do you do this?

Paul G.
SN# 090000587 (96GB Smoke)
SN# 030103046 (10GB Blue - Emergency Spare)

>Would that interfere with player's explicit control of disk spin up/down?

It might result in the disk spinning up on its own when the player doesn't expect it, but hopefully the player won't be bothered by that. If it is.. well.. I am the author of the Linux IDE disk driver, so I can probably find a work-a-round for any issues there.

Okay, my latest VolAdj+BreakOut patch (look in GENERAL) now includes a basic lowercase font and routines to output text (such as the current VolAdj setting..).

So, we're now one step further in this direction. Feel free to play with it.

Hehe, I think that is cool.

'I am the author of the Linux IDE disk driver'

TommyE

I've enhanced the font, so it now includes upper/lower case, numerals, and symbols. Basically all of the usual 7-bit printable characters are in there. And there's now a menu for selecting among presets for Richards VolAdj stuff: Off,Normal,High,Max It's all in V12 on my site.

Whew

.. I am the author of the Linux IDE disk driver, so I can probably find a work-a-round for any issues there.

No doubt about that.

Wow, not we Mere Mortals (TM) have quite a toolkit for playing around the empeg. This will certainly speed up some other projects people are working on.

Now, I just have to buy another machine so that I can install Debian and have cross-compiling environment....


Dragi "Bonzi" Raos
Zagreb, Croatia
Q#5196, MkII#80000376, 18GB green

I I use your patch to Add a Game Menu and launch Emptris which is also a good game on Empeg.

Is there objection to launch the game during song plays ?



Empeg II - 10 Gb - Red Fascia - 750 Songs -

- I Will Strike From the Grey -

> Tetris?

Go for it. BUT.. the current Tetris is a userland program, and I have not (yet) added hooks for launching such from within the kernel code. And even if you manage to launch it, it will interfere with the player: they'll both compete for the user-interface.

But if you mean to move tetris into the kernel, then no problem, even with the player running. But you may want to look at the tetris code (I have not) and perhaps think of clever ways to reduce its memory footprint first. Kernel memory is precious.

What I kind of envision is to have an alternate userland interface for IR (buttons) and display updates, so that we can launch (somehow) a userland app like tetris, and have it "hijack" the user-interface (like BreakOut does, same hooks), and not have to compete with the player software for the display etc.. This will involve adding perhaps a new "hijack" device to the kernel, which can be opened by tetris etc.. while the player software continues running on the "normal" device interface.

II definitely will NOT have time to continue with that this week though. Volunteers?

Cheers

Edited by mlord on 22/10/01 02:34 PM.

Here you go!

­­______________
Edwin de Vaan

Cool! Thanks!

Paul G.
SN# 090000587 (96GB Smoke)
SN# 030103046 (10GB Blue - Emergency Spare)

You're welcome!

­­______________
Edwin de Vaan

This would also be very interesting for the Nav system(s)

(list 6284, Mk1 S/N 00299 4GB blue [for sale]. Mk2 S/N 080000094 26GB blue)

Hell yeah. This display and input hijacking is definitely a big step. Very cool...

-Tony
MkII #554

Okay, I'm still hacking away at this stuff. In my private (non-released) version, I now have a main menu working, from which one can run the VolAdj parms, BreakOut, or just Exit again. More later..

Could you work with fvgestel to get the displayserver on/off hooks in this menu also?

Tom

I'd like to see ALL of the useful stuff in one kernel collection sometime soon.
Perhaps I'll have a look when I get back in, next week.