Okay, so I've got two days before I disappear again for several weeks, so I figured I might as well implement another nice feature or two..

Hijack v66 is now out, with a couple of major IR translation enhancements:

-- a button can have separate translations for both LONG and SHORT presses.
-- a button can have separate translations for each active input source of the player (Tuner, Aux, and Main/mp3).

Eg.

[ir_translate]

;Multiple simultaneous translations for TapeSelect button on Pioneer vsx043

00a15e4c.LT=20df07  ; If longpress and Tuner active, then toggle AM/FM

00a15e4c.A=b9461e   ; If Aux active, then select Main/mp3

00a15e4c.M=b9461c   ; If Main/mp3 active, then select Tuner

00a15e4c=b9461d     ; default: select Aux

Or at least that's how it is intended to work. Let me know if you find any bugs that I missed. Note that it is not currently possible to specify longpresses to the right of the equal sign. Maybe someday (non trivial).

Cheers

-ml

Okay, so I've got two days before I disappear again for several weeks


I knew you wouldn't be able to stay away.... And with 2 whole days before leaving, I'm guessing we'll have 10-12 new implementations by that time...

Downloading now...

66 give us a chance i only just figured out how to work 62

Keep up the good work version 62 is great

The original example I posted had the original Pioneer codes wrong, so just for completeness, here is the correct version (for anyone with a Pioneer cu-vsx043 IR remote):

[ir_translate]
;Multiple simultaneous translations for TapeSelect button on Pioneer cu-vsx043 IR remote
a15e4c.LT=20df07 ; If (L)ongpress and (T)uner active, then toggle AM/FM
a15e4c.A=b9461e ; If (A)ux active, then select Main/mp3
a15e4c.M=b9461c ; If (M)ain/mp3 active, then select Tuner
a15e4c=b9461d ; default: select Aux

A couple of things...But first let me say we all appreciate this code!!!

First, if you stack commands to navigate the menu system. Sometimes it won't be just right due to the speed of the commands being issued. I used one that was about seven commands long. About 50% of the time the last Menu/OK command was missed. Not a big deal. But if there were a Pause command, we could have slight pause where we need. Or stack them to have a longer pause when we desired. Example: 00854112=0020DF12,0020DF10,0020DF10,0020DF12,0020DF11,0020DF11,0020DF12 ;EQ
Changed to something like:
00854112=0020DF12,0020DF10,0020DF10,0020DF12,0020DF11,0020DF11,PAUSE,0020DF12 ;EQ

Secondly, Yes I know there is an easier way to the EQ, just using that as an example.

P.S. This is an Alpine remote code.

Mlord, this stuff rules. Not to mention putting the IRTrans stuff in has made my kernel patching a lot easier since I don't have two different patches modifying empeg_input.c now.

I have a wish list request in the IR translation area. I wrote a kernel mod to Frank's original IR trans which allowed me to use one of my remote buttons as a "shift lock" so to speak. Meaning that it would toggle between two different "pages" of translated codes. So on my Pioneer steering wheel remote, I could have normal functions on 10 of the buttons, then hit the "modifier" which would switch those 10 buttons to the numbers 0 through 9. Pressing the modifier again switched back to the normal buttons.

I realize that you have a Long press qualifier in the configs, but I would like to retain the long press functionality of the buttons like rewind, fast forward, "hush" etc. So would it be possible to allow for the configuration of a modifier as I have described? When I did it, I just had it check a toggle flag when translating the codes to determine which of the codes to send. I looked at your code and it looks nothing like the way Frank did it, so I can't use the same strategy.

Let me know what you think... Thanks again. BTW, I anticipate releasing my userland app sometime in the next week or so. It's coming along great so far.

>if you stack commands to navigate the menu system.
>Sometimes it won't be just right due to the speed

Yup, I see that too. I was hoping not to have to fuss with it for now, because the "fix" is HUGE -- it requires a timing queue to be implemented for button presses.

But.. I have given in and implemented it today. v67 now "paces" button presses when feeding them to the player software (let me know if the pacing is still not slow enough -- also, this might still fail if the player waits for the disk to spin up.. dunno).

A side effect of implementing the timing queue is that "LONG" presses can now be emulated as well, using the .L modifier to denote them in the IR translation sequence to the right of the equal sign.

And one person asked for a "SHIFT" toggle feature, so I'ved added that too, using a .S modifier. Any .S left of the equal sign means "do this only if in 'shift' mode", and .S on any value to the right of the equal sign means "toggle the shift mode".

Of course, all of these modifiers may be used in various combinations to really overload the buttons on a remote, so it is important (for now) to specify them in the correct order: .L comes first, then S, then T(uner), A(ux), or M(ain/mp3) (only a single dot at the beginning).

I've also fixed some rather peculiar bugs in the button translation code, so everyone should probably upgrade to v67 or higher.

It'll take a few minutes before the instructions on the web page are brought up to date, but the code is there now.

Enjoy

-ml

I've added the "shift toggle" (shift lock) feature to v67. It uses a .S modifier.

Cheers

So what is your new app? Give us a teaser?

Many Many Thanks!!!

I changed to version 67 and ".L" is no longer working on the left side codes. I can take out the ".L" and the code still works. Am I doing something wrong or is this a bug?

Well "app" is a bit misleading, it's actually a game. Something fun to play while you're sitting in heavy traffic or at a long stop light. Passengers should enjoy it too.

The only thing that I think will be missing from my first release will be a way of saving anything between plays, because that mechanism doesn't exist yet, and I don't think I'm smart enough to implement writing to a raw sector on the disks. Hopefully someone out there is working on this.

Anyone???

Mmm.. I seem to have broken them after testing.. darn..
Wait a few minutes (maybe 30 or so..) for v68

-ml

The pacing is pretty good also. It works about 80% of the time. In a long macro, it sometimes get tripped up. If it could be slowed down a little more that would be better I think.

Well "app" is a bit misleading, it's actually a game. Something fun to play while you're sitting in heavy traffic or at a long stop light. Passengers should enjoy it too.

I know we'll be getting off-topic for this thread, so maybe another can be started. What kind of game if you don't mind spilling the beans?

I was thinking of a couple that would work quite well today: A sideways break-out/arkanoid type game. Allowing to play from the right or left. Maybe letting certain levels flip the sides on you just for the hell of it (difficulty :)

Of course the screen is big enough and the processor powerful enough to do a lot more complex gaming. The controls are about the most challenging for the player. How about a small Karateka? Or Bruce Lee style game? (Think back, waaaay back - from Data East for the Commodore 64 and others)

Of course a cool visualization of stick-men kicking the crap out of each other super-king-fu style would be really nice too (anyone who's seen the flash animations of same will know exactly what I mean :)

Bruno

Can "L" and "S" be used in the same code? That is, can the meaning of a "press and hold" be different depending on the shift status? I'm trying to squeeze a lot of functionality out of my 11 button steering wheel remote :)

Ooo, the screen shape and resolution would be perfect for a port of Karateka....

Ummm I'm keeping the exact nature of the game under wraps because I like surprises. :) It's not an arcade-style game, though. I'm still feeling my way around the graphics libraries and such, so maybe I'll think about those soon.

It'd be cool if bmihulka ported his Emptris to the userland interface. If he doesn't I might give it a whirl after I'm done with my own game.

The main problem I'm having is that the GD graphics libraries aren't too quick. As things evolve it'd be nice if some assembler folks could string together some assembly libraries for graphics. GD works well for me but it's definitely not optimized for the SA1100.

>The pacing is pretty good also. It works about 80% of the time.

I'll slow it down some more by default (v68), and also include a tuneable parameter for you (and others) to play with in config.ini

-ml

>Can "L" and "S" be used in the same code?

Yes. And either/both can also be used in combination with T(uner), A(ux), and M(ain).

-ml

>I changed to version 67 and ".L" is no longer working on the left side codes.

Actually, at least for me, it sort of works.. but I'm doing too much in one breath inside the interceptors, and this is confusing the Empeg code in empeg_input.c.

So I've split things out some more, divying up the workload over time, and empeg_input.c appears to be happier about it. v68 will be out shortly.

-ml

Okay, v68 is out.

Hopefully the .L modifier for IR translations is working better for everyone.

And is it just me, or has this stuff degraded the player's responsiveness to IR codes? Perceptually it seems slower to respond to button presses, even though I have tried flipping back and forth between new/old kernels without any measurable difference.

'Guess somebody's gotta put two players side-by-side, one with hijack and one without, and then hit some buttons on a single remote to see which is quicker..

Last chance for bug fixes .. I'm leaving for three weeks in less than 24 hours from now.

Cheers

-ml

>And is it just me, or has this stuff degraded the player's responsiveness to IR codes?

It was my imagination. I just now set up my Mk2 and Mk2a units together on the table, one with Hijack and one without, and with a single remote (Rio) I sent commands to both units simultaneously. The result? No difference in response speed, except for a very slight lag on short presses of "MENU/OK", which I understand perfectly as a side-effect of hijack having to wait briefly looking for a long press of that button.

So, no difference, no worries.. whew!
(And to think I wasted 2 hours poking at this on Saturday).

-ml

2 hours Mark, you could have realized 3 or 5 fives Versions from 68 to 73.....

Hi Mark,

Two requests. First, any chance there can be a beep (possibly configurable) for each button press? Second, I noticed you change the button codes display to show the pre-translated code. can you change it to show both the pre and post? I think this would help us debug our IR translations.

>Two requests. First, any chance there can be a beep ..for each button press?

Yes, just turn on/up the regular Empeg beep feature.
That is really the only way for the beeps to be even close to being synchronized with the button actions.

>..the button codes display .. show both the pre and post?

Not enough room on the screen. And I think it would be WAY too much code/effort for a non-feature. For debugging, just connect up the serial port and look at the echo-back of the codes that worked. That'll have to do (and it's pretty good).

Cheers

-ml

Tony! This is a GREAT IDEA! If I ever see Karateka running on my empeg I'm going to CRY!

Ok Mark, I tested v69 with my kenwood steering wheel remote, and L does not seem to work. Maybe it is something with the remote itself? Basically, it alsways gets a single button press.
Needless to say, the rest is working perfectly. Now my source button on the remote is working again as I wanted.
Ok, I know everybody told you this, including me , but again, great great job. Thank you!

>I tested v69 with my kenwood steering wheel remote, and L does not seem to work.
Not all remotes (and not all buttons) can actually do "long" presses..
Maybe that's the case here.

In the "Button Code Display" screen, press and hold your problem button. Only one code should appear (once) on the screen, until you release it again.
-ml

I figured someone would dig the Karateka idea. Some otehr titles that would probably do well with the limited resolution and screen dimensions... Choplifter... Kung-Fu Master (this one will be hell on the remote!)... Games running the Infocom text-based adventure interpreter (damned if I can remember the name right now) - an interface could be made to use buttons on the remote to correspond to common keywords (and if you wanted to be really silly you could put a predictive text engine into it, like on the Nokia Phones and similar to what we have for Search in the player software). Temple of Apshai (sort of hack-like dungeon game), Pitfall...

Of course, the ultimate would be to make a simple driving game, like Pole Position. Now that would be irony.

Bruno