What to do

Ufff! There are tons of things to do. You can pick any to do :-)
Some in no particular order:

  • Start codding a few HardwareDevices as model, specially some Network card support [Started. Status?]
  • Code PCI Bus handler. [Done] 
  • Code Network support. [Status?]
  • AMD Lance PCNet-32 PCI Network Card (vmware). [It's working, could be improved]
  • RTL8139. [Working] 
  • Code CMOS support (hardware clock for example).[Parts Done]
  • Add better video mode selection support. This mainly involves solving how GRUB can pass SqueakNOS' kernel information on what video mode is selected. Not too complicated, but as we already have video support, we won't stop to do it for now. We think it'll be better to do it for GRUB 2 than for GRUB Legacy, we'll see.
  • Test what Plugins can be compiled natively without any platform support. We have now LargeIntegerPlugin, Balloon support, and some other. We know there are quite a few that could be included just by drag and drop in VMMaker.
  • Reimplement PCKeyboard, remove everything not needed because the Sensor now is an EventSensor. Rework all the hardware part, looking at the right documentation. Move ps2 mouse support to a separate class (PS2Mouse).
  • Fix the Mouse cursor problems.
  • Somebody should check how the basic primitives have been implemented (nos/sqGluc.c) and say if they are Ok. We know some of them are not (ioRelinquishProcessorForMicroseconds() for example), but we need some VM expert to review them.

Ideas

  • See how spoon and SqueakNOS can take advantage from each other (specially SqueakNOS from spoon).
  • See how Exupery can help SqueakNOS. Although we'd like to avoid native code as much as possible, we understand it may be necesary.

Possible problems

  • Saving the image from within Squeak. We think the easiest way is to copy the hole .image from RAM to a ByteArray using a primitive (primitiveReadMemory is alreay there), and then save this ByteArray using the Squeak Hard Disk driver. It should work, not sure, but we are working on it right now.
  • Related to the previous: Smalltalk startUp is executed after saving, and we are not sure how this will affect HardwareDevices that are reinitialized without rebooting the system. I think we'll need a slightly different startUp scheme.
  • We may need to add primitives for external memory handling (a la heap), specially because some HardwareDevices may need to allocate locked memory (is this possible to lock a Squeak object so the GarbageCollector doesn't move it?). Even if it's possible to lock objects, some hardware needed memory to be located below the 640k barrier.
  • Although we doubt it, speed may be a problem for some HardwareDevices. In this case we'll need to add some native code support.
  • Too much power consumption (bad for laptops), because we have not implemented sqInt ioRelinquishProcessorForMicroseconds(sqInt mSecs) (it's a noop right now). We tried putting a hlt there, but it makes everything impossibly slow, and the keyboard and mouse don't work as expected. Our theory is that we need to increase the timer interrupt frequency (right now 18.2 hertz), and then, the hlt instruction should be enough, however, we don't really understand why the mouse and keyboard are not responding.
  • Apparently the interpreter loop doesn't check for process rescheduling as often as we'd like it to (for example, in VMWare, the mouse freezes when Squeak is opening a System Window). We are not sure how it really works, but as IRQ handling depends on Process scheduling, we may find some problems there.