Okay, the v4x series of my patches all seem to have buggy button state tracking in various scenarios, so I've rewritten my button state tracker to clean up the logic and eliminate (all?) the quirks.

-- replaced ugly button tracker with less ugly code
-- fixed the & and ' characters in the font (they were reversed)
-- prevent overflow on input in the calculator
-- new Reboot option (with confirmation), for Tony
-- press and continue to hold knob to cycle through input-sources at 1sec intervals

This version (v45) looks good so far for me, much better than its recent predecessors.
Give it whirl, and let me know if you find any undocumented features.

http://rtr.ca/empeg/

Cheers!

Ooops.. no bugs (yet), but I think I forgot to remove a printk() from the button handler.
Expect v46 in about 3 minutes or so..

Heh, thanks for the reboot feature. I'm grabbing 46 now.

I'm about to head off on a really long drive in the morning. Hope 46 is stable.

Okay, the reboot feature rocks. Also, the hold-knob thing with switching to radio worked perfectly the first time I tried it. Did you have to do something special or was I wrong about the behavior of the Source button?

I did special stuff to make it work.

There's STILL an excess printk() spewing to the serial port on every button press, but mostly harmless. I'm now tracking down a very strange issue with the 100% setting on the blanker -- fails to fire cuz one byte is different on the screen (but it shouldn't be different.. ) most strange. Maybe a caching issue? Everything else looks really good now.

Okay, found it. Compiler bug, I think.

(screen blanker failing at 100% sensitivity due to a phantom screen byte "differing").

I was declaring a static 2048 byte screen buffer on the same line as a 1-byte variable, and the compiler just aligned them next to each other, giving a horribly misaligned 2048 byte buffer. Funny thing is, this results in memcpy not working correctly on the buffer, and neither does a hand coded for-loop doing the same copy. ARrrrggg.

Anyway, I'll hand tweak it so it works again.

UPDATE:

The scary part of this, was that the "static" local variable moved around in memory on successive calls.. static vars ain't supposed to do that! So I moved it to outside of the function, and now it stays put, and is correctly aligned as a bonus.

v47 will follow

Hmmm ....

I think I've been hijacked permanently. I just downloaded v47.voladj.hijack.v200b3.mk1.zImage and can't seem to get out of it. Every five seconds or so the screen flicks back to the visual (briefly) and then repaints the hijack menu.

>I think I've been hijacked permanently. I just downloaded v47and can't seem to get out of it.
>Every five seconds or so the screen flicks back to the visual (briefly)
>and then repaints the hijack menu.

I'm gonna need more information to go on than just that -- it works perfectly for me.

Which model of player; what buttons did you press; what did you do inside the menu; how did you exit from it; .. etc.


UPDATE:

Okay, I got it to happen here now..

For the morbidly curious, this requires a Kenwood remote. Just hit CD CD CD and watch!

v48 will be out in a few minutes with this bug squashed.
Everything else still looks and works great! (repeat 100 times..)

Okay, after a crazy evening rewriting the button tracker, and then fixing the odd bit here and there, we're up to v48 now. Here's most of what's different since v45:

--- fixed the CD/CD/CD entry sequence to allow exiting again!
--- fixed a compiler issue with 100% sensitivity on the screen blanker
--- removed some stray debugging output (printk calls)

I'm now pretty happy with it; which is good, since I'll be away travelling a lot in the near future.

Thanks (!) to "andy", there's a tuner module on its way to me, and thanks to my spouse there's a Mk2a also on the way (her car stereo just died today). So I guess we ain't done with new features here yet!

Cheers

Thank you! I'll download v48 in just a moment.

Ok, Here is a great idea. Could an alarm clock implemented in HiJack 49 or 50? ;) That would be simply amazing!!!

It sounds like more of a candidate for the first userland app to be called from the hijack menu, any takers ?

Well, I'm totally disappointed in all of you!

Ever since I introduced the Low/Medium/High VolAdj settings, nobody has bothered to point out that they all sound exactly the same! I mean, really! And you call yourselves beta testers! Hmmph.

The code has been there all along, it just never got invoked as near as I can tell. So Low/High were using the default (Medium) Vol\Adj parameters.

Anyway, while I was cleaning things up I noticed it and fixed it.

Announcing: v49: The Ultimate Empenguin Release
-- VolAdj Low & High actually work for the first time ever
-- turned off USER_DEBUG and FRAME_POINTER in the kernel config, saving memory
-- a few KB of dead IDE driver code now #if'd out for EMPEG, saving memory
-- the KNOB code in hijack is #if'd out for the Mk.1 kernel, saving memory
-- I think these kernels are now smaller than the stock v200v3 kernels

Cheers

I didn't think I could hear any difference or see any significant change in the multiplier value . I should have more confidence in my observations and report them. Sorry .

Excellent hacking btw. I'm really looking forward to future releases of this & any other hacks & apps you & others will develop. I wish I were better at programming so that I could help .

I think there's a problem ....

V49
Mark I


Internal error: Oops: 0
CPU: 0
pc : [<796e6120>] lr : []
sp : c00f5ee4 ip : c00b21cc fp : 00000000
r10: 00000000 r9 : 00000038 r8 : 000000ec
r7 : 00000000 r6 : 00000000 r5 : c00c3f74 r4 : c00c3f74
r3 : 796e6120 r2 : 00000000 r1 : 000000ec r0 : c00c3f74
Flags: nzCv IRQs on FIQs on Mode SVC_32 Segment kernel
Control: C000517D Table: C000517D DAC: 0000001D
Process swapper (pid: 1, stackpage=c00f5000)
Stack:
c00f5f00: c005d21c
c00f5f20: 796e6120 20000013 ffffffff 00000000 c00c3f74 c00c3f34 00000000 c00c3fc4
c00f5f40: c005d5a4 c009e1e4 c00c3fc4 0000001c 00000000 00000164 c00c3f34 c00c3df8
c00f5f60: 00000001 00000000 c00c3dd0 c00f5f84 c005dd88 00000001 000000e1 00000004
c00f5f80: c005dea0 00000001 c00b7200 c009c764 c00bc4f8 c00a1650 c00bd184 4401a119
c00f5fa0: c0008580 c0059b2c c0059ff0 00000001 c0055db4 c005a00c c0041f14 00000001
c00f5fc0: c009c764 c00bc4f8 c00a1650 c0009954 c009c75c c0009a1c c00c3f34 c009c75c
c00f5fe0: c009c760 c009c984 c0009a24 c0009a1c c00c3f34 c009c75c c009c760 c000b424
Backtrace: no frame pointer
Code: pc not in code space


v48 didn't oops. But it did let me out. :)

Exactly which of the kernels were you using when it Ooops'd.

Without knowing that, the data posted is worthless.

Thanks

Here is the filename:

v49.voladj.hijack.v200b3.mk1.zImage

You provide a link to only one kernel image for V49 and Mark I on your website.

I suppose it crashes immediately on boot, every time, right?

If so, then I think I see my misplaced #ifdef; affects the mk1 image only.

Right?

Correct.
Oops'd 4 times out of 4 boot attempts.

V49
Mark I
Internal error: Oops: 0

Okay, I see what's wrong. Looks like I was just slightly too aggressive with the memory scrounging.

Mk2 players can have 1/2 drives, on a single ide controller.
Mk1 players have TWO ide controllers! Cool. Anyone got 4 drives in their Mk1 player yet?

v51 fixes this problem (v51 is identical to v50 for Mk2 players).

Spiffy!! No Oops!

Uh, just to be clear about it, that would be:


V51
Mark I
HwRev: 04
v51.voladj.hijack.v200b3.mk1.zImage


No Oops.



Yet.

>Spiffy!! No Oops! ... Yet.

Just try turning OFF the voladj while playing a tune.. v52 shortly.

Yea, it got _much_ quieter .... but no oops.

Although, I got this showing up on minicom:

E !! mp3_decoder.cpp 1052: Failed to seek to offset 3751126, error=0xc0044000
E !! local_audio_component.cpp 1846: Invalid bitrate tag for FID 0xba0.

Which, i believe, doesn't have anything to do with the hijack stuff ....

Mk1 players have TWO ide controllers! Cool. Anyone got 4 drives in their Mk1 player yet?

Don't think so It's a bit short on space. Hmmm, the max height of the disks in a MkI is 19.5mm (according to riocar.org) and there are the 9.5mm disks... Even room for a layer of double sided tape!

Then there's the power supply issue - don't know if it could supply 4 disks...

I'm currently in the process of swapping disks, have a MkI with 10+18G, a MkIIa with a 10G and a loose 30G drive. Final config will be 10+10 in the MkI and 30+18 in the MkII, all data from the MkI transfered to the MkII.
Disk to disk copy is slower than I expected (no numbers tho)

/Michael

Don't forget the empeg only has an ISA bus, which is going to be the limiting factor in drive to drive copies.

Don't forget the empeg only has an ISA bus

Dopeslap! Of course...

And ISA is limited to something like 8MB/s, isn't it?

/Michael

>And ISA is limited to something like 8MB/s, isn't it?

Well.. 8Mhz * 16-bits == 16MB/sec, if it could clock data every cycle.
In practice, the limit is about half that number, so you're right on.

But the current drive-to-drive copies are probably not even close to that.
Turn on IDE multmode and they'll get a LOT faster. I'm going to include multmode=8 as a standard setting in my next hijack kernels, as an experiment (oh ye guinea pigs..)..

Can you please elaborate on "a LOT faster" ? Will those speed-ups take effect from a console prompt using the cp command?

Thanks for all your great work. Wow this is an exciting way to develop! Thank you for the hacks!

>Will those speed-ups take effect from a console prompt using the cp command?

Try it yourself, with any empeg kernel:

echo 'multcount:8' >/proc/ide/hda/settings

I'm just making that the power-on default in my new kernels.

echo 'multcount:8' >/proc/ide/hda/settings

And the corresponding for hdb/hdc I presume?

Unfortunately, as I read your post, I'm already halfway through copying the fids from the 10G and the 18G was done during the night..

/Michael