Re: [MiNT] strange memory violation

[Evan Langlois <Evan@CoolRunningConcepts.com>]

On Sun, 2005-11-06 at 15:21 +0000, Odd Skancke wrote:

> > FreeMiNT have system calls to support time triggered tasks. I'm sure the 
> > resolution of this is exact enough for 99% of all problems.
> 
>  I may be asking a stupid question, but has such things been documented?
> I havent seen any docs on these things, but then again, I havent looked
> very hard ;-)

Generally, when you can't find documentation, check POSIX/Unix docs. I
can't really comment on Atari specific issues, but I can tell you how
its done "The Unix Way".

The closest thing to an "interrupt", would be a signal. If you are going
for portability, see if mintlib supports setitimer() and sigaction().
The MiNT OS calls you want are Talarm() to schedule the "interrupt" and
Psigaction() or Psignal() to set a handler for the "interrupt".  Unix
has an alarm() but the granularity is seconds.  Setitimer has
microsecond granularity, so MiNT compromises with a millisecond
Talarm().

If I remember, you may actually be limited to 5ms intervals and you
should test and see if the old "early timeout" issue is still around
(the timer returns immediately if set under 1 second)... that was the
case a long time ago.  Someone who knows the kernel better could comment
here.

Timer driven isn't really what you want though.  You just need to stream
data to the audio device.  Someone mentioned /dev/audio, and I can't
comment if there is any sort of asynchronous notification of low/empty
buffers, etc, but Windows has been writing code that doesn't use such
things for a long time.  

You just create a thread that blocks on the device file handle when no
more data can be written, and then feed it the next chunk of data when
the thread wakes up.  Essentially, you would create a thread with the
mintlib function tfork(), which would run a function in the background
that would just send data to the audio device in a tight loop. Hopefully
this blocks and does nothing when the device buffer is full.  

You can add Syield() into the mix if you find yourself wanting to give
up some extra CPU time. You should also look into Psemaphore() to
provide access restriction between the thread that writes the buffer and
the thread that sends the buffer to the audio device.  The way this
works is that you create a "semaphore" with a specific id number that
all your threads can access the "semaphore" through.  Before accessing
any shared data structure, you use Psemaphore() to request ownership of
the semaphore and only touch the shared data area when you get
ownership.

>  PS: Frank, still need comments on the pexec()/pwait()/pwait3()
> inconsistencies.

I'd like to hear more on this too.

-- Evan