Hi Jecel, Marik, Gera and all, I'm on this list but mostly silent because I dont have much time to contribute... I've been away from SqueakNOS (and Smalltalk) for the last 2 or 3 years.
I looked at the SiliconSqueak web site, it is awesome. Is the Plurion board available? How do you develop for this? I didnt find quotes for LatticeECP2 development boards.
Regards, Luciano
On 6/1/09, Jecel Assumpcao Jr jecel@merlintec.com wrote:
Gerardo Richarte wrote on Fri, 29 May 2009 01:00:24 -0300:
Merik Voswinkel wrote:
A question from our Morphle team about the name SqueakNOS. Jecel and I are publishing papers about SiliconSqueak and the operating system we run on top of it. It has (among many other innovations) a new virtual parallel device driver system.
This is very interesting, where can I read more from this? or see it? screenshots, movies, anything!
The paper about the driver framework has not been written yet (much less the actual code), but there are several sources of information that are available. There was a thread about this on squeak-dev back in May 1998:
http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-May/015997.html
Unfortunately, my message that started that thread is missing from the archives. So I will add a copy of it to the end of this one.
A wish list for Squeak was discussed earlier this year and two items were a rewrite of the event interface between the VM and the image and the inclusion of the Announcements framework (created in VisualWorks and ported to Dolphin Smalltalk and Squeak) as part of the official image. I suggested that these two items could be merged and several people felt this is a good idea, but not work has been done on this.
http://wiki.squeak.org/squeak/5734
An interesting aspect of SqueakNOS is that interrupts get translated into semaphore signals. This allows some forked code to block in different points on this semaphore, which gets us something more like coroutines than traditional interrupts handlers (which always start in the same point and so have no saved state). This is very similar to what was developed for the Apertos operating system that I have mentioned here before.
http://www.sonycsl.co.jp/project/Apertos/techpaper.html
I am talking about papers 8, 9, 10 and 12 (I haven't actually read 10 since it is in Japanese). For your convenience, I have translated paper 12 from Postscript to PDF:
http://www.merlintec.com/download/SCSL-TM-94-005.pdf
Would you mind if we would call that SqueakNOS 2.0, or is that name reserved for the work that you and Luciano did?
well, truly, I think it's not a good idea, unless it's really based on SqueakNOS, and unless you are going to contribute everything back to SqueakNOS right away. We'd really have to see it to decide, but until we do, please, don't call it SqueakNOS or anything similar.
On the other hand, if you implemented a new platform where SqueakNOS can run, it's just SqueakNOS, not 2.0, we commit it to the source repository, and that's it.
The code we are developing will be just plain SqueakNOS. I am very much against forking except in extreme cases. In my discussion with Merik, I mentioned that the current state of SqueakNOS has some limitations equivalent to early Linux or even MS DOS 1.0. In those systems the hardware configuration was hardwired into the software and you had to recompile it (or wait for Microsoft to do it for you) before you could access new hardware. Eventually Linux got its kernel modules and MS DOS 2.0 got its .sys files, so I said we need to get to at least that level with SqueakNOS where some framework allows the PS/2 mouse to be replaced with a USB one, for example.
So I used the term "SqueakNOS 2.0" to refer to a version at least as modular as DOS 2.0 (not the most ambitious target for an OS developer, right?).
And then, yes, we are planning a SqueakNOS 2.0 already (and a 3.0 and a 404 too :)
Exactly - let us get our roadmaps in synch if possible.
Just to be clear: the discussion was about code to be added at the Smalltalk level to SqueakNOS and not about any details of the lower level platform. And I am also very interested in having SqueakNOS track any changes in terms of event handling that might be developed for "normal" Squeak.
-- Jecel
Here is the initial email in the i/o framework for Squeak thread:
From - Tue May 19 22:05:54 1998
Received: from jerry.cs.uiuc.edu (qmailr@jerry.cs.uiuc.edu [128.174.246.71]) by hermes.lsi.usp.br (8.8.8/8.8.8) with SMTP id CAA25363 for jecel@lsi.usp.br; Tue, 19 May 1998 02:19:02 -0300 (BSC) Received: (qmail 27590 invoked by uid 95); 19 May 1998 05:18:39 -0000 Resent-Date: 19 May 1998 05:18:39 -0000 Resent-Cc: recipient list not shown: ; Date: Tue, 19 May 1998 00:17:14 -0500 (CDT) From: jecel@lsi.usp.br Message-Id: 199805190517.AAA27596@c.cs.uiuc.edu Subject: KeyUp events Resent-Message-ID: <"Hw2QrC.A.goG.hYRY1"@jerry> To: squeak@cs.uiuc.edu Resent-From: squeak@cs.uiuc.edu Reply-To: squeak@cs.uiuc.edu X-Mailing-List: squeak@cs.uiuc.edu archive/latest/2072 X-Loop: squeak@cs.uiuc.edu Precedence: list Resent-Sender: squeak-request@cs.uiuc.edu Status: RO X-Mozilla-Status: 0001 Content-Length: 2357
I really haven't looked too deeply at this, but it seems to me that it is not possible to detect keyUp events in Squeak. That makes it impossible to write certain kinds of games, a simple piano application or, in my case, a chorded keyboard emulator.
To tell the truth, I haven't been very pleased with what I have seen so far of the input architecture. I thought you might find a design I came up with interesting (if not, sorry for wasting bandwidth...).
My idea is to have a set of components connected in a graph-like structure. The graph's edges can be either "push" (where the origin sends a message like #mouseDown: to the destination) or "pull" (where the destination sends a message like #curentCursorX to the origin).
A pushInput/pullOutput component is a buffer, like the well known keyboard type-ahead buffer. A pullInput/pushOutput object could be called a "pump", and can be quite handy in certain situations. A filter is normally a push/push component, but could also be a pull/pull one. They are linked in a 2D graph, so an object can pull from several sources or send to many destinations if the need arises.
Now this graph is dynamic, and can change in response to hardware changes (pluging in that new USB joystick) user preferences (invoking Alan Kay's character recognizer) or application needs (after a drag is initiated you want to keep track of the cursor).
The application should be able to "dip into" this event graph at the points which match its semantic needs the best. If it needs to insert text in a morph then it should poll the TextMux object for input. At this point it could be seeing cooked input from a multi- language keyboard system, the result of a fancy voice recognition system or even the interpretation of some touch tones over the phone line. On the other hand, the toy piano app I mentioned above would be driven by virtual keyboard scancodes. In the same way, a program that needs gestures could get them from a filter on the mouse or from a VR glove, while a paint program might prefer to see mouse events directly (not really, but you get the idea).
Extending Squeak with remote "hands", MIDI, future facial expression recognition from video and so on will become ever more difficult unless something like I suggested is implemented.
-- Jecel
SqueakNOS mailing list SqueakNOS@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/squeaknos
Luciano,
I looked at the SiliconSqueak web site, it is awesome.
Thanks! I consider the current pages to be mostly place holders for the pages with more detailed text to be written later.
Is the Plurion board available? How do you develop for this?
The boards have not been designed yet. In the past I have designed and built several boards and so consider this to be the most risk-free part of the project and also a step which takes up just a few days. The focus is on simulating the design within Squeak and implementing it in FPGAs using the two development boards I have (both with Xilinx chips - the ML401 with a Virtex 4 and the Xess SA100 with a Spartan 2). I might also use some Altera based boards (like the DE2) from the university. I don't expect that using one kind of FPGA for initial development and switching to another (Lattice) for production will present any problems at all.
The next step will be to develop the boards for the Sketchpad low cost toy. It will actually be a Squeak computer, but not selling it as such will avoid expectations of full featured office applications or web browser. Closer to the topic of this list, the more restricted hardware will allow SqueakNOS as it is now to be a satisfactory solution.
The Plurion boards will follow after that and will make more demands on SqueakNOS, as I mentioned in my previous email.
It is very hard to make low cost products without really high volumes (and using custom chips instead of FPGAs), so the initial idea was to start with the Plurion boards. But that was backwards in terms of the software development required.
I didnt find quotes for LatticeECP2 development boards.
A PCI Express development kit is about $900:
http://www.latticesemi.com/store/dev_kits.cfm
I don't know what the other options cost:
http://www.latticesemi.com/products/developmenthardware/lowcostfpga/index.cf...
Though the Xess kit I mentioned is very nice, it really didn't save me any time compared to my own board. So this time around the plan is to go straight to Plurion boards instead of getting one of these kits.
-- Jecel
squeaknos@lists.squeakfoundation.org
-
Jecel Assumpcao Jr -
luciano