linuxdc-dev — Developer discussion list

[linuxdc-dev]Maple problem - any advice

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

Would/could one of the maple gurus help me with this?

I have tried using all the commands shown on Marcus Comstedt's site.

The simple ones:

Request device information
Request extended device information
Reset device
Shutdown device

All work.

But so far none of the other commands have worked - all generate the unknown 
command repsonse (-3).

I suppose my questions are:

Are there likely to be other commands - or is Marcus C list likely to be 
comprehensive?

What is the correct way to set up commands with parameters?

Latest bit of code I am using:
 if (data->mq.done)
    {
      data->mq.command = 14;
      data->mq.length = 2;
      ((unsigned long *)data->mq.recvbuf)[0] = MAPLE_FUNC_MICROPHONE;
      ((unsigned long *)data->mq.recvbuf)[1] = 1<<16;
      ((unsigned long *)data->mq.recvbuf)[2] = 0x0;
      data->mq.sendbuf = data->mq.recvbuf;
      maple_add_packet(& data->mq);
    }

but I have tried all sorts of other combinations too!

In the meantime I will continue to plug away. At least I am really beginning 
to understand how this (maple) all works.

Adrian

Re: [linuxdc-dev]More maple & microphone

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

On Tuesday 05 Feb 2002 1:51 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Tue, Feb 05, 2002:
> > Generally speaking the Maple reply string is:
> >
> > "Maple reply (1, 1) cmd=9 => -3"
> >
> > Which I take to mean that the microphone just doesn't understand the "Get
> > condition" command (ie returns -3 meaning "Unknown command").
>
> It may be that you must first use "set condition" before issuing a "get
> condidtion", or that "get condition" isn't supported at all.  I see that
> you get 0x0f from the device information call ... this kinda corresponds to
> the values I have for the mic:

Well, set condition (14) generates a -3 response too! So I need to find 
something else. I'll try get memory information (10).


Adrian

Re: [linuxdc-dev]More maple & microphone

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

* Adrian McMenamin <ad...@mc...> on Tue, Feb 05, 2002:

>=20
> Generally speaking the Maple reply string is:
>=20
> "Maple reply (1, 1) cmd=3D9 =3D> -3"
>=20
> Which I take to mean that the microphone just doesn't understand the "Get=
=20
> condition" command (ie returns -3 meaning "Unknown command").
>=20

It may be that you must first use "set condition" before issuing a "get
condidtion", or that "get condition" isn't supported at all.  I see that
you get 0x0f from the device information call ... this kinda corresponds to
the values I have for the mic:

GETSAMPLEDATA	1
MICCONTROL	2
AMPCONTROL	4
TESTMODE	8

Are these indicators of what interfaces the mic supports?  That's highly
likely, since 0x0f would be the bitwise OR of all of them.  I don't know
*anything* more about the format of the calls (I haven't started reversing
more than just the basic stuff), but I'll have more later.  It does seem
that the mic supports 8Khz and 11Khz sampling, with 16-bit linear (signed)
and 8-bit muLaw samples.

Try sending these (32-bit value) on "set condition" calls and see what you
come up with (and if "get condition" now works on the next frame).  They'll
probably fail if they need accompanying data.

> The first four values of recvbuf are -3, 64, 65, 0. Meaning (I think):=20
> Unknown command reposnse sent to Port B from subperipherial 1 on Port B, =
no=20
> further words in frame: all of which makes sense. (Stop me if I am going=
=20
> wrong here!)
>=20

Not to nitpick, but could you dump the values in hex form?  It makes it a
bit easier to pick apart the bits :P.

> But this leaves me with a problem - viz: if it doesn't send data in respo=
nse=20
> to this command what does it send it in response to?!
>=20

I'll have more information later.

M. R.

[linuxdc-dev]Re: More maple & microphone

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

On Tuesday 05 Feb 2002 12:53 am, Adrian McMenamin wrote:

> But this leaves me with a problem - viz: if it doesn't send data in
> response to this command what does it send it in response to?!
>
> Adrian

The obvious thing to do seems to be to call up a block read? Is that sensible?

[linuxdc-dev]More maple & microphone

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

Apologies for boring everyone but I am testing out ideas and this is the best 
place to try:

I have this code:

static void dc_microphone_callback(struct maple_driver_data *data)
{

	struct mapleq *mq=& data->mq;
	struct dc_microphone *mic = data->private_data;
	/* Have we got data */
/*  	length = mq->length; */
	int x = 0;
  	unsigned char *buf = mq->recvbuf;

/*   	memcpy(mic->snd, mq->buf, length*2); */

	//char* buf = (char *)((mq->recvbuf) + 4);
	printk("Maple reply (%d, %d) cmd=%d => %d\n", mq->port, mq->unit, 
mq->command, mq->recvbuf[0]);
	for (x = 0; x < 20; x++) printk("%i,",mq->recvbuf[x]);
	printk("   ");
     
}

Generally speaking the Maple reply string is:

"Maple reply (1, 1) cmd=9 => -3"

Which I take to mean that the microphone just doesn't understand the "Get 
condition" command (ie returns -3 meaning "Unknown command").

The first four values of recvbuf are -3, 64, 65, 0. Meaning (I think): 
Unknown command reposnse sent to Port B from subperipherial 1 on Port B, no 
further words in frame: all of which makes sense. (Stop me if I am going 
wrong here!)

But this leaves me with a problem - viz: if it doesn't send data in response 
to this command what does it send it in response to?!

Adrian

Re: [linuxdc-dev]More ram

[Dylan E. <cra...@bi...>]

At 10:52 PM 4/02/2002, you wrote:
>* Dylan Egan <cra...@bi...> on Mon, Feb 04, 2002:
>
> > Hi i was inquiring whether you were able to add more ram to the dc
> > externally much like the ide/nic made by bITmASTER?
> >
>
>It's certainly possible, but are you inquiring on the part of feasibility
>or of someone else to implement it?  In the latter case you're pretty much
>on your own as no one has dedicated themselves to making funky DC add-on
>devices.  IOW, you need to be a hardware guru to do such things, there's no
>one around to just do it for you.  On the feasibility side, you have to ask
>yourself:
>   1) how fast could such an interface possibly be, seeing that the G2 Bus
>   (where the expansion port lives) is only clocked at 16-bit@25Mhz while the
>   native SDRAM interface is 64-bit@100Mhz?
>   2) how would applications or operating systems detect and utilize such
>   RAM?
>   3) is it more trouble than it's worth?
>
>If you feel comfortable answering those questions, then by all means go
>ahead and impress the world.
>
>M. R.
Hmmm i guess you're right but with the amount of ram on the dc atm what are 
a list of things todo on the dc?

[linuxdc-dev]Mpale driver modularisation

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

Just to point out this behaviour:

When I rmmod the microphone module and the microphone is still connected I 
get a kernel panic.

If I disconnect the microphone and then remove the driver there is no problem.

Adrian

Re: [linuxdc-dev]Testing my understanding of maple

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

On Monday 04 Feb 2002 12:59 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> > Anyone able to tell me where this data really is and how to get it?
>
> The microphone has to be controlled before read.  Unless you have another
> source on how the microphone works, be prepared to "hack it yourself".
>
> M. R.

Having spent all day (sort of) looking at the maple sources, I think I have a 
better understanding of all this, but my questions were really about the 
basic maple mecahnism, not the specifics of the SIP (which I am happy to hack 
away at).

Here are some of them:

mapleq.done - how is this set to non-zero?

maple_driver_cmd_callback - this is called via maple_dma_irq - does this mean 
there is data to be read when the callback is called (this is a slightly more 
sophisticated version of yesterday's question) - anyone able to tell me?

Adrian

Re: [linuxdc-dev]More ram

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

* Dylan Egan <cra...@bi...> on Mon, Feb 04, 2002:

> Hi i was inquiring whether you were able to add more ram to the dc=20
> externally much like the ide/nic made by bITmASTER?
>=20

It's certainly possible, but are you inquiring on the part of feasibility
or of someone else to implement it?  In the latter case you're pretty much
on your own as no one has dedicated themselves to making funky DC add-on
devices.  IOW, you need to be a hardware guru to do such things, there's no
one around to just do it for you.  On the feasibility side, you have to ask
yourself:
  1) how fast could such an interface possibly be, seeing that the G2 Bus
  (where the expansion port lives) is only clocked at 16-bit@25Mhz while the
  native SDRAM interface is 64-bit@100Mhz?
  2) how would applications or operating systems detect and utilize such
  RAM?
  3) is it more trouble than it's worth?

If you feel comfortable answering those questions, then by all means go
ahead and impress the world.

M. R.

[linuxdc-dev]More ram

[Dylan E. <cra...@bi...>]

Hi i was inquiring whether you were able to add more ram to the dc 
externally much like the ide/nic made by bITmASTER?

Regards,

Dylan

Re: [linuxdc-dev]Testing my understanding of maple

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

On Monday 04 Feb 2002 12:59 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> > Anyone able to tell me where this data really is and how to get it?
>
> The microphone has to be controlled before read.  Unless you have another
> source on how the microphone works, be prepared to "hack it yourself".
>
> M. R.

I'm making some progress, but its slow. Oh well.

Re: [linuxdc-dev]Testing my understanding of maple

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

* Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:

>=20
> Anyone able to tell me where this data really is and how to get it?
>=20

The microphone has to be controlled before read.  Unless you have another
source on how the microphone works, be prepared to "hack it yourself".

M. R.

[linuxdc-dev]Testing my understanding of maple

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

I have got my microphone driver to 'record' data, but its all garbage and 
nothing I do with sox appears to turn it into anything even approximating 
real world sound.

So I am wondering if I have misunderstood the basic maple callback mechanism 
(probably, I am sure, is the answer).

This is my current callback:

struct dc_microphone
{
  struct input_dev dev;
  struct maple_driver_data *data;
  unsigned char snd[8094];
  int open;

};

static void dc_microphone_callback(struct maple_driver_data *data)
{

	struct mapleq *mq=& data->mq;
	struct dc_microphone *mic = data->private_data;
	unsigned char *buf = (unsigned char *)mq->recvbuf;

	memcpy(mic->snd, mq->buf, 1024);
     
}

An OSS read call then reports back the contents of mic->snd. I am not worried 
about the size of the buffers at present, just getting the basic mechanism 
right.

I am assuming that on each call to callback mq->recvbuf contains the buffered 
data loaded by a DMA transfer - but this seems a pretty wild assumption.

Anyone able to tell me where this data really is and how to get it?

Thanks

Adrian

[linuxdc-dev]Re: [dcdev] KOS vs DC Linux vs Blagh; and OSX/Darwin (see bottom)

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

* RC5Stint <rc5...@ya...> on Sat, Feb 02, 2002:

>=20
> There's this other non-existent "absolute" stuff we've been hearing
> about for like ages.  But why talk about something so utterly
> irrelevant?  It might as well not be mentioned if no one can see it.=20
> After all, if a tree falls in the woods ...
>=20

The first piece of absolute is the patched toolchain you are currently
using.  But hey, after all if it's sitting in your lap...

> And besides, running Linux on a gaming console makes about as much
> sense as Dan Quayle running for President.  It's existence is purely
> academic (the only reason I bother with LinuxDC is to learn about
> embedded Linux.  It has "absolutely" no utility for me.)
>=20

I do concur, with the parenthesised portion of the second sentence.
Everything else stated happens to be hogwash.  LinuxDC is and will
continue to be reference work, as well as being the *only* other Open
Source kit that touches the hardware efficiently and strives to support all
DC hardware.

[CC'd to linuxdc-dev, since other replies in this thread are being
suspiciously dropped by dcdev moderators.]

M. R.

[linuxdc-dev]Microphone details for the record

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

So as to leave a permanent record that can be searched for by other Dreamcast 
developers and in case I fall under a bus .... microphone deviceinfo details 
follow:

function:	0x00000010
data[0]:	0x0000000f
data[1]:	0x00000000
data[2]:	0x00000000
area code: 3
direction: 1
name: 	"SoundInputPeripheral (S.I.P.) "
licence:	"Produced By or Under License From SEGA ENTERPRISES,LTD.    "
standby power:	300
max power:	300

To make some sense of this see: http://mc.pp.se/dc/maplebus.html


Adrian

Re: [linuxdc-dev]Maple connect

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

On Sunday 03 Feb 2002 7:59 am, Fredrik Hubinette wrote:
> Fredrik Hubinette <hu...@hu...> writes:
> > I'm going to write a little code that connects drivers to devices when
> > modules are added so that no disconnection will be needed, but I don't
> > know how to fix the unresolved symbol problem.
>
> Ok, I commited some patches to maple.c which attach drivers to units
> whenever they are loaded.  Maple itself still can't be compiled as
> a module because of the unresolved symbol, but at least maple module
> development should be smoother now.
>
>         /Hubbe


This appears to work fine for my microphone 'driver'. Thanks for that

Re: [linuxdc-dev]Re: [linuxdc-cvs] CVS Update: linux-sh-dc (branch: trunk)

[Fredrik H. <hu...@hu...>]

"M. R. Brown" <mr...@0x...> writes:

> 
> Please remember to update and commit the ChangeLog.dc file when making
> changes.  ChangeLog.dc should have at least one entry for every commit.
> 
> Thanks,
> 
> M. R.

Noted, will do, entry added.

        /Hubbe

[linuxdc-dev]Re: [linuxdc-cvs] CVS Update: linux-sh-dc (branch: trunk)

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

* Fredrik Hubinette <hu...@us...> on Sat, Feb 02, 2002:

> CVSROOT:	/cvsroot/linuxdc
> Module name:	linux-sh-dc
> Repository:	linux-sh-dc/drivers/maple/
> Changes by:	hubbe@usw-pr-cvs1.	02/02/02 23:46:40
>=20
> Log message:
>   Devices are now automatically connected to their approperiate drivers w=
hen a new driver is loaded. This should make developing maple modules signi=
ficantly more convenient.
>=20

Please remember to update and commit the ChangeLog.dc file when making
changes.  ChangeLog.dc should have at least one entry for every commit.

Thanks,

M. R.

Re: [linuxdc-dev]Maple connect

[Fredrik H. <hu...@hu...>]

Fredrik Hubinette <hu...@hu...> writes:

> I'm going to write a little code that connects drivers to devices when
> modules are added so that no disconnection will be needed, but I don't
> know how to fix the unresolved symbol problem.

Ok, I commited some patches to maple.c which attach drivers to units
whenever they are loaded.  Maple itself still can't be compiled as
a module because of the unresolved symbol, but at least maple module
development should be smoother now.

        /Hubbe

Re: [linuxdc-dev]Maple connect

[Fredrik H. <hu...@hu...>]

"M. R. Brown" <mr...@0x...> writes:

> * Fredrik Hubinette <hu...@hu...> on Sat, Feb 02, 2002:
> 
> > 
> > Have you tried connecting the microphone to the DC *after* having loaded
> > the module? I think that will work. (Let me know)
> > 
> 
> Have you been able to detect any other Maple devices after the
> corresponding module has been loaded?  I haven't.  No device detection occurs
> whatsoever when Maple is built as modules.  Even when the core of Maple
> itself (maplebus.o) is built into the kernel, it still doesn't work.

I never tried to compile any maple stuff as modules before today.
I tried compiling maple itself as a module, which gives me an unresolved
symbol '__flush_purge_region' when I try to load it.

However, if I comple maple.c into the kernel and leave the individual
drivers as modules, modprobe the drivers and then connect a device to
the dreamcast everything works as normal.

I'm going to write a little code that connects drivers to devices when
modules are added so that no disconnection will be needed, but I don't
know how to fix the unresolved symbol problem.

Also, I suppose some code that auto-loads the driver modules would
be nice, but I don't know how to do that either. (yet)

        /Hubbe


        

Re: [linuxdc-dev]Maple connect

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

* Fredrik Hubinette <hu...@hu...> on Sat, Feb 02, 2002:

>=20
> Have you tried connecting the microphone to the DC *after* having loaded
> the module? I think that will work. (Let me know)
>=20

Have you been able to detect any other Maple devices after the
corresponding module has been loaded?  I haven't.  No device detection occu=
rs
whatsoever when Maple is built as modules.  Even when the core of Maple
itself (maplebus.o) is built into the kernel, it still doesn't work.

Maybe this is a good time to start discussing the new core, or what should
become of the new core?

M. R.

Re: [linuxdc-dev]Maple connect

[Fredrik H. <hu...@hu...>]

"M. R. Brown" <mr...@0x...> writes:

> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> 
> > 
> > I think I am - unless you can spot an error here - is this a modularisation 
> > problem - ie this can't be done as a module?
> > 
> 
> Yeah, Maple is *completely* broken as modules.  I haven't investigated why
> since Paul was planning an eventual rewrite of the core.
> 
> It's always been broken in module form.
> 
> M. R.

I think I see the modulariisation problem...

Have you tried connecting the microphone to the DC *after* having loaded
the module? I think that will work. (Let me know)

I haven't had time to work on the maple stuff for a little while, but
if the problem is what I think it is it should be fairly easy to fix.

        /Hubbe

Re: [linuxdc-dev]Maple connect

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

* Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:

>=20
> I think I am - unless you can spot an error here - is this a modularisati=
on=20
> problem - ie this can't be done as a module?
>=20

Yeah, Maple is *completely* broken as modules.  I haven't investigated why
since Paul was planning an eventual rewrite of the core.

It's always been broken in module form.

M. R.

Re: [linuxdc-dev]Maple connect

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

On Sunday 03 Feb 2002 12:38 am, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:
> > What are the circumstances under which the 'connect' function for a maple
> > client device will be called?
> >
> > I am building an experimental driver - as a module - for the microphone
> > and while clearly the init and exit functions are being called and the
> > maple core correctly reports the loading of a microphone driver, connect
> > doesn't seem to get called.
>
> Did you register your driver with maple?  Your init() routine should have a
> call to maple_register_driver() with a pointer to the statically allocated
> maple_driver structure in your source.  Are you sure this is being setup
> correctly?
>
> static struct maple_driver microphone_driver = {
> 	function:	MAPLE_FUNC_MICROPHONE,
> 	name:		"Microphone",
> 	connect:	my_microphone_connect,
> 	disconnect:	my_microphone_disconnect,
> };
>
> M. R.

I think I am - unless you can spot an error here - is this a modularisation 
problem - ie this can't be done as a module?

static struct maple_driver dc_microphone_driver = {
	function:	MAPLE_FUNC_MICROPHONE,
	name:		"Dreamcast microphone",
	connect:	dc_microphone_connect,
	disconnect:	dc_microphone_disconnect,
	reply:		dc_microphone_callback,
	vblank:		maple_getcond_vblank_callback,
	
};


static int __init dc_microphone_init(void)
{
	
	maple_register_driver(&dc_microphone_driver);
	
	return 0;
}


static void __exit dc_microphone_exit(void)
{
	maple_unregister_driver(&dc_microphone_driver);
	if (unload_microphone()){
	  DEBGM("Maple: Microphone did not unload cleanly\n");
	}

}

Re: [linuxdc-dev]Maple connect

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

* Adrian McMenamin <ad...@mc...> on Sun, Feb 03, 2002:

> What are the circumstances under which the 'connect' function for a maple=
=20
> client device will be called?
>=20
> I am building an experimental driver - as a module - for the microphone a=
nd=20
> while clearly the init and exit functions are being called and the maple =
core=20
> correctly reports the loading of a microphone driver, connect doesn't see=
m to=20
> get called.
>=20

Did you register your driver with maple?  Your init() routine should have a
call to maple_register_driver() with a pointer to the statically allocated
maple_driver structure in your source.  Are you sure this is being setup
correctly?

static struct maple_driver microphone_driver =3D {
	function:	MAPLE_FUNC_MICROPHONE,
	name:		"Microphone",
	connect:	my_microphone_connect,
	disconnect:	my_microphone_disconnect,
};

M. R.