From mint-bounce@lists.fishpool.fi Tue Jan 3 23:12:46 2006 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Date: Tue, 3 Jan 2006 23:10:05 +0100 (CET) From: Frank Naumann X-X-Sender: fnaumann@wh58-508.st.uni-magdeburg.de To: mint@fishpool.com Subject: Re: [MiNT] XDD implementation questions (joystick driver) In-Reply-To: <43BAEBC5.2060406@home.se> Message-ID: References: <43BAEBC5.2060406@home.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scan-Signature: 16c4643b02ac9618a8b25215795d3496 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: fnaumann@boerde.de Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-0.9 tagged_above=-50.5 required=7.0 tests=AWL, BAYES_00 X-Spam-Level: Hello! > joystick ports on the falcon/ste. The current version is written in > assembler, but I might rewrite it in C later on (I guess I should, right?). For the higher level stuff it's recommended and make for sure your life much, much easier. Time critical parts can be for sure written in asm (interrupt handler or such things). > 1. Can I use Xbios in an XDD? Yes. > 2. I want to implement blocking reads. How is this supposed to work? If I > just wait until I have a new joystick packet available to the calling > process, I halt all other processes too. This is not the way to do it, right? > 3. Select & Unselect - What the heck is this, and should I implement it? This works so: - an app want to read blocking and call Fread() - Fread end up in the device driver read() - now in read() you see it's a blocking read and as no data are yet available you put the process to sleep with sleep(IO_Q, condition); sleep jump to the kernel scheduler and let other processes run (e.g. it don't return, the process is blocked in the device driver read()) - in your interrupt handler you receive data; put them into a buffer and wakeup the sleeping process with wake(IO_Q, condition) - after the wakeup if the kernel scheduler schedule the now runnable process the scheduler return from the sleep call into your device driver read(), you can put the bytes into application provided buffer and return - select & unselect are needed (and very important) if an application want to watch several file descriptors; for example a process want to read the joystick AND the keyboard; you can either poll (bad) or use Fselect(); Fselect() monitor one or more filedescriptors if I/O is possible; if the kernel do this it need help by the device driver as only the device driver know exactly if reading or writing is possible; so the kernel ask the device driver to inform him if reading or writing becomes possible (by calling select()); and the kernel can cancel the monitoring by calling unselect(); so in select() the device driver just need to remember the proc argument and call wakeselect(proc argument) if reading or writing becomes possible (most probably called from the interrupt handler that service the hardware) Ok, for more details better with concrete stuff with private e-mail I'll think. Regards, Frank -- ATARI FALCON 060 // MILAN 060 -------------------------------- http://sparemint.atariforge.net/ e-Mail: fnaumann@freemint.de