linuxdc-dev — Developer discussion list

[linuxdc-dev]Re: [linuxsh-dev] Floating point problems - Dreamcast 2.4.10-pre6 kernel

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

Additional point: I am using gcc 3.0.1 as the cross compiler

[linuxdc-dev]Floating point problems - Dreamcast 2.4.10-pre6 kernel

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

I have been working to make/port a decent mp3 player for the Dreamcast now 
that there is a sound driver.

I have built mpg123 with these options:

dream:
	$(MAKE) CC=sh4-linux-gcc LDFLAGS= \
	OBJECTS='decode.o dct64.o audio_oss.o' \
	CFLAGS='-DREAL_IS_FLOAT -DLINUX -Wall -O2 \
		-DOSS \
		-fomit-frame-pointer -funroll-all-loops \
		-finline-functions -ffast-math' \
		mpg123-make

but this always generates a floating point exception at run time.

I have been able to isolate this to the following function:

costab[k] = 1.0 / (2.0 * cos( 3.14159265358979323846 * ((double) k * 2.0 + 
1.0) / (double) divv));

This is looped 0 < k < kr With k as 0 it costab[k] is returned as NaN and 
with k = 1 the floating point exception is generated. kr is 16 and divv is 64.

My maths indicates costab[0] should be roughly 0.5.

Incuidentally with -DREAL_IS_FLOAT switched off then there is no fp exception 
but the program outputs static.

So: the questions are - is this a known problem, has it been fixed in later 
kernels or have I just got it wrong?


Adrian

[linuxdc-dev]Sound driver

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

I know it's Christmas and all that ... but I've had no feedback on this 
whatsoever, does that mean it all works for people or that it doesn't or that 
nobody has tried :->

Any comments would be welcome.

If anybody has had difficulties becuase they are not sure how to build it 
then let me know and I'll write a mini HOWTO if that would help.

Adrian

Re: [linuxdc-dev]NFS & other Qs

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

Ernie,

Out of interest - what is the production date listed on the bottom of your DC?

(I am assuming you are in the US).

Adrian

[linuxdc-dev]Sound driver available for testing (Dreamcast)

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

Pre-release version of sound (/dev/dsp) driver for Dreamcast Linux



Those of you who feel confident (and have a console) with the idea of
compiling a new module for the kernel may wish to try the /dev/dsp sound
driver I have written for Linux on the Sega Dreamcast.

The two source files you need are at:

http://www.mcmen.demon.co.uk/linuxdc/aica/aica.c

and

http://www.mcmen.demon.co.uk/linuxdc/aica/arm7.h


What you need to know etc...

The driver acts as an extended wrap around to what essentially is Dan
Potter's KOS code - ie it loads and runs some basic ARM7 code that drives the
DC's sound processor and controls that through polling.

The driver is written to comply with the OSS/Free standard and to get it to
run you need to compile the OSS soundcore.o module - this is available from
the linuxsh CVS as well as many other places.

Be careful about compiling the rest of the OSS stuff - on my kernel
(2.4.10-pre6) the DMA code appears to cause real problems.

You may also need to export a couple of additional variable from the kerenel
(I did, but can't speak for other versions of the kernel).


Performance....

Seems fine with 8 and 16 bit mono, but is a little bit jerky with stereo and
complex code (eg MP3s).

I have been able to compile SoX and MAD and play sounds with both (though
only one MP3 so far with MAD).

Sound from PRBOOM (but not MIDI music) seems also to work.

What next...

Marcus Brown is working on DMA which should greatly improve performance.

So no one should regard this as an opportunity to do anything other than to
test a pre-release version of the code.


Please feel free to let me know what problems or comments you have.

Adrian McMenamin
ad...@mc...

-------------------------------------------------------

Re: [linuxdc-dev]NFS & other Qs

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

* Ernie <st...@ma...> on Thu, Dec 20, 2001:

>=20
> I managed to configure the net-tools package, and they even execute=20
> correctly on the dc!  Except, there is no /proc file system, nor can i=20
> seem to mount one ... does /proc work on the dc yet?  Is the busybox=20
> util not able to mount it?
>=20

You need to add a /proc entry to /etc/fstab, and use `mount -a` (preferably
in a boot script) to automatically mount it at boot.  Of course, you need
/proc compiled into the kernel in the first place.  Here is my /etc/fstab
(the backslashes continue to the next line, don't use them in your fstab):

192.168.1.11:/home/mrbrown/dcdev/nfs/nfsroot  /  nfs \
    defaults,errors=3Dremount-ro 0 0
proc    /proc     proc    defaults 0 0
#none   /dev      devfs   defaults 0 0
#none   /var/shm  shm     defaults 0 0
tmpfs   /tmp      tmpfs   defaults 0 0
/dev/gdrom /gdrom iso9660 defaults,user,noauto 0 0

> Has anyone gotten bash to run?  I compiled it, but i get a 'unaligned'=20
> error...
>=20

Yeah, but it's not that trivial to cross-compile bash.  Look for hidden
(well, not really) patches on ftp.m17n.org/pub/super-h/ in the debian
directories, they might help.

> Another mount question ... can the busybox 'mount' binary mount nfs=20
> shares?  i have an nfs server i can easily throw some sh4 binaries on,=20
> which would probably be a lot faster than uploading via the serial cable=
=20
> (which is probably still easier than burning a CD every couple of=20
> minutes).  Is this possible, or do i have to use nfsroot?  I'm thinking=
=20
> it'd be great if i could just copy binaries to the nfs share,and mount=20
> it as /usr/local on the dc ...
>=20

You need to enable NFS mounting in busybox, and enable "IP: kernel level
autoconfiguration" under "Networking options" and "NFS file system support"
and "Root file system on NFS" under "Network File Systems" in the kernel.
Then, pass the appropiate command line to the kernel.  Details on the
command line format are in Documentation/nfsroot.txt.

> Is there some way to redirect the console back through the serial cable,=
=20
> even though i'm using the serial cable for uploading the kernel?  I only=
=20
> have one monitor, and 3 computers, so its a big jumble of wires behind=20
> my desk ... and i noticed some 'console' options in the dc-load tool ...
>=20

Yes, enable "Serial (SCI, SCIF) support" and "Support for console on serial
port" under "Character Devices".

> What are ya'll using your DC's for?  I guess if I could get X working,=20
> that'd be cool.  And maybe a dynamic linker?  I've read a few posts=20
> indicating X is kinda slow, but i suppose things can only get better as=
=20
> more people discover more about the DC hardware ... I mean, all the=20
> games run pretty quickly :).
>=20

glibc runs under LinuxDC so the dynamic linker is already in place.  X is
slow and will always be slow (and will never be officially supported by
yours truly).  All new discoveries into the black hole of Dreamcast
internals get put back into the kernel drivers.

> Thanks in advance, and any tips or tricks anyone would like to share,=20
> i'd appreciate ...
>=20

Here is the command line I normally use (again remove the backslashes):
  mem=3D16M video=3Dpvr2fb:640x480-16 console=3DttySC1,115200 root=3D/dev/n=
fs \
  nfsroot=3D192.168.1.11:/home/mrbrown/dcdev/nfs/nfsroot \
  ip=3D192.168.1.21::192.168.1.254:255.255.255.0:blackbox::off=20

This enables the pvr2fb console (just the penguin, no output), with the
main console on the serial port; it also sets up a static IP and mounts NFS
root off of my workstation.  The "mem=3D16M" will go away in a couple of
kernel iterations.

Our goal is to get the website back up by Christmas 2001.  That's next
Tuesday :P.  We already have preliminary "Getting Started" guides, so any
other docs you would like to see from us, tips or tricks you'd like to
contribute, and even off-site links, please send them our way.

M. R.

Re: [linuxdc-dev]NFS & other Qs

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

On Thursday 20 Dec 2001 7:45 pm, Ernie wrote:
> Hello all,
> Once Sega dropped the price of the DC to $50, i jumped on it.  I figure
> it can't get much lower than this, and $50 isn't much ... of  course,
> now i have the Dreamcast, a DC keyboard, the BBA, a serial cable, a
> mouse adapter, and Shenmue :).  Still, total, it was probably still
> cheaper than the PS2.
[snipped]
>
> -ernie
>
I guess from this that you are using Bill Gatliff's stuff - that's how I 
finally got it too work too.

But once I got there I moved on to the Debian 'distro' on m17n - see

http://www.m17n.org/linux-sh/dreamcast/

This has X but don't expect anything slick.

But I kept the more up to date kernel - I mount all this via NFS (and it is 
possible to do that with busybox too - but you have to hack the configuration 
files). 

To mount NFS make sure you have the kernel compiled to do this and the 
command line configured properly and it's not too difficult (eventually!).

If you've got a BBA then you can load the kernel via IP - see

http://www.cerc.utexas.edu/~andrewk/dc/

for dcload-ip

And do you know about the IRC channel - #LinuxDC on irc.openprojects.net

[linuxdc-dev]NFS & other Qs

[Ernie <st...@ma...>]

Hello all,
Once Sega dropped the price of the DC to $50, i jumped on it.  I figure 
it can't get much lower than this, and $50 isn't much ... of  course, 
now i have the Dreamcast, a DC keyboard, the BBA, a serial cable, a 
mouse adapter, and Shenmue :).  Still, total, it was probably still 
cheaper than the PS2.

So, I managed to get an SH4 cross compiler installed on my mandrake 8.1 
box (even though I think bill mentions he used red hat 7.1 in his 
article, i had a lot of problems with my red hat 7.1 server).  I managed 
to boot the dc using a kernel i got from a link on this list, and even 
managed to compile a few utilities ...  but first a few questions ....

I managed to configure the net-tools package, and they even execute 
correctly on the dc!  Except, there is no /proc file system, nor can i 
seem to mount one ... does /proc work on the dc yet?  Is the busybox 
util not able to mount it?

Has anyone gotten bash to run?  I compiled it, but i get a 'unaligned' 
error...

Another mount question ... can the busybox 'mount' binary mount nfs 
shares?  i have an nfs server i can easily throw some sh4 binaries on, 
which would probably be a lot faster than uploading via the serial cable 
(which is probably still easier than burning a CD every couple of 
minutes).  Is this possible, or do i have to use nfsroot?  I'm thinking 
it'd be great if i could just copy binaries to the nfs share,and mount 
it as /usr/local on the dc ...

Is there some way to redirect the console back through the serial cable, 
even though i'm using the serial cable for uploading the kernel?  I only 
have one monitor, and 3 computers, so its a big jumble of wires behind 
my desk ... and i noticed some 'console' options in the dc-load tool ...

What are ya'll using your DC's for?  I guess if I could get X working, 
that'd be cool.  And maybe a dynamic linker?  I've read a few posts 
indicating X is kinda slow, but i suppose things can only get better as 
more people discover more about the DC hardware ... I mean, all the 
games run pretty quickly :).

Thanks in advance, and any tips or tricks anyone would like to share, 
i'd appreciate ...

-ernie

Re: [linuxdc-dev]Problem with porting SoX

[Adam J. R. <ad...@yg...>]

	I am not a SuperH developer, but here is some advice on how
you might want to proceed.

>From: Adrian McMenamin <ad...@mc...>

>./sox: Killing process "sox" due to unaligned access
>To be honest I still don't know enough about Linux development to know what 
>"unaligned access" is other than it sounds like a linker fix up problem.

	I imagine the error message came from do_address_error at
line 473 of linux-2.5.1-pre1/arch/sh/kernel/traps.c (may be different
for other kernels).

	By the way, here is a handy shell command for searching
for error messages or other strings in the kernel source tree.
When you have a mysterious error message, it is a good idea to try
tis on the kernel and other potentially related source trees if you
have them handy, like the sources for glibc and the applications
that you were running.

% find /usr/src/linux -type f | xargs egrep 'due to unaligned access'
/usr/src/linux/arch/sh/kernel/traps.c:          printk(KERN_NOTICE "Killing process \"%s\" due to unaligned access\n", current->comm);

	"unaligned access" sounds like an attempt to do a 32-bit
access to an address that is not a multiple of 4 or 16-bit memory
access to an address that is not a multiple of 2.  Most architectures
allow unaligned access from hardware, but some, apparently including
SuperH, do not.  From the source code near that error message in
traps.c, it looks like the kernel emulates around ordinary unaligned
reads and writes, but that there are a number number of cases where the
kernel has to give up and generate this error, such as when jumping to
an address that is an odd number.  So, probably your next step is to
add a few printk's to the different points of do_address_error that
jump or fall through to the "uspace_segv:" label so you can see
which case is actually generating the error.  You might also want
to print out the program counter ("regs->pc") to try to figure out
what address is causing the problem (check with gdb or something).
At the very least, you should get some idea of whether or not you
were accessing an otherwise legitimate unaligned address or had
jumped to a garbage address.

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
ad...@yg...     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

Re: [linuxdc-dev]My project

[Paul M. <pm...@mv...>]

On Sun, Dec 16, 2001 at 02:04:05AM -0500, Jason Dodson wrote:
> Hmmmmm... because I can? Because I want to? My motivations are about as
> irrelevent. I don't question why you want to port linux to the dreamcast.
> Your hangups mean nothing to me, so keep them to yourself.
>=20
Well, for one, the SH4 is _not_ that fast of a processor. We're still trying
to make all sorts of optimization shortcuts in the framebuffer and such just
to get it to a point where it can decode MPEG streams in some sane fashion =
..
something like bochs will quite literrally bury the entire system, and with
the added overhead of trying to emulate non-existant instructions, it might
not be feasible at all.

One thing I've always wanted to see was to see a somewhat pluggable emulator
that was capable of emulating an architecture on whatever it happens to be
built one, breaking out architecture emulation into a modular system, though
that's a little different then what you're trying to do.

> It appears that Bochs is what I am going to start toying with. Ive already
> joined the dev-list, and started poking questions in the right places.
>=20
Plex86 might be another thing to consider, especially if you don't want the
added overhead of X11. Plex86 used SDL as its backend, and thus worked just
fine under framebuffer (with the exception of a few issues). Not sure how
bochs deals with this stuff, but it was X11 specific last time I looked at =
it.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxdc-dev]My project

[Jason D. <min...@ya...>]

Hmmmmm... because I can? Because I want to? My motivations are about as
irrelevent. I don't question why you want to port linux to the dreamcast.
Your hangups mean nothing to me, so keep them to yourself.

It appears that Bochs is what I am going to start toying with. Ive already
joined the dev-list, and started poking questions in the right places.

If you wonder why I posted this question to this list, was 1) the purpose is
to get an OS working on the dreamcast, which we are doing here and 2) I will
probably use DCLinux to load Bochs to load DOS or whatever.

Jason

----- Original Message -----
From: "Paul Mundt" <pm...@mv...>
To: "Jason Dodson" <web...@mi...>
Cc: <lin...@li...>
Sent: Sunday, December 16, 2001 1:24 AM
Subject: Re: [linuxdc-dev]My project

On Sat, Dec 15, 2001 at 05:16:32PM -0500, Jason Dodson wrote:
> ok, this may seem a little "odd" to you people, but what I want to do is
get
> an x86/DOS emulator working for the DC. My goal is to eventually take some
> old 386 type stuff and get it to run on the dreamcast. Is there code that
> anyone knows of that I can port or at least start from?

The first question that comes to mind is "what the fuck for?" .. if you want
x86 consoles, buy an xbox.

The SH wasn't designed to emulate x86 incompetence, thankfully. And as a
result, getting anything like bochs running on it should prove to be
irritating enough that no one will try it.

Regards,

--
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [linuxdc-dev]My project

[Paul M. <pm...@mv...>]

On Sat, Dec 15, 2001 at 05:16:32PM -0500, Jason Dodson wrote:
> ok, this may seem a little "odd" to you people, but what I want to do is =
get
> an x86/DOS emulator working for the DC. My goal is to eventually take some
> old 386 type stuff and get it to run on the dreamcast. Is there code that
> anyone knows of that I can port or at least start from?

The first question that comes to mind is "what the fuck for?" .. if you want
x86 consoles, buy an xbox.

The SH wasn't designed to emulate x86 incompetence, thankfully. And as a
result, getting anything like bochs running on it should prove to be
irritating enough that no one will try it.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.

Re: [linuxdc-dev]My project

[ePAc <ep...@ko...>]

i know of one such project, but i don't know if it runs on the SH proc or
even if it is fast enough...

www.bochs.com (GPL)

it has been ported to windows and linux and MACOS and some other i think
...

I hope this helps.
Jok

---
Nothing is foolproof to a sufficiantly talented fool...
  oo
,(..)\
  ~~

On Sat, 15 Dec 2001, Jason Dodson wrote:

> ok, this may seem a little "odd" to you people, but what I want to do is get an x86/DOS emulator working for the DC. My goal is to eventually take some old 386 type stuff and get it to run on the dreamcast. Is there code that anyone knows of that I can port or at least start from?
>

Re: [linuxdc-dev]Problem with porting SoX

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

On Saturday 15 Dec 2001 8:15 pm, Adrian McMenamin wrote:
> On Saturday 15 Dec 2001 8:05 pm, M. R. Brown wrote:
> > Start with your driver first.  View the assembler output via gcc -s,
> > (kbuild 2.5 is useful in this regard).
> >
> > M. R.
>
> Okay, I will, but I doubt it's the driver (famous last words) as the
> command was just a fancy way of playing a .wav and I have no problems with
> that using the cat imagination.wav > /dev/dsp method, but thanks for the
> tip anyway.
>

For anyone who is interested, this (SoX) now works (most of the time). Hacked 
up makefiles etc, available from me on request.

[linuxdc-dev]My project

[Jason D. <web...@mi...>]

ok, this may seem a little "odd" to you people, but what I want to do is =
get an x86/DOS emulator working for the DC. My goal is to eventually =
take some old 386 type stuff and get it to run on the dreamcast. Is =
there code that anyone knows of that I can port or at least start from?

Re: [linuxdc-dev]Problem with porting SoX

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

On Saturday 15 Dec 2001 8:05 pm, M. R. Brown wrote:

> Start with your driver first.  View the assembler output via gcc -s,
> (kbuild 2.5 is useful in this regard).
>
> M. R.

Okay, I will, but I doubt it's the driver (famous last words) as the command 
was just a fancy way of playing a .wav and I have no problems with that using 
the cat imagination.wav > /dev/dsp method, but thanks for the tip anyway.

Re: [linuxdc-dev]Problem with porting SoX

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

* Adrian McMenamin <ad...@mc...> on Sat, Dec 15, 2001:

>=20
> To be honest I still don't know enough about Linux development to know wh=
at=20
> "unaligned access" is other than it sounds like a linker fix up problem. =
Is=20
> this the sort of problem that I should expect because of bugs in the tool=
=20
> chain, or it is because of some error I may have made?
>=20

The SH4 expects all 16-bit accesses on 16-bit boundaries, and all 32-bit
accesses on 32-bit boundaries.  Check and make sure your driver is
accessing RAM, registers, whatever like it's supposed to.  Not a linker
issues, and it's a possibility that it's a toolchain bug - given
the quality of GCC's SH backend, you can't rule that out.  It's also
possible that sox does unaligned accesses, so don't rule that out either.

Start with your driver first.  View the assembler output via gcc -s,
(kbuild 2.5 is useful in this regard).

M. R.

[linuxdc-dev]Problem with porting SoX

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

I have been attempting to port SoX - a sound application (see 
http://sox.sourceforge.net).

After a bit of poking about I have got an application that runs, sortof, but 
when I try - for instance - ./sox imagination.wav -t ossdsp /dev/dsp - it 
reports (on the DC obviously) ---

<Walking through AICA device list>
<Attempting to lock chnnel 0>
./sox: Killing process "sox" due to unaligned access
<Walking through AICA device list>
Segmentation fault


[Messages enclosed <thus> are printk's from the driver - they indicated that 
the driver has not misbehaved (probably)]

To be honest I still don't know enough about Linux development to know what 
"unaligned access" is other than it sounds like a linker fix up problem. Is 
this the sort of problem that I should expect because of bugs in the tool 
chain, or it is because of some error I may have made?

All answers, guesses or otherwise, eagerly awaited - if anybody wants the app 
I can email it or post it on my web page - just let me know. (Without a 
/dev/dsp it is obviously gonna fail though!)


Adrian

Re: [linuxdc-dev]GD-ROM: Got larger result

[Robert L. <rm...@te...>]

On Thu, 2001-12-13 at 22:05, Michael Grig wrote:
> "GD-ROM: Got larger result"
> 
> That's what I am getting when trying to boot off the gdrom.
> And it stops after that, inspite the error aparently not being fatal:
> disconnecting and reconnecting maple devices still registers.
> 
> Could it be because I don't have a /dev/gdrom device?
> But I do have devfs and devfs mount on boot, so I figured it should
> take care of that...
> 
> Anyway, how would I go about debuging it further?
> I stared at the gdrom driver for a while, but I doesn't really
> make much sense to me... 

I've seen this error, same situation as you, and for the life of me I
can _not_ remember what I did to fix it. :-/

I did end up adding boot support for the gdrom, though, so that is the
first step.  If you aren't using a recent (past week or so) CVS dump,
apply the attached patch.

Make sure ISO-9660 fs support is compiled into your kernel.

Make sure you pass `root=/dev/gdrom ro' to the kernel command-line.

Having /dev/gdrom exist doesn't actually matter, the devices are looked
up in a table and have nothing to do with /dev or devfs.

See where this leads us ...

	Robert Love

[linuxdc-dev]GD-ROM: Got larger result

[Michael G. <mg...@ho...>]

"GD-ROM: Got larger result"

That's what I am getting when trying to boot off the gdrom.
And it stops after that, inspite the error aparently not being fatal:
disconnecting and reconnecting maple devices still registers.

Could it be because I don't have a /dev/gdrom device?
But I do have devfs and devfs mount on boot, so I figured it should
take care of that...

Anyway, how would I go about debuging it further?
I stared at the gdrom driver for a while, but I doesn't really
make much sense to me... 
Any help would be greatly appreciated,
Mag.

Re: [linuxdc-dev]bootloader usage

[Robert L. <rm...@te...>]

On Sun, 2001-12-09 at 20:38, Michael Grig wrote:

> I am trying to get my DC to boot without the initrd, using the gdrom as 
> the root device. Unfortunatly, I am having trouble getting any boot 
> loader to do that. With sh-boot, I don't know how/when/where to set the 
> kernel parameters, and ecos/redboot is so throughly under-documented in 
> english, that I can't even figure out how to compile it - the sources 
> in the cvs don't seem to have any configure 
> scripts/makefiles/instructions on what to do.

There is something called kernel-boot at ftp.m17n.org in a
tools/dreamcast directory.  It is a simple kernel and initrd boot loader
for the DC.

If you edit kernel-boot.S you will see a data section towards the bottom
with the boot command line declared.  Set it to something like:

	root=/dev/gdrom ro mem=16m

and use an empty initrd.bin.  `echo 0 > initrd.bin" will do.  Put your
zImage as zImage.bin in this directory.  (I'm going to write a
bootloader than doesn't use initrd when I get a chance.)

Then do `make clean scramble kernel-boot.bin` and then `./scramble
kernel-boot.bin 1ST_READ.BIN` ... there you go.

	Robert Love

[linuxdc-dev]bootloader usage

[Michael G. <mg...@ho...>]

Hi,

I am trying to get my DC to boot without the initrd, using the gdrom as 
the root device. Unfortunatly, I am having trouble getting any boot 
loader to do that. With sh-boot, I don't know how/when/where to set the 
kernel parameters, and ecos/redboot is so throughly under-documented in 
english, that I can't even figure out how to compile it - the sources 
in the cvs don't seem to have any configure 
scripts/makefiles/instructions on what to do.

So I was hoping someone could point me to some related documentation.

Thanks in advance,
Mag.

[linuxdc-dev]Some good news at last

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

Some good news...

My OSS sound driver for Dreamcast linux has at last got to first base - it 
will now respond to a cat somefile > /dev/dsp by outputting static.

http://www.mcmen.demon.co.uk/linuxdc/aica

The code will shortly go on the web site - but it's still a mess and 
shouldn't be considered anything other than a curiousity at the moment.

For those who are interested, I have to say that most credit must go to Dan 
Potter and his KOS code (and, I suppose, to Marcus Comstedt to whom Dan P. 
gives credit).

At the moment the "OSS driver" loads in the KOS soundstream code as a static 
array and then uses Dan's IPC mechanism to communicate.

There will need to be some hacking of Dan's code to make it comply to the OSS 
PI eventually - but that bit is all his code at the moment.

None of the ioctls are written and the architecture is all wrong now (it 
turns the SPU on and off between writes) - but at leasr I know it can work.

Feel a little proud for me - 7 months ago I had never written a line of C in 
my life (though i admit I had written many thousands of lines of C++, java 
and perl but they were all for the enemy's operating system).

Adrian

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Robert L. <rm...@te...>]

On Thu, 2001-12-06 at 16:04, Jeremy Siegel wrote:

> Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
> looks like the only file that references memscan; as far as I can tell the
> only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
> driver that maple_keyb.c was based on.

Heh, nothing to apologize for.  Yah, it seems nothing else in SH uses
memscan.  Good.  drivers/usb/usbkbd does use it, and I bet that is a
bug.  Its in a conditional and since it always evaluates to true ...
whoops!  I think some other places do use it, though.  UDF and ext2, for
example, and it is legitimate.  If not we could rip it out of everything
and save some space.

	Robert Love

Re: [linuxsh-dev] Re: [linuxdc-dev][PATCH] maple keyboard fix

[Jeremy S. <js...@mv...>]

Robert Love wrote:

> Thank you.  As SH users start using 2.4.15-pre7 and later kernels, they
> may experience odd problems.  I wish I could give a formula for tracking
> down if a specific issue is this memchr/memscan problem, but it can
> manifest itself in a myriad of ways.
>
> One thing to consider is that _all_ uses of memscan are either broken
> now or where broken before the change.  I.e., they expected one of the
> two behaviors at some point but got the other.  This means a global
> audit of memscan use may be useful.

Sorry about missing that one.  In the linuxsh drop-in tree, maple_keyb.c
looks like the only file that references memscan; as far as I can tell the
only other reference in the entire linux tree is drivers/usb/usbkbd.c, the
driver that maple_keyb.c was based on.

--Jeremy Siegel