I was wondering if it would be possible to add a force home/ac mode option to the hijack in the same way we have for car? the reason for this is im going to be using my empeg in a docking station at home and will be using the car sled to do this - would be great to have it forced to home use (for EQ etc.)

Mark, this might go without saying, but if you implement this, it'd be nice if it were just one menu entry instead of two. Like "Select power mode" with the options "normal, force AC, force DC" or something like that. I think the number of menu entries is getting a little crazy. Any chance you'll start breaking some of these options into submenus? I realize it's not the most important thing on your plate but scrolling through the long list of menu options some of which I never use gets to be tedious.

Actually I just looked and it's pretty easy to comment out hijack menu entries in the kernel source. Maybe I'll just do that.

I am also going to be assembling a home docking station for the player, and I think I will hack the hardware slightly to allow automatic detection of the dock, perhaps by looping back a wire on the serial port or something.

Anyone got any suggestions, before I invent my own hack here?

I have already seen the "support the ac-adaptor plug" method (with photos!), but would prefer to save the wear and tear on that connector.

Cheers

-ml

Actually, I might use the MIC input as my dock-detection method, by just wiring a ???-ohm resistor across the wires from the sled. Nice, safe, and easily duplicated by others on the BBS.

??

Until they come out with VR, then you're going to want to use that Mic input.

>Until they come out with VR, then you're going to want to use that Mic input.

Oh good. In that case, it should be a VERY safe bet for me to use the MIC.
(I'm not expecting Empeg VR in my lifetime).

-ml

I like the MIC input suggestion! When VR does come around, you could change it to something else.. What about using the Telephone Mute line held to a specific value. I don't recall what triggers it, but perhaps it can sense a voltage level vs. a specific 1 or 0 state.

yea any of these suggestions sound good to me. I would also like to avoid the wear and tear on the power socket.

Oh goodie!

The cellphone mute input is even better, since it wouldn't normally have any use when on AC power.

Can somebody scrounge around the kernel source to find where this bit can be read.. I'm kinda busy right now with other Hijack priorities.

Thanks

-ml

Hi.

If you use the cellphone mute to detect AC/at-home operation, how will you differentiate in-car use with an active phone (at empeg startup) from at-home usage?

cu,
sven

I agree we will never see the VR on these units by empeg anyway. So lets use that.

But as a side note to this feature, I have more than one vehicle that I use the Empeg in. And the volume setting is different for each. In one vehicle it is the main head unit(only head unit) and the volume hence doesn't get onder 15 or so on the volume at max. While my second vehicle it is the secondary head unit with my Alpine CVA-1005 as the main. For the empeg to play at the same volume as the cd changer and the radio it must be cranked to 4-6 on the volume. When I swap the unit back and forth the volume is too loud in the first vehicle. I can't always remember to turn it down beforehand. So.... If there was a way to designate, via the mic input, what vehicle it was in for a volume setting and possibly other settings. This would solve the whole issue of where it's docked. Different resistor for let say 3 or 4 different docking modes, if we need that many.

Okay, so we're back to using the MIC input for sure.

So.. can you now dig around in the code to figure out how I can "read" the MIC input? That will save me a ton of time when I "get to" this feature next week.

And possibly even try/suggest some suitable resistor values (I'm a software geek.. I'd rather have a practising engineer type figure that stuff out for me)

Thanks

-ml

The mic input, being for audio, is AC coupled. Any static voltage (eg a resistor) won't be detectable.

Hugo

GPLR&EMPEG_SERIALDCD is phone mute, GPLR&EMPEG_SERIALCTS is light sense.

Hugo

(...intrigued, so he ventures out on a limb....)
Those are boolean values I assume? Or is there a way to measure analog levels on those inputs?

BTW: I was reading on /. about old bbs' when I came across this link and who do you suppose is the first name on the list, but our own Mr. Fiennes. I think I'd heard that bit of trivia somewhere, but wouldn't have been able to recall it. Boy, it is a small world when you're leaving foot prints around isn't it?

>The mic input, being for audio, is AC coupled.
>Any static voltage (eg a resistor) won't be detectable.

Will it pass 60HZ (or 50HZ for you islanders)?
Or possibly double those frequencies if I cobble some diodes together?

What sort of voltage .. 0-1V okay?

And where do I find it and how do I "read" it?

Thanks

Boolean, there's no A/D on these lines.

Yes, I wrote ARCbbs a looooooong while ago! Actually, many of us here were known in the acorn scene: I wrote ARCterm (all the versions, ie 3 (pd) 6 & 7 (commercial)), ARCbbs, the Telnet/rlogin client for the ANT internet suite, the server/user management tools for ANT multiuser suite, a very good 3270 emulator that got canned when the company went bust, the first soundtracker player on the ARM CPU, and some of the very first "scrolly" demos for the acorn.

Patrick did the 2 port serial cards for the acorn (I did the firmware), and we co-developed many of the acorn SCSI cards (me doing the firmware again). He also did the Graphics Enhancer for the acorn, a 56001 DSP card, and more strange stuff.

John Graley did a great acorn demo (!funkydance?) and probably a lot more stuff I don't know about...

Rob ran an Acorn BBS and did the PC keyboard interface box with Patrick, plus lots of other stuff...

Toby did a lot of acorn bits - some educational software, for example - plus lots of graphicsy things.

Peter wrote a lot of the ANT Fresco browser, and before, when he worked at Iota, did bits of Animator. Also known for his GIF optimisation/animation tools.

I'm sure I've missed a lot out, but those are the acorn links I know of. Mike was a QL user, so missed out on the rich vein of acornism ;)

Hugo

It should pass 50/60Hz, yes, but there's not a lot of that about in the car. 1v should be fine. Sampling frequency is up to 29kHz.

See empeg_cs4231a for more info.

Hugo

As Mark is look to detect when it is docked at home that shouldn't be a problem...

Is there a reason I have no idea what an Acorn is? Is it a platform that didn't catch on in the States or something?

Acorn are the company which made the BBC B computer in '81/'82. This box was the equivalent in the UK of the Apple ][ in the USA - expandable, solid, etc. The BBC B was much more advanced than the apple, but was made later on... it had multiprocessing options & lots of good stuff (second 6502 cpu, second z80, second 32016, second 68000, second ARM1-development-cpu). There are emulators available, and the games were arcade-quality for the time (unlike the apple ][!) - eg, Rocket raid (scramble), Snapper (pacman), Meteors (asteroids), etc. The BBC games scene produced Elite, which was well ahead of its time!

Acorn had networking done & dusted very early on, too. Back in 1980 you could buy fileservers (System III, I think) and clients (Acorn Atom) from them running Econet (about the same as Appletalk in terms of speed & wiring). Allegedly, Bill Gates came to see them back in the early 80's and they offered to show him their networking technology - his reply was (allegedly, again) "what's networking?"

For the followup, acorn looked at existing CPUs, didn't like any of them, and so invented the ARM CPU in-house. Silicon worked first time, and by '87 they were selling the Archimedes range of ARM2 based machines, having also designed the A/V chip, the IO controller and the memory controller. Lots of us in this office got our hands on ARM CPUs back in 1987 :)

ARMs got very sucessful, as you probably know. Almost every mobile phone has one, they had 77% of the risc market share in 2000 (cf mips 11%, hitachi sh 7%, power pc 3%, other 2%).

Acorn never managed to get the hang of marketing though; the products were good but a bit expensive and never mass market. Like Apple, they sold well into education until PCs just became unbeatable. Rumour has it that the ARM was almost used for Apples instead of PowerPC.

What was left of acorn spun-off a chip design part (element 14, which then got bought by Broadcom for megabucks) and the remaining machine design part got bought by Pace, who make set-top-boxes. Acorn at that point was worth rather a lot less than their share of ARM!

...and there the story ends. A lot of ARM is made up of ex-acorn bods, and it's almost impossible to go into a pub in cambridge without running into people who used to work for acorn.

Hugo

Hmm. In theory, you could make a VERY simple PIC board to connect to the tuner module port and report a device id of (say) 15 to indicate in-home. It could be done on a 12c508 with external crystal, only needing a voltage regulator and a few resistors.

Hugo

Very cool background, thanks. I have stumbled upon the Acorn name in my travels looking for ARM assembly code, etc. but didn't know the lineage. Yet another example of how bad marketing can doom a product that has a lot more potential than the competition.

Or, rather, how superior marketing can squash otherwise superior products.

Or, rather, how superior marketing can squash otherwise superior products.

Yep. Around here we call it the IBM principle.

IBM = Inferior, But Marketable.

(equalp MS "Marketable Shít")

Edit: Didn't notice that it censored me. Oddly, sometimes I can get out a shít and sometimes I can't.

God, I really need to cut down on the scatological references today. I'm really going overboard.

Tsk, how could you bring up the keyboard interface (let us never speak of it again) but not mention Noddy's Playtime

Rob

(equalp MS "Marketable [censored]")

Just doesn't have the same effect when the BBS censors you. :)

Jebus, I vaguely remember Noddy's Playtime. And I've long been familiar with the BBC and Archimedes, since I used to be heavily into the European computer scene for a North American resident. :)

Did the c64 and Amiga thing though, as expected. The Archimedes had stiff competition from the Amiga and Atari ST. Apple wasn't a factor for the Amiga with the Macintosh in the home, but surpassed everyone but the PC clones elsewhere. Apple's market has grown, thanks in part, to the demise of all these other machines.

I was looking through the BBS list linked earlier today. They're missing a few of the most popular c64 BBS programs - they were definitely used around the world, but they originated here in the Toronto area. One of my best friends (who I happen to work with now) actually was responsible for an assembly version of one of them. I also knew the original programmers and people in the companies that released the others. Not to mention the people behind a couple of the more popular Amiga systems. And the person who wrote a large bit about one of the big Amiga programs on the website used to live around the corner from me. I also managed to find out that one programmer, whom I had also met and whom my friend was one of the original beta testers for his BBS program, works for Microsoft and was the person behind the compression in their CAB files (LZX-based). Small small world.

It would be a kick to find out where all sorts of people are today - I used to know a number of people in the UK back in the hey-days of the c64 and later Amiga.

Bruno

Let us make this clear: you had System III running on 6502!?

Ah, you said 'Acorn', not specifically BBC B. Which hardware file servers were running on?

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

>I was wondering if it would be possible to add a force home/ac mode

Done. v95.

Okay, good.

Maybe after I get the FTP/rexec server into my kernels, we can hack together a quick shell script to do kernel updates via ethernet.

Cheers

wow, thanks alot. Shame the auto detection thing didnt work out, but this is fine for me anyway as i'll only be using this unit at home.

Will post some pics of my docking unit when my second empeg arrives and i can finish it off.

Thanks again, and thanks for all the great mods!

No shortage of Hijack requests here...

How's this one sound. In another thread we've been discussing how sometimes people accidentally push the knob when they're trying to change the volume. I happen to suffer from the opposite problem. I'll be trying to push the knob and it'll rotate to the left or right one click while I'm pushing it, causing it to change volume instead of bringing up my hijack popup menu. Not desirable.

So how about a (possibly configurable) threshold where the first one or two knob twists in a given direction are thrown away, after which they are all processed normally. Not everyone would want this obviously so I think it'd be disabled by default and only enabled with a config.ini option.

This is along the lines of strange requests, but I don't know if it's any stranger than the "jog dial" for changing tracks.

Oddly enough the knob on my old Mk2 was less prone to this type of error. I think something is "off" mechanically on my new knob, but it's not major enough to have me send it across the pond.

I sent my back for that exact problem, but mine was so bad that the knob-push was effectively unusable. David Moss said that the guys up there were going to use it to test a remedy. I didn't get any updates from them, so I don't know how that came along, but, then again, I don't really care, since I have a knob that works now. Nyah-nyah!

>So how about a (possibly configurable) threshold where
>the first one or two knob twists in a given direction
>are thrown away, after which they are all processed normally.

I've also been thinking about something along these lines. I think the "Rotary Knob glitch" patch (now in beta7) is partly responsible for the increased glitchiness of my player's rotary control.

I suppose we just need to hack the knob driver to ignore spin's that (1) occur while knob is pressed, and (2) occur within a few msec's prior to a knob press. Simple enough to do.

-ml

I like the way you're thinking. Though I don't think I'm running the rotary fix patch unless it's part of the hijack patch. I didn't like the results with the rotary patch so I think I avoided it.

But I love features 1 and 2. Great ideas.

All (even non-hijack) v2.00beta7 kernels include the rotary knob patch as a standard item now.

Hijack v96 now has added deglitch logic to try and prevent accidental rotations when pressing the knob. Let me know how it works for you.

Okay, implemented in v96.

Hi Hugo.

Just to get this straight:
Flash areas <0x4000 are actually _not_ flashable without tempering with the hardware.
Flashareas 0x4000 and above are flashable from userspace (after the empeg booted, obviously) or via the serial update route which is even available when all writable areas (0x4000 and above) have been overwritten with random data. Right?
So if I would implement a special function into a user level ftp daemon to do abitrary writes to the flash and totally hose all writeable areas of the flash in the process, I would still be able to apply an upgrade using serial, right?

cu,
sven

Yes, it's designed to work that way.

Hi.

Not exactly related to this thread, but to the subject:
Another question I have regarding home docking is this: If I dock my MkII(a) at home, using the sled, but powering it using the AC adapter (and thus enforcing AC mode), will the player still look for and use the tuner module?

cu,
sven

PS: Sorry for posting this somewhat unrelated question in the thread, but I felt that opening a new thread wouldn't have been right.
PPS: I really need to go to bed now, it's almost 4am now and I need to get up again by 7:30am.