VolAdj+BreakOut+Menus(!)

Okay, just for fun, I've added a rudimentary menu system into my latest patches (V14).

This means some of the controls are now simplified (the LOWER & LEFT/RIGHT buttons on the front panel are NOT used any longer -- no more conflicts with info/visual toggling).

The code is evolving, as needs arise, but I think I kinda like what's there at the moment.

http://rtr.ca/empeg/

Summary: Custom kernels with VolAdj patch, menus for adjusting it, persitent settings, a bonus Break-Out game, and kernel-based font/renderer for future extensions. The hooks for connecting to userland aren't there yet (that's next week's project), but we're getting there fast enough.

Wow! You come out with new programs faster than I can download and install the damn things! Thanks for all the cool hacks, and keep up the great work! I'm just starting to get my feet wet with Linux development, but I hope to be able to help with some userland app development RSN. Especially Sven's GPS project.

mlord, you are an absolute madman, but for some reason (using the patch) I'm still getting the breakout game instead of the user menu. I rolled back to a 2.0b3 kernel and applied voladj then your v14 patch but I still get breakout. I'm supposed to get a menu right/

-Tony
MkII #554

Works nice for me, the menus are cool! Actually you should add "start over" option to the end of the game. Then it's easier to try again. In previous versions it took only 3 cd presses to start over, now i have to make 3 cd presses + right button + cd again.

Veiko
[email protected]

MK1 #317 - 20GB green

Er ok it must be something I did then...

Okay just got it working. Amazing what a "make clean" will do!

Great stuff!!

-Tony
MkII #554

Yeah, restarting the game is a bit of a mess, now, eh.

The simplest fix for it is to have the menu DEFAULT to the game (rather than the VolAdjust). That way, four clicks of the same button and you're back in quickly. I've made that adjustment in my copy now.

>I hope to be able to help with some userland

Yeah! I won't have the required hooks in there for another 10 days or so (busy), but I've added some notes on what is planned to the top of the hijack.c file .. enough maybe for others to think about it some. I'll put up the latest patch shortly, but NO prebuillt kernels this time (not much has changed).

Cheers

Version V15 is up on my site. Nothing revolutionary (this time), but game players will appreciate the rearranged menu that allows four repeated presses of CD / SELECTMODE to start up BreakOut.

However, in the source code, I've dumped some comments describing my proposal for tying in userland applications to the menu. Here's what it says:

+// Near-future plans: Implement a new virtual device (or piggyback existing)
+// for a userland app to open/mmap/ioctl to/from for userland menus, apps,
+// etc.. to be able to use the hijack capability to run while player is running.
+// We hijack the screen, and MOST buttons, leaving just a few buttons under
+// control of the player itself (most likely just the four on the front panel).
+//
+// Basic userland interface would be like this:
+// vdev = open("/dev/hijack") // access the hijack virtual device
+// mmap(vdev,displaybuf,2048) // get ptr to kernel's displaybuf
+// fork(); // create an extra thread
+// ioctl(vdev, HIJACK_WAIT_MENU, "GPS") // thread1: create a menu entry,
+// // and wait for it to be selected
+// top:
+// ioctl(vdev, HIJACK_WAIT_MENU, "TETRIS") // thread2: another menu entry
+// ...
+// ## user selected "TETRIS" menu item
+// ## kernel unblocks thread2 only.
+// ## thread2 now has *exclusive* control of screen and (most) buttons
+// ...
+// while (playing_tetris) { // thread2
+// ioctl(vdev, HIJACK_IR_POLL) // thread2: poll for input from IR buttons
+// write stuff to displaybuf // thread2
+// ioctl(vdev, HIJACK_UPDATE_DISPLAY) // thread2: force another screen update
+// }
+// ...
+// ioctl(vdev, HIJACK_UPDATE_DISPLAY) // thread2: force another screen update
+// goto top; // thread2
+// ...
+// ioctl(vdev, HIJACK_REMOVE_MENU, "TETRIS") // optional
+// close("/dev/hijack") // optional
+//
+// Well, that's the idea, anyway.
+// So if you want to port/develop an application for this,
+// then at least you've now got the basic structure to build around.
+// I hope to implement this (smaller than it looks) by early Nov/2001.

Edited by mlord on 23/10/01 10:13 PM.

With your screen code, are you planning on any overlay capabilities like the clock hack in 1.03, or is it full screen only? Being able to say "Box with the text "Blah" at coord "2,34" for 2 seconds would be awesome.

Do we get to start a wish list forum for this little prog too?

Seriously this absolutely ROCKS!!


better post it on the Rio Car Dot Org site before tony gets a chance!

Murray
new styleee

>Do we get to start a wish list forum for this little prog too?

Yep! But I don't actually envision it getting much bigger.
Rather, from now on I'd like to concentrate only on creating
an excellent interface to/from userland applications for the menu.

What we really need now is someone to hack the existing userland
stuff (displayserver on/off, alternate IR codes for third party remotes,
Emptris (tetris clone), etc.. such that they can plug into the new
(yet to be coded by me) interface.

Then we get rid of the clunky boot menu workarounds, and have all
our NEAT STUFF tied directly into our "player extensions" menu,
accessible anytime -- even when the player is running.

A Really Neat Hack would be if someone implemented a VT that uses
this "hijack" interface (my name for it) to allow login ON the front panel.
Maybe not too useful, but I'd use it!

>With your screen code, are you planning on any overlay capabilities
>like the clock hack in 1.03, or is it full screen only?
>Being able to say "Box with the text "Blah" at coord "2,34"
>for 2 seconds would be awesome.

Cool. I'm planning on it NOW!

How about a simple ioctl() (from userland) for "HIJACK_SET_GEOM" to specify a "window" geometry (upper left coordinate, height, and width)?

This would be somewhat messy to implement internally, but doable.

Method (1) would be to modify the blatter routine to only blat the rectangle we specify. But given the extreme weirdness in the hardware displaybuf layout, this likely ain't gonna happen.

Method (2) might be simpler: merge the player's displaybuf with our rectangle before blatting. A lessor known "secret" of the hijack method is that the player continues to update the "screen" even while we are running -- except its updates never make it to the blatter.

The second Method looks a lot less efficient than the first, but might not be too bad because its simpler logic makes for faster code than Method 1.. mmm..

Cheers

Method (2) might be simpler: merge the player's displaybuf with our rectangle before blatting. A lessor known "secret" of the hijack method is that the player continues to update the "screen" even while we are running -- except its updates never make it to the blatter.

I think method 2 was already tackled in the 1.03 days to provide a clock when none existed. Take a look at this thread. I'm also attaching the source diff for empeg_display.c

BTW I didn't write this but I toyed around with it and got it working at one point.

-Tony
MkII #554

Cool.

There's a few things in there we might use, such as the separate display queue for our hijacked overlays for menus/userland: what we do right now is simpler, but only works while the player is running (the code doesn't currently do refreshes on its own. ToBeFixed).

And since the clockoverlay used the same device as the player, that answers our question about whether or not to create a brand new device: not needed since there isn't any apparent conflict with the player (it might have been using open(O_EXCL) but I guess it doesn't).

So we can just stick in some ioctls() like the clockoveray did and voila, we're there!

[next week]

So we can just stick in some ioctls() like the clockoveray did and voila, we're there!

Yeah, it looks that way. See, IMHO there's a VERY deep pool of programming expertise around here, but it's never been totally focused. Each of us has hacked in our own little things that we're looking for at that particular moment. So when new people get involved, there's no central resource to show all of what's been done in the past. This BBS is good, but searches don't always find the real gems that are buried within (this display overlay code, for instance.) I've seen other times when people wanted to code something that had already been in existence, albeit quiet existence deep in the threads of this BBS.

The riocar.org site has potential to be this... I'd love to see a really well-organized developer section in there with all of the collected works from various other programming sites. That way anyone new coming on would know everything that's been done already so they wouldn't re-invent the wheel.

In any event, the work you're doing is one of the more significant steps so far, because it really knocks down the wall that has existed between user apps and the player. We'll all be able to "plug in" our own user apps into a slick interface that works side-by-side with the player app. I'm sure as other projects progressed they would all find their ways to get input and display output on the VFD, but this middle layer is the perfect. All it needs is a slick marketing name like the Empeg Power Pack or the Empeg Resource Kit or something.

Why'd you wait so long to show up here, anyway? We coulda used you back in the early days of the MkII! :)

-Tony
MkII #554

Hi Mark,
I'm glad to see that someone is as enthousiastic as I was when I first fot my hands on the empeg, and a decent kernel-hacker also...
I haven't tried your hacks yet, but I'm certainly going to install it later.
I haven't read the BBS for two weeks and there are about 250 unread messages!!!

What we really need now is someone to hack the existing userland
stuff (displayserver on/off, alternate IR codes for third party remotes,
Emptris (tetris clone), etc.. such that they can plug into the new
(yet to be coded by me) interface.

Well, I think I wrote most of that stuff, so count me in for trying to adapt the code to the new interface...

Then we get rid of the clunky boot menu workarounds, and have all
our NEAT STUFF tied directly into our "player extensions" menu,
accessible anytime -- even when the player is running.

I'm glad we can now stop adjusting the boot-sequence; I already skipped this in the ds2 install, but this is way nicer than stopping the player before doing stuff. Though I would like a way to totally stop the player app, for userapps that are very memory-hungry ( the GPS project? ).

A Really Neat Hack would be if someone implemented a VT that uses
this "hijack" interface (my name for it) to allow login ON the front panel.
Maybe not too useful, but I'd use it!

I did something similar; It used a 200 lines x 80 char buffer, which could be scrolled with the rotary and the front-buttons. I don't think I published it, bit I showed it at the first empeg-meet in Amersfoort; there's a photograph of my empeg showing ps-output on Rob Schofield's photo-site ( Rpb, haven't you submitted your album to riocar dot org yet? )
I even fooled around with an IR-keyboard for a while, but couldn't get it to work, so I left it for later.
I'll try to see if I can find the code for that, but I think a rewrite ( kernel device ) would be much cooler. It would be cool to switch through consoles like standard linux with ALT-F1-F6, but then with remote presses or something...
Anyway, I'm gonna install this stuff now, let you know later...

Frank van Gestel

Thanks for the info.

We will definitely have to get in touch when I return next week, and get this stuff integrated into one nice user-friendly release.

I have just found/fixed a gazilion bugs in my stuff, and will put out V16 with the fixes Real Soon Now.

I still have not added in the ioctls() for connecting to userland, nor have I implemented extensible menus yet (the existing one is static). But that's all for when I get back.

Cheers!

Okay, version 16 is up on my webserver (which, btw, is also an SA-110 based Linux box).

This version has a re-implemented font renderer, and several important bug fixes. If v16 is NOT rock solid stable on your player, I wanna know about it!

So, rev up those modems, pull down v16, and letmeknow if it does anything strange.

http://rtr.ca/empeg/

Thanks all!

If v16 is NOT rock solid stable on your player, I wanna know about it!

Wow, did you test while docked at all? I'm getting stuttery playback and sticking RW & FF buttons. I did a reinstall of 2.00b3 and a redownload of V16 and got the same results. It only happens while docked in the sled. Going back to V15 solved the problem.

Tom

I'm getting stuttery playback and sticking RW & FF buttons.

I'm getting the exact same thing on mine. Every time I hit a button, it seems to think I'm holding it down. Just hitting the "Next Track" button makes it start skipping through the entire song. Very strange. I thought maybe some packets got lost durring the synch or something, so I was going to just try it again...

Anyway, using the remote seems to be alright, but I'm still getting a stutter whenever I do anything.

mlord -
I can't remember exactly which version I have, but it was the latest version availible on your site as of about 11 or 12 last night (PST).

Bad news, Mark.

I loaded v16 (fast 1-drive) on my Mk2a this morning as I was running out the door. Big mistake. Front panel I/O always sticks, like it never seens the button come back up, and any I/O remote causes exactly two stutters.

Will be going back to 15 unless there's a 17 tonight. ;)

-Z

Just an update, I did in fact have 16 loaded before, when I was haveing the trouble. I have since switched to 15, and all is well now.

Same problem for me .

When using buttons on the Empeg, it reacts ramdomly , switch to visuals when want to go next track etc ...

I reinstalled V15 and all is good.

v16 messes up button presses for me (Empeg (not Rio) Mk2). When I use any button or the knob, the music mutes briefly. The new menu hung on me once on the way to work this morning. I'll try v15 and report back if I have problems with it.

Thanks, this is a great idea and a great interface. Keep up the great work. The only other hack I'd like is the start up in visualization mode hack along with single drive and vol adj.

-Hoagy.

Yes, same problem here. Unfortunately I don't have V15 anymore. Could you leave older versions on your website? That would help in cases like this. Anyway, simply great job!

They are still located on his website, just not directly linked. Use the link for v16 and replace it with v15, it worked for me.

Tom

Yeah, me too. BTW I threw up a really hacked MK2 2.0b3 kernel with hijack v15, voladj, irtrans, displayserver irpatch, and no FM bass boost if anybody wants it.

-Mike

What did you change to give the FM less bass? what setting?

What did you change to give the FM less bass? what setting?

It's not a setting. It's a code change in the kernel.

If he followed "The Rules", he will have posted a piece of source code patch along with his compiled kernel, and you can look there to see what lines were changed.

If he followed "The Rules"

:-) Well I didn't think it was worth a patch for a one line change that I didn't really write (Hugo told me what to change). See this thread for more info. If someone wants a patch or really thinks I should provide one let me know and I will put one up.

-Mike

Foud it! Thank you!

A funky new sound effect. With the VolAdj on high and the player starts to stutter, the volume goes up and down. I thought this is messed up bad. Then I realized the VolAdj was on high. Turned it off, now the player just stutters as normal.

Okay, I'm back in town and back in the forum.

The V16 VolAdj+BreakOut patch had a leftover "printk()" in the keypress handler, which is the cause of the button-stutter reported by many in this forum. Commenting out that statement "fixes" the problem.

Since it doesn't happen "undocked", I would guess that the serial port (where the printk() output goes) must run at a slower speed when Docked versus Un-Docked, right?

Anyway, V17 with the printk() removed will be up shortly at http://rtr.ca/empeg/

Thanks to those who tried (and reverted from!) v16, and again, PLEASE TRY v17 so we can find/fix any more kinks before I proceed with the master plan to embed userspace apps into the menus.

Cheers

Okay, I'm back in town and back in the forum.

Welcome back! Business trip or pleasure?

I would guess that the serial port (where the printk() output goes) must run at a slower speed when Docked versus Un-Docked, right?

Yup.

..the master plan to embed userspace apps into the menus.

[drool]... I cannot wait for this! I have a little project I'm working on which will hopefully take advantage of this.. It's kinda along the "passenger seat entertainment"

Hey, one thing... I was looking at your plans for this and I don't recall seeing anything about letting user apps write some text to the screen in the same way your menu system does... Like I'm thinking the user app could call something like this:

hijack_print("This is some text", 16, 4);

To write a string starting at location x=16 y=4 on the display. Obviously if you implemented the overlay and "full screen" display modes the user apps could put together the text themselves, but since you have some fonts already in the kernel, were you planning on opening those up to the users? This would make it really easy for people to write little messages to the display without having to piece together display buffers... Right?

Yes, exactly.

When I rewrite the menu stuff (this week or next),
I'll add a scrolling text window widget to the interface
for use from both kernel/userland. Maybe even wire up
the kernel printk() to it.

Cheers