Okay, this is a call for somebody to implement something that is (1) useful, (2) moderately easy (for a kernel hacker), and (3) a freakin' great way to get involved and become a Hero!

All Empeg/RioCar units have a USB-slave port, even the "lowly" Mark-1 units. But currently, this uses a dedicated (though "open") protocol, which only talks to the Rio tools, like Emplode.

But.. since it's all done in Kernel space, we have source code for it all. So..

Let's modify the driver to emulate a USB-ethernet adaptor.

This mostly would involve just changing the way the existing driver identifies itself over the link, and then tying the read/write interface into the Linux ethernet driver models. Lots of example code exists in the kernel today for all of this, so figuring out what has to be done is not impossible for a moderately skilled hacker.

Why? Because this would then make the Empeg, any Empeg, appear to be ethernet connected to the host computer. This means that standard applications built upon TCP/IP would then be able to communicate with it under Windows, Linux, or any other OS that supports USB-Ethernet adaptors.

This would enable FTP, HTTP connections to the player, without an ethernet card or hub, even to a Mark-1 player!

CL, Eh?

All we need is somebody willing to have a run at it (I'm booked).

That would turn many of us MK1 owners into happy campers A long tme ago there was talk of HTTP over serial but nothing ever became of it. The Hijack mods are the only thing that makes me like my MK2 over the lowly MK1s, in the car playing music there's no difference.

Alan

Would it have to emulate a specific Ethernet adaptor, or is there a generic USB Ethernet device class and driver (like the mass storage one) ?

I don't know if there's a generic one. If not, then just pick a very common one to "emulate", such as "Belkin" or "eTEK", with which the 2.4.xx usbnet.c driver already knows how to communicate, as do the win32 drivers.

-ml

Well, I have experimented with some same ideas, but at userspace level. I've got proxy-software running on windows, which is fed into the usb channel. On the empeg side an app is listening on usb and forwards data to a tcp port. The windows software is working; I haven't got a working empeg client yet.
Unfortunately I'm not skilled as a kernel programmer; I know most modern programming-languages, but nothing hardware-related. How to write an ethernet-adapter-driver for win32???
If nobody takes up on the task, We can allways use the proxy idea. let the proxy-server map ports on the windows machine to the empeg.

Well, if you really want to just support the one platform (specific windows version), then I suppose the protocol to use would be PPP.

If you can get a windows PPP client pointed at the USB, then on the Empeg side it oughta be pretty easy to get PPP running off the USB as well.

But more complete solution would be ethernet emulation for some popular USB-ethernet device, so that we get multi platform support out of this.

Cheers

Oh.. the idea here is NOT to write a driver of any kind for Windows or Linux or MacOS, but rather, to modify the Empeg's USB-slave driver to emulate some existing USB-ethernet device, for which drivers are already available under Windows, Linux, MacOS, etc..

Cheers

I had been looking around, and I'm unsure if any existing USB-ethernet-driver will work with the empeg USB-port. I though that every USB-implementation had specific channels and speeds to which it is restricted.

If this can be done, it would be brilliant. Excellent lateral thinking.

A long time ago, there was a lot of talk about implementing PPP-over-USB, but I don't think anyone ever got it working under Windows.

What would be exceptionally cool is if we could choose to emulate a driver for which the default install of Win98-and-later automatically includes a plug-and-play driver. That way, you could just plug the empeg into the PC and it would just detect it.

Dunno how to have it handle the case of two possible USB devices on the same wire, though. Because that USB wire already identifies itself as "Empeg Car" or whatever when it's plugged in. So is it possible for the driver to fake the computer into thinking it's two different devices (Empeg USB and a faked USB ethernet adapter) at the same time?

How about emulating a USB hub? Then have these virtual devices hanging off that?

This is getting to be quite complicated!

- Trevor

I've just downloaded the belkin driver for win32, hacked up the inf-file, deleted the empegusb entry and added the belkin one. I started a 'cat /dev/usb' on the empeg to see if something was sent and rebooted the PC ( win2000 ). After reboot the device is inactive with error :

This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)

No output showed up on the empeg side. I replaced the USB-id in the inf files, but that is probably not the way it is going to work...

I think you may have to also hack the empeg driver in the empeg kernel for the detection to work correctly, though one would think hacking the .inf should have come close..

??

Yes, you've gotta hack the empeg usb driver itself (in the empeg/hijack kernels) so that it identifies the empeg as a network device.

-ml

No need for more than one device.

So long as it can do "ethernet", Emplode can talk to it.

Do you know that is true for the Mk1 ? Do we know that the player is the same on both Mk1 and Mk2, it is possible that the Ethernet side of things is complied out on the player as well as the kernel ?

usbnet is *not* what you want to emulate - that's a usb host-host adaptor.

You want to emulate something like a pegasus. Should be quite possible.

Hugo

According to the USB specs, it is quite allowed for a "physical unit" to have several "logical interfaces"
My D-link cheap-cheap digital camera is both a digital camera and a digital video camera when connected to my laptop.

The ideal solution would (of course?) be that the empeg player has both an ethernet "emulation" and a storage device "emulation", that way, it could be mounted as a "harddisk" on quite a lot of OS platforms.
The "read file" for mp3 files work seems to have been done already by mlord. Writing mp3-files to this disc, and having them show up in the playlists may be trickier, but not too much...

(I wish I had more spare time to write cool projects like that)

Marius (Escort Cab + Mark II)

The ethernet and tcp/ip stuff IS missing from Mark1 kernels, and maybe from the player binary also. But once we get the USB thingie working, we'll find a way around that issue too.

-ml

Okay, that's a cool idea -- emulating a mass storage adaptor, in addition to the ethernet-device emulation. I like it, especially for Mark-2 players! I like it A LOT!

You're right about not needing to emulate the empeg USB interface.

Since the USB driver needs to be changed anyway then the Mk1 kernel would need to be recompiled so adding back the ethernet and TCP/IP support is just a matter of turning it back on.

Another matter would be the player software though... Anybody want to try running the Mk1 player binary on their Mk2 to see if there is any TCP/IP support in it? Unless somebody at empeg can tell us?

- Trevor

I was rather thinking of doing it the other way around.. perhaps trying the Mk2 player on a Mk1 unit, once the ethernet is functional.

But that will probably just run us out of memory or something, in which case we leave in the dedicated USB functionality, in addition to adding USB-ethernet and possibly USB-mass-storage to it's bag of tricks. The TCP/IP will allow things like kftpd/khttpd to be used, and in the worst case emplode can just muck around with the dedicated USB interface as before.

-ml

I have just checked the two player exes, they are definitely different.

mk2 - 1323440 bytes
mk1 - 1192632 bytes

I think someone did a ext2 fs for windows, didn't they? You'd really need that to make it useful to "normal" users.

You should also be aware that the USB chip in the mk1 is particularly pants and will drop packets fairly often (maybe 1 in 100000 32byte packets). The mk2 controller also does do the same, although less frequently.

Hugo

Every day I visit this BBS I seem to learn a new British English word. I had never heard something described as "pants" before... For those Americans (like me) who are interested...

In reply to:

---

“It’s pants”
An informal survey on the usage of the term 'pants'

Gareth (from Wales): "It means something's bad, something's rubbish. It's an exclamation of displeasure. It is not swearing..."

Amanda (from London): "It's a way of converting rude swearing to mild swearing."

Andrew (from Lancashire): "It's pants. It means 's***' or 'crap'. It is not swearing, but I wouldn't use it in polite company. It might be used as a substitute for 'that's bollocks'".

Lindsay (from Glasgow): "It means that's crap or rubbish. It is not swearing, but I wouldn't use it around older people."

Contributor Judith notes: "I have only heard 'pants' used by a young man at work. I used to work in <government department> where they are very politically correct in everything. The man was reprimanded for using the word 'f***'. He started to use 'pants'. I recently read in <newspaper> that pants meant 'rubbish'. In my teens my peers used to say knickers. We used it as a 'polite' way of saying 'f***'. So when my colleague used 'pants', I thought it was just a male gender version of 'knickers'.

The archives at deja indicate that the term 'pants' has been used on the television programmes "The Mary Whitehouse Experience" and "The Young Ones".

---

Taken from http://www.alt-usage-english.org/ucle/ucle9.html

A very on-topic post, I know...

Every day I visit this BBS I seem to learn a new British English word. I had never heard something described as "pants" before.

Americans and other aliens should also note that -- while "it's pants" is an expression of disapproval -- "it's the pants" is short for "it's the ants' pants", an expression of approval.

Emphatic forms of the disapproving version are "a pile of pants" and "a bag of pants".

Peter

Do you guys find American slang as cool as we generally find British slang?

I dunno... "That's the bomb" just doesn't hold up does it... Which begs another question... is the slang of British youth as different/annoying as it is in America?

The main difference is that young American English slang is usually just co-opted Black English slang from 15 years ago. British English has a wonderful history of slang that American English has never even begun to have. For example, the height of American English slang paradigms seems to be to invert the meaning of a word (``bad'' for ``good'', etc.). The height of British English slang paradigms seems to be to rhyme the word you're slanging with a multiword phrase and then drop the last word -- the one that made it rhyme in the first place (``butcher's'' for ``butcher's hook'' for ``look'', etc.). Judge for yourself which is more interesting.

The height of British English slang paradigms seems to be to rhyme the word you're slanging with a multiword phrase and then drop the last word

That's cockney rhyming slang, and nobody really uses that now - with the possible exception of used car salesmen and characters in movies such as Snatch.

Rob

Americans and other aliens should also note that -- while "it's pants" is an expression of disapproval -- "it's the pants" is short for "it's the ants' pants", an expression of approval.

We have the same thing here. Fairly recently, "It's The Shit" has become an expression of the highest approval. You wouldn't necessarily use it to describe another person, but you certainly would use it to describe a nice gadget. The car player, for example, is definitely The Shit.

Word.


Back on topic, this thread is way beyond anything I could contribute to, but I have to admit an odd facination with it. Quite the interesting project!

The car player, for example, is definitely The [censored].

And all sorts of rap-inspired variations, such as "Tha Shiznit", "Tha Shizzle" and, my personal favorite, "Tha Shiz-nizzle."

Back on topic...

The ideal solution would (of course?) be that the empeg player has both an ethernet "emulation" and a storage device "emulation", that way, it could be mounted as a "harddisk" on quite a lot of OS platforms.

Wouldn't this require writing two win drivers. To have the camera appear as two different devices windoze loads two sets of drivers and they appear in teh system properties as such. Although it would be cool, it's a bit out of the scope of this project.
Having a set of drivers loaded on the empeg itself would be great. plug the player in and it gets recognised as a riocar audio player, USB ethernet device and an external hard disk. Where are the drivers for the hard disk device stored? On the player itself which is accessed in the setup process through the TCP/IP address which was loaded earlier!

Now that's the Da Pantsshizzlenit!

Yes... as seen from windows, the still-picture camera and the video camera are two separate "devices".

For the empeg, we won't write any windows drivers, we'll use the generic mass storage for "disc emulation", we'll use an existing ethernet driver for "ethernet emulation" and we'll use the emplude-supplied drivers for empeg-USB.

*Windows will then "think" that there are three separate devices connected.

(A conditional "will, if this project is implemented the way I think is the best way to implement it")

Marius (Escort Cab + Mark II)

I saw this Movie last week.

I tried to watch it in English but I couldn't understand most of Brad Pitt's sentences....

Anyway this movie isi very very good and funny !!!!

I tried to watch it in English but I couldn't understand most of Brad Pitt's sentences

That's alright, neither could us Brits !

Perhaps, but it certainly existed and was fairly widespread, and is vastly more interesting than anything we Americans ever came up with.

Though a USB device can have multiple profiles, only one can be active at any one time (as far as I'm aware, anyway!). So you'd have to choose which one you wanted (maybe with a hijack menu).

The mk2 has softconnect, which means in software we can simulate a bus disconnection/reconnect, which should mean you wouldn't have to unplug the cable when switching profile.

The disk profile is going to be the easiest to start with. You won't need to mess with a lot of the usb driver - the enumeration should be fine, for starters.

Hugo

I think it's so cool to see Hugo here offering tips. This is a really cool idea for a project and I'd like to see it work. One thing, though:

The mk2 has softconnect,

Which is nice, but it's the Mk1 owners who would benefit the most greatly from this project.

Somebody else suggested that if we emulate a USB Hub, then we might also be able to emulate (simultaneously) all three "devices" attached to it: (1) Empeg/RioCar, (2) Mass Storage Adaptor, and (3) USB-Ethernet.

I'd leave the hub thing for later, though. Get something simple working first, like the Mass Storage emulation. But then, {b]I am not working on this particular project.

-ml

Emulating a hub and downstream devices would be hard; the USB controller only responds to one device ID programmed into the address register.

I don't think changing the ID on the fly is possible. You're going to have to pick one and just be that device I suspect.

Hugo

With the three options of what it shows up on the USB as:
1 - Empeg custom device (as normal)
2 - Ethernet adapter
3 - Mass storage device
I can see where it might be helpful to have 2 & 3 at the same time, but it seems like it would be a very minor inconvenience to have to reboot to change between the two. With a reboot time of <10s, it's on par with Windows normal USB detection times for a device that's already on

If option 2 were implimented, would there be any advantage to switching back to the default (1)? I only ask since someone posted the desire and I can't figure out why.

Since I've got a Mk2a, I'm not as interested in option 2 as I am in option 3. But I think there's more Mk1 owners who would rather have option 2 than there are Mk2[a] owners who would want option 3. I probably wouldn't even use option 3 since that would mean physically close proximity of my empeg to my PC (and crawing around behind to plug in the USB cable).

This may be way off base with what is trying to be acheived, and not as neat... But how about a USB<>Ethernet converter?

Something like an SMC
:-
http://www.smc.com/index.cfm?action=products_show_datasheet&productCode=SMC2206USB/ETH

http://www.smc.com/index.cfm?action=products_show_datasheet&productCode=SMC2208USB/ETH

http://www.smc.com/drivers_downloads/library/SMC2208_DS.pdf

They are getting small and compact... US$30 from outpost.com

http://shop1.outpost.com/product/3237311

SMC do win and linux drivers for it. Not totally platform independant, but not too shabby...

I use a older larger version for my ADSL, and it works well...

I know some are also using a combo wireless media converter (into the empeg/rio ethernet port whilst in the car sled), 802.11 card and wireless gateway , to synch while the player is still in the garage, and also optionally scare the crap out of someone walking by the office when it's in the carpark, and you turn it on and blast an appropriate tune - as I do works well... similar idea....

Thoughts ?

Cheers,

Kieran
OZ

The empeg USB port is a slave port, not a master USB port, which a USB->Ethernet adapter requires. This device would not work on the empeg.

It's in the faq here

Even if one of the adapters were able to work... It would defeat part of the purpose of this thread. Not everyone has a network. Not everyone has any form of ethernet at home to connect to.

The idea behind the thread is to be able to use the networking protocols over a USB connection. That means not changing that USB connection to something else.

Bruno

Sorry gents... Should have been clearer. Other way around.

The USB end plugs into the USB port on your PC. + a quick driver install on your PC. The ethernet end is a jack which you plug a small patch lead straight into the network port on your empeg/rio. The USB<>Ethernet adapter simply shows up like a LAN connection.

Normally I guess you would think of it, as a portable LAN card for your USB only PC, but since they've got so small cheap and portable, for this purpose, it is more like - take it around with your peg and plug it into someones USB port, and you then have all the LAN connectivity you want (at USB speed).

Not as nice as doing it without the little piece of hardware, but once connected and the quick driver install (it is really quick and easy), functionally it like your peg is connected directly to a LAN card as far as the PC is concerned.

You could even blat out a little auto-execute 8cm minicd, yu can leave in your case that installs the driver, and set's the local lmhost and IP or whatever. And you have a quick easy plugin. Good if you are at a party and their music is pants, but you don't want to frig with their network setup (or they may well not have a card).

From there you have your streaming XML playlists, your webserver, install seeds for java and java emplode - your hot to trot

Anyway, just a thought. it may be off thread as far as cool programming, but the result would be much the same.

Cheers

Hi.

The result would only partly be the same. One of the goals of this project (has anyone actually started programming it?) is to get IP-only functionality (esp. FTP/HTTP) to a MkI. The MkI does not have any Ethernet port, so the only way to get IP to it is via PPP (wether over serial or USB is only a matter of speed) or through the emulation of a USB-to-Ethernet adapter on the empeg's side.
In other words, the goal is to get Windows (and possibly even Linux) to think that the empeg is actually a USB-to-Ethernet adapter that is in turn connected to the ethernet port of an empeg (even though the MkI doesn't actually have an Ethernet port).
A more complex, but even better solution would be to have the empeg emulate a USB hub which is connected to an empeg (for "classic" emptool/emplode USB connections) as well as to a USB-to-Ethernet adapter (for pseudo-Ethernet connections to the empeg). Using ASCII graphics to illustrate it, it would basically look like this:

                             +----------------------+       

                             | +-----+  +---------+ |       

                             | |     |--| USB2Net |*|

 +----+                      | | USB |  +---------+ |

 | PC |--- USB connection ---+-| HUB |              |       

 +----+                      | |     |  +---------+ |       

                             | |     |  | empeg   | |       

                             | |     |--| USB     |*|       

                             | +-----+  +---------+ |       

                             +----------------------+       

                                                            

where the big right box depicts the empeg, the boxes        

inside it only show "virtual" devices the PC sees. The

"*" characters stand for Linux device nodes (one serial

device, one ethernet device).

Yes, that would be my ideal solution for this project, but it is well beyond my abilities to implement that.

cu,
sven

Yeah, sure, if you don't have a Mk1 then you will get an ethernet connection on a machine that doesn't have an ethernet card this way. The beauty of this software solution though is that:
1) you don't need to drag yet another bit of hardware around with you
2) if it works the way most people thing you won't need to install *any* software or drivers on the host PC
3) it won't cost anything except a little of our time
4) it will give Mk1 owner s access to a lot of the really cool features in Hijack and Jemplode, and at a much higher speed! Do you know how slow the serial connection is?!

And once someone has cracked the tcp/ip over USB stuff it is not so much harder to start getting things like disk mode working. A nice easy to use file taxi! Again without need for extra drivers/software. You won't even have to learn any FTP commands if you are illiterate. Now that is cool :-)

(And I'm sure someone else can thing of some other good reasons to go with this!)

Not much point in that. a real ethernet interface is cheaper, and better in most respects.

Hmm, has the code been done already?

We've got a sharp zaurus here. It's a StrongARM PDA running linux that does Ethernet over USB.

On my desktop i run either a patched CDCEther driver that gives me an eth1 interface, or with newer zaurus software you use the usbdnet driver which give me a usb0 ethernet interface.
(Not sure if the usbdnet driver is in the stock kernel tree, but mandrake 8.2 ships with it)

Now the source for the linux kernel on the zaurus is at http://more.sbc.co.jp/slj/source/source_dl.asp (may require registration)
Perhaps you can just grab the ethernet over usb driver from there?

I don't think anything s being done, no...
Does the Sharp have a slave or a master USB?
When you connect it to a PC, what does it show up as?

Marius (Escort Cab + Mark II)

I presume it is a slave.

When i plug it into my linux box it goes:
hub.c: USB new device connect on bus1/2, assigned device number 51
CDCEther.c: detected BULK OUT packets of size 64
usb.c: ignoring set_interface for dev 51, iface 0, alt 0
CDCEther.c: eth1: SL Series 40:00:02:00:00:01Apr 5 17:41:39 ou119028 kernel: usb.c: USB device 51 (vend/prod 0x4dd/0x8004) is not claimed by any active driver.
/etc/hotplug/net.agent: invoke ifup eth1
/etc/hotplug/usb.agent: Setup acm CDCEther.o.gz.bak CDCEther for USB product 4dd/8004/0
/etc/hotplug/usb.agent: missing kernel or user mode driver acm
/etc/hotplug/usb.agent: missing kernel or user mode driver CDCEther.o.gz.bak
/etc/hotplug/usb.agent: Module setup CDCEther for USB product 4dd/8004/0
CDCEther.c: eth1: set multicast filters
CDCEther.c: eth1: set too many MC filters, using allmulti

The newer firmware builds cause my linux box to load the usbdnet driver instead of the CDCEther driver.

Here's the lsusb output for it:

Bus 001 Device 051: ID 04dd:8004 Sharp Corp.

Device Descriptor:

  bLength                18

  bDescriptorType         1

  bcdUSB               2.00

  bDeviceClass            2 Communications

  bDeviceSubClass         0

  bDeviceProtocol         0

  bMaxPacketSize0         8

  idVendor           0x04dd Sharp Corp.

  idProduct          0x8004

  bcdDevice            0.00

  iManufacturer           1 Sharp

  iProduct                2 SL Series

  iSerial                 0

  bNumConfigurations      2

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           73

    bNumInterfaces          2

    bConfigurationValue     1

    iConfiguration          3

    bmAttributes         0xc0

      Self Powered

    MaxPower                0mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           0

      bInterfaceClass         2 Communications

      bInterfaceSubClass      6 Ethernet Networking

      bInterfaceProtocol      0

      iInterface              4 CDC Ethernet Comm Interface

  unknown descriptor type: 05 24 00 10 01

  unknown descriptor type: 0d 24 0f 05 00 00 00 00 ea 05 00 00 00

  unknown descriptor type: 05 24 06 00 01

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        1

      bAlternateSetting       0

      bNumEndpoints           0

      bInterfaceClass        10

      bInterfaceSubClass      0

      bInterfaceProtocol      0

      iInterface              6 CDC Ethernet Data Interface - Disabled mode

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        1

      bAlternateSetting       1

      bNumEndpoints           2

      bInterfaceClass        10

      bInterfaceSubClass      0

      bInterfaceProtocol      0

      iInterface              7 CDC Ethernet Data Interface - Bulk mode

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x01  EP 1 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x82  EP 2 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Configuration Descriptor:

    bLength                 9

    bDescriptorType         2

    wTotalLength           32

    bNumInterfaces          1

    bConfigurationValue     2

    iConfiguration          8

    bmAttributes         0xc0

      Self Powered

    MaxPower                0mA

    Interface Descriptor:

      bLength                 9

      bDescriptorType         4

      bInterfaceNumber        0

      bAlternateSetting       0

      bNumEndpoints           2

      bInterfaceClass       255 Vendor Specific Class

      bInterfaceSubClass      1

      bInterfaceProtocol      1

      iInterface              9 Simple Ethernet Data Interface - Bulk mode

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x01  EP 1 OUT

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

      Endpoint Descriptor:

        bLength                 7

        bDescriptorType         5

        bEndpointAddress     0x82  EP 2 IN

        bmAttributes            2

          Transfer Type            Bulk

          Synch Type               none

        wMaxPacketSize         64

        bInterval               0

  Language IDs: (length=4)

     0009 English(English)

This looks promising... But just to be sure...
Can you connect the Sharp via USB to anything other
than a PC? I suppose they don't use the standard plugs, so that's nothing to go by...

My real question is wether the Sharp->PC cable may contain electroncs, like those USB-laplink-cables that are available.

I'll download the sources and hava a look.

Marius (Escort Cab + Mark II)

[email protected] wrote:


This looks promising... But just to be sure...
Can you connect the Sharp via USB to anything other
than a PC? I suppose they don't use the standard plugs, so that's nothing to go by...


Hmm, what else would you connect it to?

The zaurus plugs into a cradle, and the cradle plugs into the PC with a USB cable.

I think you can get cable to go straight from the zaurus to the computers USB port.

My real question is wether the Sharp-&gt;PC cable may contain electroncs, like those USB-laplink-cables that are available.

Could do, there might be something in the cradle...

But the fact that a firmware upgrade changes the type of device it appears as counts against that i think (but then i'm no expert)

OK.. totally off topic, and I hate myself for it, but does the Zaurus kick a$$? I'm thinking about getting one ...

I don't think anything s being done, no...

Actually, I've been working on this, and I've gotten pretty far along, but not anything near useful ... yet.

It's very cool

I wouldn't get the developers version, SL5000, that only has 32Mb. Get the newer retail version SL5500 it has 64Mb. With 32Mb its partitioned as either 20Mb application heap and 12 Mb storage, or 26Mb heap and 6 Mb storage. So either you run of heap or you have no space for files.

You can get around the storages space with a SD or CF card. The zaurus if good cause it has both a SD and CF slot built in. It's about the size of the ipaq, a little smaller i think, but with the ipaq you have to add bulky sleaves if you want to add a CF card.

Having both a SD and CF card means you can pop more RAM into the SD slot and still have the CF card free for a wireless network card or other expansions. I heard a wireless network card sucks allot of battery juice though.

I think it's a shame that it doesn't have a proper speaker, it's got a buzzer for alarms, but if you want to play mp3s or have sound effects in games then you have to plug headphones in.

That's about all the complaints i have... not as many apps as for palm or wince of course, but they seem to be appearing pretty quick, and if you need any of the usual linux tools you can just grab them from the debain arm distro...

The zaurus is basically binary compatible with the familiar/qtopia setup that people run on ipaqs so hopefully that will stimulate more apps with a common bigger market.

The screen is very good,64K colours i think, and im getting pretty good at the handwriting recognition, i can't decide if it's quicker to use handwriting or the pullout keyboard.

rc5 client doesn't pause itself when running on battery power like it does on my x86 laptop

We got it for developing Java stuff on and the Jeode java runtime looks pretty good. Basic AWT apps take about 4-5Mb not much more than native QT apps.

Thanks for the review.... I'm really interested for the Java support also -- To see a PDA that comes stock with a nice VM is great. I tried Jeode out back when it first came out (before they had AWT support). How is it now? What's performance like? I have a couple master plans (non-Empeg-related) that I'd love to execute if I got one Mike

Well we haven't actually programmed for it yet, still playing with it

It ships with a couple of basic demos, of the drawing circles all over the screen variety. The seem to perform OK, but i've yet to see the performance of a "real" app.

There are some Java apps people have released for the zaurus, a few board games and the like, so it's definately useable.

Here a couple of java app screen shots:

It looks like it is a slave device according to the zaurus FAQ
After scanning the zaurus kernel source, it seems the Zaurus is using the internal SA1100 USB slave-port.

Not sure if this is useful but lineo have released their USB *device* stack for linux (as used by the zaurus). Wouldn't the mark2 have one of those already?

http://www.linuxdevices.com/articles/AT5124708001.html

They include implementation of a USB network function driver.

Is anything happening with this? I've been doing some hunting around and there are some handheld linux based devices that use a usb-eth driver that does tcp over usb...

http://www.linuxdevices.com/articles/AT5124708001.html

and http://dredd.crimea.edu/ipaq/ipaq-usb-howto-new.html

I'd *love* this at work - my computer is plugged into the network, but I can't plug my empeg into the corporate network. If I could plug it into USB as I currently do *and* have access to http, ftp etc it would be fantastic!

Well, you could accomplish that today by buying a USB ethernet card and hooking that up. Someone posted one that was for sale for $5 from tigerdirect if I recall. USB sucks compared to a real NIC, but it's better than nothing...

Matthew

That's already been discussed in this very thread. It defeats part of the object of this, which is to get TCP/IP applications usable on the Mark 1 player.

Cheers,

A.

OK, so I mentioned some USB stuff in another thread, and Drakino pointed me here, and since I didn't have my soldering iron with me over Christmas I have been working on this.

Currently when I plug in my Empeg to my Win2K machine it finds a NETGEAR FA101 USB Fast Ethernet Adapter. I chose that adapter as it was available in CompUSA while I was there (so I have the real HW to see what that does), it uses the PegasusII chipset which is supported by Linux, and it is made by Netgear, so the drivers are available and it is supported.

The attachment shows the properties window, check the location field to see that it is actually the Empeg connected. At the moment it doesn't think the network cable is connected, so doesn't send any data, but I am working on that at the moment.

NOTE: This is using my MKII, I haven't tried the MK1 yet as the Mrs has it in her car at the moment.

Cool. You've made more progress than I have

I did start work on an equivalent driver but with a RTL-8150 chipset instead. It's used in the Linksys USB adapter I've got and the driver looked the simplest out of the ones available.

I never got around to finishing it however and device detection wasn't very reliable.

- Trevor

Sweet, I have that same adapter

OK, I now have the link status stuff working, and it thinks there is a connection, so can anyone tell me if this looks like an ethernet packet?

0x2a,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00,0x00,0x00,0x00,
0x00,0x00,0x08,0x06,0x00,0x01,0x08,0x00,0x06,0x04,0x00,
0x01,0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0xa8,0xf0,0x64,
0x00,0x00,0x00,0x00,0x00,0x00,0xc0,0xa8,0xf0,0x69,0x80,
0x64,0x01,0x10,0x00,0x01,0x00,0x00,0x00,0x00,0x00,0x00,
0x20,0x45,0x45,0x45,

or do I need to do some more manipulation?

Looks like an Ethernet Version II MAC frame to me. Giveaways are the 0x08 0x06 in approximately the right spot where the type field would be, and the 4-byte Frame Check Sequence at the end.

Cool, as that is what the Empeg is receiving over its USB cable

Now all I need to do is work out how to patch it in so it thinks it was received over Ethernet.
Thanks.

Nice. The only caveat I'll add is that it looks like some of the preamble is missing from the beginning of it.. Starting with 2A is okay, except that's only the last six bits of the preamble (101010.) From what I remember, the premable is supposed to be 8 bytes of solid alternating ones and zeroes.

All the frames I have captured so far start 2a then go on to something else, I am taking out a lot of my debug right now so that I can work on the next bit without pages of working stuff flying past.

Thanks for the help.

If all preambles are the same size ( 2 bytes ) and always start wit 0x2a, you shouldn't have a problem. I've ran the packet through ethereal and here's the packetdump :

Frame 1 (57 on wire, 57 captured)

    Arrival Time: Jan 12, 2003 00:41:23.8484

    Time delta from previous packet: 0.000000 seconds

    Frame Number: 1

    Packet Length: 57 bytes

    Capture Length: 57 bytes

Ethernet II

    Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)

    Source: 00:00:00:00:00:00 (00:00:00:00:00:00)

    Type: ARP (0x0806)

    Trailer: 806401100001000000000000204545

Address Resolution Protocol (request)

    Hardware type: Ethernet (0x0001)

    Protocol type: IP (0x0800)

    Hardware size: 6

    Protocol size: 4

    Opcode: request (0x0001)

    Sender hardware address: 00:00:00:00:00:00

    Sender protocol address: 192.168.240.100

    Target hardware address: 00:00:00:00:00:00

    Target protocol address: 192.168.240.105



   0  ffff ffff ffff 0000 0000 0000 0806 0001   ................

  10  0800 0604 0001 0000 0000 0000 c0a8 f064   ...............d

  20  0000 0000 0000 c0a8 f069 8064 0110 0001   .........i.d....

  30  0000 0000 0000 2045 45                    ...... EE

If the answer was not clear, that ethereal dump shows exactly what you want, a perfectly good ethernet packet, good work!

Thanks for the additional info guys, even those protocol addresses look like the ones I was using

Progress is stalled at the moment as we have an excretion, rotary cooling device collision at work that is taking up all of my time

OK, a little more progress, I have written a fake device driver for my 'emulated' network card, and that passes data into the empegs network handlers in the same way the existing ethernet port does. When I start emplode looking for the device over Ethernet this is what I see from my debug:
RCV: LENGTH 3a
Packet of length 58
ffff ffff ffff 0009 5b03 7bf0 0806 0001
0800 0604 0001 0009 5b03 7bf0 c0a8 0064
0000 0000 0000 c0a8 0069 80d8 2810 0001
0000 0000 0001 2046 4844
netif_rx()
no backlog, and not dropping
Dequeueing SKB packet
type is 1544
pt_prev = -1072769308
Send
Packet of length 44
2a00 0009 5b03 7bf0 0009 5b03 7bdc 0806
0001 0800 0604 0002 0009 5b03 7bdc c0a8
0069 0009 5b03 7bf0 c0a8 0064

It looks like the send packet is a response back to Emplodes request, but my Empeg never turns up in the discovery window. I suspect at the moment that there is something wrong with the USB response I am sending, so I am looking at that, but can anyone confirm that this is a correct response that Emplode is looking for?

I really have no experience here, but can you not hook up the network directly and see what a good packet trace looks like? Then try to duplicate that with your driver?

That would be the ideal solution, but I am at work at the moment, and the IT department would have a fit if they found a device that wasn't theirs on the network, plus I have no free sockets near me anyway. I could use the real USB ethernet adapter I have, but I have no crossover cable so that is out.
The bottom line is that the USB TX stuff needs looking at anyway, so that is what I shall do, but I just thought I would place the packets here incase anyone recognised them

The first response will be an ARP reply; no packet will be transmitted (apart from broadcasts) to any host without the sender knowing the ethernet MAC address of the recipient first. To find this, the sender does an ARP broadcast of a "who is 1.2.3.4?". The reply is then cached for later use.

If the ARP request is being received by the empeg's kernel, it'll be sending an ARP reply; ISTR it should be the same length as the request though.

To appear in emplode requires a TCP connection and quite a bit of network traffic - identifying player type, version, etc. You'd notice this! I'd try a simple ping first, which should be an ARP request, an ARP response, an ICMP request and and ICMP response.

Hugo

It just ocurred to me that you may be sending back a "runt" packet (<64 bytes?) which is getting dropped by the host. There's a minimum ethernet frame length - pad anything <64 bytes with junk, it's ignored.

Hugo

Hi Hugo,

Thanks for the heads up on runt packets, I tried a ping and nothing, adding in the runt thing now means a second 'differant' frame is sent, but it looks like it doesn't like that response, so I am playing a little more.

Thanks,

OK, so ping now works when connected via a USB cable.

Hugo, you guys appear to send LOTS of data when I try to start Emplode, I am removing traces now as they appear to be slowing everything down.

Cool! Good work!
Looking forwards to trying it when you approeach alpha/beta stage :-)

Marius (Escort Cab + Mark II)

Thanks,

I merged my development build with my Standard B13/HiJack301 build so I could try out the HTTP server in HiJack, but I am now having "branch through zero" problems so I just need a little more debug time before I dish it out

This is totally freaking cool stuff!!

I really want to look through the code for this once you've got it mostly working! Hopefully I'll learn some new tricks from it.

Cheers!

Mmm.. has anybody else thought through where this project is leading for Mk2(a) players.. just add the ipchains app and kernel code to the Hijack build, and your RioCar can become a router/firewall across its ethernet and USB ports.. Cool! I might use mine to filter rogue packets from an 801.11b wireless access point.. Or not.

Cheers

if we can emulate ethernet over usb, how long before we can do other devices? a general usb-host emulation layer would make anything possible... usb keyboard and a program to display the shell on the display = portable linux workstation.

usb keyboard and a program to display the shell on the display = portable linux workstation.

YES YES YES! I've been wanting that for 2 years!

The actual USB controller does some of the work still. It's still only a USB slave device. The ethernet controller that's being emulated is another USB slave device.
There isn't any way of making it appear to be a USB master which is needed to work with mice and keyboards.

- Trevor

Hehe. I think you may have misunderstood a little... Do you want the Empeg to act as a keyboard for your computer?
A better solution would be a serial-port keyboard. A shell for the empeg display already exists I seem to remember.

But What I really wish for is an empeg-USB Storage Device driver.

Marius (Escort Cab + Mark II)

Bulk-only MSC is actually pretty easy to implement; for most users (read: windows users) it'd be rather less useful unless you have an EXT2 filesystem plugin for your windows box... actually, do those exist?!

You could always run FAT on the empeg though, with a few tweaks!

Hugo

unless you have an EXT2 filesystem

I believe that you can only get this as a user-mode library. Last I checked, Microsoft were charging a fortune for the Installable Filesystem DDK. The licensing terms probably preclude using "viral-licensed" code, as well.

There used to be a free one I believe at http://tarzan.cr.cyco.com/~andreys/ext2fsnt/ but it's now part of a commercial product and you have to buy it. It's $30 so it's not that expensive though...

I've never personally used it so I've got no idea how good it is.

- Trevor

OK, so Mark Lord thinks my stuff is cool

As soon as I have it stable I will kick something out (pre-built binaries and the source) so everyone can try it out or just comment on my coding style

The problems at the moment are that the kernal only apears to start one network device, so I have disabled the built in one to get the USB emulation working, it shouldn't be a big change to get them both going, but that is not my priority at the moment. Once I have things stable on my MK2 I will get to the same stage on my MK1 so all those people can get HiJacks cool features too (which is why this thread was started wasn't it )

iMaGe, Trevor is correct in saying that this is just a USB device still, the HW in the Empeg is still doing a lot of the work, and it would be impossible to emulate a host port (like the one on your PC that you can actually plug a keyboard into) in just software.

I actually started on this task as I was looking at how to connect USB devices, and Drakino suggested this may be a nice little warm-up task. For the discussion on connecting USB devices see here, and don't worry as soon as I have this one nailed my focus will switch back to that one.

So, what's happenin' Dude?

The world awaits..

Haha... Mark gets back at all the users (e.g. me) who ask about how the docks are coming along! (Or what's going to be in the next Hijack release..)

Work is rapidly heading towards project milestones, and we are in the middle of customer acceptance, so 12hour days are the norm here. Plus We are due to complete on a new house next Friday so we are doing walks and inspections on that as well as trying to pack up all the stuff from where we are at the moment.

Hopefully things will settle in a couple of weeks and I can finish it off then.

In that case, leave him alone, I am getting enough cr@p at work without being hassled here

PS. anyone got a HP N class server they don't need, our compile times just went through the roof and having a machine under my desk would be nice

Too bad. I just returned an unutilized 8-way 16GB rp7405 demo unit today.

unutilized

"utilized" (or "utilised") is overutilised . Just settle for a plain "unused", please.

Well if you find any more that are unused feel free to send them my way

Oh, it was used. It just wasn't utilized. It was doing stuff, just nothing useful.

hi, i've an iPAQ 3630 (with pocket pc 2002) with both USB and SERIAL sync cables. i've got a "female (normal) USB" to "male (little) USB" adaptor like this http://www.national-tech.com/specs/30u1-03300.htm that permits to physically connect the iPAQ to my MKII via USB. is there a chance to share a file in the empeg HD (possibly over tcp/ip, i'm thinking to a divx .avi) to be used with the iPAQ ? if the answer is yes, is it possilbe to do it with the USB sync cable and pocket pc 2002 ? if no, will it be possible if i'll install familiar linux over the iPAQ ? i've no budget for a pcmcia jacket and a pcmcia eth adapter and to use the USB sync cable will be a real legend for me thanks for help

What ever happened with this project, is it integrated into Hijack now?

Hey Chimaera (Mark),

Could you please grab the code you had for this, warts and all, and post it here for us. I would really like to have this working now, and possibly port it to some other plaforms as well (eg. Receiver, Central, ..).

Just post it. No work, no changes, we'll deal with it!

Thanks

I was just curious where does this project stand?

Lost. The original author never made his code available to us, and all has since vanished. Such a shame.

I may have a go at it in a few months, but it would be much better (and more likely to get done) for someone else to do it. This is not particularly difficult to do, either. A good intro to Linux kernel development.

Cheers

Hi Mark,

Well the work isn't totally lost. Last year turned into a complete nightmare for me, work got pretty busy (imagine project managing a SW project similar in scale to Karma, but shipping over 800K units per month), plus I had a close friend die and spent a month or so flying back and forth between the UK to deal with that.

I didn't actually see your message to send him the source, I wasn't ignoring him. But infact I had only a couple of days ago got out my dev machine and started to set everything up again, only to find a dying hard disk, so I have copied off all of the files, and I am waiting for a new disk to arrive, then I can set up the machine and get going again.

Sorry it has taken so long, but hopefully I can get going on this again and get it finished as from what I remember I was getting pretty close.

Hey, welcome back!

Thanks,
According to the UPS pages, I should get my disk tomorrow, kick me hard (via PM) if you don't hear from me by Monday!

Okay, good.

I've patched your ethernet emulation code (untested, and slightly hacked) into the Hijack v365 source tree, to be released shortly. It is NOT compiled in by default -- use "CONFIG_EMPEG_PEGASUS" to configure it.

Any new patches anyone wants to send in should be based on the code now in Hijack.

Thanks Mark!

cool. how is this supposed to work, anyways? plug the usb cable in and (j)emplode thinks that its on then network?

The code in there emulates a Netgear FA101, so when you plug it in and load the Netgear drivers Windows thinks it has a new network card. From that point you need to set all of Windows settings for the network card, IP address, subnet etc... Also you need to give the Empeg a static IP address (differant from the one you just gave to the PC, but reachable from the settings you just gave the PC).

The Empeg should magically apear to a device on your network, or atleast until it panics the kernel .

I am working on trying to fix the problems, and will let Mark have any patches once I come up with them.

COOL! question... Netgear FA101 is included in the included drivers, right? this is great. no more using a cross over cable at my friends house. just borrow one of the already connected usb peripherals. question... does the empeg think it has a network connection also, therefore letting us do network stuff? ping, ntp, wget, etc?

Netgear drivers should be downloaded from the netgear website. I chose that adaptor as it had a Pegasus chipset that appears to be supported by Windows, Linux and Mac although it has only been tried on Windows.

Yes the Empeg thinks it has a network connection, ping works fine, everything else PANICs the kernel.

Also another note, as the Empeg only appears to bring up the first ethernet interface, the version that is in the current Hijack will disable the built in ethernet when you do a build that enables the Pegasus emulation, this will be fixed, but it is in the queue after the kernel panics.

And for those who don't know, when he says "the kernel panics" he means it crashes...

...
empeg usb initialised, PDIUSBD12 id 1012
Writing to endpoint 5
Ack Only!!
USB Int: 128
USB Int: 0
empeg state support initialised 0089/88c1 (save to d0005980).
empeg RDS driver initialised
...

installed latest hijack, and it seems that i have this in my bootlog now. something to do w/ PEGASUS? thought it shouldn't be configured by default.

oh man.... i'm just seeing the potential.... imagine jEmplode saturating the bus completely with a dual-headed upload to both the usb-ethernet and the regular ethernet. i'm aware that there won't be much of an improvement, but any additions help.

That is debug trace from the USB code, a quick look at the actual patch Mark used it looks like the functionality is disabled but the debug trace is still enabled (for the original USB code), hopefully nothing to worry about

Those are just harmless debug messages, which happen to be on the pathway of the "regular" USB code. I imagine they'll get DEBUGed out in a later release.

EDIT: Hijack v369 will be out shortly, with the Pegasus debug messages removed (ifdef'd out).


Cheers

I have a question, how do you install the drivers? When trying winXP 'Add Hardware' wizard the driver is not detected so i cannot get it installed.. I am using the NXPFA101.INF file

Sean in NC

My W2K machine detects new HW and then asks for the driver, I point it at the INF file and it "just works".

Although thinking about it I have always used the install CD and never tried the drivers from the Netgear site, I would assume they work the same way.

OK for the la(me)y man, Is this the install process?,

Install v369.hijack.mk2.zImage (latest HiJack as of now
Plug in USB to empeg
Install driver s where/if prompted by WinBlows(XP)

Sean in NC

You must reconfigure and recompile hijack first -- the USB-ethernet stuff is not built-into the binaries I provide; rather, it is merely included in the sources.

The latest Hijack (369) doesn't have the support for this feature enabled, so you would need to rebuild the hijack kernel from its source after enabling the PEGASUS flag, flash that resulting kernel, then continue with the "plug in USB to empeg..."

The reason it isn't compiled in as default yet is that it is very buggy and will crash your empeg, when I get it working it will be up to Mark to decide if it is enabled by default or not.

Not ready for the masses yet then...

Sean in NC