ColorForth as just IDE?

[Jack Chidley]

I am a newbie.  I understand the interest in running ColorForth natively, if only for historical reasons.

I can also see the benefits of just using it like an IDE, like they did at Green Arrays previously.  I haven’t tried but is it possible to use it as a front end for development on Forth based embedded devices?  Could it do the same over an IP link?

Jack

[Nicolas Maroudas]

"An integrated development environment (IDE) is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of at least a source code editor, build automation tools and a debugger."   -- Wikepedia

I am not a software developer, simply a researcher who has used Forth to programme solutions to specific problems since 1970. The things I liked about Forth are, how easy it is to learn, how close it gets you to the hardware, and how fast it gets you going. ColorForth even more so. Ten years ago I learnt CF and used it to drive an external DAC and play string quartet music at 300kHz 16bit PCM. This was unheard of in commercial DACs at the time, though now High Res HiFi is the audiophile norm.

Commercial synths still suck. Part of the problem is the need to calculate the harmonic sum of N instruments, each with M harmonic partials, in parallel in real time. GreenArrays products seem ideal for this purpose (and for many more problems that require the solution of multivariable Partial Differential Equations in real time). So, I bought Evaluation Board #1 a few years ago, and am brushing up my CF to use it. Part of this process will be to learn Intel's HDA Audio codes for the PC's PCI, and to learn Chuck's USB blocks so I can communicate at USB speed between the PC and the EVB. The codes are there, it will just take a little time to learn them.

But meanwhile GreenArrays have decided, quite sensibly, that the vast majority of Forth programmers are more familiar with conventional ASCI, and have provided a new board #2 with PolyForth as the main proven and reliable higher level workhorse. So I shall buy EVB #2 also, and attack my problem that way as well. Working in parallel on two parallel EVBs: programming the one in CF, the other in PF. I have plenty of time -- I'm a pensioner.

--
You received this message because you are subscribed to the Google Groups "ColorForth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Color-Forth...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/Color-Forth/308d1f0b-d191-455c-8745-8830a27996ad%40googlegroups.com.

--

Dr NG Maroudas, 47 Hachoresh, Kyriat Tivon, Lower Galilee, Israel 36051 
Tel  Home +972 48 337 315     Cellular +972 547 602 687


***

[Jack Chidley]

On Tuesday, 14 April 2020 05:38:52 UTC+1, NickM wrote:

But meanwhile GreenArrays have decided, quite sensibly, that the vast majority of Forth programmers are more familiar with conventional ASCI, and have provided a new board #2 with PolyForth as the main proven and reliable higher level workhorse. So I shall buy EVB #2 also, and attack my problem that way as well. Working in parallel on two parallel EVBs: programming the one in CF, the other in PF. I have plenty of time -- I'm a pensioner.

I am an IT industry veteran and in 2016 I retired early. My personal IT journey started with the Commodore 64 (its processor, the 6502, was an early target for Fig-FORTH) and professionally with IBM-DOS and the Intel 80286 processor.  Because I, too, have plenty of time I am free to pursue my passions. IT is still one of my hobbies hence my interest in Forth.

 

Forth is fascinating because it does things so very differently from mainstream IT. These differences include the language Forth uses to describe things (e.g. meta-compilation vs cross-compilation).

 

ColorForth, as far as I can tell, included 3 parts:

1) Native booting FORTH operating system - now just a Windows executable running SaneFORTH (sF) and still used with ArrayFORTH (aF)

2) Some middleware providing some kind of byte-code compilation/pre-compilation - I am not really clear what this does and why it is strictly necessary - this appears to have been removed in aF 3.

3) The editor - which still exists in aF 3 and appears to work the same.

 

The GreenArray evaluation boards appear to use polyFORTH for the host chip and eFORTH for the targets.

 

As far as I can see Chuck Moore stopped developing a native booting FORTH system after he converted it for the Intel Pentium. Booting an operating system for any modern system's chipset (Intel, AMD, ARM, etc) is fiendishly complicated.  GreenArrays decided to use a Windows Application (saneFORTH) instead.  This makes sense as you can let Microsoft worry about the details.  These days EFI booting is the way to do this. 

Much of the recent ColorFORTH activity on this mailing list is aimed at creating a new, USB bootable, version of ColorFORTH.

 

The middleware part of ColorFORTH seems to have been dispensed with because the benefits were outweighed by the complexity.

 

The editor still exists and this bit is what I am interested in, just because it is unusual.  Thankfully GreenArrays default keyboard is qwerty and not the, utterly useless in my view, Dvorak keyboard (see https://reason.com/1996/06/01/typing-errors/).  The question in my mind is how you might use the editor to code for other FORTH targets.

 

PS: Elizabeth Rather clearly had a gift for understanding, documenting and explaining FORTH.  I think that without her no one, other than Chuck Moore, would have used the language

[Nicolas Maroudas]

Yes, there are a handful of people like Howerd who are attracted to the sparsity of Forth in general and CF in particular; they update Chuck's minimalist CF booting via Intel CPU calls. I have found CF fast and convenient in practice (even the Dvorak keyboard). And I have the leisure to follow this line on EVB1.

However, the important point here - which so far as I can tell has not been addressed by the Forth  community - is that GA144 today is like the Laser in 1960: a solution in search of problems. I know of only one published article which compared actual performance of a GA144 array against another type of array, and that was for signal processing. They concluded that GA144 gave less bang per buck for this particular application. Perhaps there are other such comparative studies on array computing in the pipeline? I think parallel CPUs, each with its own small cache of memory (like GA144) are suited to the solution of Partial Differential Equations. 

My own interest is in synthesising arrays of musical instruments using high speed Fourier harmonics of real instrumental timbre in parallel.   

--

You received this message because you are subscribed to the Google Groups "ColorForth" group.
To unsubscribe from this group and stop receiving emails from it, send an email to Color-Forth...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/Color-Forth/c62f5a37-8585-4d09-8996-cf17b92159d9%40googlegroups.com.