Re: Timing Under MiNT

[ekl%beastie@sdf.lonestar.org]

>At the moment I use Talarm() to set timer callbacks in order to implement
>evnt_timer() and evnt_multi(MU_TIMER). This works fine (there's a delta queue
>backing up the signal handler to allow multiple events), but the problem
>is the Talarm() only has a resolution of 1 second, which is to long for
>several apps (notably Yukon calls evnt_timer() in between dealing each card
>- with a minimum 1sec delay, dealling a full deck takes ages).

GEM doesn't have real timers, so there is no real reason for Talarm.  What
you should do is simply select() on whatever communications medium (pipe or
socket) you are using for IPC.  

The way I see envision things, when an app is run, its stdin and stdout/stderr
are redirected through psuedo-terminals.  When an application expects an event,
meaning it calls evnt_multi() or some other evnt_* call, it calls select()
waiting a handle (which it gets from appl_init()) and if keyboard events are
wanted, then it also selects on stdin.  This allows the server (or AES) to
dispatch mouse clicks or other events by writing to the event socket or pipe
of the application - if the app isn't selecting it gets buffered by the socket
or by the pipe.  To dispatch keyboard presses, it sends the data out the
proper psuedo-terminal (or to th pseudo-terminal owned by the top window).
Should the AES ever recieve data from the pseudo-terminal, it should open
a window for the output, liek TOSWIN or MINIWIN.

The evnt_multi() timeout would be implemented by the timeout on the select()
call.  This is a kinda complex model, but it allows for some standing problems
to be fixed (such as TOS apps, having to tell the desktop if you are a TOS
or GEM app, messy file extensions, and hybrids never working).  All that
stops with the above.

>I think I should implement my own clock device (write a time in milliseconds,
>select on it and it will write back after n millisecond) - can anyone give me
>a few pointers on devices (I don't really have time to work it out myself, as
>there is still a fair bit of XaAES to finish).

Clearly the internals of your AES are bit different from that which I outlined
above.  Why would you select() on a clock device, when you could select on
a message pipe, with a timeout on the select(), which is what you really wanted
anyway?  Making a new device sounds messy.

CYA,
Evan Langlois
ekl@sdf.lonestar.org