[SqNOS] driver framework (was: SqueakNOS boots under VirtualBox on Mac OS X 10.5)

[luciano]

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 at 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 at 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 at 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 at lsi.usp.br
> Message-Id: <199805190517.AAA27596 at c.cs.uiuc.edu>
> Subject: KeyUp events
> Resent-Message-ID: <"Hw2QrC.A.goG.hYRY1"@jerry>
> To: squeak at cs.uiuc.edu
> Resent-From: squeak at cs.uiuc.edu
> Reply-To: squeak at cs.uiuc.edu
> X-Mailing-List: <squeak at cs.uiuc.edu> archive/latest/2072
> X-Loop: squeak at cs.uiuc.edu
> Precedence: list
> Resent-Sender: squeak-request at 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 at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/squeaknos
>