"This site is dedicated to etherforth, a variant of colorForth running
entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth
was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to
assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web
pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, 16 April 2022 at 20:42:50 UTC+1, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth
was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to
assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web
pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, April 17, 2022 at 5:22:32 PM UTC+10, jpit...@gmail.com wrote:

On Saturday, 16 April 2022 at 20:42:50 UTC+1, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

+1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, April 17, 2022 at 5:42:50 AM UTC+10, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

Thanks to Daniel for doing this. Maybe he can adopt Jeff's software. Like aha, into this. It was bad the way colorforth disappeared. At least this might be suitable for an eccentric hobby computer. If only they could get this, and sine hardware into
a sub stamp computer. I can offer help into getting it down into the millimetres range. It would be really novel let that. I've been aiming to do such with my retro computers. But in modern interface terms, all you need to do is package wifi direct/
Bluetooth, and USB lines into a minimal plug, then a stacking mechanism or horizontal mechanism. This would be really revolutionary for the Arduino Raspberry Pi market, who has size issues. You could put many modules in the size of a stamp. Even using
magnetic signalling IO proposals. They then can do button and wearable electronics, and simple control things. Of course it's not meant to be anything like a high end Arm running some latest megalith desktop OS, but will present an video interface,
GUI, sound, user controls, and the normal IO.

Let's have a look at this. Usb originally allowed something like 8 devices hanging off a port through a hub or daisy chain. I don't know what the latest is. Using the main control module as a corner of a 9 block, gives a square shape of maybe 1.5cm
square for 9 modules. Using four corners, four ports (1 to 4 in the diagram) you can get a roughly square shape of 33 modules in:

1111
11222
112223
44C223
444333
444333

About 3cm by 3cm.

Or anyway you want to join them. If a top and bottom port is used, you could stack vertically at any width you like, maybe even 16 modules in half a millimetre. In reality, these will take up variable spacing.

The modules can be any distance apart, and the connection between them flexible, do that wearable array of modules would flex.

There are USB card storage standards. I don't know how many are still supported, but that is going be more modules long, and maybe it could be classified as a long module. I would not want the normal module to be more than 1cm in dimension, which
should be too small to fit a card in.

This is suitable to be included in 3D printed devices. An adaption to the 3D print mechanism, allows the simple placement and trace wiring. The 3D printer printing over and sealing on and in.

While USB standards have various different video over USB types, and VGA 256 colour is over 15MB/s, which is doable under usb2.x, if you go 8 bit per channel, that's 45MB/s, which isn't expected to be a stable rate supported by many USB 2 implementations.
Also, in a bus, 8 have to share data rate. If you went 10-12 bits, it just becomes impossible. However, USB 3.x, allows a lot more options. A wide SD display is desirable, as well as HD and full HD. On a wide field of view, wearable glasses version,
full HD would be a desirable minimum. But, the standards allow HDMI and display port over USB I think. What we really want, is a minimum data line version, as with USB flash cards above, for module size.

For every body else. Yes, the module can be covered with edge pins, all over, and of a type used in mounted chips. Frankenstein hundreds of pins over all surfaces, if you wish. Only a moderate amount are needed. However, io modules can carry the pins,
and DMA count shifter timers etc for industrial embedded work. You maybe have module with everything, including some pins. Module with no additional pins, but the USB and wifi/Bluetooth direct. Module with pins and USB. Additional pin only modules.

There is HDMI over two wire.

Wifi/Bluetooth.

Unfortunately, wifi direct priced to be lower in energy than Bluetooth, but harder for users to set up, and faultered in the market. I don't know if it is still a supported purchasable item. But, there is a standard that puts wifi with Bluetooth (not
my favourite, as I still find it can be difficult often). Presuming wifi direct is still a goer, as we need speed for VGA.

Now, the video over wifi is a disaster zone. There were previously compressed wireless and wifi standards (and a old non compressed 27gb/s plus standard from the HDMI people). Then Google stepped in and offered to fix everything. However, partway
through the process, they dropped the basic functionality of live mirroring of the screen, the only useful part for fast interactive games. Instead, after bothering them, they reneged and incorporated mirroring, but through your local router, which
delays everything. The Linux people were developing a version with direct mirroring. It is this sort of functonality you need, which means needing to make a receiver, and virtually developing the standard yourself. Jpeg now has more compressible live
streaming codecs. With extremely little latency, and good compression. All the elements are there, and you could design a custom industrial embedded wifi version, for signalling and communications. There are also other low end embedded communications
protocols out there. You might have to use a seperate wifi chip on the all in one processor module, as the GA likely wouldn't be able to get to speed for video, fast printing or storage.

Usb, wifi direct and Bluetooth, offer device types and their data formats, so this make device support easier to setup, enabling module makers to make their own compatible driver for a format.

Anyway, that's the basic idea of it, and would make etherforth, and the ga144, more useful.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, April 16, 2022 at 3:42:50 PM UTC-4, Jan Coombs wrote:

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

Magnificent!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 17 April 2022 at 08:22:32 UTC+1, Jurgen Pitaske wrote:

On Saturday, 16 April 2022 at 20:42:50 UTC+1, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

With an entry cost of more than $200 just to switch it on, ,
the only option might be an FPGA implementation of this functionality.
Has anybody treid this one here yet, or a few of them linked together?

I wonder if such a setup could use the GA Software http://mindworks.shoutwiki.com/wiki/Forth_Computing_on_FPGA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

They really need to next chip this board, and offer 8t fur $200 to the hobbyist market. They might pick up a collection of programmers and sales.

On Monday, April 18, 2022 at 1:15:57 AM UTC+10, Wayne morellini wrote:

On Sunday, April 17, 2022 at 5:42:50 AM UTC+10, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

Thanks to Daniel for doing this. Maybe he can adopt Jeff's software. Like aha, into this. It was bad the way colorforth disappeared. At least this might be suitable for an eccentric hobby computer. If only they could get this, and sine hardware into a

sub stamp computer. I can offer help into getting it down into the millimetres range. It would be really novel let that. I've been aiming to do such with my retro computers. But in modern interface terms, all you need to do is package wifi direct/
Bluetooth, and USB lines into a minimal plug, then a stacking mechanism or horizontal mechanism. This would be really revolutionary for the Arduino Raspberry Pi market, who has size issues. You could put many modules in the size of a stamp. Even using
magnetic signalling IO proposals. They then can do button and wearable electronics, and simple control things. Of course it's not meant to be anything like a high end Arm running some latest megalith desktop OS, but will present an video interface, GUI,
sound, user controls, and the normal IO.

Let's have a look at this. Usb originally allowed something like 8 devices hanging off a port through a hub or daisy chain. I don't know what the latest is. Using the main control module as a corner of a 9 block, gives a square shape of maybe 1.5cm

square for 9 modules. Using four corners, four ports (1 to 4 in the diagram) you can get a roughly square shape of 33 modules in:

1111
11222
112223
44C223
444333
444333

About 3cm by 3cm.

Or anyway you want to join them. If a top and bottom port is used, you could stack vertically at any width you like, maybe even 16 modules in half a millimetre. In reality, these will take up variable spacing.

The modules can be any distance apart, and the connection between them flexible, do that wearable array of modules would flex.

There are USB card storage standards. I don't know how many are still supported, but that is going be more modules long, and maybe it could be classified as a long module. I would not want the normal module to be more than 1cm in dimension, which

should be too small to fit a card in.

This is suitable to be included in 3D printed devices. An adaption to the 3D print mechanism, allows the simple placement and trace wiring. The 3D printer printing over and sealing on and in.

While USB standards have various different video over USB types, and VGA 256 colour is over 15MB/s, which is doable under usb2.x, if you go 8 bit per channel, that's 45MB/s, which isn't expected to be a stable rate supported by many USB 2

implementations. Also, in a bus, 8 have to share data rate. If you went 10-12 bits, it just becomes impossible. However, USB 3.x, allows a lot more options. A wide SD display is desirable, as well as HD and full HD. On a wide field of view, wearable
glasses version, full HD would be a desirable minimum. But, the standards allow HDMI and display port over USB I think. What we really want, is a minimum data line version, as with USB flash cards above, for module size.

For every body else. Yes, the module can be covered with edge pins, all over, and of a type used in mounted chips. Frankenstein hundreds of pins over all surfaces, if you wish. Only a moderate amount are needed. However, io modules can carry the pins,

and DMA count shifter timers etc for industrial embedded work. You maybe have module with everything, including some pins. Module with no additional pins, but the USB and wifi/Bluetooth direct. Module with pins and USB. Additional pin only modules.

There is HDMI over two wire.

Wifi/Bluetooth.

Unfortunately, wifi direct priced to be lower in energy than Bluetooth, but harder for users to set up, and faultered in the market. I don't know if it is still a supported purchasable item. But, there is a standard that puts wifi with Bluetooth (not

my favourite, as I still find it can be difficult often). Presuming wifi direct is still a goer, as we need speed for VGA.

Now, the video over wifi is a disaster zone. There were previously compressed wireless and wifi standards (and a old non compressed 27gb/s plus standard from the HDMI people). Then Google stepped in and offered to fix everything. However, partway

through the process, they dropped the basic functionality of live mirroring of the screen, the only useful part for fast interactive games. Instead, after bothering them, they reneged and incorporated mirroring, but through your local router, which
delays everything. The Linux people were developing a version with direct mirroring. It is this sort of functonality you need, which means needing to make a receiver, and virtually developing the standard yourself. Jpeg now has more compressible live
streaming codecs. With extremely little latency, and good compression. All the elements are there, and you could design a custom industrial embedded wifi version, for signalling and communications. There are also other low end embedded communications
protocols out there. You might have to use a seperate wifi chip on the all in one processor module, as the GA likely wouldn't be able to get to speed for video, fast printing or storage.

Usb, wifi direct and Bluetooth, offer device types and their data formats, so this make device support easier to setup, enabling module makers to make their own compatible driver for a format.

Anyway, that's the basic idea of it, and would make etherforth, and the ga144, more useful.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 19 April 2022 at 09:50:46 UTC+1, Jurgen Pitaske wrote:

On Sunday, 17 April 2022 at 08:22:32 UTC+1, Jurgen Pitaske wrote:

On Saturday, 16 April 2022 at 20:42:50 UTC+1, Jan Coombs wrote:

"This site is dedicated to etherforth, a variant of colorForth running entirely in GreenArrays' GA144 multi-computer chip. It is a programming language, operating system, and development environment in one."[1]

Found this site while looking for clues as to which processors colorforth was originally designed to run on.

The efficiency of Chuck's array processors has also been difficult to assess, but this page[2] provides data. In summary, processor usage
is:

CPUs Module - Function Summary
---- -------------------------
32 Video module VGA 640-480 driver (or bigger?)
27 Block of free (apart from routing) processors
16 USB (for keyboard, etc?)
15 Compiler - compile src from block, deliver to target chip
14 Editor - for blocks
7 SRAM access and 18-16-18b data connection
6 Scattered unused (apart from routing?) processors
6 Interpreter - user command interface
6 Utilities module - debug and system status to VGA
5 Loader - parse and process load blocks for interpreter
5 Multi Media Card Interface
2 12MHz Ceramic Oscillator driver
2 Asynchronous link module
1 Link module
---
144

Functions normally just software are split into hardware zones. The web pages also contain details of how this complex system is managed.

Jan Coombs
--

[1] ...colorForth ... in GreenArrays' GA144 multi-computer chip http://www.etherforth.org/

[2] Floorplan - Programming GA144 chip is not an ordinary experience. http://www.etherforth.org/sw.html

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

With an entry cost of more than $200 just to switch it on, ,
the only option might be an FPGA implementation of this functionality.
Has anybody treid this one here yet, or a few of them linked together?

I wonder if such a setup could use the GA Software http://mindworks.shoutwiki.com/wiki/Forth_Computing_on_FPGA

A starting point might be here http://mindworks.shoutwiki.com/wiki/Forth_Computing_on_FPGA?fbclid=IwAR0QPqVlhUKiHxd-dJmApCPhJ6WfRPdVWlswTHY9gQa4EHlKZFulYPVvOmo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-04-17, Jurgen Pitaske <jpitaske@gmail.com> wrote:

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

+1 I'd love to know. It's hard to compare something so different from
what's widely available.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, April 22, 2022 at 9:53:52 AM UTC+10, meff wrote:

On 2022-04-17, Jurgen Pitaske <jpit...@gmail.com> wrote:

It is nice to see activity regarding the GA144.

But I wonder, how many people actually own and use one of these chips / boards.

And more importantly - for wich project / application.

And how this would compare in speed and power to modern chips with a single core.

And more interestingly -
what would the performance be, if the GA144 would use a comparable process.

The only thing new I could find on the GA website was the Chuck video. https://rumble.com/vdiqtr-welcome-by-chuck-moore.html

+1 I'd love to know. It's hard to compare something so different from
what's widely available.

@Meff, it shouldn't require so many cores just to do video.

@Jurgen.+1

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)