Floating point, grayscale, scheduler, audio, and PS/2 keyboard?

While I haven't posted any updates lately, I've been working on Punix and occasionally posting my progress on the Cemetech forums.
I have also had family issues for the past few months now that have taken much of my free time.
Here's a summary of what I've done since last time:

• M68881 FPU emulator is still under development, but a few instructions work well so far: fmove, fadd, fmul, fsub, fabs, and fneg. Execution speeds for fadd/fsub and fmul are faster than the equivalent operations in PedroM (which uses a slower BCD floating-point format to be compatible with TI-AMS).
• Four-level grayscale! Currently only HW2 is supported, but that's probably more common than HW1 anyway. Text glyphs are also anti-aliased to take advantage of grayscale.
• The scheduler has been tested quite thoroughly by now. I recently stress-tested it by running a few dozen busy processes at various "nice" levels, while also playing audio. Surprisingly, playing audio at the base nice level (zero) with 43 busy processes resulted in smooth, skip-free sound.
• I'm playing with the idea of adding a PS/2 driver which will allow a user to plug a regular keyboard into the link port (with an appropriate adapter) and start typing away on it. This is a low-priority feature, but I'm the most excited about it at the moment.

Subversion and scheduler

A couple days ago I finally put the Punix source code into the Subversion repository on SourceForge. I figured it was about time that I used Subversion instead of the older CVS. This also means that the CVS repository is deprecated and will not be maintained. It will exist only for looking at code history.

Also, during the past couple of days I have been working on fixing the scheduler. To do this I wrote a simple program that simulates the scheduler that I can run on my computer and that shows everything that happens in the scheduler (such as clock ticks and the results of priority calculations). As a result of this, I found one small but serious bug in nextready() which would cause a crash in the real system. Besides that, I tuned the algorithm so it would take the process's nice value into account with a reasonable weight relative to the cpu time of the process (higher nice and/or higher cpu time means lower priority). I implemented the computation of load averages in the simulation, so I still need to copy that over to the real version.