Ore for Wood

5 days to go - I've missed a few here. Graphics is going reasonably well; the past day or so has seen the addition of skyboxes, proper terrain clamping, texture blending on the terrain (albeit a hacked-together software version), smooth normals, water reflection, and a few test scenes to my project. Above: a test scene that shows the use of the skybox (rendered in garish colours for maximum obviousness!), one tree (with eight levels of branching), and a few randomly positioned rocks (two levels of subdivision each).

Real-Time, on the other hand, is coming to an inauspicious close. Our program suffers from a showstopper bug: sensor polling freezes. We managed to hack around this to complete most of the first train control objective, but the second control objective will remain elusive until this is resolved. The PsychOS team is running out of time rapidly, but we still have a few more tricks up our sleeves:

• We can redesign sensor polling. The current plan is to extend the kernel's event-handling structures to support software events as well; this way, the SensorManager() can trigger EVENT_NEW_SENSOR (or something like that) whenever a new sensor comes along.
• We can attempt adding a chain of couriers (or similar data-passing tasks) to the train input server. If the problem lies in dropped bytes, this might resolve the issue.
• Failing all else, we can add some NOPs (or the C equivalent: a busy-wait for loop - our TA actually did this when he took the course.) The mere thought of adding such a blatant hack induces violent fits of cringing, but we'll do it if we need to.

If we can get past this, we already have systems in place to find routes and reserve track sections - they just need to be tested and used.

Personal notes: it is now quite obvious that the month is drawing to a close. This has been a bizarre ride of ups and downs, of hope and despair, of sleeplessness and take-out meals and 16-hour debugging sprints. I'm feeling strangely calm as I enter the final stretch, in stark contrast to the near-complete-breakdowns that some of those Real-Time sprints drove me to. Not even the possibility of missing the final Real-Time demo fazes me; regardless of what happens with the project, I've learned an incredible amount about hardware, low-level programming, and operating system design - and it's all practical knowledge, especially given that we've been working with the ARM architecture.

If I had to pinpoint the source of our problems, I'd put it down to hubris. The early assignments were relatively easy, the test programs rather trivial; we simply wrote the required code and then went off to take care of our other assignments, working on the assumption that everything would continue to go well. This is never good practice, not even in the classroom. We implemented proper error-checking about three weeks ago, something we should have done three months ago. We should have rigorously tested our kernel, bombarding it with interrupts and I/O and requests and everything else that could possibly bring it to its knees; we did some of that, but it was too little and far too late.

Despite the above tirade - which looks suspiciously like a pre-emptive post-mortem - I should add that I refuse to give up. Once I get Graphics out of the way, we'll dig our heels in this weekend to try anything and everything that might work. Keep posted!