linuxdc-dev — Developer discussion list

[linuxdc-dev] cvs and kernel building

[Jeff T. <jw...@me...>]

I recently placed this as a comment to the cvs source being available on
sourceforge but figured this would be a more appropriate place to put my
questions.

 First a note about my setup

RedHat 6.2
binutils-sh4-linux-010127-2.i386.rpm
gcc-sh4-linux-2.97.001120-3.i386.rpm
gdb-sh-linux-5.0.001127-2.i386.rpm

Please note that the gcc is actually -2.deb version, but alien increased
the number
when I converted it. I was unable to find the -1 version as listed in the
HOWTO
document.


When I compile the firstkernel tarball's source I get the following error:

make[1]: Entering directory `/root/box/kernel/arch/sh/kernel'
sh4-linux-gcc -D__ASSEMBLY__ -D__KERNEL__ -I/root/box/kernel/include -ml
-m4-nofpu -c -o entry.o entry.S
entry.S: Assembler messages:
entry.S:375: Error: must be @(r0,...)
entry.S:376: Error: must be @(r0,...)
entry.S:377: Error: must be @(r0,...)
entry.S:378: Error: must be @(r0,...)
entry.S:379: Error: must be @(r0,...)
entry.S:433: Error: must be @(r0,...)
make[1]: *** [entry.o] Error 1
make[1]: Leaving directory `/root/box/kernel/arch/sh/kernel'
make: *** [_dir_arch/sh/kernel] Error 2

I assume that this is caused by the problems with different gcc versions
as
mentioned in the HOWTO document. Has anyone else got this going with this
version of gcc from m17n.com?

I also retrieved the cvs source and attempted to compile. In this case I
get a failure
in the make dep:

make[4]: Leaving directory `/root/box/linux/net/bridge'
make -C core fastdep
make: Entering an unknown directory
make: *** core: No such file or directory. Stop.
make: Leaving an unknown directory
make[3]: *** [_sfdep_core] Error 2
make[3]: Leaving directory `/root/box/linux/net'
make[2]: *** [fastdep] Error 2
make[2]: Leaving directory `/root/box/linux/net'
make[1]: *** [_sfdep_net] Error 2
make[1]: Leaving directory `/root/box/linux'
make: *** [dep-files] Error 2

Also when I do a make vmlinux not suprisingly I get a:


[root@c895938-a linux]# make vmlinux
sh4-linux-gcc -D__KERNEL__ -I/root/box/linux/include -Wall
-Wstrict-prototypes
-O1 -g -m3 -pipe -c -o init/main.o init/main.c
In file included from /root/box/linux/include/linux/capability.h:17,
from /root/box/linux/include/linux/binfmts.h:4,
from /root/box/linux/include/linux/sched.h:8,
from /root/box/linux/include/linux/mm.h:3,
from /root/box/linux/include/linux/slab.h:13,
from /root/box/linux/include/linux/malloc.h:3,
from /root/box/linux/include/linux/proc_fs.h:4,
from init/main.c:14:
/root/box/linux/include/linux/fs.h:286:28: linux/shmem_fs.h: No such file
or directory

/root/box/linux/include/linux/fs.h:447: field `shmem_i' has incomplete
type
/root/box/linux/include/linux/fs.h:699: field `shmem_sb' has incomplete
type
In file included from /root/box/linux/include/linux/mm.h:4,

etc..etc..

So, the next question is, has anyone had any luck in building these
sources? Any
tips or thoughts are welcome!

I'll be spending some time this weekend working on these problems and
trying to get
things going. I work for a OS level computer security company and have two
other
kernel developers who are going to be getting linux going on their systems
(we want
to get our security extensions on the dreamcast just for fun!), so
hopefully we'll be
able to make a few substantial contributions to the effort.

Thanks for any help!

Jeff

Jeff Thompson
Software Evangelist and Visionary
Senior Security Analyst
Argus Systems Group, Inc.

[linuxdc-dev] CD booting

[Frapazoid <jd...@te...>]

I have several questions here.
First, I need to know if a dreamcast will be able to read a CDRW disk.

Next, I want to know if Linux on a Dreamcast will be able to mount a cd
iso9660 filesystem.
As far as I can tell from the kernel source config, DC Linux doesn't
seem to have a driver for
the dreamcast cdrom drive. (or gdrom.. whaterver)

Is it possible to run the kernel, the filesystem and all the other
software directly
off the cdr without any serial transfers? Is there a DC linux bootloader
yet?

Is it possible to read the raw data from the controller ports? What
about using the modem?
Does that work as a normal serial port, or does the modem need special
drivers?

[linuxdc-dev] First revision of the Unofficial Dreamcast Technical Manual is out

[<ka...@us...>]

Hi all.

The Dreamcast Linux team (linuxdc.sourceforge.net or
www.dreamcastlinux.org or linuxdc.oss [opennic]) has released its first
incantation of a technical manual covering the information on the Sega
Dreamcast gaming console.

The goal of this manual is to collect all available technical information
on the DC console in one place. We chose to write the manual in Docbook
since we can publish the result in PDF, PS, HTML, RTF, info pages or
whatever is wanted fairly easily.


The information contained in this release has been gleaned from various
sources, among those are: Marcus Comstedt's home pages, some of
bITmASTER's releases, the powervr2 register specs released by Lars Olsson.
A complete list of credits is in the appendix. If you see anybody missing
from the credit list, tell us, and we'll fix the original author some
candy as an apology.

The manual itself is licensed under the GNU Free Documentation
License.


If, for any reason, the authors we haven't had any replies from
(Hello bITmASTER) do not wish their material republished in this manual,
please contact me <ka...@us...> asap, and I'll remove the
offending sections.


A browseable version of this release can be found at
http://linuxdc.sourceforge.net/files/book/book1.html

The sources for the manual can be checked out from the Dreamcastlinux CVS:
cvs -d:pserver:ano...@cv...:/cvsroot/linuxdc login
cvs -d:pserver:ano...@cv...:/cvsroot/linuxdc co \
docs



Kind regards,

Karl T

Re: [linuxdc-dev] Contacting Sega

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

On Tue, Jan 30, 2001 at 09:07:59PM -0900, Ryan Bouwens wrote:

> With the pending announcement of the DC's doom. Perhaps Sega will be
> much more open to talking about their systems architecture.

That's certainly an interesting suggestion. Rene, weren't you in contact
with John Byrd about this once before ? 


Karl T

[linuxdc-dev] Contacting Sega

[Ryan B. <rbo...@po...>]

With the pending announcement of the DC's doom. Perhaps Sega will be
much more open to talking about their systems architecture.

-- 
Ryan Bouwens
ry...@bo...

MinorProHockey.com
rbo...@mi...
www.minorprohockey.com

Portalaska.com
rbo...@po...
www.portalaska.com

The Coast Hockey
rbo...@th...
www.thecoasthockey.com

[linuxdc-dev] new to the list

[Vann, M. (CRTATL) <Mar...@co...>]

I heard about this list and project and became very excited at the idea of
making a cluster of these boxes. I figure that with the ether net card
comming out for it in april and the boxes very low cost that making a
beowolf cluster would be very cheap, produce little heat, and consume very
little power. Does anyone have  a bootable iso out yet? Are there any
external storage device available?

Mark Vann
Network Guy
CCNP, CCDA, CCNA , MCSE, Network+
w 678-556-6206
c 404-502-8161



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
Antigen for the presence of computer viruses.
**********************************************************************

[linuxdc-dev] the technical manual

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

Hi all.

After ditching RH 6.0 in favour of Debian 2.2 r2, DocBook finally works 
as it should, so I've even managed to generate some HTML output from 
my first draft for technical manual.

I've also dispatched a mail to Dan Potter, Marcus Comstedt and Bitmaster,
asking for their permission in including all the DC specs and info they have
on their pages into the manual.

I will not import the book into CVS before I've got an affirmative from them,
as I've already included a few tables from both Potter and Bitmaster.

Our Marcus (Brown) has mentioned he'd lend a hand with the book as it got
under way. There's still room for other people to join in. 

Helping in writing the book is probably the easiest way of getting directly
involved in this project until we have a need for massive bug testing. It 
requires only a strong interest in the technical aspects of the DC, a 
familiarity with the English language, and the wits to install the necessary 
DocBook tools on your machine (which is a real hurdle unless you run Debian,
trust me).


I'll report back in a few days, or as soon as I have the go from the original
authors, whichever comes sooner.


Regards,

Karl T

[linuxdc-dev] (no subject)

[Gabe J. <ja...@ho...>]

Thanks I will work on it now.  If anyone knows a very reliable place =
they got all the parts from and how much they paid approximately then =
they could send me the info I would appreciate it.

[linuxdc-dev] Docs...

[John W. <lin...@ho...>]

From the Howto on linuxdc.sourcforge.net, Marcus' web site has all the info 
you're looking for to make the serial cable.
Here's the URL if you want to straight there:

http://mc.pp.se/dc/serifc.html


>From: "Gabe Jaggi" <ja...@ho...>
>To: <Lin...@li...>
>Subject: [linuxdc-dev] (no subject)
>Date: Sun, 7 Jan 2001 11:15:46 -0800
>
>Then I guess my next question is who on thislist will make one for a little 
>over cost or who has some simple instructions with a part list and where I 
>can get the parts?

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

[linuxdc-dev] (no subject)

[Gabe J. <ja...@ho...>]

Then I guess my next question is who on thislist will make one for a =
little over cost or who has some simple instructions with a part list =
and where I can get the parts?

Re: [linuxdc-dev] Stupid Question

[<gh...@in...>]

On Wed, 3 Jan 2001, Gabe Jaggi wrote:

> Hey I know I may be the total stupid first to ask this but in order for all
> this to work you need to make a serial cable right??
> 
> Or am I confused on this?

To run our current kernel release, you will have to make a serial cable,
I'm afraid. We'll see if I can't put together a bootloader so that the
kernel can be burned and booted from CDR(W) in the near future.

Regards,

Karl T

[linuxdc-dev] Stupid Question

[Gabe J. <ja...@ho...>]

Hey I know I may be the total stupid first to ask this but in order for all
this to work you need to make a serial cable right??

Or am I confused on this?

[linuxdc-dev] Kernel sources available

[<gh...@in...>]

Hi all.

Rene doesn't seem to have mentioned to you guys that his patched kernel
has been uploaded to the FTP.

I've html-ized his mini-howto on compiling and installing the kernel and
put it up on our pages: 
http://linuxdc.sourceforge.net/files/LinuxDC-Mini-HOWTO.html

Unless anybody objects, I'll start the work of diffing and importing his
kernel into the CVS, which Rene hasn't done yet. I've not looked at his
sources myself yet, so I don't know how much time this will take.

Cheers,

Karl T

Re: [linuxdc-dev] State of the Kernel 1/1/1

[M. R. B. <ma...@uw...>]

On Tue, 2 Jan 2001, Rene Malmgren wrote:

> 
> Well I have a uploaded my kernel to ftp.dreamcastlinux.org/pub/ And
> added a Mini-HOWTO on how I have done. I would love to se the
> Tools-HOWTO and Kernel-HOWTO, just to compare notes. Its basicly ths
> sh-kernel witch DC RTC added. If your kernel does n't do anything more.
> I think we should start with this one as a starting point. And then add
> your stuff on top. Since my kernel is out there and I think its a doable
> start for many newbies. And it uses the new shlinux standard and has
> Dreamcast as a configurable option.
>

What version of the LinuxSH kernel are you using?  I would still like to
see your patches, especially the ones for DC RTC, I'm curious to see how
you implemented this.
 
> 
> Personaly I belive that the FB and keyboard should get priorety. There
> are lots of people who arn't kernel-hackers but whos contribution to
> this project depends on a working kernel. Its hard to write software
> without a kernel, but you can make do with a slow one. Why cant we
> simply use dans work here for a quick fix.
> 

> As for the Roadahead, from my kernel so to speak. (Taken from a doc I am
> working on)
> 
> Well heres my 2 cents. Right now we can advance on 6 fronts.
> 
> 1 We need a alternative lunch vehile to gdb. A dclilo so to speak. There
> are some alternatives. Also we nead to be able to boot compressed
> kernels, zImage and bzIamge. 
> 

GDB? It looks like we're using completely different methods of uploading
:).  I've been using andrewk's dcload 1.0.0 to upload zImages, which goes
pretty fast.  Unfortunately, the sh tools over at ftp.m17n.org don't
really apply to DC development (kernel or otherwise), so others have been
working to forge our own tools (incl. myself) and so far, dcload is the
best.

> 2 We nead to make this lonely crashing krenel a initrd image. So that we
> an boot an entire OS. Preferbly in a ramdisk or ramfs of some sort. And
> then start moving over user space programs. Now there are some good code
> over at the m17n that would make a good start. This work require little
> skill in programing but could take quite some time.
> 

I'm still trying to calculate where to place initrd in RAM and provide the
right kernel parameters (in empty_zero_page @ 8c011000).  As for bootable
CD/GD-ROM kernels, my idea was that we load zImage and initrd.img using
the scrambled 1ST_READ mechanism, therefore when the DC boots all the
1ST_READ has to do is relocate zImage and initrd (which has already been
loaded into RAM) and boot the kernel.  This would result in a MUCH faster
load IMHO :).

> 3 We nead to expand the driver support for this kernel. Most urgen is
> ofcause mapelbus (keryboard and pad) support and FB support. In the near
> future Modem, CDROM support and NIC support, and then alsa support for
> sound and possebly GDROM.
> 

I disagree here.  The FB and Maple support would be easy enough to write
(based on current KOS/libdream sources), but we wouldn't have "real"
hardware support for the PowerVR2DC ASIC such as interrupts (i.e. instead
of hacked maple/fb support, we would _know_ when we have vert. refresh or
if Maple DMA has completed), external DMA for sound, GD-ROM, and the
expansion port, etc.  The reason I haven't patched this in already is that
I'm still researching how everything works, instead of just having *bits*
and *pieces* I'm going for the big picture.

> 4 Documentasion. We nead better HOWTOs and FAQs
> 

I'm with you there, my HOWTOs are almost finished.

> 5 Integration and testing. So that we can eventualy remerge this kernel
> with the linuxsh and eventualy the linux kernel.
> 

This should be simple enough, I already plan on merging the current
LinuxSH kernel with ours at least once a week.  And by submitting our
patches back to LinuxSH means that they'll eventually make it into Linus'
Kernel.

M. R.

Re: [linuxdc-dev] State of the Kernel 1/1/1

[Rene M. <re...@dr...>]

"M. R. Brown" wrote:

<snip>

> Where's the kernel?
> ===================
> 
> Good question :).  I admit I haven't been spending a lot of time working
> on foolproofing the kernel, but there are a couple of other issues that
> need to be addressed as well.  First off, if you are subscribed to
> LinuxSH's development list (lin...@so...) you'd have seen a
> message from Mitch Davis regarding status of the toolchains (GNU binutils
> and GNU gcc are what I'm most concerned with).  I'm currently working with
> binutils and gcc from cygnus's CVS from Dec. 21st, which appear to be
> mostly stable.  There have been some patches to LinuxSH's kernel (on which
> our LinuxDC kernel is derived), which also help building the kernel with
> the new tools.  I've been taking notes and testing with the procedures
> I've been using to build the kernel, so I'm drafting a Tools-HOWTO and a
> Kernel-HOWTO independant of the ones you'll find on the LinuxSH site.
> Also, Rene, if you got some patches that allow the kernel to build, could
> you also post them to the list as well as committing them to CVS?

Well I have a uploaded my kernel to ftp.dreamcastlinux.org/pub/ And
added a Mini-HOWTO on how I have done. I would love to se the
Tools-HOWTO and Kernel-HOWTO, just to compare notes. Its basicly ths
sh-kernel witch DC RTC added. If your kernel does n't do anything more.
I think we should start with this one as a starting point. And then add
your stuff on top. Since my kernel is out there and I think its a doable
start for many newbies. And it uses the new shlinux standard and has
Dreamcast as a configurable option.

> 
> So, to make a long story short, from my side of things, we need to get
> going on starting to add peripheral support to the Linux kernel for the
> DC, but I'm still a little unsure of where to start.  The framebuffer
> would be good for the demo effect, but there are things to consider when
> writing a FB such as acceleration and overall system performance.  So I've
> been reversing the kernel and gathering info in an attempt to map out the
> resources provided by the PowerVR2DC (G2) ASIC, so that low-level support
> for the G2 can go into the kernel first.

Personaly I belive that the FB and keyboard should get priorety. There
are lots of people who arn't kernel-hackers but whos contribution to
this project depends on a working kernel. Its hard to write software
without a kernel, but you can make do with a slow one. Why cant we
simply use dans work here for a quick fix.

As for the Roadahead, from my kernel so to speak. (Taken from a doc I am
working on)

Well heres my 2 cents. Right now we can advance on 6 fronts.

1 We need a alternative lunch vehile to gdb. A dclilo so to speak. There
are some alternatives. Also we nead to be able to boot compressed
kernels, zImage and bzIamge. 

2 We nead to make this lonely crashing krenel a initrd image. So that we
an boot an entire OS. Preferbly in a ramdisk or ramfs of some sort. And
then start moving over user space programs. Now there are some good code
over at the m17n that would make a good start. This work require little
skill in programing but could take quite some time.

3 We nead to expand the driver support for this kernel. Most urgen is
ofcause mapelbus (keryboard and pad) support and FB support. In the near
future Modem, CDROM support and NIC support, and then alsa support for
sound and possebly GDROM.

4 Documentasion. We nead better HOWTOs and FAQs

5 Integration and testing. So that we can eventualy remerge this kernel
with the linuxsh and eventualy the linux kernel.

6 Tools, we nead better understanding and decription on the tools we
use. Most critecly now is the buggs in GCC and binutils. We also nead to
make nice .deb packages of all the tools to make life easier for
developers, and hopefully make debian policy complient. And ofcauser we
nead to supp other distributions aswell. Most notebley Redhat and
Mandrake RPM and slackware .tgz





--
/Rene

[linuxdc-dev] State of the Kernel 1/1/1

[M. R. B. <ma...@uw...>]

Aargh! Life.

I apologize for being so quiet lately, I've been juggling between work,
family, reversing the lengthy Dreamcast BIOS, and GNU toolsmithing.  The
good thing is, next week (after the 1st), I'll have working DSL in my apt.
so all my updates will come straight from home :). 

Anyways, here's some ideas and here's where I'm headed starting next week:

Karl, the hardware doc will be A Good Thing, as long as we have a defined
format for submissions and an organization for chapters, I have some info
to submit :).  The info I have would probably go under "BIOS" or "Hardware
Initialization".  They key is to sectionalize each major component of the
DC (e.g. Section 1: SH4 Core, Section 2: PowerVR2DC/System ASIC, Section
3: BIOS, Section 4: Physical Hardware).  Here's a contrived example:

Section 1: SH7750 Core

- Memory map
- Programming Models
- ...

Note that this is NOT an exact duplicate of the SH7750 HW manual, it
should introduce a newbie to the DC's structure (e.g. how the pieces of
different systems work together), so that the SH7750 HW/Programming
manuals become _supplements_ to the DC HW manual.

Section 2: PowerVR2DC System ASIC

- Introduction
- Resources: External DMA, IRQ 9, etc.
- GD-ROM
- Video (just raw info on components, not tutorials on 3D ;)
- AICA
- Maple
- Expansion Port

This is the most "uncharted" area of the DC.  I've been spending a lot of
time lately with the GD-ROM syscalls, the code of which is located in the
16KB of space @ 8c000000-8c003fff.  The Introduction chapter would give a
brief rundown of each system connected to the ASIC (or G2 - which is it?),
followed by raw details of each subsystem.

Section 3: BIOS

- Hardware Initialization
- System/Bios calls
- DC Shell

I've seen some wicked code in the DC BIOS, anyone who finds themselves
bored one afternoon should give it a shot :P.  The most interesting
routine I've seen so far is the main hardware init routine, which sets
huge sets of HW registers using a special register/init table.  Also,
system calls (copied from the BIOS during init to 8c000000) can also be
explained in this section, and possibly a treatise on the inner workings
of the DC Shell.

Section 4: Peripherals

- Maple bus peripherals (keyboard, mouse, etc.)
- Expansion peripherals (modem, NIC, etc.)

Details inner workings of each peripheral.

Section 5: Physical Hardware

- Pinouts of external DC ports
- Pin locations inside the DC
- Timing info, etc.

Where's the kernel?
===================

Good question :).  I admit I haven't been spending a lot of time working
on foolproofing the kernel, but there are a couple of other issues that
need to be addressed as well.  First off, if you are subscribed to
LinuxSH's development list (lin...@so...) you'd have seen a
message from Mitch Davis regarding status of the toolchains (GNU binutils
and GNU gcc are what I'm most concerned with).  I'm currently working with
binutils and gcc from cygnus's CVS from Dec. 21st, which appear to be
mostly stable.  There have been some patches to LinuxSH's kernel (on which
our LinuxDC kernel is derived), which also help building the kernel with
the new tools.  I've been taking notes and testing with the procedures
I've been using to build the kernel, so I'm drafting a Tools-HOWTO and a
Kernel-HOWTO independant of the ones you'll find on the LinuxSH site.
Also, Rene, if you got some patches that allow the kernel to build, could
you also post them to the list as well as committing them to CVS?

So, to make a long story short, from my side of things, we need to get
going on starting to add peripheral support to the Linux kernel for the
DC, but I'm still a little unsure of where to start.  The framebuffer
would be good for the demo effect, but there are things to consider when
writing a FB such as acceleration and overall system performance.  So I've
been reversing the kernel and gathering info in an attempt to map out the
resources provided by the PowerVR2DC (G2) ASIC, so that low-level support
for the G2 can go into the kernel first.

Anyone who has more info on the G2 or _any_ low-level DC components is
encouraged to fire when ready :)

But I'll start churning out what I have now, thanks for being so patient.

M. R.

Re: [Linuxdc-dev] CVS decision.

[<gh...@in...>]

On Sun, 31 Dec 2000, Rene Malmgren wrote:

> Well I an't Marcus. But in the meantime I thinkt we have to make due
> with my kernel...
> 
> I got tierd of waiting and pached up mine to a "workable" state.

Wonderful.

> How do I check it in?

Easiest way of doing it would be this:

cvs -d :ext:du...@cv...:/cvsroot/linuxdc co \
linux

Now you have the linux kernel tree that lies on SF. Copy/patch your
modifications into the checked out tree. (You might have already worked in
this tree. But it's imperative that you checked it out as your SF login
account, not as anonymous. If you checked it out as anonymous, you're not
allowed to check changes back in.)

After the patching, stay in the linux directory (the root directory of the
tree) and do:

cvs up

This will insure that if marcus or anybody else with cvs access (me ;)
have done any modifications, those modifications will be applied to your
local tree. Your local tree must be completely up to date before you do a
check in.

To check in, you have to do two things:

1) For all the new files that are not already in the tree, you must do
   cvs add <filename>
2) Once all those files have been added and the rest have been patched,
   do, from the linux-kernel root directory ('linux')
   cvs commit -m "First attempt at a bootable kernel"

The message is for you to decide. It's normal to have a specific message
for each file that you commit. That is, for each fix you do, you commit
the file you fixed with an appropriate comment. That way, we can easily
look at a file's revision history and see who and when fixed which bugs.

General comments such as that one I suggested above ("First attempt..")
should be used very seldom, since it really doesn't tell us what has been
fixed in the files that have been touched (patched).


I hope this helps. If there's any interest for it, I can look around and
see if there are any CVS guidelines we could adopt. If not, I could try
writing some, and put them up on our pages. It would be a Good Thing to
have some kind of guideline for how we mess up the tree.


Regards,

Karl T

Re: [Linuxdc-dev] CVS decision.

[<gh...@in...>]

On Sun, 31 Dec 2000, Rene Malmgren wrote:

> Well cant we have both? I would like to keep asterix as a "standby"
> server. If SF should start acting up again. So we dont get stuck like we
> did last time.

Then we use asterix is an off-site backup ready to take over if SF cvs
goes down. 

Official CVS is then: cvs.linuxdc.sourceforge.net
(anonymous access:
:pserver:ano...@cv...:/cvsroot/linuxdc)

Marcus, now is the time to start checking in your work. We're all anxious
to have a completely working Linux port by the end of this year ;)


Regards,

Karl T

[Linuxdc-dev] CVS decision.

[<gh...@in...>]

Hi all.

The problem with anonymous access to CVS on sourceforge has been fixed.
Which leads me to the question: Should we move the CVS back to SF since
nobody has used it on asterix anyway ?

Pros:

- Better servers with faster lines
- CVS mail
- Regular backups

Cons:

- Currently no direct access to the CVS repository (will come shortly)


Any thoughts on this ? I think we should move back so that we have asterix
available for more interesting work (such as automatically generating
kernel binaries every night).

Regards,

Karl T

[Linuxdc-dev] Problems with CVS

[Victor R. <yco...@so...>]

 Hi!

I can't download the files of anonymous cvs, he sais: "REJECTED ACCESS". =
Please, help me ^^

bye, aka Daijo.

Re: [Linuxdc-dev] Not on this list

[Gabe J. <ja...@ho...>]

Sorry the point was that it has no prblem with thos settings and had nothing
to do with burning any other thing or promoting that.

In fact I am trying to just help a guy mainly with some new development of
an emulator.  All my games have been legally bought ;P

[Linuxdc-dev] Not on this list

[Jeff D. <jd...@dr...>]

> burning DC copies with an IDE recorder. Anyone?
...
> I use a HP 9110i to burn DC games just fine but that is in Windows I have

There are plenty of other forums to discuss copying games.  Let's stick to
discussing which drives are compatible with our goals of creating a
linuxDC boot disc... get it?  If your experience with burning DC discs is
gained for non-legit means, let's try not to be so explicit.

Thanks,
Jeff

[Linuxdc-dev] Re: Burning to disc

[Gabe J. <ja...@ho...>]

Heheh

I use a HP 9110i to burn DC games just fine but that is in Windows I have
yet to try it in Linux but I will be attempting that tonight!

We will see I guess.

Re: [Linuxdc-dev] Re: Burning to disc

[Matt P. <ma...@mp...>]

Plextor PlexWriter 12/10/32S (SCSI) has been working like a charm for myself.

At 12:00 AM 12/19/00, Coma wrote:

>The HP 7200i was the first CD Recorder i tried, and let me tell you, it 
>sucked.
>No matter what they say, i'll always love my Yamaha SCSI :)
>
>I own a Yamaha CRW4416S for a while and it has never let me down. I don't 
>know if it's 'cause IDE recorders just can't handle the job, or Yamaha CD 
>Recorders kick ass.
>
>Eitherway, SCSI Recorders are alot more relieable, so you really should 
>get one, if you want to do some DC Burning. In fact, i don't know anyone 
>burning DC copies with an IDE recorder. Anyone?
>
>I liked that database idea. Count me on
>
>
>Coma
>'life is never bad enough, that can't get worse'
>
>
>_______________________________________________
>Linuxdc-dev mailing list
>Lin...@li...
>http://lists.sourceforge.net/mailman/listinfo/linuxdc-dev

--
Matt Plummer               [ma...@mp...]
MP3.com, Inc.              [858.623.7000]
Your Premier Music Service Provider {MSP}

[Linuxdc-dev] Re: Burning to disc

[Coma <co...@de...>]

The HP 7200i was the first CD Recorder i tried, and let me tell you, it sucked.
No matter what they say, i'll always love my Yamaha SCSI :)

I own a Yamaha CRW4416S for a while and it has never let me down. I don't 
know if it's 'cause IDE recorders just can't handle the job, or Yamaha CD 
Recorders kick ass.

Eitherway, SCSI Recorders are alot more relieable, so you really should get 
one, if you want to do some DC Burning. In fact, i don't know anyone 
burning DC copies with an IDE recorder. Anyone?

I liked that database idea. Count me on


Coma
'life is never bad enough, that can't get worse'