defying graffiti: the making of GNUton

motivation

the motivations for this work are varied. initially, the goal was to have an emulator as part of a free development environment. even after Newton, Inc released the toolset, an emulator would be useful as a low-cost means of development, as a testing environment, to enable lower-level debugging, etc.

of course, the greater scheme was always a freeware pda. however, it was not until Apple dropped development of the Newton (just as it was reaching a widely useful state), that this became a pressing need.

for the future, i'd hope that having a system where the hardware is both off the shelf and not restricted to a single processor and form-factor, and the software is freely available, will enable a growth a the platform not seen under Apple. smaller systems, larger systems, Java VM extensions, C programming API, multi-threaded NewtonScript, novel UI concepts -- all are possible.

in the short term: i want something to replace my MessagePad when it's time to upgrade. the goal is to get Newton OS 2.1, subject to suitable hardware, running as a free system.

software

current work is on four fronts:

virtual machine

progressing, but really waiting for the package loader to have some code to execute. all these easy instructions are done, and the more complex are awaiting some heavy bytecode disassembly to see what the real semantics are.

this is based on two documents, the first now largely redundant since Apple released the bytecode and virtual machine specifications.

i've heard rumours (well, Walter Smith said it, so it's fairly substantiated ;-) that there were changes/extensions to the VM for OS 2.x. we'll need documentation for these at some point, so if you know anything, don't hesitate to share ...

package loader

decoding the package format and creating the application in the emulator memory. again, this is derived from the Apple-published specifications released by Newton Inc. loading the package requires the packages soup ...

the decoder for the package format is mostly done, except for pointers which are not being added to a pointer table, and looked up if they have already been decoded. once this is done, we'll be loading packages.

i just need to figure out exactly what SuckPackageFromBinary does now (time to write a little app for the mp2k) so i can reimplement it properly (along with freezing, thawing and package removal). anyone got any clues?

stores and soups

on the MessagePad, the limitations of memory require that stores put a lot of effort into compressing things, and then paging them into dynamic RAM during use. for the moment, i'm not worrying about this. all we need for now is working storage.

the current boot process is identifying devices configured that are possible store hosts, and probing for formatted stores. unformatted devices (like a new file) are queued for a notification once the event loop is up and running. if you give the ok, then the stores are mounted.

some work is still needed on the actual store implementation, but it's downhill from here.

view system

support for the primitive view classes, creation of the system messages and redevelopment of the standard protos.

because i think that the biggest difference between the possible host hardware is the displays, what i plan to do is implement both the drawing primitives, and the C-level views in the display drivers. that way, we can have a Tk driver, an MFC driver, a Linux SVGAlib driver, etc.

otherwise, the view system consists of the event loop to handle NewtonScript message sending. GnutOS will support both Python and NewtonScript objects, with some chance for other formats (C objects compiled for various processors) later on.

hardware

hardware is an issue: we need to use something that is freely available, an open architecture, and preferably better than the MessagePad 2100 ;-)

now that i've stopped dreaming (sorry) the actual plans are to use something supporting a minimal linux kernel, with just the essential drivers (video, digitiser, serial, ethernet, ... ?). why linux? because it is free, widely ported, quite small and i like it ;-)

potential hosts are varied, but include x86, 68k, MIPS and ARM boxes from a variety of vendors. some that i have been considering are:

screen shots

There's not much to see yet, but ... just to whet your appetite, here's a look at the current screen, and the boot log messages as well.

When it boots, it checks for available store devices. In this case, the config file specifies that a disc file be made available, but since it doesn't exist, the GNUton asks whether you'd like to initialise it as a store (much as if you'd put a blank PC Card into a MessagePad).

download

Warning ...

This does not work! That is, while it should run, it doesn't do anything yet. It's a snapshot of the code which you're welcome to look at, and more welcome to fix problems with, but it won't actually do anything. You have been warned!

Prerequisites for running this snapshot are

contacts