Hijack v505 is now released. And I'd like people to try it out soon-ish if possible, and let me know if it causes any new problems.

The one change therein, is that the I2C "start" sequence has been shortened, by removing an unneeded "clock low" at the end of the "start". This means that code which talks to the DSP chip will be slightly quicker than before, running with interrupts disabled for a shorter period of time. All nice and good .. if it works reliably.

Tested and working reliably here on a Mk2 and a Mk2a unit.

* * *

Hijack v504 was released earlier, and has a single change to increase the tolerance for disks responding slower-than-spec to a WRITE SECTOR(s) request. This appears to solve a problem with Transcend SSDs in the empeg, and is totally harmless otherwise.

Cheers

Hi,

I installed it on 2 each Mk2 (12MB RAM), and 8 each Mk2a (16MB RAM - not expanded yet, still looking for chips) Empegs (10 Total Empegs).

I loaded some older hijacks to test. I upgraded v440, v444, v461, v464, v488 to v505. Didn't try non-hijacked Empegs, didn't care because of big drive final configurations.

Had some older drives that I upgraded from, tried those. Disk configurations included dual 12GB, 20GB, 30GB, 40GB, 60GB, 120GB. I even tried it without drives in the Empeg.

Final disk configuration was v505 plus dual 250GB in them.

I tried loading with the existing databases and they were unaffected.

I tried to corrupt the load by disconnecting the power while loading. I know, not a smart thing to do, (just thorough testing), but, I did it on one of the old Mk2s with 12GB drives installed. It recovered fine and programmed v505.

The Mk2s loaded slower (about half as fast), expected I guess, less RAM.

It still fixes the Temp Sensor Bug.

All of the vital signs looked good after the load.

I have tried it with and without reserve cache in the config.ini, the final configuration has lots of playlists & lots of songs (>30k songs).

The v488 Pump 5 Error Bug is confirmed fixed in this version too.

Emplode v2.01 saw all of the Empegs with v505. Didn't try earlier versions of Empeg Software or other software.


Looks good to me......


By the way who is Schofie? Popped up today. Happy birthday anyway... another Easter Egg, how many are there?

Hope you all had a Merry Christmas and will (are having), a Happy New Year.

Ross

Dude, do you want a job in software testing? We could use someone that thorough.



I'm guessing Rob Schofield, long time friend of the Empeg crew, host of many international empeg meets, and the official Europe/UK repair guy.

Hi,

<< Dude, do you want a job in software testing? We could use someone that thorough. >>

No, I'm a Analog/Signal Integrity/EMC Hardware guy. In a previous life I tested/broke/fixed DOS,Windows,Unix X-Windows video drivers for Video Controller cards/chipsets & Display designs though. Got to be thorough there.

This was one of the reasons why I purchased so many Empegs from the community & ebay besides having them all over the house and cars. It wasn't too tough to bring them all together for the test effort to give back to the community.


Got it about Rob.

Thanks,

Ross

Hi,

I have had my main computer Empeg running for a few hours now to see if any "features" show up with the DSP timing. Not a problem seen even with bouncing around the playlists invoking .wav & .mp3 songs intermixed with pauses, Ffw, Rew, stops, random playlist selections, etc.

No artifacts heard (Empeg RCAs -> Adcom GTP-502 Pre-amp -> Mitsubishi DA-A10 Power Amp -> Klipsch Heresy's), normal disk access, no display anomilies, normal front control operation, normal remote control operation, normal thermal. There was the normal pause while filling the buffer with .wav on the first song only. I did notice an extra pause once after the first hour of play, but I wouldn't call that a problem yet.

Still solid.

Once again Mark proves that he is the "Master" and not the "Slave" of code.

Thanks Mark!

Ross

I've been working on mine as well -- and it seems ok - but the artifact is still in there.. I emailed Mark already.

But so far, the firmware isn't causing any problems for me either.

Thanks to Ross, Ben, and the other testers for looking at v505 in detail here!

Hijack v506 is now released, with a substantial rewrite/simplification of the I2C code, reducing duplicated paths and speeding it up quite significantly in general (important, since it runs with interrupts disabled at times).

This probably results in bit-to-bit timings closer to Hugo's original code, way back before I ever began hacking it (years ago), but faster overall due to shorter start sequences.

Cheers

And now Hijack v507 is out, with one more microsecond shaved from the clocking of low data bits.

Release early, release often!

Cheers

I'll play with it in the next few days. Too much going on right now.

Ross

Ditto --- and I'll make more scope shots...


-Ben

Ok, looking at v507

SCL+ = 1.12uS (too short)
SCL- = 2.40uS (ok, but possibly still "too short" for 100K resistor)

SDA RiseTime to +5 = 31.2uS ~= 32KHz

This is too long a rise time with the Fan installed for even 100KHz operation. (hi/lo times == 5uS/5uS)

I'm stuck to test without my scope since I can't do measurements without it on the line. So I would say if anyone has problems with the I2C devices on the bus, to change out the 100K to 5.1K.

I think it works by the luck of the draw as most of the bus ops are WRITEs where Mark has control of how long he wants to delay between writing a 0 or 1. (With 1's being a longer "wait" time before asserting SCL)

If someone tried readbacks, they'd have to wait a while before each clock (32uS). Even with those delayed writes of 1's, the risetime only allows for about 3.3V level. SO it works - but only because it's coded to.

What would you guys like to do from here?

-Ben

I'm happy with how it looks now. Logic high is not +5V -- it only really has to clear a bit beyond +3V for that, which it is doing.

The timing is now very similar to how the factory kernels do it, except Hijack now allows one extra microsecond for logic 0->1 rise time on SDA before clocking the bit out.

So, very safe for stock hardware.
How's the fan controller dealing with it now?

Cheers

I see what you're saying... and thankfully right now there's no readbacks being done.

The fan controller seems to work ok with and without the scope probes with 100K.

In the future however, hopefully no one will ever need to do actual reads on the bus, because then the rise-time wouldn't be enough to clear a '1' at the current clock rate unless some big delays are added between every clock pulse.

Personally, I'm changing mine back to 5.1K so that it could actually operate to specifications based on a 400KHz clock.

I don't have warm fuzzies about the current 100K resistor.

Thanks for all your help though... simply fabulous.

If you want, post that last PNG I sent you if everyone else would like to see.

Ciao,

-Ben

Well, there is a lot of reading done by the CPU over the I2C bus when accessing the DSP registers as part of ordinary sound playback and stuff.

For that direction, the kernel always uses the stretched 15us+ clock intervals, regardless of bit values.

Ditto with the fan controller -- reads get done there, too.

Here's your last scope picture from Hijack v507 (thanks again!)

Ok, as long as they are long. (I think 14uS was needed to hit 3.3V)

So I think we're good. But yeesh, a 4.7K or 5.1K would have let that bus run at full speed with no monkey business. (400KHz)

Anyway -- thanks again for all the help. As I saw in another thread, "You Da Man!"

-Ben

Hijack v508 is now released.

The only changes are those required to support 12-byte SAT commands (ATA passthru), as used in hdparm-9.8.

An updated binary of hdparm-9.8 is also now available from the top of the Hijack website. This fixes a few bugs having to do with LBA48 usage in Hijack, and compatibility with LBA48-incapable drives.

Full source code for hdparm-9.8 is available from its home page at sourceforge.net.

Cheers

Hi Mark,

What version would you like me to test over my Empeg set?

Thanks,

Ross

Hi Ross,

There's no particular need to test anything for the sake of testing. But you could install the latest Hijack (v508) onto a couple of your players and confirm that they still play mp3s normally.

Everything is working fine here on my own Mk2 and Mk2a players, so there's not much to fuss over at the moment.

Cheers