[Amforth-devel] Beginner's experience

[pito <pi...@vo...>]

Hi dear friends,
as the amforth is a nice gadget worth of consideration, let me summarise

my beginner's first impression I've got after few evenings with it (and
forth). It is my second attempt to learn and utilise it, the first I
did was in '82 as I had built my first ucomputer (8085 based).

I got a dev system which is fully stable (usb usart and usb programmer,
Avr Studio, Avrdude, XP SP3). So I am a win user who does not fit into

the community (:-)..

The install of the fresh amforth from the template was easy, some editing
of template was required (see my earlier posts). Then I started my
learning process by trying the examples. None .py tools used.

Here I learned the dict* files needs to be enhanced by several words

in .asm, in order to start with. The upload of .frt for atmega32 and

other words needed was not easy as of the delay required. Hyperterminal
is of no use. After long tweaking and 20 reflashes (because of hangs)
I found Forfiter, which enabled me to upload (however it works with 
19k2 max) as it has ok commit. 

It seems there is no check whether a word has been uploaded correctly,
so it happened the words were uploaded partially because of a missing

definition following an abort of the upload. However the word
appeared in wordlist. So I had many new words. And sometimes I had
to reflash because of a hang. 

When I tried a small routine within an interrupt routine I need to 
reflash at least 15 times to get it stable (I think because
of stackoverun and resulting crashes - no prompt, thus reflash). So the
development cycle was longer as with C or asm.

I do not have access to python and pearl scripts (XP Python incompatibility)so
the only way is to upload the required frts (marker, 2x, atmega32 reg
def, etc)each time again. Then marker - dev and I tried again. When
happy and none crash I used -dev to start again without a reflash.

The biggest problem for me (a beginner) is the "OS" ruggedness and support.
The new words might be available on net, but the OS is hardwired. Words
like .s and .res did not help me much, so I did mostly "try and error"
wise, with frequent reflashing the rom. Many times the systems stoped
response after running the new word and I lost the acces to the system.
Even hardware reset did not help.

The ctrl-C for return to interpreter, or ctrl-Q for a soft reset would
be
really necessary. Also some stack overflow exception with a return to
prompt would be a nice feature.

Simple an ability to run a word and interrupt it anytime with a return

to prompt is higly required. So the main differentiator against others
shall be the blackbox is bullet proof and always responsive. I do not
know
how to achieve that (maybe an OS interrupt with highest priority always
checking the incoming RX escape sequences.. e.g. every system tick..).
The amforth, from my understanding, will never be used by someone for
extreme time critical applications, so more such OS features in its
kernel/interpreter would be an andvatage.

My trigger to spend some time with forth is basicly a) with my interest
in
FPGA, simple hw implementation of many forth processors in today's high
density arrays, and b) that I do like such small black boxes (e.g. parallax
stamps, 51 basics, etc) to play with between football matches..

Maybe the current linux toolchain is more advanced, however the development
process with amforth and my XP tools is a challenge for a beginner (not
speaking about a good simulator..)

PS: Any plans for amforth 32bit with float??

Cheers,
Pito