linuxdc-dev — Developer discussion list

Re: [linuxdc-dev] VMU filesystem question

[M. R. B. <mr...@0x...>]

* M. R. Brown <mr...@0x...> on Sun, Dec 08, 2002:

> * Callum Lerwick <se...@ha...> on Sun, Dec 08, 2002:
>=20
> >=20
> > You copy the entire directory tree.
> >=20
>=20
> Reread Adrian's post.  The data he is talking about can't be "copied"
> outside of the vmufs driver.  There is no way to persist custom data in t=
he
> Linux VFS without making all other filesystems understand that informatio=
n.
>=20

Let me clarify.  Even if you devise a brilliant scheme to expose vmufs
directory info or metadata in other "files" or "directories", as _soon_ as
that data leaves vmufs it becomes meaningless.  There is no way you can
assure that data will remain together or intact as it travels to the four
corners of the Earth.  Thus, you are back to square one and you have
incomplete file info.  You could store it as part of the file, but then you
lose compatability because that single file can't be transferred to
non-Linux-vmufs systems who won't know what to do with the extra
information (or even know that it exists).  And be realistic, copying an
entire directory tree for one file is ridiculous...

Besides that, vmufs doesn't support directories and you can get pretty
flexible with the filename (it's plain ASCII).  Whatever filenaming scheme
you enforce would also cause vmufs to force policy on the rest of the syste=
m.

M. R.

Re: [linuxdc-dev] VMU filesystem question

[David W. <dav...@ia...>]

> * David Willmore <dav...@ia...> on Sun, Dec 08, 2002:
> 
> >=20
> > You Linux VFS sees the files, but the filesystem driver makes them up fro=
> m the=20
> > info in the directories (the hidden pointers and such).  I'll write a bet=
> ter=20
> > description when I get a moment--have to go finish makeing dinner. :)
> >=20
> 
> How does this help you when transferring files to/from a filesystem that
> doesn't understand this information, like NFS?  Or when transferring saves
> around across the network?

That's the advantage of these.  Normal tools will copy the 'special' files
as well.  Tar up the whole thing and you will save the special info with
the normal info.

> The solution would be a user space tool that understood and could transfer
> files between full VMU images (whether dumped or mapped via MTD).  This is =
> the
> only way you can persist the nonstandard info and be flexible enough to
> allow other uses of the VMU save data.  MTOOLS (the MSDOS userspace
> filesystem utilities?) comes to mind.

This requires a whole suite of cross-platform tools that understand how
one hokey little system mangles its data., ick.

> Such tools would be a hell of a lot easier to implement than a full-blown
> (and unfortunately incompatible) VFS driver.

There is nothing incompatable about it--as far as being a VFS driver goes.

Okay, how does this sound.  Make the first block of the file be the special
data for that file?  When the first block is read/written, the fs knows to 
generate that info/save that info in the 'special' area.  All other blocks
work normally.

For inspiration on how I see this working, look at the AppleShare system.
How do unix systems serve files to Macs which expect a file to have a 
code and a resource fork?  They do it by having this split and mirrored
directory structure.

rootoffilesystem/code/pathtostuff/myfile is the code 'fork' of the file
rootoffilesystem/res/pathtostuff/myfile is the resource 'fork' of the file.

If the filesystem is HFS (say a disk from a Mac that's been stuck into
a linux box) then on disk the data is in one big 'file' chunk that one has
to understand how to split into code and resource 'forks'.  The VFS makes it
look like seperate files.  If the Linux box serves it out to an AppleShare
client, it makes it look like one file again.

The VFS just wants to say 'here is a path, open this file and give me
blocks of it'.  The filesystem driver has complete control over what
goes to and comes from the backing store--disk, flash, tape, etc.  Some
filesytems are completely 'made up'--proc, devfs... 

I must be describing this poorly and for that I'm sorry.  It's really
a clever way of making the two systems see the same thing differently/
different things the same.

Cheers,
David

Re: [linuxdc-dev] VMU filesystem question

[M. R. B. <mr...@0x...>]

* Callum Lerwick <se...@ha...> on Sun, Dec 08, 2002:

> M. R. Brown wrote:
> >* David Willmore <dav...@ia...> on Sun, Dec 08, 2002:
> >
> >
> >>You Linux VFS sees the files, but the filesystem driver makes them up=
=20
> >>from the info in the directories (the hidden pointers and such).  I'll=
=20
> >>write a better description when I get a moment--have to go finish makei=
ng=20
> >>dinner. :)
> >>
> >
> >
> >How does this help you when transferring files to/from a filesystem that
> >doesn't understand this information, like NFS?  Or when transferring sav=
es
> >around across the network?
>=20
> You copy the entire directory tree.
>=20

Reread Adrian's post.  The data he is talking about can't be "copied"
outside of the vmufs driver.  There is no way to persist custom data in the
Linux VFS without making all other filesystems understand that information.

M. R.

Re: [linuxdc-dev] VMU filesystem question

[Callum L. <se...@ha...>]

M. R. Brown wrote:
> * David Willmore <dav...@ia...> on Sun, Dec 08, 2002:
> 
> 
>>You Linux VFS sees the files, but the filesystem driver makes them up from the 
>>info in the directories (the hidden pointers and such).  I'll write a better 
>>description when I get a moment--have to go finish makeing dinner. :)
>>
> 
> 
> How does this help you when transferring files to/from a filesystem that
> doesn't understand this information, like NFS?  Or when transferring saves
> around across the network?

You copy the entire directory tree.

Re: [linuxdc-dev] VMU filesystem question

[M. R. B. <mr...@0x...>]

* David Willmore <dav...@ia...> on Sun, Dec 08, 2002:

>=20
> You Linux VFS sees the files, but the filesystem driver makes them up fro=
m the=20
> info in the directories (the hidden pointers and such).  I'll write a bet=
ter=20
> description when I get a moment--have to go finish makeing dinner. :)
>=20

How does this help you when transferring files to/from a filesystem that
doesn't understand this information, like NFS?  Or when transferring saves
around across the network?

The solution would be a user space tool that understood and could transfer
files between full VMU images (whether dumped or mapped via MTD).  This is =
the
only way you can persist the nonstandard info and be flexible enough to
allow other uses of the VMU save data.  MTOOLS (the MSDOS userspace
filesystem utilities?) comes to mind.

Such tools would be a hell of a lot easier to implement than a full-blown
(and unfortunately incompatible) VFS driver.

M. R.

Re: [linuxdc-dev] VMU filesystem question

[David W. <dav...@ia...>]

> On Sunday 08 Dec 2002 6:10 pm, David Willmore wrote:
> > > On Sat, 7 Dec 2002 10:37:39 +0000
> 
> > Does any of this make sense to anyone?  Or did I explain it poorly?
> > (could be both.)
> 
> Sorry, but you totally lost me :-<
> 
> I think the point is that the Linux VFS knows nothing of this extra directory 
> information and so I can see no way of writing a Linux fs driver that can use 
> it. I could obviously just write a bespoke device driver or userland app that 
> hacked it all, but that is not as elegant.
> 
> Furthermore I want to be able to save any file I like on the vmu.
> 
> I think I'm just going to have to live with it.

You Linux VFS sees the files, but the filesystem driver makes them up from the 
info in the directories (the hidden pointers and such).  I'll write a better 
description when I get a moment--have to go finish makeing dinner. :)

Cheers,
David

Re: [linuxdc-dev] VMU filesystem question

[Adrian M. <ad...@mc...>]

On Sunday 08 Dec 2002 6:10 pm, David Willmore wrote:
> > On Sat, 7 Dec 2002 10:37:39 +0000

> Does any of this make sense to anyone?  Or did I explain it poorly?
> (could be both.)
>
Sorry, but you totally lost me :-<

I think the point is that the Linux VFS knows nothing of this extra directory 
information and so I can see no way of writing a Linux fs driver that can use 
it. I could obviously just write a bespoke device driver or userland app that 
hacked it all, but that is not as elegant.

Furthermore I want to be able to save any file I like on the vmu.

I think I'm just going to have to live with it.

Adrian

Fwd: Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[Adrian M. <ad...@mc...>]

----------  Forwarded Message  ----------

Subject: Re: [linuxdc-dev] RedBoot CD booting and MPEG playback
Date: Sun, 8 Dec 2002 18:47:42 +0000
From: Adrian McMenamin <ad...@mc...>
To: dav...@ia...

On Sunday 08 Dec 2002 6:19 pm, David Willmore wrote:
> > I think to get that sort of throughput you'd certainly need accelerated
> > 2-D video or else be prepared to accept frames being dropped. I and
> > others have compiled mplayer but there are two eseential problems:
> >
> > 1. Sound driver design (needs dma) eats up processor cycles for high
> > sample rate sounds meaning that the pressure is really on the video
>
> Does the DMA 'steal' cycles from the CPU?  Normally, isn't DMA supposed to
> help use less processor time?  This sounds backwards.

No, just my writing was unclear: I meant the driver really needs to use dma
 to be better (actually dma coupled with interrupts). It eats cycles now
 because it doesn't use dma. I haven't tried to write any dma code for it for
 some time, but I got nowhere when I last tried.

> > 2. Alternative sound driver design (not with dma, but less processor
> > hogging) gives better video performance, but sound clicks and repeats -
> > an accelerated 2d video driver might fix that.
>
> Ick.
>
> Are there sufficient spec's on the video to write a DRI driver or even a
> good accelerated 2D driver?  I've been following the DRI development for
> about a year, now, and they are always busy with things, but they're also
> very helpful to new people.  So, getting questions answered is easy.  They
> also have weekly meetings on Monday afternoons at 2100UTC (5:00EDT) on
> irc.freenode.net #dri-devel. Anyone interested in developing DRI or related
> software is invited to participate and all are invited to listen in. :)

The problem we have, as always, is there are no developers!

> The big thing for video playback would be what colorspaces and scaling
> ability the video chip has.  If it has a nicely scaled YUV colorspace
> ability, video playback gets a lot easier.  The DC has pretty good floating
> point, so that should help.
>
> Cheers,
> David
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev

-------------------------------------------------------

[linuxdc-dev] DC BBA, Serial Upload Cable, PS2 Convertor

[Chris J. <ch...@ch...>]

Hi All
Just clearing through all my rubbish and find I have a brand new BBA =
(proper Sega HIT-0400), serial upload cable and keyboard convertor cable =
which I'm sure may be of use to somebody.

Please feel free to email offers to me off the list.

Regards
Chris.

ch...@ch...

Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[David W. <dav...@ia...>]

> I think to get that sort of throughput you'd certainly need accelerated 2-D 
> video or else be prepared to accept frames being dropped. I and others have 
> compiled mplayer but there are two eseential problems:
> 
> 1. Sound driver design (needs dma) eats up processor cycles for high sample 
> rate sounds meaning that the pressure is really on the video

Does the DMA 'steal' cycles from the CPU?  Normally, isn't DMA supposed to 
help use less processor time?  This sounds backwards.

> 2. Alternative sound driver design (not with dma, but less processor hogging) 
> gives better video performance, but sound clicks and repeats - an accelerated 
> 2d video driver might fix that.

Ick.

Are there sufficient spec's on the video to write a DRI driver or even a good
accelerated 2D driver?  I've been following the DRI development for about a
year, now, and they are always busy with things, but they're also very helpful
to new people.  So, getting questions answered is easy.  They also have weekly
meetings on Monday afternoons at 2100UTC (5:00EDT) on irc.freenode.net #dri-devel.
Anyone interested in developing DRI or related software is invited to participate
and all are invited to listen in. :)

The big thing for video playback would be what colorspaces and scaling ability
the video chip has.  If it has a nicely scaled YUV colorspace ability, video
playback gets a lot easier.  The DC has pretty good floating point, so that
should help.

Cheers,
David

Re: [linuxdc-dev] VMU filesystem question

[David W. <dav...@ia...>]

> On Sat, 7 Dec 2002 10:37:39 +0000
> Adrian McMenamin <ad...@mc...> wrote:
> 
> > (a) Ban all interaction between vmufs and any other filesystem (ie
> > assume that all an any file is a vmufs file)
> > 
> > (b) Ignore the problem because it is probably not too serious in any
> > case
> 
> Test (b). Is it possible to "fake" the extra info somehow ? 

Yes, I can see two sort of clean ways to do it.
One is to make the files look just like they do now and hide the 
extra directory info in a file called .filename or in another
directory--from the root of the fs--with the same directory
structure that has a 'filename' file that has the info in it, so:

filesystemrootdir/supergame/bob is our file
filesystemrootdir/supergame/.bob is the extra info or:
filesystemrootdir/extradirinfo/supergame/bob is the extra info

Or make each file a directory and have files in it with the 'main'
chunk and the 'extra' chunk:

filesystemrootdir/supergame/bob/main is our file and
filesystemrootdir/supergame/bob/extra is the extra info

They're all pretty easy to implement as the 'extra' directories
and files are faked by the filessytem.  To make life easy, you
can ban directory creates in the 'extra' info directory structures.
You can ban the creation of . files if you use that scheme.  Pick
a scheme above and implement some rules like that to make life easier--or
you can make it a bit tougher and more flexable and make a dir create
in the 'extra' dirs actually make one in the 'real' dirs--which will 
implicitly create on in the 'extra' dirs.

Does any of this make sense to anyone?  Or did I explain it poorly?
(could be both.)

> > PS Today is my birthday... all together now....
> 
> C O N G R A T U L A T I O N S !

C O N G R A T U L A T I O N S !

Cheers,
David

Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[Adrian M. <ad...@mc...>]

On Saturday 07 Dec 2002 10:42 pm, Gavin Hamill wrote:
> Thanks for the fast feedback, guys :)
>
> Unfortunately, my own coding skills amount to nothing more than a few
> lines of shoddy Perl and shell script :/


If you can hack perl, you can do C!

Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[Gavin H. <gd...@ac...>]

Thanks for the fast feedback, guys :)

Unfortunately, my own coding skills amount to nothing more than a few 
lines of shoddy Perl and shell script :/

But, I'll have a tinker nonetheless... my goal would to be to use the DC
as a player for a 'Personal Video Recorder' unit (DVB -> MPEG2)... but
even if the DC can do fullscreen MPEG1 352x288 then that might be
adequate for a bedroom player on a small screen, and make the server box 
do the conversion from MPEG2 -> MPEG1 on-the-fly...

Should be fun whatever happens =)

gdh

Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[Adrian M. <ad...@mc...>]

On Saturday 07 Dec 2002 10:05 pm, Gavin Hamill wrote:
> Hullo :)
>
> I bought a DC + BBA a year ago to tinker with Linux / NFS stuff, but at the
> time there was no audio support in the Linux kernel for the DC's onboard
> sound hardware, and real life got in the way, so I lost interest...
>
> Now I see sound has been added and I have a bit of free time to produce a
> DC-based 'Media Station'...
>
> Certainly mp3 and MPEG-1 movie playback is possible from what I've read on
> the mailing list, but is there sufficient grunt in the DC to play MPEG2 at
> broadcast quality (702x576 at about 6Mbps) with mp2-sound under X, or if
> not X, is the framebuffer device adequate for mplayer usage?
>
I think to get that sort of throughput you'd certainly need accelerated 2-D 
video or else be prepared to accept frames being dropped. I and others have 
compiled mplayer but there are two eseential problems:

1. Sound driver design (needs dma) eats up processor cycles for high sample 
rate sounds meaning that the pressure is really on the video

2. Alternative sound driver design (not with dma, but less processor hogging) 
gives better video performance, but sound clicks and repeats - an accelerated 
2d video driver might fix that.


If you have a video clip in mind please send me (not the list!) it and I'll 
give it a try and report performance. Otherwise, if you wanted to tackle 
either of the above problems (no sound dma, no accelerated video, I'd be more 
than happy to help!)


Adrian

Re: [linuxdc-dev] RedBoot CD booting and MPEG playback

[<ps...@wi...>]

i would highly doubt that the DC has the power to play MPEG2 video back, let alone with audio. the framebuffer might be adequate for movie playback, but i'm not sure. best thing to do would be to write a good/better DRI driver and use hardware acceleration to the best of the DC's abilities (or as close as we can get ;)

On Sat, 7 Dec 2002 22:05:16 +0000
Gavin Hamill <gd...@ac...> wrote:

> Hullo :)
> 
> I bought a DC + BBA a year ago to tinker with Linux / NFS stuff, but at the time there was no audio support in 
> the Linux kernel for the DC's onboard sound hardware, and real life got in the way, so I lost interest...
> 
> Now I see sound has been added and I have a bit of free time to produce a DC-based 'Media Station'...
> 
> Certainly mp3 and MPEG-1 movie playback is possible from what I've read on the mailing list, but is there 
> sufficient grunt in the DC to play MPEG2 at broadcast quality (702x576 at about 6Mbps) with mp2-sound under X, 
> or if not X, is the framebuffer device adequate for mplayer usage?
> 
> Cheers!
> Gavin.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
> 

[linuxdc-dev] RedBoot CD booting and MPEG playback

[Gavin H. <gd...@ac...>]

Hullo :)

I bought a DC + BBA a year ago to tinker with Linux / NFS stuff, but at the time there was no audio support in 
the Linux kernel for the DC's onboard sound hardware, and real life got in the way, so I lost interest...

Now I see sound has been added and I have a bit of free time to produce a DC-based 'Media Station'...

Certainly mp3 and MPEG-1 movie playback is possible from what I've read on the mailing list, but is there 
sufficient grunt in the DC to play MPEG2 at broadcast quality (702x576 at about 6Mbps) with mp2-sound under X, 
or if not X, is the framebuffer device adequate for mplayer usage?

Cheers!
Gavin.

Re: [linuxdc-dev] VMU filesystem question

[Karl T. K. <ka...@pr...>]

On Sat, 7 Dec 2002 10:37:39 +0000
Adrian McMenamin <ad...@mc...> wrote:

> (a) Ban all interaction between vmufs and any other filesystem (ie
> assume that all an any file is a vmufs file)
> 
> (b) Ignore the problem because it is probably not too serious in any
> case

Test (b). Is it possible to "fake" the extra info somehow ? 

> PS Today is my birthday... all together now....

C O N G R A T U L A T I O N S !

Kind regards,

Karl T

[linuxdc-dev] VMU filesystem question

[Adrian M. <ad...@mc...>]

I have a thorny problem with vmufs design.....

The vmu directory is designed to save games files from a dreamcast and 
contains game specific information (eg header offsets). This means nothing to 
Linux.

Thus if one executed the command...

cp old_vmu/OLD_FILE new_vmu/NEW_FILE the copy would not be perfect - the data 
in the file itself would be copied and a basic directory entry created, but 
not all the directory information would be copied over fully.

There seem to be two ways to solve this:

(a) Ban all interaction between vmufs and any other filesystem (ie assume that 
all an any file is a vmufs file)

(b) Ignore the problem because it is probably not too serious in any case


(a) seems overly restrictive and I doubt whether it is practible in any case. 
I won't know about (b) until I've actually done an implementation and tested 
it.

Have I missed anything? Any thoughts?

Adrian

PS Today is my birthday... all together now....

[linuxdc-dev] FS design

[Adrian M. <ad...@mc...>]

This is more a general filesystem design question than an SH specific one - 
but if is for the vmu fs on the dreamcast...

I am seeking to implement write on this (read only currently works). One can 
now successfully delete files on the system, but I am not sure how best to 
implement writing/creating a file.

Should creating a new file be handled in file::write, or is it dealt with by a 
dissferent set of system calls?

The vmu fs is FAT based so the "inode"s created are entirely synthetic - it is 
easy to 'create' an inode but there is a real dislocation between that and 
writing a file out to disk and I am just trying to get my head round the 
appropriate sequence of calls....

Adrian

Re: [linuxdc-dev] Dreameye

[Jason D. <min...@ya...>]

What may I ask is a dreameye?

----- Original Message -----
From: "Adrian McMenamin" <ad...@mc...>
To: <dc...@ya...>
Cc: <lin...@li...>
Sent: Saturday, November 23, 2002 4:05 PM
Subject: [linuxdc-dev] Dreameye


> I have just acquired one of these (the price has halved in the last year
on
> ebay). Has anyone else got one?
>
> It seems to register six functions with maple. One of which is a
controller -
> and the functions OR out to 0x801 (0x001 being a controller). None of the
> other functions are recognised by Linux which means, I guess, it's not a
> mouse or a puru puru pack :->
>
> But if it has 5 more functions then they all must have the same function
code
> - unless my binary maths is all wrong.
>
> Any thoughts....
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev

Re: [linuxdc-dev] Re: [dcdev] Dreameye

[Dan P. <ba...@al...>]

On Nov 23, Adrian McMenamin wrote:

> Why is my maths wrong? It reports as 6 different devices, one of which is a 
> controller. The other five all have the function code 0x800.

Ohh.. I see what you mean then. Looking at the dump you sent over, it
looks like it basically does what a lot of the 3rd party keyboards and
such do, and only checks to see if the sub-device code is 0 or greater
(basically treating the sub-port as a don't-care). I had some troubles
in KOS with that where it would detect a keyboard for A0, A1, A2, ... .
What we ended up having to do was only poll the top-level x0 port for
attached devices, and it'll return a bitmask showing what's really
connected. Works much better :).

Or it could really have 5 more sub-devices, dunno... Unfortunately I
don't have one to try it myself.

[linuxdc-dev] dmesg showing dreameye stuff

[Adrian M. <ad...@mc...>]

Linux version 2.4.20-pre11-sh-dc (Adrian@landslide) (gcc version 3.0.3) #71 
Wed Nov 20 22:41:13 GMT 2002

[snip]


[maple stuff starts to come through....]

maple(1,0): Connected(function 0x40)
input0: keyboard(0x3060080): Keyboard
IP-Config: Complete:
      device=eth0, addr=192.168.62.2, mask=255.255.255.0, gw=192.168.62.123,
     host=dreamy, domain=, nis-domain=(none),
     bootserver=192.168.62.123, rootserver=192.168.62.123, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
maple(2,0): Connected(function 0x1)
input1: controller(0xf06fe): Dreamcast Controller
RAMDISK: Compressed image found at block 0
maple(2,1): Connected(function 0xe)
mtd: Giving out device 5 to Dreamcast VMU Flash @ C1
maple(2,1): No driver for function(s): c.
maple(2,2): Connected(function 0x100)
purupuru.c: adding Puru Puru Pack  input2
maple(3,0): Connected(function 0x1)
input3: controller(0x800): Dreamcast Camera Flash  Device
maple(3,1): Connected(function 0x800)
maple(3,1): No driver for function(s): 800.
maple(3,2): Connected(function 0x800)
maple(3,2): No driver for function(s): 800.
maple(3,3): Connected(function 0x800)
maple(3,3): No driver for function(s): 800.
maple(3,4): Connected(function 0x800)
maple(3,4): No driver for function(s): 800.
maple(3,5): Connected(function 0x800)
maple(3,5): No driver for function(s): 800.
Freeing initrd memory: 4096k freed
EXT2-fs warning: checktime reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
mount_devfs_fs(): unable to mount devfs, err: -2
Looking up port of RPC 100003/2 on 192.168.62.123
maple(0,0): Connected(function 0x1)
input4: controller(0xf06fe): Dreamcast Controller
Looking up port of RPC 100005/1 on 192.168.62.123
maple(0,1): Connected(function 0xe)
mtd: Giving out device 6 to Dreamcast VMU Flash @ A1
maple(0,1): No driver for function(s): c.
VFS: Mounted root (nfs filesystem).
Trying to move old root to /initrd ... failed
Unmounting old root
Trying to free ramdisk memory ... okay
Mounted devfs on /dev
Freeing unused kernel memory: 84k freed

[Pulled out connector to camera .....]

maple(3,0): Disconnected (3,0)
maple(3,1): Disconnected (3,1)
maple(3,2): Disconnected (3,2)
maple(3,3): Disconnected (3,3)
maple(3,4): Disconnected (3,4)
maple(3,5): Disconnected (3,5)

[reattached it.....]

maple(3,0): Connected(function 0x1)
input3: controller(0x800): Dreamcast Camera Flash  Device
maple(3,1): Connected(function 0x800)
maple(3,1): No driver for function(s): 800.
maple(3,2): Connected(function 0x800)
maple(3,2): No driver for function(s): 800.
maple(3,3): Connected(function 0x800)
maple(3,3): No driver for function(s): 800.
maple(3,4): Connected(function 0x800)
maple(3,4): No driver for function(s): 800.
maple(3,5): Connected(function 0x800)
maple(3,5): No driver for function(s): 800.

Re: [linuxdc-dev] Re: [dcdev] Dreameye

[Adrian M. <ad...@mc...>]

On Saturday 23 Nov 2002 9:32 pm, Dan Potter wrote:

> Unless I misunderstand you, your math is wrong. :)
>
> 0     8     0     1
> 0000  1000  0000  0001
>
> The 0x800 is probably the DreamEye specific function for video input or
> something...

Why is my maths wrong? It reports as 6 different devices, one of which is a 
controller. The other five all have the function code 0x800.

[linuxdc-dev] Re: [dcdev] Dreameye

[Dan P. <ba...@al...>]

On Nov 23, Adrian McMenamin wrote:

> It seems to register six functions with maple. One of which is a controller - 
> and the functions OR out to 0x801 (0x001 being a controller). None of the 
> other functions are recognised by Linux which means, I guess, it's not a 
> mouse or a puru puru pack :->
> 
> But if it has 5 more functions then they all must have the same function code 
> - unless my binary maths is all wrong.

Unless I misunderstand you, your math is wrong. :) 

0     8     0     1
0000  1000  0000  0001

The 0x800 is probably the DreamEye specific function for video input or
something...

[linuxdc-dev] Dreameye

[Adrian M. <ad...@mc...>]

I have just acquired one of these (the price has halved in the last year on 
ebay). Has anyone else got one?

It seems to register six functions with maple. One of which is a controller - 
and the functions OR out to 0x801 (0x001 being a controller). None of the 
other functions are recognised by Linux which means, I guess, it's not a 
mouse or a puru puru pack :->

But if it has 5 more functions then they all must have the same function code 
- unless my binary maths is all wrong.

Any thoughts....