way OT: IITRAN was Re: RX02 and intel hex file tools - test-drb@ccmp.vtda.org

30 Jan 2006

Hi
 I'm not sure what you mean here. I have code that I
use similar to Dave Dunfields that talks directly
to I/O devices. The only assembly code I wrote
is a few lines for the interrupt acknowledgment
...
 from the DMA controller. Ease of I/O control is
one of the better points.
 If you mean there are often no libraries, this is
really a matter of whose Forth you are using.
 There is a commercial Forth that is intended to
be run as a tethered Forth. It can be used with
a serial port or with one bi-directional line and
a strobe signal. This allows interactive from
a PC while the final application could be standalone,
on minimum resourses.
Dwight

...
 From: "Roy J. Tellason" <rtellason at
blazenet.net>

On Monday 30 January 2006 02:03 pm, Richard wrote:
  In article <200601301050080652.435B73FC at
10.0.0.252>,

     "Chuck Guzis" <cclist at sydex.com>  writes:
  I first saw Forth as STOIC under CP/M. [...]
 My impression is that the suitability for a
 task decreases quickly as the task size increases. 
 I'd say that's accurate.  FORTH was designed for microprocessor
 control in embedded systems.  People have added all kinds of layers on
 top of the kernel over the years, but its typeless nature gets kind of
 grungy in larger applications. 
In spite of what I hear about it being designed for that kind of app 
(originally for telesscope control?) the stuff I've gotten so far seems to be 
remarkably weak in terms of i/o operations,  with a LOT (way too much) being 
devoted to console-I/O type stuff.  Which doesn't help a whole lot when you 
don't have a console...

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin