i'm hoping that this process will become a little easier shortly, as soon as SourceForge gets the CVS repository installed. at that point, sharing development will also be simpler as well.

the major benefit of this change will be the ability to get the source code available through CVS, making it a lot easier for other developers.

effectively, this means that the first graphics driver for GNUton will be a GDK (aka GIMP Drawing Kit)-based view primitives implementation. this has one benefit over GGI in that it is easily portable to Win32 (but not yet MacOS). the major reason behind this is laziness on my part -- i can't get excited about all the layers of stuff i have to get working to have a decent development environment on the target machine (the libretto) under GGI.

i've made considerable progress with the VM, and am now working mostly on the graphics stuff so i can get a basic package installed and running.

the most useful thing is a package decoder -- it finally appears to successfully decode a range of packages, from simple 1.x to more complex 2.x multipart packages. this code will implement the SuckPackageFromBinary() internals, and the next step is to integrate it into the memory manager. but in the meantime, it forms that basis for some nice package management tools which i might hack on if i get a moment.

the other area that has changed a lot is the VM code: i've started to reimplement the bytecodes using the same classes as the package decoder with the intention of merging the two via the memory manager once that is done.

the only barrier to executing a package after that is the lack of the view system and protos. the hello world package in the distribution seems to need only two protos (protoApp and protoTextButton), so they'll be the first targets.

on the view system front, i have continued to look at GGI, but the Python wrappers for it are quite out of date. an alternative library which writes directly to the framebuffer was announced on freshmeat last week -- xfb. i'll be looking more at both of these before deciding what to do for the view drawing code.

anyway -- progress!

notice the "for the moment" above -- i'm moving towards a position where i will develop a graphics driver for the Linux kernel framebuffer (possibly via GGI) rather than the (always interim) Tk canvas. the reasons for this are many, but the principle problem is that the canvas just doesn't allow the level of access needed to implement the Newton's imaging model.

i'm working on the bootstrap process still. it's kinda complex, and i expect it to take some time (ha!). the current problems are how to implement the "ROM" and DRAM domains in the memory controller (all very abstract within the emulator, of course). it's tempting to dip into C at this point, but i'm trying to resist.

once i have the ROM, and the "internal" soup, i have the infrastructure in place to hard-boot the emulator, and start executing the ROM-resident blessed app. this will require tools for creating ROM images, and support in the ROM for initialising the internal store with the packages and system soups, etc.

you might also notice that today is 18 months since the Newton was cancelled. ho hum.

it's very minor. the biggest change is that the source has been moved into CVS, ready to make available via Anon-CVS. Marcel van der Boom has generously offered to assist with the coding, so with his contributions (and the added impetus for me to generate code to keep up with him ;-) we might get some more done!

it's nothing to get really excited about unless you want to do some development. there's been no visible changes since the last snapshot, although the code has been restructured quite a bit.

in terms of actual work, most of the changes are in the opening and mounting of stores, and the creation of soups and VBOs. these all work ok now, and there's even a Packages soup created on all mounted stores ;-) this is gradual progress toward the task of actually loading a package.

download (if you're brave) and enjoy!

i've finally located some publicly available HWR software, which is reassuring, and i have some hints about other packages as well.

there's been some discussion in the last few days in comp.sys.newton.programmer where Walter Smith has talked about some of the problems with the NS interpreter in the Newtons which has also been interesting.

i have a stack of changes that i will put together as a snapshot real soon -- hopefully this weekend.

i also spent some time this weekend playing with the WISE installation tools for Win32 systems. not this time, but perhaps next, the Windows version will have a standard installer, and if we're lucky, the file associations for the GNUton DeskPad configuration files will automatically launch the emulator. if we're lucky, anyway ...

I'll have the new snapshot by mid-week.

while i was in the US i picked up a Wacom PenPartner digitiser as well. i have been investigating the drivers for Linux and it appears to be supported under XFree86, but only as a mouse replacement. i'll be looking into this ...

expect the new snapshot early next week.

happy hacking!

i'll put out a new snapshot over the weekend, but it's not too different, although you can actually mount stores now! have a look at the devtest.py module -- you'll see the global variable and functions frames there, and you can write simple Python functions that use the global functions. nothing useful yet, but it's nice to call GetRoot() and actually have something happen ;-)

serious work will resume first week of august. you'll note that 27th August is the six-month anniversary of the announcement ... hmmm ... motivation! ;-)

i've also started adding the dialogs off the main menus, first cab off the rank: load package. this is not yet complete, but it'll get done this week, and hopefully we'll have packages loading for the next snapshot.

speaking of snapshots, i'm kinda aiming at fortnightly releases at the moment. if anyone wants my changes sooner, let me know and we can talk about it.

this week i want to continue with the views, in particular getting the basic message/event handling working. then back to complete the file-based stores, and then focus on getting a package loaded and creating its templates.

we've had about 30 downloads of the first snapshot, but not too many comments - i guess this one will actually do a little more that's visible, and it's got some documentation too (well - a README anyway ;-)

worse is that it's not in any way releasable at the moment. i'm going to try to get something together over this weekend and next. here's hoping.

i have thought more about the overall structure, since i needed a framework into which to put the entry cache. the basic device class now contains a set of manager classes which lookup after various subsystems. i have done some initial work on the HardwareManager (device drivers, etc) and the StorageManager (guess what).

the abstract storage classes are a little empty still, but the disc-based store stuff is coming along nicely. hopefully, *this* weekend will see me release that for you to ponder.

i've decided to go with the 2.x package loading, and this is progressing well. i'm tempted to release a really alpha version once this is working, but i'll see how it goes.