[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XDD implementation questions (joystick driver)


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?


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

- 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.


e-Mail: fnaumann@freemint.de