|
|
 Up |
|
|
  |
Author: geomochgeomoch Date: Nov 24, 2007 15:12
Hello all,
I've been learning Forth for the past year or two, and it has struck
me as a very elegant and powerful language/philosophy.
I had some exposure to Forth as a child and I am saddened to see it
slip into...
|
| Show full article (1.09Kb) |
|
| | 119 Comments |
|
|
Author: MatthewKMatthewK Date: Nov 25, 2007 07:44
>
>I am interested in a
> complete operating system and associated software in Forth, kinda like
> a forth-unix (foonix?). I have been toying with
> the idea of writing my own native Forth for ARM as x86 is not ideal
> for Forth.
I'm newer than you to all of this but I have followed the forth community
for a lot of years. The projects that spring to mind are retroForth,
enth/flux, and colorForth. I seem to recall a french project that had
some eye-candy graphics --- I know no other infromation on it.
Seems to me the way to go about this is being application based rather
than trying to create a modern operating system. If I was going to do it
I would start with a text-based webtv type application. That would be a
fun hardware and software product. Base it off an x86 platform like a
mini-itx or nano-itx. Make your favorite forth boot into ram from a CF
card and write to a second one or hd.
What I understand about colorforth is that it seems to be made for this
type of work. It is an operating system.
|
| Show full article (1.46Kb) |
|
| | no comments |
|
|
Author: Ian OsgoodIan Osgood Date: Nov 25, 2007 08:04
> Hello all,
>
> I've been learning Forth for the past year or two, and it has struck
> me as a very elegant and powerful language/philosophy.
> I had some exposure to Forth as a child and I am saddened to see it
> slip into obscurity, it seems to me to be a superior approach
> to computer software. While I have been learning Forth on an x86 under
> Linux I feel that to truly get the best from 'The Forth Way'
> it should really be in a system where Forth is used for everything,
> where the operating system is Forth. I am interested in a
> complete operating system and associated software in Forth, kinda like
> a forth-unix (foonix?). I have been toying with
> the idea of writing my own native Forth for ARM as x86 is not ideal
> for Forth. I feel confident I could complete a native Forth
> given time, but perhaps not as well as some others could. When all the
> associated code required to create a full system is
> taken into account it seems like an insurmountable task. Are there any
> active open source projects that share this aim? If not,
> would anyone else be interested in such a project? ...
|
| Show full article (1.53Kb) |
| no comments |
|
|
Author: Mikael NordmanMikael Nordman Date: Nov 26, 2007 03:24
> I feel that to truly get the best from 'The Forth Way'
> it should really be in a system where Forth is used for everything,
> where the operating system is Forth. I am interested in a
> complete operating system and associated software in Forth, kinda like
> a forth-unix (foonix?). I have been toying with
> the idea of writing my own native Forth for ARM as x86 is not ideal
> for Forth. I feel confident I could complete a native Forth
> given time, but perhaps not as well as some others could. When all the
> associated code required to create a full system is
> taken into account it seems like an insurmountable task. Are there any
> active open source projects that share this aim? If not,
> would anyone else be interested in such a project?
>
> I am but an egg,...
|
| Show full article (1.93Kb) |
| no comments |
|
|
Author: astrobeastrobe Date: Nov 26, 2007 05:05
> I'm newer than you to all of this but I have followed the forth community
> for a lot of years. The projects that spring to mind are retroForth,
> enth/flux, and colorForth. I seem to recall a french project that had
> some eye-candy graphics --- I know no other infromation on it.
>
|
| |
| no comments |
|
|
Author: geomochgeomoch Date: Nov 26, 2007 05:56
Thanks for the answers all!
Perhaps I should clarify, I am interested in a desktop/server
operating system, not embedded. Many of the suggestions given
have been very useful and I can see me reading a lot of source
in the next few days, but none are really what I am aiming for.
Retroforth would be ideal if they had a native system for ARM
or some similar chip, but while there is talk of an ARM port
there doesn't seem to be much progress on that front. While
Riscy Pygness is targeted at ARM it seems to be aimed at
umbilical development of embedded systems. Enth seems to
not be active any longer, but the same author has written
Raven, which although not being what I am looking for either
seems very interesting in it's own right.
|
| Show full article (1.54Kb) |
| no comments |
|
|
Author: geomochgeomoch Date: Nov 26, 2007 06:05
On Nov 26, 1:05 pm, astrobe gmail.com> wrote:
That's pretty close to what I'm looking for, thanks for
the link :)
|
| |
| no comments |
|
|
Author: Albert van der HorstAlbert van der Horst Date: Nov 26, 2007 10:41
In article ,
Mikael Nordman wrote:
>geomoch@ gmail.com wrote:
>
>A few years back I had the idea that a native Forth system living
>in flash based microcontroller would be an attractive Forth learning
>and application platform.
>
>Now a few years later this idea has for my part evolved into
>FlashForth for the PIC18Fxxxx.
> http://www.sourceforge.net/projects/flashforth
>
>I like the way of working where you just write words, test them
>and when the last word is tested, the application is ready and already
>in the flash.
>The Forth kernel is write protected, so you can abuse it, but still
>recover by saying COLD.
>
>What is special with FF is that it maps the PIC Harvard architecture
>to a linear address space and that you can define the data ...
|
| Show full article (2.49Kb) |
| no comments |
|
|
Author: John PassanitiJohn Passaniti Date: Nov 26, 2007 12:05
Albert van der Horst wrote:
> I'm working on the Renesas M16C at the moment. Flash buffers are
> 64 kbyte. (and a few smaller ones.) This gives problems for
> implementing blocks.
It would only be a problem if you directly tied the BLOCK primitives to
the flash writing routines, which seems like a bad idea to me.
Depending on how you use the flash memory, chances are you need to do
this anyway. Flash devices (especially NAND flash) can come from the
factory with bad blocks, and over time, blocks will fail. This alone
suggests some sort of mapping facility that takes Forth's BLOCK numbers
and translates them, through some lookup table, into a flash sector.
You'll probably also want to do this for another reason-- wear-leveling.
An application that writes over and over to the same physical block
will eventually wear out that block. Most flash memory managers will
schedule writes across different physical blocks.
|
| Show full article (1.24Kb) |
| no comments |
|
|
|
|
|
Author: Anton ErtlAnton Ertl Date: Nov 26, 2007 14:17
Albert van der Horst writes:>I'm working on the Renesas M16C at the moment. Flash buffers are
>64 kbyte. (and a few smaller ones.) This gives problems for
>implementing blocks.
Actually, I think that standard blocks are quite well suited for that,
especially if the application is aware of that.
A very simple way (that requires a lot of application awareness), is
to have the application change and UPDATE 64KB worth of blocks, and
then SAVE-BUFFERS them all at once.
|
| Show full article (1.77Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
