seems kinda obvious to me, but why not use the serial port? Seems like that would be the easiest thing to hack, rather than screwing the the mic or other input line.

>seems kinda obvious to me, but why not use the serial port?
>Seems like that would be the easiest thing to hack,
>rather than screwing the the mic or other input line.

Yes, just using a pin off the serial port would be easier for me, but there are tons of third party in-car projects/addons that use the serial port, and I wouldn't want any conflict with those(GPS, Palm, remote controls, ..).

Right now I'm leaning towards connecting one of the serial port output pins (eg. TXDATA) through a resistor to the MIC input. That way, I could just have Hijack toggle out a bit or two on the serial during boot, and take MIC samples to see if the two are connected. If done right, it might not even interfere with in-home use of the microphone (assuming the output pin chosen can be avoided during "normal" serial port usage).

-ml

seems kinda obvious to me, but why not use the serial port? Seems like that would be the easiest thing to hack, rather than screwing the the mic or other input line.

Well, we obviously don't want to tie serial port up, but IIRC RTS/CTS pins are connected and serial driver does not use them. Perhaps they could indeed be used to recognise 'home sled' environment.

Hm, on further reflection, I think that handshaking lined are connected to DB-9 on the empeg itself, but not to the one that is part of the sled wiring harness.

RTS? Handshaking does not appear to be used by serial driver...

Rather than use the serial port on the docking Sled, which has some drawbacks - not least a lack of connected handshaking wires.

Why not use the 2 serial port pins on the Tuner connector that extends from the Docking sled?

[I'm assuming we are all using the docking sled for in home docking as we wish to avoid the wear and tear on the 12volt socket on the empeg itself]

Hugo has previously stated that the tuner has its own seperate Serial port going to the Tuner module [at 3.3volt level only not RS232 level]. [its /dev/ttyS1 I think - do a search for 'Tuner module pinouts' post I did some months ago.]

To exploit this then all we need is a small loop back link between TXD and RXD lines on this connector.
[or some other similar combination of links]

When the empeg powers up it sends something to the serial port on the Tuner connector [before the player runs so its safe to do so] - if its gets the *same* message back it knows its in 'home docked' mode.

The only wrinkle here would be to prevent this 'message' from confusing a real tuner module if it were attached.

If a real tuner module is attached you could read the unique ID set on the Tuner module by the rotary hex switch on the side and use that to decide the settings to use for this case.

I am sure there is a message Hugo (or someone else within the group) can tell us is safe to use that we should send to the Tuner module and/or to request the module id - if we get the same packet back when we send this message we know we are in 'Tuner connector loopback' mode and act accordingly.

If we get no response you assume DC/Car mode [no Tuner attached like now]

If we get a valid response we know either we are in car with a tuner module, or we are in home and use theTuner module Id - which we ask theTuner module for, to determine which of these two modes is correct.
[I have assumed we can specify in config.ini or somwhere what the Tuner module ID is for 'in home' - all others imply 'in car'].

Thats my suggestion

Sorry, but using the "tuner port" (lack of a tuner) to detect "at home -- docked" won't work, at least not for me. My tuner module is in the home docking station, not in my car. I have a separate head unit in the car (tuner, CD, poweramp) that the empeg is used with.

-ml

Okay, Here is what I'm planning to do for "detection" of a "home docking station" for my Mk2(a) player(s):

Connect serial port Pin3 (TX-data) to Pin1 (CD - Carrier Detect). I will have the Hijack bootup code send data out the serial port, and watch for the CD line to toggle appropriately. The CD input is normally not used by the player serial software, since it is instead used for the infamous "cell phone mute" signal. Strobing a nice known pattern on it ought to prevent any confusion with a Real cell-phone mute from in-car mode.

Comments, suggestions?

Whatever we do here is likely to be copied by multitudes, so correct me now or forever hold your fuses.

Cheers,

-ml

Tuner has an ID (3 or 4 bit, I don't remember) settable via one of those tiny rotating things one uses to set SCSI address, and is capable of reporting it via its serial interface. So, idea was, if I understood correctly, to either have tuner set to a particular ID which would mean "tuner at home", or, if it is not connected, to plug into its connector a kind of loop-back thing which would connect Tx and Rx pins, which is also software-detectable. So, the SW would first test for 'tuner has "at home" ID set' condition, and if it finds no tuner at all, for 'loopback connector present'.

Ah, so CD is there in sled harness, only not in serial DB-9...

OK, if we don't hook anything to phone mute line at home, and if the player ignores the line when in home personality, there should be no interferrence. Connection can probably be done in the docking connector itself. Well, sounds good to me (but so does number6's idea).

Bonzi - you understand my idea correctly, it will support in-home and in-car tuner configurations as well as 'no tuner' configurations.

Mike: re: CD input idea
I'm not sure if your idea will work 100% as stated.

As I thought the CD pin was used for the Cellphone Mute input [which is a seperate wire on the docking sled harness].

You plan to wire the Real TX Data pin via some method to the CD pin on the Serial port/or the cellphone mute therefore allowing you to output some serial data on the serial port and check for the Cellphone mute [aka CD input] toggling in the predefined way.

However would this mean that any apps outputting serial data to the serial port [while the player is docked in the same sled] would also cause the CD pin to toggle as the data went oout and this would presumably make the player think the cellphone mute was going on and off?

Does this not effectively prevents apps using the serial port while home docked - something I thought we wanted to avoid.

Personally while the Tuner module idea is a little more complicated - it is inherently fail soft - it won't glitch anything if done right and still lets you have a Tuner module at home [which I also intend to have setup on my unit] and/or in the car.
[Simply tell the software what the ID of the Tuner module for 'home docked' is and keep the in-car and at home tuner modules Id settings seperate from each other]

However if a reliable way to use the cellphone mute in the docking station at home can be found without compromising the use of this mute setting in the car or the serial port in the home docked setting - (remember some folks may want to have this mute available in their car) then I bow to your skills
and say 'do it'.

Cellphone mute is ignored in "AC/Home" mode, so no issues there.

The serial port software ignores "CD" completely, so no issues there.

Very simple, very easy, very effective, no complexity.

Done [soon].

-ml

Using TX->CD should not cause any issues with "phone mute" in the car, because those two pins won't be wired together in the car harness. And the detection code will send a bit pattern out TX to read back on CD, something that will prevent a real "phone mute" signal from fooling it.

Looks simple to me.

What's your proposed easy way for the multitudes to make this pin connection? I can think of a few ways, but don't know if they'd be the ideal ways. ;)

Bruno

What's your proposed easy way for the multitudes to make this pin connection? I can think of a few ways, but don't know if they'd be the ideal ways. ;)

Well, for my own dock I will just cut into the cables, and splice them together, disconnecting CD from the serial connector at the same time (to prevent having two line drivers fighting over the same signal).

But a less intrusive method would be to just solder a pair DB-9F / DB-9M connectors back-to-back, and do the splice/cut therein. Then just plug the finished doodad into the existing connector.

Cheers

I don't remember what CPU the System III ran (this wasn't the OS, this was the name of the computer) but I think it was a 6502.

I'm not talking about UNIX sysIII ;)

You could get a 68k unix-type 2nd processor for the acorns though. I think it was called the "Torch".

Hugo

Okay, I've got my docking station together and running. For the serial hack I just built an intermediate cable, that connects to the docking harness on one end, and onto the factory-supplied serial patch cable at the other end. The "home dock detection" hack was added on this intermediate cable, connecting the CD signal to TX-Data.

I think most folks might want to go a similar route, since the serial connector on the docking harness is the "wrong sex" to begin with, so some kind of sex-change adaptor/cable is required there.

And, no, the software hack for "home dock detection" is not available (from me) yet. Real Soon Now.

Cheers

-ml

Ugh! Major setback.

The Empeg boot firmware (runs before kernel) performs a "power source" test, and skips the "kernel download" check if running from "DC" power.. or if running from "AC" power supplied via the docking connector. This means I cannot do kernel updates while docked!!

Shame on you, Hugo!

Any chance of a special loader from SB without this test?
Or will I have to write my own..

Cheers

-ml

Phew, I feel better now.

Never mind.. I'm just going to have my docking station use the regular AC-Adaptor plug for power, so that the boot firmware can handle it correctly. Otherwise, I wouldn't be able to download/test new Hijack kernels while docked, which was kinda the whole idea here.

This means I'm dropping the idea of doing a TXD -> DCD loopback on the serial cable (since I did it with an intermediate cable, I'll just snip one wire to restore things). This also means I won't be releasing any special Hijack support for docking, since it will just work normally with the AC-Adaptor plug-in.

I'll post some pics of the docking station details later in the week, showing how the ethernet and power plugs are "held in place".

If enough people scream, I'll add an option to "Force AC/Home Mode" for diehards who need it (anyone?).

-ml

Yes, I'd like that force mode. I suspect I'll make a dock with the new parts that come with my new unit. And my best solutions to a clean and seamless dock woul dbe to use the dock's DC connections with my own power supply inside the box.

Bruno

But using only the docking connector means you'll have to "undock" to do any software or kernel upgrades. Having a Hijack menu override doesn't help at all with this "feature".

And if you want ethernet, you've still gotta muck about a little (not much, though), and the AC-power connector is no more fuss than the ethernet hookup..

But as I say, if enough folk want the menu item, I'll probably add it, though it does cost another bit of precious flash space from the dwindling savearea..

-ml

But using only the docking connector means you'll have to "undock" to do any software or kernel upgrades.

You could also beg the empeg people to implement the upgrade-from-temporary-file feature, which would allow upgrades from USB or Ethernet...

Or offer to help them implement it...

Didn't Displayserver 2.0 somehow flash the kernel from the empeg it's self? I don't remember how this worked, since I didn't choose that route (I was using a custom kernel with the necessary IR stuff at the time anyhow).

Could this also be modified to be used as a security feature? For example, if a thief pulled the empeg out of your car it wouldn't play unless he/she either had another docking cage for car mounting or if the player detected a home signal such as resistors etc. Just a thought.

It would be a mild feature, at best, since most of us would agree that the player should still operate in stand-alone undocked condition on the test bench.

Cheers

-ml

Any idea if the flash loader is itself flashable?

If you set a link inside the player, and take extreme care.

Rob

No, because if you trash it you need to desolder the chip.

There is an internal link, which is not fitted, that enables writing to the flash chip (addresses <0x4000 are protected; the bootloader is 0x0000-0x1fff, the ID information is 0x2000-0x3fff). DO NOT fit this link (it's labelled PROT) unless you *really, really* know what you're doing. There should never be a need to fit it.

There are 2 paths for the boot; if the boot is a normal one then it jumps to 0xe000 (which *is* writable) with r0=hwrev, r1=ram (MB), r2=rom (MB). Early mk1s didn't set up registers like this though, I think (if r0 is >9 then assume it's rev3).

If the power up is a watchdog powerup (ie, powering up from deep sleep when the sleep timer expires in the power control PIC) then 0xc000 (again, writable) is called with the same r0,r1,r2; this obviously only applies to mk2/mk2a's as mk1s didn't have a power PIC.

The default action of 0xc000 code is to send a "deep sleep now" command which makes the unit go into indefinite power down (no automatic wake). This is just in case the power PIC ever thinks it has its sleep timer set - we don't use it yet.

The idea with 0xc000 code is that it can do something (check the RTC, for example) and if a condition is met then it will call e000 and cause a full boot (or boot linux with different command line options). If the condition is not met, it can sleep again. This gives very low power sleep (<5mA) but can be set to wake up with ~30s granularity if required; if it wakes up too early, you get about 200mA current drain (no display, no HDDs) for a fraction of a second before it goes into sleep mode again.

Hugo

>There are 2 paths for the boot; if the boot is a normal one then it
>jumps to 0xe000 (which *is* writable) with r0=hwrev, r1=ram (MB),

I take it the code which checks for DC-Power and decides to skip the flash loader prompt must be in the protected area, rather than up at 0xe000, Right?

-ml

Yes, it's in the protected area. If you're thinking about applying upgrades though, you can do this from userspace using the /dev/flash-xxxx (?) files. You can flash everything that is flashable from there.

The initial code is very simple and doesn't rely on *anything* apart from working RAM to get into the reflasher - this means you should never not be able to reflash a unit. If you enter the test program, this doesn't even use a byte of RAM until the ram has been tested...

Hugo