Okay, so I couldn't resist it.

Hijack v53 is out:

-- force multmode=8 on IDE drive(s) for faster transfers (?)
-- new one-shot countdown timer for alarm(audible), wakeup, or sleep
-- show Jiffies (kernel tick counter) in Vital Signs
-- a few small bug fixes
-- accelerated auto-repeat when selecting timer values in the menu
-- last menu selection remembered over power cycles
-- audible alarm for maxtemp-exceeded
-- mm:ss format for timerouts in menu
-- miscellaneous bugs fixed

The IDE changes hopefully won't bother any units, but ya never know with those older Mk1's. Let me know if you see anything funny happening. (been there, done that.. this is the exact same feature that got me started with the Linux kernel almost 10 years ago..).

Have fun!

Out of curiosity what does multmode do? I am used to fighting with PIO/DMA modes and write caching to get decent drive speeds, but I don't think I have heard of multmode.

-Mike

Any chance of getting low temp. code into your kernel before you head off for a month? It's the time of year here where it's either freezing or really warm, so having both tempature warnings working would be useful.

Thanks for all the work so far...

You are a freakin' animal man. Where have you been all our lives!?

Great great stuff. Thanks for all your efforts!!

I think you've already been told: YOU DA MAN! :D
Thank you!

Great work keep it up. Love the redifing the the knob being pressed can now shuffle/unshuffle on the fly.

Great stuff as usual, mlord. Just so you know, that app I've been working on is progressing very well this weekend... Since I'm under the weather, about all I can do is hack on my computer, so...

Hey I have an addition to the wish list. This isn't for what I'm working on now, but for a future project... I know that the currently playing FID, timecode, etc. is written to the flash every second or so... Any way to give us an ioctl() to retrieve this information? This would open up a window for applications to synchroni[sz]e (albeit primatively) with the songs. Among other things...

Also, to open up the "where do we write stuff" discussion... Is there anyone out there who's working on a method to write stuff to a raw sector on the disks? I just don't have the experience to sector-level I/O, especially when the player can lose power at any moment! The lack of persistent storage, even a relatively small amount of it, seems to be the next hurdle. We're running out of bits in that powersave flash block!

Hey Mark I tried to play with SETGEOM but I'm not getting any overlay, all I'm getting is the fullscreen behavior. I created a geom structure with what I think are the correct arguments... Did you test overlay and if so, can I get the test program you used?

Thanks.

I have not tested ANYTHING from userland,
but the overlay stuff (SETGEOM) is what is used
by the "VolAdj Knob Press Redefinition".

Any overlay you establish will be there only while
your app is running from the menu, and it will disappear
as soon as your app does another WAITMENU.

Cheers

I believe there is an existing Empeg API for this purpose, the exact same method as is used by the player software. Of course, you'll have to figure out which bytes are which.. the kernel just sees a "blob" of data going back/forth.

The existing save/restore stuff is in arch/arm/special/empeg_state.c, but all that you need to do is open("/dev/flash") (I'm not positive about the devicename), and do a "read()" from it.

Okay but how is the user program to know which flash block is the real (active) state versus ones that were saved previously? From the comments in empeg_state.c, the 128 byte block could be anywhere betweeen EMPEG_FLASHBASE + 0x4000 to +0x5FFF. Only the kernel knows which one is the current block, right?

From a very quick look at the code, the read/write seem to ONLY work on the active block. Of course, I *did* say I'm not 100% certain about *which* /dev/ entry is bound to that driver.. Do an "ls -l /dev | grep 250," to find it.

Okay the device seems to be empeg_power. I wrote a test program to read 128 bytes from /dev/empeg_power and ran it several times while a song was playing.. So theoretically each time I call it while a song is playing, the hex dump should look different. No joy. Same 128 bytes each time. I tried changing volume, changing tracks, even changing the VolAdj setting, and the hex dump is the same. So something tells me it's not just reading from the active block. I'll play around with it some more.

/dev/empeg_state might be a better bet. I think you can open it when the player has it open, but I don't have the source to hand...

/dev/empeg_power is not readable, you should get an error. It's just there for ioctls.

Hugo

Okay I was doing something stupid, reading empeg_power does yield an error.

However, the 128 bytes I'm getting from /dev/empeg_state don't seem to be changing. The code and the output looks like this:

fd = open("/dev/empeg_state", O_RDONLY);

if (fd > 0) {

   n = read(fd, buf, 128);

}

for(i=0; i < n; i++) {

   printf("%2X ",buf[ i ]);

   if( ((i+1) % 16) == 0) {

      printf("\n");

   }

}



Output:



14 B4  6 40  0 60  1 40 D8 E3  1 40  5  0  0  0 

70 62  1 40  3  0  0  0 F8  3  0  2 44 E6  1 40 

8E FF 77  1 3C 3E  1 40 60 FD FF BF DB  6  0  2 

A4 DE  6 40  0 60  1 40  0  0  0  0  0  0  0  0 

 0  0  0  0  2  0  0  0 6C 5F 14 40 A8 C2  0 40 

3C  9  0  2 2C FD FF BF  4  0  0  0  0  0  0  0 

 0  0  0  0  4  0  0  0  8  0  0  0  0  0  0  0 

 0  0  0  0  5  0  0  0 78 FD FF BF  8 F5 FF BF 

Does this look like a valid state block? Do I have to manually locate the active block or something?

The state block you posted looks possible. The last two bytes are supposed to be the CRC, so if you want to steal the crc routine from the kernel you could validate it in your readout. The 8 bytes before the CRC belong to the Hijack stuff. Take a look inside the kernel empeg_state.c file to see more about the CRC and other bytes that may mean something.

-ml

Very cool I just loaded it on mine, love the alarm will use it pretty often in my car I imagine. The flashing works at getting attention but the beeps are even better.
Could you make something to take memos or messages for cell phone?

>Could you make something to take memos or messages for cell phone?

Yes, I *could*. But I prefer to leave userland stuff like that to.. the users.

I'm not sure I understand you, please explain. I'm one user that has no skills at stuff such as this.

I'm not sure I understand you, please explain. I'm one user that has no skills at stuff such as this.


He's not referring specifically to you... It's that Kernel/programs distinction.

A lot of the stuff Mlord is adding to the kernel now, probably shouldn't be. In the Empeg, we don't have much choice, but it's not a clean design.

The Kernel runs supreme over everything, and as such, should be the arbitrator of requests. When you add programs to the kernel, they also run supreme, which can cause problems.

Windows NT is a very good example of why you don't want to do this.

3.51 had a very good kernel design, but the video responsiveness wasn't as good as 95/98... So, in NT 4.0, Microsoft changed the design to allow the video drivers to run at ring 0 in the kernel. Speed came up. Reliability went in the crapper.

Mlord has put some very nice hooks into the kernel now that allows us to write usermode programs that will work WITH the player executable. Now we just need to use them, instead of throwing everything into the kernel...

And as he said.. He's a kernel guy, not usermode...

No I didn't think it was directed totally at me. Your explaination was excellant, for I know nothing of Linux or Kernel workings.

Dont know if iis in question you have .

As I have broken my car (wasnt playing with empeg before accident) ( ;-( ), i will try to focalize on testing some stuff with my Nokia cellular phone.

1) FV Gestel has compiled Perl for Empeg. GOOD.
I experience problems to make it work.

2) I already ask the question on this board but none had answered.
Better answer is to make myself cos many people involved in empeg stuff dev
like Displayserver, fastest MLord kernels improvements.
I wanted something to manage my 6110 via Empeg.
It's almost possible cos I found gnokii
It runs on linux, empeg is Linux, maybe it will be possible on Empg. Maybe.

So I'd like to thank Mark Lord for his kernels improvements and espescially for the long knoib press to rotate in player tuner aux cos I can go to AUX when I have a call in my car (I simply cut the head phone on hand free kit then replaced with RCA cables , plugged to Empeg AUX In).

3) If you go to see Gnokii site, you will see a crazy guy made a Perl Module for Gnokii libs and control easily, manage Nokia phones via Perl.

So, I have time to try all this stuff now my car has to be repaired.
1) Find serial interface for my phone (Not so difficult)
2) Experiment Perl Stuff for Gnokii on my linux Box (A bit Harder)
3) Finalize it and test on empeg via bash.
4 Add it in userland menus from Mark Lord.

I am not a programmer, coder just know Perl programming for my job , that's all.

>Is there anyway the remap tables could be put into the config.ini instead?
>Frank would have to setup his stuff to read from that file.

Just before I disappear, I figured I might make that easier for someone (Frank?) to do.

Hijack v57 is now out, and includes a read of config.ini during boot-up. It doesn't actually do anything with the file other than read it, mostly cuz I haven't had time to do more than figure out the reading part. But if we can agree on a nice, compact, extensible format for specifying MULTIPLE sets of IR data in this file, then we can very simply have the Hijack menu extended to select among codesets.

Maybe someone will cobble it together while I'm away for the next 5 weeks.

Cheers

-ml

For this reading of config.ini to work I assume the partition needs to be mounted before the read config is called (as the config file doesn't live in the root partition)... Does this mean we need to have the partition mounted from /etc/fstab rather than a mount command called from /sbin/init ...?

Cheers

Kim

Well, the hijack code actually waits until the player s/w is initializing before reading in the config.ini (it gets read automatically, by the way). That way, we know the partitions must already be mounted by whatever mounts them (/sbin/init).

So the code is there already, TESTED (rare for me..), and there are some nice big comments pointing out where to insert code to parse the file -- hijack.c just reads the entire file into an allocated char[] buffer.

Ahh... OK... I was just wondering what difference the fact that I am using a different root might make... but I see it shouldn't make any... however the fact that it waits for the player software means that I shouldn't expect the menus to contain things loaded from config.ini if I drop to a shell before calling the player software...

Cheers

Kim