[SqNOS] ColaNOS

[Gerardo Richarte]

Luke Gorrie wrote:
>>    I can do "interpret"("nand:\") for example, and it works :)
>>     
> Cool :-)
>   
    More accurately, what I did is:

    OFW_callout("interpret",1, 0, "dir nand:\\")
and then
    OFW_callout("interpret",1, 0, "dir disk:\\")


    from Squeak. What I wanted to test is if the USB (disk:) and the
internal filesystem (nand:) was working from within Squeak, and
it is. With those two commands I saw a directory listing of both
devices! But it was just for testing.
> Is there an easy way that when starting Squeak you can allocate all
> the memory you will ever need (e.g. 95% of system memory) for the
> Squeak heap and runtime system -- and then keep all your own memory
> allocations inside that and make OFW happy with the leftover 5% that
> it can keep for itself? (Just an idea.)
>   
    That's a good idea. I think that some solution like what you
propose will probably be the easies. However, I want to give Squeak
most of the available memory so the Object Memory can grow as
needed by the Smalltalk applications. My approach is to give Squeak
everything for a certain address and up. When nothing else is
running underneath, it's ok. But with OpenFirmware the story
is a little bit different...

    Building on your suggestion I may actually do something like:

allocate a big buffer before booting SqueakNOS
boot SqueakNOS
release the buffer.

This way I expect to create a hole in OFW's memory map, but, on
one side, it's too much implementation dependent, and on the other
side, I'm not sure it's going to work.
> I've been reading over the C "client interface" towards Openfirmware.
> http://www.complang.tuwien.ac.at/forth/1275.ps.gz
>   
That's a good pointer! tx.

I was getting ideas from the svn repository. There are a few client
examples, and just yesterday Mitch Bradely told me to get a full
implementation of emacs (in C) from the SVN, so I updated and it
was just there! Emacs needs, of course, access to the services
provided by OFW, so everything needed is actually there.

There is, in fact, a small libc-like library wrapping the services.

I've done a few tests, trying to open files, all of the unsuccessful so
far :(

("open", 1, 1, "nand:\etc\passwd", 0)

is what I tested.

It returns -1 (error), but does change 0 to some pointer. So I'm
not really sure if it's failing or not. I any case, I kept going ignoring
the error, and tried to read from the file, but it didn't work. I'll keep
trying, my fear right now is that the memory sections are clashing,
and Forth objects get mangled with Smalltalk objects.

I'll keep trying. Do you have any idea what "open" is supposed to
return? (a number?, a pointer?)

    richie