François Revol | 15 Dec 12:59 2003
Picon

OpenBeOS floppy driver

This morning at 6 am I succesfully transfered the first file from a 
floppy using the OpenBeOS floppy driver :) (and fell on the bed just 
after)

It's slow as hell for now as I transfer each sector at once, but it 
works.
I currently use the PIO mode, and I think if I get it fast enough we 
might 
be able to drop ISA DMA support from the isa bus manager, since it's 
only 
used for that it seems.
It already supports 720K floppies and double drives, which the R5 
driver
doesn't know about.

It should appear in the cvs RSN.

François.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Axel Dörfler | 15 Dec 13:27 2003
Picon

Re: OpenBeOS floppy driver

"François Revol" <revol@...> wrote:
> This morning at 6 am I succesfully transfered the first file from a 
> floppy using the OpenBeOS floppy driver :) (and fell on the bed just 
> after)
> 
> It's slow as hell for now as I transfer each sector at once, but it 
> works.
> I currently use the PIO mode, and I think if I get it fast enough we 
> might 
> be able to drop ISA DMA support from the isa bus manager, since it's 
> only 
> used for that it seems.
> It already supports 720K floppies and double drives, which the R5 
> driver
> doesn't know about.
> 
> It should appear in the cvs RSN.

That sounds really great, François! :-)

Bye,
   Axel.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
François Revol | 15 Dec 13:44 2003
Picon

Re: OpenBeOS floppy driver

> "François Revol" <revol@...> wrote:
> > This morning at 6 am I succesfully transfered the first file from a 
> > floppy using the OpenBeOS floppy driver :) (and fell on the bed 
> > just 
> > after)
> > 
> > It's slow as hell for now as I transfer each sector at once, but it 
> > works.
> > I currently use the PIO mode, and I think if I get it fast enough 
> > we 
> > might 
> > be able to drop ISA DMA support from the isa bus manager, since 
> > it's 
> > only 
> > used for that it seems.
> > It already supports 720K floppies and double drives, which the R5 
> > driver
> > doesn't know about.
> > 
> > It should appear in the cvs RSN.
> 
> That sounds really great, François! :-)
> 
Btw Axel, this one is for you
http://www.back2roots.org/Tools/Files/Amiga%20Floppy%20Reader%2C2/
:)))

Actually Amiga floppy support is nearly impossible with PC FDC, since 
they don't seem use the same track format...
AFR.C in this zip tells a bit about it.
(Continue reading)

burton666 | 15 Dec 14:09 2003
Picon

Re: Re: OpenBeOS floppy driver


>Actually Amiga floppy support is nearly impossible with PC FDC, since they don't 

>seem use the same track format...

>AFR.C in this zip tells a bit about it.

Actually, there is a solution, which involves the use of a second floppy drive, but can't remember right now.

---------------------------------------------------------
Stanco dello spam nella tua email? Prova GRATIS
il nuovo servizio ANTISPAM di superEva:
http://webmail.supereva.it/spam.html
---------------------------------------------------------

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
Axel Dörfler | 15 Dec 15:24 2003
Picon

Re: OpenBeOS floppy driver

"François Revol" <revol@...> wrote:
> Btw Axel, this one is for you
> http://www.back2roots.org/Tools/Files/Amiga%20Floppy%20Reader%2C2/
> :)))
> 
> Actually Amiga floppy support is nearly impossible with PC FDC, since 
> they don't seem use the same track format...
> AFR.C in this zip tells a bit about it.

Actually, I still have an Amiga to do that, so I won't need such a 
thing ;-)

Bye,
   Axel.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
François Revol | 17 Dec 11:35 2003
Picon

lock.h

There are several drivers and filesystems that make use of a file 
called lock.h, which defines nothing more than a benaphore struct and 4 
kernel exports. Instead of copying this file everywhere, ould we have 
it public ? Btw, there is a 
current/headers/private/kernel/lock.h
which doesn't define the same API, as it comes from NewOS.

François.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
Axel Dörfler | 17 Dec 15:24 2003
Picon

Re: lock.h

"François Revol" <revol@...> wrote:
> There are several drivers and filesystems that make use of a file 
> called lock.h, which defines nothing more than a benaphore struct and 
> 4 
> kernel exports. Instead of copying this file everywhere, ould we have 
> it public ? Btw, there is a 
> current/headers/private/kernel/lock.h
> which doesn't define the same API, as it comes from NewOS.

Yes, I thought about "melting" them to one file. I guess we have to 
export the functions anyway, although I'd check first if the mlock 
stuff is used anyway (looks very superficial to me).
AFAICT only the PCMCIA bus manager and the NTFS file system add-ons are 
using it, so I'd say that we should try to remove them first, if only 
in the headers.
I also think we should change the LOCK() and UNLOCK() macros to static 
inline functions and rename them to acquire_lock() and release_lock().
We should just replace our benaphore_*() stuff in the lock header with 
those functions, in order to keep the kernel as clean as possible.

Bye,
   Axel.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
François Revol | 17 Dec 15:27 2003
Picon

Re: lock.h

> "François Revol" <revol@...> wrote:
> > There are several drivers and filesystems that make use of a file 
> > called lock.h, which defines nothing more than a benaphore struct 
> > and 
> > 4 
> > kernel exports. Instead of copying this file everywhere, ould we 
> > have 
> > it public ? Btw, there is a 
> > current/headers/private/kernel/lock.h
> > which doesn't define the same API, as it comes from NewOS.
> 
> Yes, I thought about "melting" them to one file. I guess we have to 
> export the functions anyway, although I'd check first if the mlock 
> stuff is used anyway (looks very superficial to me).
yeah... m = minimalistic ?

> AFAICT only the PCMCIA bus manager and the NTFS file system add-ons 
> are 
> using it, so I'd say that we should try to remove them first, if only 
> in the headers.
They are at least used by the NFS client too.
But we have the source for this one.

> I also think we should change the LOCK() and UNLOCK() macros to 
> static 
> inline functions and rename them to acquire_lock() and 
> release_lock().
> We should just replace our benaphore_*() stuff in the lock header 
> with 
> those functions, in order to keep the kernel as clean as possible.
(Continue reading)

Axel Dörfler | 17 Dec 15:51 2003
Picon

Re: lock.h

"François Revol" <revol@...> wrote:
> > Yes, I thought about "melting" them to one file. I guess we have to 
> > export the functions anyway, although I'd check first if the mlock 
> > stuff is used anyway (looks very superficial to me).
> yeah... m = minimalistic ?

Dunno if they thought much at all when introducing these :)

> > AFAICT only the PCMCIA bus manager and the NTFS file system add-ons 
> > are using it, so I'd say that we should try to remove them first, 
> > if only 
> > in the headers.
> They are at least used by the NFS client too.
> But we have the source for this one.

Hm, the CIFS add-on does not, and I don't have a NFS add-on here. Also, 
the file system API will be different, and not compatible, so that's 
not a problem ;)

Okay, I'll add those calls then, and remove the various lock.h - thanks 
for the hint.

Bye,
   Axel.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
(Continue reading)

Niels Reedijk | 20 Dec 14:43 2003
Picon

Build broken

Hello all,

I don't know if this is a known problem, but the build is currently 
broken in libroot. I know
that you are working on this, Axel, so if the compile error is intended
/known, don't worry
then. The message:

KernelLd objects/x86.R1/kernel/init
objects/x86.R1/kernel/libroot.so: undefined reference to `vsnprintf'

        ld  --script=src/kernel/ldscripts/x86/app.ld  -o "objects/
x86.R1/kernel/init"  "objects/x86.R1/kernel/libglue2.o" "objects/x86.R1
/kernel/apps/init.o" "objects/x86.R1/kernel/libroot.so"  -L /boot/
develop/tools/gnupro/lib/gcc-lib/i586-beos/2.9-beos-991026 -lgcc  ;

Niels Reedijk

P.S. I hope to have a small surprise ready for christmas!

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Gmane