LinuxDC: Linux for the Sega Dreamcast

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...

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.

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.

What may I ask is a dreameye?

----- Original Message -----
From: "Adrian McMenamin" <adrian@...>
To: <dcdev@...>
Cc: <linuxdc-dev@...>
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
> Linuxdc-dev@...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev

* Adrian McMenamin <adrian@...> on Thu, Nov 21, 2002:

> In the vmu all the game files are loaded into the vmu from block 0. Other=
=20
> files can be loaded anywhere.
>=20
> Should I implement this in the vmufs driver - ie should I force game file=
s=20
> (those with the eXec bit on) to be loaded into the vmu from block 0.
>=20
> Reasons for: unless this behaviour is enforced it will not be possible to=
 use=20
> vmufs to swap games files.
>=20
> Reasons against: could cuase problems loading the vmu with additional fil=
es,=20
> mixes questions of policy with mechanisms.
>=20
> What do people think?
>=20

Isn't the whole point of vmufs to stay compatible with official Dreamcast
software?

M. R.

mrbrown@... wrote:
> * Adrian McMenamin <adrian@...> on Thu, Nov 21, 2002:
> > In the vmu all the game files are loaded into the vmu from block 0. Other=
> =20
> > files can be loaded anywhere.
> >=20
> > Should I implement this in the vmufs driver - ie should I force game file=
> s=20
> > (those with the eXec bit on) to be loaded into the vmu from block 0.
> >=20
> > Reasons for: unless this behaviour is enforced it will not be possible to=
>  use=20
> > vmufs to swap games files.
> >=20
> > Reasons against: could cuase problems loading the vmu with additional fil=
> es,=20
> > mixes questions of policy with mechanisms.
> >=20
> > What do people think?
> >=20
> Isn't the whole point of vmufs to stay compatible with official Dreamcast
> software?
> M. R.
> 
Isn't the point to stay compatible with the format not simply 
the software? If I follow the Sega way then you woin't be able to
save more than two executibles on a vmu, say.

Whats the deal with the website?

Ben

-- 
Ben Srour
srour@...

On Thu, 21 Nov 2002 adrian@... wrote:

> mrbrown@... wrote:
> > * Adrian McMenamin <adrian@...> on Thu, Nov 21, 2002:
> > > In the vmu all the game files are loaded into the vmu from block 0. Other=
> > =20
> > > files can be loaded anywhere.
> > >=20
> > > Should I implement this in the vmufs driver - ie should I force game file=
> > s=20
> > > (those with the eXec bit on) to be loaded into the vmu from block 0.
> > >=20
> > > Reasons for: unless this behaviour is enforced it will not be possible to=
> >  use=20
> > > vmufs to swap games files.
> > >=20
> > > Reasons against: could cuase problems loading the vmu with additional fil=
> > es,=20
> > > mixes questions of policy with mechanisms.
> > >=20
> > > What do people think?
> > >=20
> > Isn't the whole point of vmufs to stay compatible with official Dreamcast
> > software?
> > M. R.
> >
> Isn't the point to stay compatible with the format not simply
> the software? If I follow the Sega way then you woin't be able to
> save more than two executibles on a vmu, say.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Linuxdc-dev@...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
>

* adrian@... <adrian@...> on Thu, Nov 21, 2002:

> Isn't the point to stay compatible with the format not simply=20
> the software? If I follow the Sega way then you woin't be able to
> save more than two executibles on a vmu, say.
>=20

Well, based on our (heated) discussion on IRC, you can only run one
executable on the VMU anyway, so saving to executables is moot.  IMO it's
best to stay *completely* compatible.

M. R.

On Thu, 21 Nov 2002 17:23:58 -0600 (CST)
Ben Srour <srour@...> wrote:

> Whats the deal with the website?
> 
> Ben

AFAIK, M.R.Brown has been without internet access for some time. give him a bit to get his stuff together and we should have a pretty new website.

* psypete@... <psypete@...> on Fri, N=
ov 22, 2002:

> On Thu, 21 Nov 2002 17:23:58 -0600 (CST)
> Ben Srour <srour@...> wrote:
>=20
> > Whats the deal with the website?
> >=20
> > Ben
>=20
> AFAIK, M.R.Brown has been without internet access for some time. give him=
 a bit to get his stuff together and we should have a pretty new website.
>=20

No, I have my net connection back, but there are still other things
precluding me from getting it done.  I'll keep the list posted.

M. R.

On Thursday 21 Nov 2002 11:49 pm, M. R. Brown wrote:
> * adrian@... <adrian@...> on Thu, Nov 21, 2002:
> > Isn't the point to stay compatible with the format not simply
> > the software? If I follow the Sega way then you woin't be able to
> > save more than two executibles on a vmu, say.
>
> Well, based on our (heated) discussion on IRC, you can only run one
> executable on the VMU anyway, so saving to executables is moot.  IMO it's
> best to stay *completely* compatible.
>
> M. R.

Heated?

Hardly! Lively, probably.

--- Ben Srour <srour@...> wrote:
> Whats the deal with the website?

- regardless of the reaons, those of us with
dreamcasts  just itching for an updated Linux kernel
will just have to wait...

- btw, it appears that while you can indeed, log into
the dreamcast via the coders cable using the release
from http://www.m17n.org/linux-sh/dreamcast/kernel,
you apparently cannot use it for anything else, such
as slattach for SLIP or pppd PPP... 

- we mere (non-developer) dreamcast mortals are still
stuck w/the m17n.org - all else is conjecture... the
serial cable is the only viable option (one would have
to be truly mad to pay for a broadband adapter)...

- it would be wonderful to have a working kernel and
release w/X with a working serial port... 

- otherwise, my dreamcast remains a toy...
> 
> Ben
> 
> -- 
> Ben Srour
> srour@...
> 
> On Thu, 21 Nov 2002 adrian@... wrote:
> 
> > mrbrown@... wrote:
> > > * Adrian McMenamin <adrian@...> on
> Thu, Nov 21, 2002:
> > > > In the vmu all the game files are loaded into
> the vmu from block 0. Other=
> > > =20
> > > > files can be loaded anywhere.
> > > >=20
> > > > Should I implement this in the vmufs driver -
> ie should I force game file=
> > > s=20
> > > > (those with the eXec bit on) to be loaded into
> the vmu from block 0.
> > > >=20
> > > > Reasons for: unless this behaviour is enforced
> it will not be possible to=
> > >  use=20
> > > > vmufs to swap games files.
> > > >=20
> > > > Reasons against: could cuase problems loading
> the vmu with additional fil=
> > > es,=20
> > > > mixes questions of policy with mechanisms.
> > > >=20
> > > > What do people think?
> > > >=20
> > > Isn't the whole point of vmufs to stay
> compatible with official Dreamcast
> > > software?
> > > M. R.
> > >
> > Isn't the point to stay compatible with the format
> not simply
> > the software? If I follow the Sega way then you
> woin't be able to
> > save more than two executibles on a vmu, say.
> >
> >
> >
> >
>
-------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Linuxdc-dev mailing list
> > Linuxdc-dev@...
> >
>
https://lists.sourceforge.net/lists/listinfo/linuxdc-dev
> >
> 
> 
> 
>
-------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linuxdc-dev mailing list
> Linuxdc-dev@...
>
https://lists.sourceforge.net/lists/listinfo/linuxdc-dev


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus – Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Out of curiosity, I may have missed the threath, but is their any plans to
use the modem driver that was recently released on http://www.dreamcast.info.

Ryan

* Ryan Bouwens <rbouwens@...> on Fri, Nov 22, 2002:

> Out of curiosity, I may have missed the threath, but is their any plans to
> use the modem driver that was recently released on http://www.dreamcast.info.
>=20

This modem driver was written for KOS, not Linux.

M. R.

On Saturday 23 Nov 2002 1:21 am, M. R. Brown wrote:
> * Ryan Bouwens <rbouwens@...> on Fri, Nov 22, 2002:
> > Out of curiosity, I may have missed the threath, but is their any plans
> > to use the modem driver that was recently released on http://www.dreamcast.info.
>
> This modem driver was written for KOS, not Linux.
>
The basic point is - we only have three people currently doing any development 
work and we're all busy doing other things at the moment.

A year ago I hadn't written any kernel stuff - so it's not rocket science. 
Anyone with C programing experience can do this - so why don't more people 
jump in!

Adrian

Not like this is any kind of real contribution, but because I am generaly
just an idiot, all I can offer is a true thank you. I usualy do not post
cause I am not part of the solution,just a bystander, but I would really
like you guys to know that the work you do is very much apreciated. I guess
I am just one of those crazy people who find this stuff interesting with out
any real ability to do anything to be part of the community. So all I can
offer is my thanks.

Ryan

> The basic point is - we only have three people currently doing any
development
> work and we're all busy doing other things at the moment.
>
> A year ago I hadn't written any kernel stuff - so it's not rocket science.
> Anyone with C programing experience can do this - so why don't more people
> jump in!
>
> Adrian

if you did want to be helpful, there is something you can do. rally more support for the cause! :D if you know any C coders who'd like to help out, let them know about the list. the more the merrier and all. oh, and thanks for the link - i hadn't seen that before! i might just take on porting it if nobody else has started. time to get more familiar with C ;)

On Sat, 23 Nov 2002 02:38:04 -0900
"Ryan Bouwens" <rbouwens@...> wrote:

> Not like this is any kind of real contribution, but because I am generaly
> just an idiot, all I can offer is a true thank you. I usualy do not post
> cause I am not part of the solution,just a bystander, but I would really
> like you guys to know that the work you do is very much apreciated. I guess
> I am just one of those crazy people who find this stuff interesting with out
> any real ability to do anything to be part of the community. So all I can
> offer is my thanks.
> 
> Ryan

On Sat, 16 Nov 2002 12:23:32 +0000
Adrian McMenamin <adrian@...> wrote:

> But is it a framebuffer device or an mtd device?

Physically, it's obviously a framebuffer device, and I guess we should try
to make it appear as one logically as well.

However, if that doesn't work, can we address its buffer using mmap after
doing an open("/dev/lcd0") or whatever node name we choose ?

Kind regards,

Karl T

* Adrian McMenamin <adrian@...> on Sat, Nov 16, 2002:

> Can I have a definitive statement on where people think this code should =
live?=20
> This seems like a reasonable Saturday afternoon project as most of the co=
de=20
> is extant anyway in the vmu flash driver.
>=20
> But is it a framebuffer device or an mtd device?
>=20
> Answers please.....
>=20

Note that in both stable and devel trees, Maple will be gutted and redone
within the next few weeks.  I don't know if you want to continue with the
driver, but just know *all* maple drivers will be ripped to shreds fairly
quickly...

M. R.

On Saturday 16 Nov 2002 4:00 pm, M. R. Brown wrote:
> * Adrian McMenamin <adrian@...> on Sat, Nov 16, 2002:
> > Can I have a definitive statement on where people think this code should
> > live? This seems like a reasonable Saturday afternoon project as most of
> > the code is extant anyway in the vmu flash driver.
> >
> > But is it a framebuffer device or an mtd device?
> >
> > Answers please.....
>
> Note that in both stable and devel trees, Maple will be gutted and redone
> within the next few weeks.  I don't know if you want to continue with the
> driver, but just know *all* maple drivers will be ripped to shreds fairly
> quickly...
>
> M. R.

I haven't got very far in any case - as doing this as an fb device is not as 
simple as simply ripping out bits of code I don't want.

I will stick to vmufs then...

Adrian