[Oberon] Re. (4) How is ETHO with USB?

[Chris Glur]

Sven wrote:

> This 2252+ seems to be a beast ;-)
> 
I'm hoping that it's no worse than the existing and many to 
come ZeroCD devices. Did I read that it had a Mac driver too ?
Probably not, else the PC would also have to identify itself to
the device !!

> > Principally a clever idea, but this approach is highly OS dependent. 
> > Seems to only work for Windows now.
> > With some USB trickery (USB_modeswitch) this can be fixed. 
> > But this is not (yet??) implemented in NO/A2.

> Not really OS dependent. Just requires a device driver that is aware of 
> this feature... Any OS with a USB mass storage class driver will see the 
> mass storage device (A2 should, too) - well, 
Yes A2 identified the CDROM, but I couldn't progress, since I couldn't
'file' any bytes except via Backup.Tool .

> not all will start the 
> autorun automatically and also, the windows driver found on the 
> "mass  storage device" won't help non-MS-OS's  ;-)

We don't want auto-run; we just want what linux has come to call
'ModeSwitch'.  I'm getting the LInux Debian ModeSwitch package,
and I expect the souce-code to be small.  If it's written with low-level 
primitives I'll be able to decode it, but if it calls a lot of other external
routines with non-descriptive names, it will remain hidden knowledg.

> Note here that USB stack locates device drivers in a specified order, 
> starting from device-specific drivers (vendor/product ID) going to 
> generic drivers (class/subclass/protocol). If the vendor's driver is 
> installed, it therefore will be loaded and bound to the device and the 
> USB stack does not further look for other drivers... Although this is a 
> very nice feature of USB, it seems to be possible to abuse it...

OK, so that's how M$ and ETH arrange the <mapping of the device 
driver to the device's ID> ?

> If you had a specification of the device, "mode-switching" wouldn't be a 
> problem, but without... I wouldn't be patient enough to reverse-engineer 
> such "features".

I don't believe that the wireless-modem device is new/different to
earlier wireless-modem devices. The previous model, with just the
"+" char missing, tested OK. And I expect this 2252+ to be the same,
once it's toggled out of CDROM mode.

NB. the copied and repeated statement that "the first time the
device is IDed, it shows it self as a CDROM, and then subsequently 
as a wireless-modem" is ambigious.

" until the sael is broken" is not ambigious, because clearly the
'device' has the "memory" that it's [once only breakable] seal
is broken.  For ZeroCD, where is the "memory"?

If the state-machine resets to CD-mode on power-up,
and toggles to modem-mode after the driver is up-loaded;
then that's understandable.

Also, I suspect that eject immediately after CD d/l starts is
not useable, because the mode has to toggle after the d/l
- is complete ?  And I don't think a timer is used.

Until the weekend, I'm going to the location which has the
A2 facility but no inet [unless 2252+ works]. I transfer my 
main IDE back&forth.  Life and engineering's progress depends
on such real-life trivialities. That's why, when ETHO puts the
operational knowledge 'inside your fingers', it's such a big help.

Thanks,

== Chris Glur.