Re: [MiNT] strange memory violation

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Mon, 2005-11-07 at 11:12 +0100, Miro Kropacek wrote:

> and let's add the comment about /dev/audio. And for let's say XMs we 
> need /dev/xm and for S3M /dev/s3m. So this will lead us to 
> /dev/modplayer (I remember some library with similar functionality, 
> libmikmod?) and we've got what? General-purpose mod player? And what is 

No, /dev/audio would be like the Linux /dev/audio.  You use would likely
use Fcntl() to set the sample rate and bits per sample, and then give it
a stream of samples and it plays them.  Decoding of your data, such as
XM, mp3, s3m, mod, or whatever, would be done in userspace.  The
libmikmod library is just that, a library.  It runs in userspace and
this library would be in charge of opening /dev/audio and playing the
data.

> the difference between 'normal' app and this one? NONE. Ask you why? 
> Since if (again that if) my kernel module crash, it will hang whole 
> system (since it modifies important HW registers) and we're in the 

The difference is that you don't need HW registers to decode a file
stream.  Only to play the final uncompressed stream.  This is where the
division between kernel and userspace is.

> beginning. So I think good approach isn't to avoid supervisor oriented 
> applications completely but to write safe and public (open) code so 
> everyone can track bugs.

An application has NO business EVER being in supervisor mode.  It is NOT
the system supervisor.  The OS is.

> interface to it and then make another, separate version for 
> TOS/MagiC/MiNT-NP. So theory is maybe nice thing but we have to think in 
> the range of our possibilities.

All such libraries for decoding exist, and are likely portable.  All
that is needed is a playback device with the proper capability, and I'm
assuming /dev/audio can handle it.  If not, maybe /dev/audio needs some
tweaking, but only so it can handle the data that the library feeds it.
Do not attempt to place audio codecs and decompression routines for
audio or video into the kernel.

> I use it in demos since it's free timer in (nearly) every case since A 
> is for DMA/samples tracking, B for HBL and C for AES (iirc).

Hardware timers are for the OS to use, not for applications.  Timing
facilities for applications are provided by the OS.  If these aren't
good enough, we'll work on the OS.

-- Evan