linuxdc-dev — Developer discussion list

Re: [linuxdc-dev]dnet client for Dreamcast

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

* edd...@wa... <edd...@wa...> on Thu, May 16, 2002:

>=20
> I remember reading a paper about cooling problems in the Dreamcast, that=
=20
> may be a killer if you spend the whole [day|week|month|year] running it...
>=20

What cooling problems?  Have any URLs of relevance?  Sounds strange since
I've left my DC on for days at a time, with a fair amount of CPU load
(crashme) and I've never had any problems with it.

M. R.

Re: [linuxdc-dev]dnet client for Dreamcast

[<edd...@wa...>]

Adrian McMenamin wrote:

> I am not sure what the point of all this really is - but there is a working 
> dnet client for linux on the Dreamcast at:
> 
> http://www.distributed.net/download/prerelease.html
> 
> (see the SH4 pre-release).
> 
> If that's what you're into you might like it?
> 
> Adrian


Wha that's one heck of a game! Endless hours of fun, high level of 
adrenaline and user interaction... :)

I remember reading a paper about cooling problems in the Dreamcast, that 
may be a killer if you spend the whole [day|week|month|year] running it...

Anyway, that's still cool!

/Dantes

[linuxdc-dev]dnet client for Dreamcast

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

I am not sure what the point of all this really is - but there is a working 
dnet client for linux on the Dreamcast at:

http://www.distributed.net/download/prerelease.html

(see the SH4 pre-release).

If that's what you're into you might like it?

Adrian

Re: [linuxdc-dev]DC memory map question

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

* Adrian McMenamin <ad...@mc...> on Sun, Apr 28, 2002:

> Do these addresses mean anything to anybody?
>=20
> r7 =3D 0x8c03f9c0
> r6 =3D 0x8c03f890
> r5 =3D 0x8c03f890
>=20
> Or are they just system ram addresses?
>=20

Anything between 0x8c000000 and 0x8cffffff are system ram addresses (or
0x0cXXXXXX or 0xacXXXXXX).

M. R.

[linuxdc-dev]DC memory map question

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

Do these addresses mean anything to anybody?

r7 = 0x8c03f9c0
r6 = 0x8c03f890
r5 = 0x8c03f890

Or are they just system ram addresses?


Adrian

Re: [linuxdc-dev]SH4 functions on DC - re assistance if possible

[Stuart M. <stu...@st...>]

Adrian

The frame pointer is used when stack contains objects of unknown size, for
example variable size arrays, or when alloca() is used. It is also used
sometimes when setting up the parameters for functions which take a large
number of parameters.

In this case the stack will look something like:

  higher address

    |caller's stack
    +------------------
    |parameters
    |
    |local variables
    +------------------   <- frame pointer
    |
    |dynamic data
    |
    +------------------   <- stack pointer

  lower address

Normally the compiler uses the offset from the stack pointer to reference
local variables. However when there is dynamic data, the compiler cannot
use the stack pointer because it doesn't know at compile time the size
of the dynamic data. 

So what the compiler will do, when it detects this situation, is after
moving the stack pointer down to make room for the local variables, it
copies the stack pointer into the frame pointer, and from then on reference
local variables and parameters through the frame pointer. The stack pointer
is now used only for allocating dynamic data and making further function
calls.

In theory the compiler only need to do this when dynamic data is being used,
but in practice it makes backtracing through code easier if the frame pointer
is always used. So you'll frequently see code which stores the frame
pointer on the stack, and copies stack pointer to frame pointer on entry
to a function, and then never uses it, simply because it makes backtracing
easier for debugger.

Stuart


On Tue, 23 Apr 2002 23:27:07 +0100
ad...@mc... wrote:

> On Tuesday 23 Apr 2002 11:40 am, Stuart Menefy wrote:
> > Adrian
> >
> > This is something I wrote a while ago when somebody asked the same question
> > (I assume were talking gcc here).
> >
> 
> Stuart,
> 
> Thanks very much for this - very helpful and already the dissasembly is 
> beginning to make sense - but what is the frame register (r14) - ie what is 
> it's function.
> 
> This is not a term I've coem across before and I cannot find it referenced in 
> the Hitachi programming manual.
> 
> Thanks,
> 
> Adrian


-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

Re: [linuxdc-dev]SH4 functions on DC - re assistance if possible

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

On Tuesday 23 Apr 2002 11:40 am, Stuart Menefy wrote:
> Adrian
>
> This is something I wrote a while ago when somebody asked the same question
> (I assume were talking gcc here).
>

Stuart,

Thanks very much for this - very helpful and already the dissasembly is 
beginning to make sense - but what is the frame register (r14) - ie what is 
it's function.

This is not a term I've coem across before and I cannot find it referenced in 
the Hitachi programming manual.

Thanks,

Adrian

Re: [linuxdc-dev]SH4 functions on DC - re assistance if possible

[Stuart M. <stu...@st...>]

Adrian

This is something I wrote a while ago when somebody asked the same question
(I assume were talking gcc here).

Simply:
- r0-r7 are caller save (ie the called function can use them without
      having to save them first)
- r8-r15 and pr are callee save (ie if the called function wants to update 
      them then it must save them first)
- First four integer parameters are passed in register r4-r7, remainder on
      the stack
- r15 is the stack pointer, so will generally by saved/restored automatically,
      and r14 is the frame pointer, which you may or may not choose to use.
- r0 is used for the return value, if it fits in a word, otherwise the function
      is called with r2 as a pointer to where the result should be stored.
Floating point I'm not so sure about, and can be complex, but basically:
- fr0-fr11 are caller save
  fr12-fr15 are callee save
- Parameters are passed in dr4-dr10 (which corrisponds to fr4-fr11),
  but when a mix of floats and doubles are passed they are
  'packed' into the lower registers, possibly 'rounding up' to get the
  next available double length register. The remainder are on the stack.

In general the easiest way to do anything with this is experiment. Try
writing a small C program which does what you want, and look at the
generated assembler.

So for your example:
  foobar(int32 x, void* y, int16 z)
x, y and z will be in r4, r5 and r6 respectivly.

Hope this is some help

Stuart



On Mon, 22 Apr 2002 22:42:38 +0100
ad...@mc... wrote:

> if I have a function in C - say:
> 
> foobar(int32 x, void* y, int16 z)
> 
> When that turns up in SH4 assembler - how are the parameters passed?
> 
> Adrian
> 
> _______________________________________________
> Linuxdc-dev mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxdc-dev


-- 
Stuart Menefy                                        stu...@st...
STMicroelectronics Ltd                         ST Intranet: mo.bri.st.com
Bristol, UK                         Rest of the World: www.linuxsh.st.com

[linuxdc-dev]SH4 functions on DC - re assistance if possible

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

if I have a function in C - say:

foobar(int32 x, void* y, int16 z)

When that turns up in SH4 assembler - how are the parameters passed?

Adrian

[linuxdc-dev]Apologies and update

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

Sorry - made the same mistake twice in a row and forgot to saved edited 
change log - so recommitted changes in Config.in for Puru Puru pack to 
reflect its limited support for real world PPP devices.

Adrian

Re: [linuxdc-dev]Burning bootable CD

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

* edd...@wa... <edd...@wa...> on Wed, Mar 20, 2002:

>=20
> The code contained in 1ST_READ.BIN is dependant on the system state, as=
=20
> initialised by IP.BIN. That's why they're tied. As long as the=20
> 1ST_READ.BIN only needs the standard stuff, it's fine. But you can't say=
=20
> they are fully independant for this reason.
>=20

Sorry, I still can't accept this.  Homebrew software and Linux doesn't care
about the state of the machine since they reinitialize it anyway.  VBR,
cache, etc. is either setup implicitly (crt0.s), explicitly (newos, kos, or
linux), or ignored.  Even Sega software reinitializes the hardware past what
the IP.BIN bootstrap provides, and WinCE definitely goes and does its own
thing (trust me, I've seen the code).  The DC system BIOS and boot block do=
es
more meaningful hardware initialization than anything the IP.BIN bootstrap
could hope to accomplish.  Case-in-point: the original Serial Slave and
gdbstubs port were available as IP.BIN bootstrap replacements.  They did not
have any IP.BIN bootstrap routines to rely on, since they replaced them :P.

Also, since everyone uses the Sega standard IP.BIN, including games,
incompatibility is a non-issue.  There is no explicit connection (other
than the boot filename field in the IP.BIN header) between IP.BIN and
1ST_READ.BIN.  They are fully independent of one another.

M. R.

Re: [linuxdc-dev]Burning bootable CD

[<edd...@wa...>]

M. R. Brown wrote:

[snip]

> I never said it was standard or that the bootstrap code couldn't be
> modified.  But what does the above have to do with the original discussion
> about pairing IP.BIN and 1ST_READ.BIN?


The code contained in 1ST_READ.BIN is dependant on the system state, as 
initialised by IP.BIN. That's why they're tied. As long as the 
1ST_READ.BIN only needs the standard stuff, it's fine. But you can't say 
they are fully independant for this reason.

> Right, because you're wrong.  WinCE games use the same bootstraps as
> non-WinCE games.  There is a replacement IP.BIN on www.boob.co.uk that
> replaces the Sega bootstraps with non-Sega (OSS) code, but since the
> license screen can't be removed it's pretty much moot (unless it does
> something spectacular that the Sega bootstraps don't).


Fine. That's something I didn't dig, just a mere thought.

> Any CD authoring software worth its salt doesn't care what tracks you burn
> to a CD, or what order you burn them in.  You burn track 1 as audio, and
> leave the session open.  You burn track 2 as mode 2 form 1 (CD-XA) and close
> the session.  What software is unable to do that?
> 
> The boot sector is irrelevant as it's inserted by a 3rd-party program (at
> least under Windows sans Cygwin it is, under Linux you can use cat and dd).
> The boot sector is embedded in the first 16 sectors of the CD image, and no
> CD authoring software that I'm aware of cares about or otherwise utilizes this
> data.
> 
> Furthermore, there have been countless tutorials, guides, and scripts that
> show you how to generate valid DC CD boot images.  Even if you are inept
> enough not to be able to follow those, do you mean to tell me that you
> can't burn the countless homebrew demos and games that are already provided
> in a burnable image?


You're interpreting what I said (or maybe it's my english). I did NOT 
say that is was not possible, but that is was not straightforward. Audio 
+ CD-XA with bootstrap code is not a *common* CD format, and those 
wizards thingies under Windows don't allow you to do so. You need to 
follow a procedure to obtain the correct CD. That's it.

If you increase the number of steps, you increase the possibilities of 
combinations between those steps, and (probably by a much larger factor 
:) the number of SCREWUPBIGTIME (c) results. That is the weakness of 
those procedures.

The burnable images have nothing to do with it, they're already made. 
Just dd'ing a CD under Linux gives you a correct image to burn. This is 
not a very complex task.

> Windows CD authoring programs were designed for non-literate people, as are
> the guides that demonstrate creating a bootable CD.  The only protection
> afforded by the GD-ROM media was that it was proprietary, and once that
> limitation was overcome there were no other protections.  Sega did a
> presentation on how hard it was to pirate via CDRs?  Or were you referring
> to the GD-ROM format?
> 
> M. R.
> 

Well spotted, my mistake. That was about the GD-ROM format. OK, I got 
this one wrong. :)

/Dantes

Re: [linuxdc-dev]Burning bootable CD

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

* edd...@wa... <edd...@wa...> on Wed, Mar 20, 2002:

>=20
> And what do you call the areas "bootstrap 1" and "bootstrap 2"? Standard=
=20
> boot code? No way! As MC says:
> "...this code can be modified. The default implementation sets up a few=
=20
> hardware registers and then transfers control to Bootstrap 2. ... Like=20
> Bootstrap 1, it can be modified. The default implementation sets up the=
=20
> CPU stack, the VBR, disables the cache, and transfers control to the=20
> 1ST_READ.BIN."
>=20

I never said it was standard or that the bootstrap code couldn't be
modified.  But what does the above have to do with the original discussion
about pairing IP.BIN and 1ST_READ.BIN?

> As far as I can understand, there is a *default* implementation, not a=20
> *standard* one. I believe (from my own experiments) that games using=20
> different APIs (as in Sega opposed to WinCE) use different IP.BIN, but=20
> that should not be taken as proved.
>=20

Right, because you're wrong.  WinCE games use the same bootstraps as
non-WinCE games.  There is a replacement IP.BIN on www.boob.co.uk that
replaces the Sega bootstraps with non-Sega (OSS) code, but since the
license screen can't be removed it's pretty much moot (unless it does
something spectacular that the Sega bootstraps don't).

>=20
> Having a boot sector in the beginning of the second track, and not of=20
> the CD, is not a common thing. Therefore, most CD authoring software=20
> don't do it correctly, which leads to weird manipulations. We're not=20
> talking odd hardware problems, we're talking general use of software. If=
=20
> it was so straightforward, it would'nt be so long and complicated to=20
> burn such a CD.
>=20

Any CD authoring software worth its salt doesn't care what tracks you burn
to a CD, or what order you burn them in.  You burn track 1 as audio, and
leave the session open.  You burn track 2 as mode 2 form 1 (CD-XA) and close
the session.  What software is unable to do that?

The boot sector is irrelevant as it's inserted by a 3rd-party program (at
least under Windows sans Cygwin it is, under Linux you can use cat and dd).
The boot sector is embedded in the first 16 sectors of the CD image, and no
CD authoring software that I'm aware of cares about or otherwise utilizes t=
his
data.

Furthermore, there have been countless tutorials, guides, and scripts that
show you how to generate valid DC CD boot images.  Even if you are inept
enough not to be able to follow those, do you mean to tell me that you
can't burn the countless homebrew demos and games that are already provided
in a burnable image?

> Moreover, do you really believe that Sega would sell a console with no=20
> media protection? As advertised in one of their presentations, this=20
> implementation provides some sort of protection for the non-literate=20
> people, unable with standard software (at the time) to do a perfect copy.
>=20

Windows CD authoring programs were designed for non-literate people, as are
the guides that demonstrate creating a bootable CD.  The only protection
afforded by the GD-ROM media was that it was proprietary, and once that
limitation was overcome there were no other protections.  Sega did a
presentation on how hard it was to pirate via CDRs?  Or were you referring
to the GD-ROM format?

M. R.

Re: [linuxdc-dev]Burning bootable CD

[<edd...@wa...>]

M. R. Brown wrote:

[snip]

> Yes you can.  What do you think the distributed IP.BIN files contain?  They
> contain standard Sega boot code - used by all Dreamcast software.
> 
> The only dependancy between IP.BIN and 1ST_READ.BIN (or whatever you decide
> to call it) is the boot filename - it must name an existing file.  It doesn't
> matter what you call it as long as it exists.
> 
> See http://mc.pp.se/dc/ip.bin.html and http://mc.pp.se/dc/ip0000.bin.html
> for further clarification (you can also get an utility from this site to
> create custom IP.BIN files).


And what do you call the areas "bootstrap 1" and "bootstrap 2"? Standard 
boot code? No way! As MC says:
"...this code can be modified. The default implementation sets up a few 
hardware registers and then transfers control to Bootstrap 2. ... Like 
Bootstrap 1, it can be modified. The default implementation sets up the 
CPU stack, the VBR, disables the cache, and transfers control to the 
1ST_READ.BIN."

As far as I can understand, there is a *default* implementation, not a 
*standard* one. I believe (from my own experiments) that games using 
different APIs (as in Sega opposed to WinCE) use different IP.BIN, but 
that should not be taken as proved.

> Um, nonstandard?  DC bootable CDRs are composed of 1 or more Red Book CDDA
> audio tracks and 1 Yellow Book CD-XA track.  How is this nonstandard?  Your
> "enhanced" Doobie Brothers CD is in the same format.  Older and crippled CD
> burners (i.e. Sony) don't support CD-XA in hardware, but any modern burner
> should.
> 
> M. R.
> 


Having a boot sector in the beginning of the second track, and not of 
the CD, is not a common thing. Therefore, most CD authoring software 
don't do it correctly, which leads to weird manipulations. We're not 
talking odd hardware problems, we're talking general use of software. If 
it was so straightforward, it would'nt be so long and complicated to 
burn such a CD.

Moreover, do you really believe that Sega would sell a console with no 
media protection? As advertised in one of their presentations, this 
implementation provides some sort of protection for the non-literate 
people, unable with standard software (at the time) to do a perfect copy.


Regards
/Dantes

Re: [linuxdc-dev]Burning bootable CD

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

* edd...@wa... <edd...@wa...> on Wed, Mar 20, 2002:

> > I used an IPBIN file from I think fivemouse.com and one from DCquake.=
=20
> > Does the IPBIN and firstboot file have to be created together?
>=20
> Yes, they are paired. The IP.BIN file does not only contain data about=20
> the software, it also contains the boot code, which initialises the DC.=
=20
> For example, you can't use an IP.BIN file from a game (using WinCE or=20
> not) to put in a LinuxDC CD. The code contained is just not the same.
>=20

Yes you can.  What do you think the distributed IP.BIN files contain?  They
contain standard Sega boot code - used by all Dreamcast software.

The only dependancy between IP.BIN and 1ST_READ.BIN (or whatever you decide
to call it) is the boot filename - it must name an existing file.  It doesn=
't
matter what you call it as long as it exists.

See http://mc.pp.se/dc/ip.bin.html and http://mc.pp.se/dc/ip0000.bin.html
for further clarification (you can also get an utility from this site to
create custom IP.BIN files).

>=20
> No clue...
> I've got a Yamaha CRW2100S, and before that I had a Yamaha 4416S, and=20
> both did/are doing the job perfectly.
> I can't stress enough the fact that due to the somehow weird (as in=20
> nonstandard) nature of those CDs, I never managed to get one correct=20
> under Windows, regardless of the soft I was using. Switch to Linux, and=
=20
> try again!
>=20

Um, nonstandard?  DC bootable CDRs are composed of 1 or more Red Book CDDA
audio tracks and 1 Yellow Book CD-XA track.  How is this nonstandard?  Your
"enhanced" Doobie Brothers CD is in the same format.  Older and crippled CD
burners (i.e. Sony) don't support CD-XA in hardware, but any modern burner
should.

M. R.

[linuxdc-dev]Linux Progress Patch on DC?

[Micah D. <mi...@yo...>]

Hi everybody,

I just had a (hopefully) quick question... has anyone tried using the Linux Progress Patch with the dreamcast yet? I'm sure it's not high on the priority list, but it would probably be a pretty quick hack to get it working, and it would allow a completely graphical startup of linux if that's desired. I know that when LinuxDC becomes useful for games and network apps and such, the average user would prefer that to seeing boot messages.

Time for bed...

-- 
Only you can prevent creeping featurism!

Re: [linuxdc-dev]Burning bootable CD

[<edd...@wa...>]

Dave Kaupp wrote:

[snip]

 > I've killed about 8 cd's and had to quit when I ran out. :)

I bought a tower of 100 no-brand no-box el-cheapo CDs just to prevent 
this from happening when I started playing with DC CDs... :)

 > I used an IPBIN file from I think fivemouse.com and one from DCquake. 
 > Does the IPBIN and firstboot file have to be created together?

Yes, they are paired. The IP.BIN file does not only contain data about 
the software, it also contains the boot code, which initialises the DC. 
For example, you can't use an IP.BIN file from a game (using WinCE or 
not) to put in a LinuxDC CD. The code contained is just not the same.

 > When reading the burning instructions I believe it stated that the
 > CDrom
 > needed to support as certain mode and that cheap burners don't support
 > that mode. I'm not really sure what "cheap" means, does anyone know
 > what
 > burners do not support the mode mentioned?

No clue...
I've got a Yamaha CRW2100S, and before that I had a Yamaha 4416S, and 
both did/are doing the job perfectly.
I can't stress enough the fact that due to the somehow weird (as in 
nonstandard) nature of those CDs, I never managed to get one correct 
under Windows, regardless of the soft I was using. Switch to Linux, and 
try again!

Good luck. :)
/Dantes

Re: [linuxdc-dev]Burning bootable CD

[Dave K. <re...@li...>]

On Wed, 13 Mar 2002, Adrian McMenamin wrote:

> On Wednesday 13 Mar 2002 6:38 am, David Willmore wrote:
> > >  I'm trying to create a bootable linux CD and I can't seem to get it to
> > > work. Is this a proper forum to ask about creating bootable CD's?
> > >
> > >  I tried the master.sh and also followed the instructions on the mc.pp.se
> > > site. I'm guessing it could be my burner? It's a Microimages backpack CD.
> > >
> > >  I can boot from a CD my friend made me a few months ago using Nero I
> > > think.
> >
> > I walked through the instructions twice on two seperate occasions and
> > have never had any luck.  I think I'm hung up on getting a good IP.BIN
> > as I don't have any existing DC software to snag a copy from.  I found
> > a tool that claimed to make one, but the resulting disk doesn't read.
> >
> It can be done, I assure you! What is going wrong? Just coasters? Have you 
> looked at http://www.fivemouse.com? It has some instructions too...


 I've killed about 8 cd's and had to quit when I ran out. :)

 I used an IPBIN file from I think fivemouse.com and one from DCquake.
Does the IPBIN and firstboot file have to be created together?

 When reading the burning instructions I believe it stated that the CDrom
needed to support as certain mode and that cheap burners don't support
that mode. I'm not really sure what "cheap" means, does anyone know what 
burners do not support the mode mentioned?

Re: [linuxdc-dev]Status of LinuxDC / 3D drivers

[Micah D. <mi...@yo...>]

On Mon, Mar 18, 2002 at 03:25:15AM -0600, M. R. Brown wrote:
> * Micah Dowty <mi...@yo...> on Mon, Mar 18, 2002:
> 
> > Hi Everybody,
> > 
> > I'm an embedded systems enthusiast, linux geek, and author of the PicoGUI (http://picogui.org) GUI architecture for embedded systems.
> > 
> > Last thursday I saw a friend's dreamcast boot linux, compile and run PicoGUI. It was so cool I got my own 2 days later, and found a broadband adapter on eBay.
> > 
> 
> Cool.  Have any links to binaries or images?

I posted the pgserver binary itself at:

http://picogui.org/download/dreamcast/first-sh4-pgserver

Right now you can't do much with it. You'll probably want to download at least one picogui theme from http://picogui.org/themes, and load that with the -t option. I haven't tried compiling apps for the Dreamcast yet, we were running the apps on an x86 PC via the broadband adaptor.

Once I get my own broadband adaptor I'll be able to do some developing on it, hopefully including an accelerated video driver, and input drivers for the controllers (and the samba de amigo maracas :)

> 
> > I'm interested in helping with Linux on the Dreamcast, but since I maintain PicoGUI and attend college i don't have time to maintain a distro myself. So I was quite happy to find the LinuxDC project seemingly alive and well :)
> 
> Alive, but I'm not so sure about well :P.  Adrian's been actively fixing bugs
> and cracking hardware, Paul and I have been busy with the 2.5 restructuring
> work for our parent project, LinuxSH (linuxsh.org), which hasn't hit the
> LinuxDC tree yet.
> 
> > 
> > Most of all, I'd like to be able to run PicoGUI fast on the dreamcast, and port games like BZflag. This requires having a driver for the tile accelerator under linux. Wading through all the "31337 haxor"-isms surrounding console game development, it looks like there's plenty of information on the PowerVR chip available. So I would just need to know where this driver goes.
> > 
> > I'm not sure I'm up for writing a complete OpenGL layer on top of the PowerVR, but I'd like to at least put together a kernel module and/or userspace library that lets applications use the accelerator. Is there a standard for doing this that doesn't require X?
> > 
> 
> I don't know of any other kernel-level interfaces for direct access to
> graphic accelerators besides DRI/DRM (dri.sourceforge.net) and /dev/opengl,
> which is used to access the 3D features of certain SGI machines (see the
> SGI OSS MIPS port).  Currently DRI/DRM requires X.
> 
> Paul started a DRM module in CVS, but it was only the initial boilerplate
> needed to get it to compile, nothing specific.  You're more than welcome to
> develop your own implementation or finish the DRM module - it's entirely up
> to you.  Any form of TA access for userland under Linux would be a good
> thing, official or not :P.
> 
> Please let us know what you come up with.  If you can even develop a basic
> patch that adds any functionality to the kernel, we'll grant you SF developer
> access for CVS, etc.

Ok, cool. Once i get my BBA i'll try writing a userspace app to demo the accelerator, and get some sort of interface into the kernel. I guess my options are:

 - Something DRI-like, but without X
 - Something in /dev you can mmap to get the PowerVR registers, then a userspace library to manipulate the accelerator
 - Mesa?

I dunno.. i'll have to research this more

> 
> Thanks,
> 
> M. R.



-- 
Only you can prevent creeping featurism!

Re: [linuxdc-dev]Status of LinuxDC / 3D drivers

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

* Micah Dowty <mi...@yo...> on Mon, Mar 18, 2002:

> Hi Everybody,
>=20
> I'm an embedded systems enthusiast, linux geek, and author of the PicoGUI=
 (http://picogui.org) GUI architecture for embedded systems.
>=20
> Last thursday I saw a friend's dreamcast boot linux, compile and run Pico=
GUI. It was so cool I got my own 2 days later, and found a broadband adapte=
r on eBay.
>=20

Cool.  Have any links to binaries or images?

> I'm interested in helping with Linux on the Dreamcast, but since I mainta=
in PicoGUI and attend college i don't have time to maintain a distro myself=
. So I was quite happy to find the LinuxDC project seemingly alive and well=
 :)

Alive, but I'm not so sure about well :P.  Adrian's been actively fixing bu=
gs
and cracking hardware, Paul and I have been busy with the 2.5 restructuring
work for our parent project, LinuxSH (linuxsh.org), which hasn't hit the
LinuxDC tree yet.

>=20
> Most of all, I'd like to be able to run PicoGUI fast on the dreamcast, an=
d port games like BZflag. This requires having a driver for the tile accele=
rator under linux. Wading through all the "31337 haxor"-isms surrounding co=
nsole game development, it looks like there's plenty of information on the =
PowerVR chip available. So I would just need to know where this driver goes.
>=20
> I'm not sure I'm up for writing a complete OpenGL layer on top of the Pow=
erVR, but I'd like to at least put together a kernel module and/or userspac=
e library that lets applications use the accelerator. Is there a standard f=
or doing this that doesn't require X?
>=20

I don't know of any other kernel-level interfaces for direct access to
graphic accelerators besides DRI/DRM (dri.sourceforge.net) and /dev/opengl,
which is used to access the 3D features of certain SGI machines (see the
SGI OSS MIPS port).  Currently DRI/DRM requires X.

Paul started a DRM module in CVS, but it was only the initial boilerplate
needed to get it to compile, nothing specific.  You're more than welcome to
develop your own implementation or finish the DRM module - it's entirely up
to you.  Any form of TA access for userland under Linux would be a good
thing, official or not :P.

Please let us know what you come up with.  If you can even develop a basic
patch that adds any functionality to the kernel, we'll grant you SF develop=
er
access for CVS, etc.

Thanks,

M. R.

[linuxdc-dev]Status of LinuxDC / 3D drivers

[Micah D. <mi...@yo...>]

Hi Everybody,

I'm an embedded systems enthusiast, linux geek, and author of the PicoGUI (http://picogui.org) GUI architecture for embedded systems.

Last thursday I saw a friend's dreamcast boot linux, compile and run PicoGUI. It was so cool I got my own 2 days later, and found a broadband adapter on eBay.

I'm interested in helping with Linux on the Dreamcast, but since I maintain PicoGUI and attend college i don't have time to maintain a distro myself. So I was quite happy to find the LinuxDC project seemingly alive and well :)

Most of all, I'd like to be able to run PicoGUI fast on the dreamcast, and port games like BZflag. This requires having a driver for the tile accelerator under linux. Wading through all the "31337 haxor"-isms surrounding console game development, it looks like there's plenty of information on the PowerVR chip available. So I would just need to know where this driver goes.

I'm not sure I'm up for writing a complete OpenGL layer on top of the PowerVR, but I'd like to at least put together a kernel module and/or userspace library that lets applications use the accelerator. Is there a standard for doing this that doesn't require X?

-- 
Only you can prevent creeping featurism!

[linuxdc-dev]Progress/lack of progress wth Sega Puru Puru Pack

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

I have been trying to get this to work all weekend - with no luck :-<.

This is the code that sends packets to the maple bus:

static void play_puru(struct dc_purupuru *puru)
{
	/* Play the selected effect */
	struct mapleq *play = &(puru->data->mq);
	play->command = 14;
	play->length = 2;
	((unsigned long *) (play->recvbuf))[0] =
	    cpu_to_be32(MAPLE_FUNC_PURUPURU);
	((unsigned long *) (play->recvbuf))[1] = "A VALUE";
	play->sendbuf = play->recvbuf;
	if (maple_add_packet(play) != 0)
		DEBGM("Could not add packet\n");
}


Here are the different results for different "A VALUE"s


/*
Works
0x11 - no output
0x10 - no ouput
0x12 - tho appears to generate disconnect/connect messages
0x14 - as for 0x12
0x18 - no output
0x1f - no output
0x8010 - though no output
0x8018 - as above
0x801f - as above
0x0810 - as above
0x081f - as above
0x10108010 - as above
0xffff8010 - as above
Fails
0x00
0x20
0x30
0x40
0x80
0x100
0x110
0x210
0x410 - generates a small jolt on NAKI
0x800
0xf10 - though generates a small jolt on NAKI
0x1010
0x2010 - though produces tiny jolt on NAKI
0x4010 - though produces tiny jolt on NAKI
0x8000
0x80ff
0x8110 - though runs gentle spin on NAKI
0x8210
0x8030
0x8410 - though spins on NAKI
0x8810
0x8f10 - though spins on NAKI
0xffff - though does work on NAKI
0xff10 - though does work on NAKI
0xff20
0xff30 - though does work on NAKI
0xf010 - though does work on NAKI
0xf000
0xff00
0xff
0x40
*/

Works means that the maple bus returns a command acknowlegement (7), fails 
means the bus returns a -4 (resend command). The NAKI PPP always seems to 
return a 7.

Nothing I've done actually makes the SEGA one vibrate (this is what no output 
means above).

Can anyone see a pattern? Given that the NAKI pack vibrates normally with 
games then it must be the case that there is a condition where it's behaviour 
and the SEGA behaviour are the same.

The only thing I can see is that bit 4 needs to be on as a minimum condition 
for the SEGA pack.

Adrian

[linuxdc-dev]Maple bus -4 response

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

Can anyone tell me about how/why such a response might be generated and how 
to handle it?

My puru puru device driver for Linux works fine with the Naki (cloned) rumble 
pack, but with the Sega puru puru each command sent to the device appears to 
generate a -4 response.

Adrian

[linuxdc-dev]Very odd behaviour - any clues?

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

On Saturday 16 Mar 2002 10:45 am, Adrian McMenamin wrote:
> MR Brown had already told me about this - but now I've seen it with my own
> eyes.
>
> The current Puru Puru driver does not support Sega's own PP pack device.
>
> I'm investigating and will post a fix as soon as.
>
I wrote the driver and tested against the Naki runble pack I had. Works fine, 
apart from an odd hot plugging bug I have been dealing with...

But the SEGA pack behaves 'oddly' in that - driver correctly identifies it 
and is associalted with it.

But when I attempt to play an effect it appears to reset the device/whole 
maple bus - generating a whole set of disconnection/connection messages - 
anybody any ideas as to what causes this sort of behaviour?

Adrian

[linuxdc-dev]Puru Puru bug

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

MR Brown had already told me about this - but now I've seen it with my own 
eyes.

The current Puru Puru driver does not support Sega's own PP pack device.

I'm investigating and will post a fix as soon as.

Adrian