amforth-devel — Development discussion and user support

Re: [Amforth] wordlist scope

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
> looks fine 
>
> GIve me some more days to think about it (Im currently
> busy with other things) I find the sequence "(create) !e" 
> sligthly strange. Your smudge change from an simple 
> XT to WID-XT makes sense.
>
> Matthias

Hello Matthias,

I look forward to your critical reading of the patch. Currently I'm
using the mechanism to emulate Python private names convention (*) but
this scope word is bound to evolve.

Regards, Enoch.

(*) In Python names in a "module" which begin with underscore cannot be
imported to another via "from module import *".

P/S If you approve of this patch I suggest submission of an RfD to
forth200x.org.

----------------------------------------------------------------------

wordlist constant _private

get-order _private rot rot 1+ set-order

: scope  ( c-addr len -- c-addr len wid )
   over c@ [char] _ =  if
      _private
   else
      get-current
   then
;

' scope is wlscope

Re: [Amforth] AmForth JTAG support

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>> *Background* A brief visit to Atmel's Studio while debugging the wlscope
>> ("wordlist scope") patch convinced me that this magnificant tool is not
>> really good at Forth level debugging as it has no concept of the Forth
>> VM.
>
> You dig deep into the inner workings of amforth. A rather dark place. A
> casual programmer is seldom seen in this area.
>
>> 
>> *Idea* Let us take advantage of Atmel's documented JTAG protocol (e.g.,
>> AVR067: JTAGICE mkII Communication Protocol) and some reverse engineered
>> data (from AVaRICE) to explore the possibility of enhancing
>> amforth-shell.py with several commands that set VM breakpoints and
>> examine data unintrusively.
>
> The idea sound crazy enough to follow it. Its only beyond what I can do....
> I don't know whether the amforth-shell is the right place to start, it may 
> need a more modular design.
>
> Keep in mind that some atmegas do not have JTAG (they have e.g. Debug Wire or
> nothing at all).

That's one of the reasons why such a project is beyond a single
programmer reach. I just have the JTAG Mk II to play with while Atmel is
pushing Mk III (*), there's the debugWIRE to handle, etc.

Within a few days I hope to find the time to conclusively decide about
this project feasibility or if it requires an AmForth kernel heck to
succeed.

Thanks again for the encouragement!

Regards, Enoch.

(*) IIRC the AVRDUDE / AVaRICE guys are in the process of reverse
engineering this Mk III protocol. 









>
> Matthias
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar

Re: [Amforth] AmForth JTAG support

[Matthias T. <mt...@we...>]

Hi Enoch,

> *Background* A brief visit to Atmel's Studio while debugging the wlscope
> ("wordlist scope") patch convinced me that this magnificant tool is not
> really good at Forth level debugging as it has no concept of the Forth
> VM.

You dig deep into the inner workings of amforth. A rather dark place. A
casual programmer is seldom seen in this area.

> 
> *Idea* Let us take advantage of Atmel's documented JTAG protocol (e.g.,
> AVR067: JTAGICE mkII Communication Protocol) and some reverse engineered
> data (from AVaRICE) to explore the possibility of enhancing
> amforth-shell.py with several commands that set VM breakpoints and
> examine data unintrusively.

The idea sound crazy enough to follow it. Its only beyond what I can do....
I don't know whether the amforth-shell is the right place to start, it may 
need a more modular design.

Keep in mind that some atmegas do not have JTAG (they have e.g. Debug Wire or
nothing at all).

Matthias

Re: [Amforth] wordlist scope

[Matthias T. <mt...@we...>]

Hi Enoch,

looks fine 

GIve me some more days to think about it (Im currently
busy with other things) I find the sequence "(create) !e" 
sligthly strange. Your smudge change from an simple 
XT to WID-XT makes sense.

Matthias

> Hello Matthias & All:
> 
> wlscope, "wordlist scope", is a deferred word which enables AmForth appl
> to choose the wordlist for a new voc entry based on its name.  For
> example, put all created words whose name begins with a tilde (~) on a
> private wordlist. The default action is get-current.
> 
> Please find in <http://pastebin.com/KEWfnWNz> a tested new patch for
> your review against AmForth r1400. This patch enables do the following:
> 
> ======================================================================
> 
> wordlist constant private
> 
> : scope  ( c-addr u -- c-addr u wid )
> 
>    over c@ [char] ~ =  if
>       private
>    else
>       get-current
>    then
> ;
> 
> ' scope is wlscope
> 

[Amforth] AmForth JTAG support

[Enoch <ix...@ho...>]

Hello AmForth-ers,

*Background* A brief visit to Atmel's Studio while debugging the wlscope
("wordlist scope") patch convinced me that this magnificant tool is not
really good at Forth level debugging as it has no concept of the Forth
VM.

*Idea* Let us take advantage of Atmel's documented JTAG protocol (e.g.,
AVR067: JTAGICE mkII Communication Protocol) and some reverse engineered
data (from AVaRICE) to explore the possibility of enhancing
amforth-shell.py with several commands that set VM breakpoints and
examine data unintrusively.

*Needed* People with Python and C skills to show interest and share the
burden.

Did anyone attempt this approach before? Any interest?

Thanks, Enoch.

[Amforth] wordlist scope

[Enoch <ix...@ho...>]

Hello Matthias & All:

wlscope, "wordlist scope", is a deferred word which enables AmForth appl
to choose the wordlist for a new voc entry based on its name.  For
example, put all created words whose name begins with a tilde (~) on a
private wordlist. The default action is get-current.

Please find in <http://pastebin.com/KEWfnWNz> a tested new patch for
your review against AmForth r1400. This patch enables do the following:

======================================================================

wordlist constant private

: scope  ( c-addr u -- c-addr u wid )
   over c@ [char] ~ =  if
      private 
   else
      get-current
   then
;

' scope is wlscope

----------------------------------------------------------------------

> private show-wordlist
 ok
> 911 value ~sos
 ok
> private show-wordlist
~sos  ok

======================================================================

I agree, the above is just "semantical sugaring" to the normal use of
wrappers:

get-current 
private set-current
911 value ~sos
set-current

Don't know about you guys, I prefer sweetening my AmForth coffee :-)

Regards, Enoch.

Re: [Amforth] wordlists empowered

[Enoch <ix...@ho...>]

Hello Matthias & All,

Just in case someone is interested in my kernel patching exercise for
automatic wordlist selection :-)

> I prepared a kernel patch, it's very simple, but ain't working, for some
> stupid reason, I guess :)
> The kernel patch is here: http://pastebin.com/8MShMtn4

Delving into the asm code I see that my current docreate.asm patch is
insufficient since the created word is actually linked to the selected
wordlist outside XT_DOCREATE.

It would save some code and would be cleaner programming to put the
equivalent to [.dw XT_GET_CURRENT, .dw XT_STOREE] inside XT_HERE except
for the XT_COLON / XT_SEMICOLON "smudge" issue.

Will have it done tomorrow.

> Here's a simple test case.
>
> ----------------------------------------------------------------------
>
> wordlist constant private
>
> : scope  ( c-addr u -- c-addr u wid )
>    over c@ [char] ~ =  if
>       private
>    else
>       get-current
>    then
> ;
>
> ' scope is wlscope

I hope that I managed to persuade some of you that auto wordlist
selection is a good thing ;-)

Regards, Enoch.

Re: [Amforth] wordlists empowered

[Enoch <ix...@ho...>]

Hello Matthias & All:

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>
>> In the best Forth tradition let this "autoscope" be initially a NOP and
>> allow the programmer to introduce whatever naming scheme he/she desires
>> via a subsequent IS.
>
> A better place for such a hook would be (CREATE) (same asm file). And
> the default should be the standard behaviour (get-current).
>
>> Am I missing something? Did I reinvent the wheel? :-)
>
> I think you solve a problem, nobody else has ;) We'll see how
> much response you'll get..

*Thanks for the encouragement*

I prepared a kernel patch, it's very simple, but ain't working, for some
stupid reason, I guess :)

The kernel patch is here: http://pastebin.com/8MShMtn4
(Sorry Erich, there's no other way with patches, unless you allow me to
insert uuencoded text here).

Here's a simple test case.

----------------------------------------------------------------------

wordlist constant private

: scope  ( c-addr u -- c-addr u wid )
   over c@ [char] ~ =  if
      private
   else
      get-current
   then
;

' scope is wlscope

Trying to create anything "private" (e.g., 100 constant ~test) renders the
dictionary inaccssible. Otherwise it functions as usual.

----------------------------------------------------------------------

I guess that without the Studio (i.e., going to the dark Windows side) I
won't be able to figure this out, so please help.

Thanks, Enoch.

Re: [Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Hello Michael,

"Michael Kalus" <mi-...@t-...>
writes:

> What about mnemonic conventions like
>
>    .s  .r  .line  ." xxx"
>
> or
>
> key?  ?DO
>
> and such? Don't we already use such "unwritten laws"?

Wis was talking about giving an appropriate name to what cvariable
*creates*. There is indeed the Hungarian school of thought which
believes that variable name prefixes should immediately reveal the
variable type. For example, uiParam "says", I am an unsigned integer
parameter.

Regards, Enoch.

Re: [Amforth] CVARIABLE

[Michael K. <mi-...@t-...>]

Hi.

What about mnemonic conventions like

   .s  .r  .line  ." xxx"

or

key?  ?DO

and such? Don't we already use such "unwritten laws"?

Michael




Am 21.03.2013 um 21:24 schrieb Enoch:

> Matthias Trute <mt...@we...> writes:
>
>> Hi Wis,
>>
>>> It may be a good practice to prefix any "cvariable" name with a
>>> mnemonic string (e.g., "c_") to help avoid the troublesome behavior
>>
>> IIRC it is called Hungarian Notation. I'll add a link
>> to the wikipedia article to the recipe.
>
> But Leo Brodie is defintely not Hungarian :-)
> He writes about Choosing Names: The Art
> Choose names according to “what,” not “how”
>
> "But good names are essential for readability. Moreover, the mental
> exercise of summoning a one-word description bears a synergistic  
> effect
> on your perceptions of what the entity should or should not do."
>
> Let's leave the Hungarian method to Microsoft, where it was  
> invented. It
> is an essential evil when managing large projects though.
>
> Regards, Enoch.
>
>
> ---------------------------------------------------------------------- 
> --------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] wordlists empowered

[Enoch <ix...@ho...>]

Erich Waelde <ew....@na...> writes:

> Hi,
>
> On 03/20/2013 11:29 PM, Enoch wrote:
>> Hello AmForth-ers:
>> 
>> Did any of you put "wordlists" into a good use?
>
> yes. I use this to create a separate wordlist, which
> is used to parse a special source code structure. I need
> a special wordlist, because I need to *temporarily* "overload"
> the meaning of some important words.
>
> I have also used this to reduce the available wordlist on
> the serial interface after startup.
>
> Also, Lubos Pekny (forth.cz) uses wordlists to separate
> things.

So we all agree that wordlists are important.  What I asked myself was
how to make them easier to use.

>> I suspect the answer is no for a simple reason. To use it, say, to
>> create a private "scope" ("namespace") of words / variables / constants
>> one needs to wrap each dictionary entry with calls to get-current,
>> get-order, set-current, set-order, ... too much trouble.
>> 
>> What if we decide that all names that begin with a tilde (~) should
>> *automatically* be created into a specific private wordlist.  How can we
>> accomplish that?
>
> Well. I do use a number of words myself starting with ~ (tilde). And
> I do not agree at all, that creating special prefixes *for everyone*
> and do something entirely different with those words,
> is the way to go. Even if I need to explicitly enable the feature,
> I do not want to have the freedom of choosing token names stumpled upon.
> Remember the FORTRAN rule of "undeclared variables starting with [I-N]
> are assumed integer"? How awkward. Can I at least choose the prefix
> freely? Can it be more than one character? Recognizers would be the
> way to go, I think.

The thought of imposing naming conventions on other programmers did not
even cross my mind :-)

> Who stops you from implementing this for your use and put the
> resulting code into a message on the list ? (reminder: I will not
> look at code elsewhere) And why do you want your solution to be
> included into the amforth distribution and *enabled by default*?

I will contribute my code and will let Matthias decide on its worthiness
and yes, I can live with a rejection :-)

Why do I want to have "my" solutions included into the AmForth
distribution... I am puzzled by this question -- isn't it the very
nature of OSS development, free competition of ideas. By the way, having
a "benevolent dictator" who decides about the worthiness of ideas /
implementations is well rooted into the OSS culture too.

If code is short it will go to the mailing list. If it is long, I
disagree, its place is a seperate "pastebin".

> What use cases for the suggested feature are you currently looking at?

1. Keeping certain words/variable/constants private, i.e., unknown
outside a certain source file.

2. In a large library, say, graphic library, put all public words/... on
a seperate wordlist.

> Are there other ways to accomplish your goal? Why is this way the
> ultimate thing to do?

I suggested a kernel hack but I can see high level help in handling
wordlists too. How do you utilitize wordlists, using raw get-current,
set-current, etc. calls?

> Imho Forth is about simplicity. You suggest to add a bit of complexity
> (automagic different behaviour).

Default behavior would be set-current (of-course). 
 
>> Here's my suggestion for your review:
>> 
>> If I am correct the kernel word "header ( addr len wid -- voc-link )" is
>> responsible for creating dictionary entries of all kinds. What if this
>> "header" would begin with a call to a (e)deferred word, say, "autoscope"
>> that would examine the new entry name (via "addr len") and would set the
>> "wid" etc.  as needed.
>> 
>> In the best Forth tradition let this "autoscope" be initially a NOP and
>> allow the programmer to introduce whatever naming scheme he/she desires
>> via a subsequent IS.
>
> But that is a penalty of 1 call to noop for every call of header, and for
> everyone.

Get serious Erich, that's a one-time compile-time penalty :-)

10000 dictionary-entries × 10µS penalty = 0.1s

Regards, Enoch.

Re: [Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> Hi Wis,
>
>> It may be a good practice to prefix any "cvariable" name with a
>> mnemonic string (e.g., "c_") to help avoid the troublesome behavior
>
> IIRC it is called Hungarian Notation. I'll add a link
> to the wikipedia article to the recipe.

But Leo Brodie is defintely not Hungarian :-)
He writes about Choosing Names: The Art 
Choose names according to “what,” not “how”

"But good names are essential for readability. Moreover, the mental
exercise of summoning a one-word description bears a synergistic effect
on your perceptions of what the entity should or should not do."

Let's leave the Hungarian method to Microsoft, where it was invented. It
is an essential evil when managing large projects though.

Regards, Enoch.

Re: [Amforth] wordlists empowered

[Matthias T. <mt...@we...>]

Hi,

> Recognizers would be the way to go, I think.

Thats an interesting point. Until now, recognizers
are not considered part of the *compiler*, but part
of the (outer) *interpreter*.

That means, they are used to find the proper meaning
of an *already defined* word, but they are not active
*during the definition* of a word.

Fascinating idea, indeed.

Matthias

Re: [Amforth] wordlists empowered

[Erich W. <ew....@na...>]

Hi,

On 03/20/2013 11:29 PM, Enoch wrote:
> Hello AmForth-ers:
> 
> Did any of you put "wordlists" into a good use?

yes. I use this to create a separate wordlist, which
is used to parse a special source code structure. I need
a special wordlist, because I need to *temporarily* "overload"
the meaning of some important words.

I have also used this to reduce the available wordlist on
the serial interface after startup.

Also, Lubos Pekny (forth.cz) uses wordlists to separate
things.


> I suspect the answer is no for a simple reason. To use it, say, to
> create a private "scope" ("namespace") of words / variables / constants
> one needs to wrap each dictionary entry with calls to get-current,
> get-order, set-current, set-order, ... too much trouble.
> 
> What if we decide that all names that begin with a tilde (~) should
> *automatically* be created into a specific private wordlist.  How can we
> accomplish that?

Well. I do use a number of words myself starting with ~ (tilde). And
I do not agree at all, that creating special prefixes *for everyone*
and do something entirely different with those words,
is the way to go. Even if I need to explicitly enable the feature,
I do not want to have the freedom of choosing token names stumpled upon.
Remember the FORTRAN rule of "undeclared variables starting with [I-N]
are assumed integer"? How awkward. Can I at least choose the prefix
freely? Can it be more than one character? Recognizers would be the
way to go, I think.

Who stops you from implementing this for your use and put the
resulting code into a message on the list ? (reminder: I will not
look at code elsewhere) And why do you want your solution to be
included into the amforth distribution and *enabled by default*?

What use cases for the suggested feature are you currently looking at?
Are there other ways to accomplish your goal? Why is this way the
ultimate thing to do?

Imho Forth is about simplicity. You suggest to add a bit of complexity
(automagic different behaviour).

> 
> Here's my suggestion for your review:
> 
> If I am correct the kernel word "header ( addr len wid -- voc-link )" is
> responsible for creating dictionary entries of all kinds. What if this
> "header" would begin with a call to a (e)deferred word, say, "autoscope"
> that would examine the new entry name (via "addr len") and would set the
> "wid" etc.  as needed.
> 
> In the best Forth tradition let this "autoscope" be initially a NOP and
> allow the programmer to introduce whatever naming scheme he/she desires
> via a subsequent IS.

But that is a penalty of 1 call to noop for every call of header, and for
everyone.

Re: [Amforth] wordlists empowered

[Matthias T. <mt...@we...>]

Hi Enoch,


> In the best Forth tradition let this "autoscope" be initially a NOP and
> allow the programmer to introduce whatever naming scheme he/she desires
> via a subsequent IS.

A better place for such a hook would be (CREATE) (same asm file). And
the default should be the standard behaviour (get-current).

> Am I missing something? Did I reinvent the wheel? :-)

I think you solve a problem, nobody else has ;) We'll see how
much response you'll get..

Matthias

Re: [Amforth] CVARIABLE

[Matthias T. <mt...@we...>]

Hi Wis,

> It may be a good practice to prefix any "cvariable" name with a
> mnemonic string (e.g., "c_") to help avoid the troublesome behavior

IIRC it is called Hungarian Notation. I'll add a link
to the wikipedia article to the recipe.

Matthias

[Amforth] wordlists empowered

[Enoch <ix...@ho...>]

Hello AmForth-ers:

Did any of you put "wordlists" into a good use?

I suspect the answer is no for a simple reason. To use it, say, to
create a private "scope" ("namespace") of words / variables / constants
one needs to wrap each dictionary entry with calls to get-current,
get-order, set-current, set-order, ... too much trouble.

What if we decide that all names that begin with a tilde (~) should
*automatically* be created into a specific private wordlist.  How can we
accomplish that? 

Here's my suggestion for your review:

If I am correct the kernel word "header ( addr len wid -- voc-link )" is
responsible for creating dictionary entries of all kinds. What if this
"header" would begin with a call to a (e)deferred word, say, "autoscope"
that would examine the new entry name (via "addr len") and would set the
"wid" etc.  as needed.

In the best Forth tradition let this "autoscope" be initially a NOP and
allow the programmer to introduce whatever naming scheme he/she desires
via a subsequent IS.

Am I missing something? Did I reinvent the wheel? :-)

Thanks, Enoch.

Re: [Amforth] CVARIABLE

[Macomson, W. <wis...@in...>]

I like this.

It may be a good practice to prefix any "cvariable" name with a mnemonic string (e.g., "c_") to help avoid the troublesome behavior noted on Matthias' "...RAM-Efficiency.html" page.

-wis

-----Original Message-----
From: Matthias Trute [mailto:mt...@we...] 
Sent: Saturday, March 16, 2013 11:43 AM
To: Everything around amforth
Subject: Re: [Amforth] CVARIABLE

Hi Enoch,

>> : cvariable variable -1 allot ;
> 
> Implementation is not the issue -- education is (i.e., please be 
> reminded that the AVR is an 8bit µC).

I hope you like
http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html

Matthias
PS: the recipe deserves more ideas ;)

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/ Amf...@li...
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Code for pcf8593 and ds1307 real-time clocks

[David W. <ins...@gm...>]

Just digging it out, so it's on its way...


Hi David,

> I have some code for the above real-time clocks if it's of any use to
> anyone.

yes me ;) (send it directly to me, please. The mailing list
strips attachments unless special care is taken with the mime-type.)

Matthias

Re: [Amforth] Code for pcf8593 and ds1307 real-time clocks

[Matthias T. <mt...@we...>]

Hi David,

> I have some code for the above real-time clocks if it's of any use to
> anyone.

yes me ;) (send it directly to me, please. The mailing list
strips attachments unless special care is taken with the mime-type.)

Matthias

Re: [Amforth] Xbee with amforth

[Matthias T. <mt...@we...>]

hi David,


> The difficulty that I'm trying to overcome is that the xbee radios 
> transmit the data in packets. Now a simple solution would be to
> create new emit/emit? and key/key? words to get and receive 
> characters, enclosing them in packets. This would, however, be 
> terribly inefficient because I'd be making a packet for every 
> character (so every character sent would take ~ 20 characters with 
> the rest of the packet). I'd probably end up overrunning the buffers 
> too, if the serial traffic went up 20 times. This is why I was 
> considering an interrupt driven transmit. I make my own emit that 
> puts characters in a buffer, and the ISR periodically gathers up 
> whatever's in the buffer, builds a packet and sends it to the uart. 

Sounds good. Even a multitasker job could do that job too, I see
no ultimate reason for an interrupt. Just call PAUSE often enough,
esp when EMIT? signals a "no".

> Receive has the same problem. I'm getting in packets and have to
> pull out the text from within the packet.

As long as a single packet fits into the receive buffer, I see no
problem here. KEY and KEY? check this buffer and read from
it. Exactly this does the interrupt driven usart receive.

>  The building/reading
> packet code is done, but I need to somehow integrate this in to
> key/emit.

Let them work on the buffers. Where the buffer content comes from or
where it goes to and how, let that work do other code.

> I guess I'm going to have to go through the source. I have found the 
> files in core/drivers. I think this is probably where I need to 
> start...

The usart transmit interrupt routine uses a (small) buffer as well.

Good luck
Matthias

[Amforth] Code for pcf8593 and ds1307 real-time clocks

[David W. <ins...@gm...>]

Hi all,

I have some code for the above real-time clocks if it's of any use to
anyone.

Cheers,

David

Re: [Amforth] Xbee with amforth

[David W. <ins...@gm...>]

In AmForth the words EMIT and EMIT? are not fixed...


Thanks for the reply Matthias.

The difficulty that I'm trying to overcome is that the xbee radios transmit
the data in packets. Now a simple solution would be to create new
emit/emit? and key/key? words to get and receive characters, enclosing them
in packets. This would, however, be terribly inefficient because I'd be
making a packet for every character (so every character sent would take ~
20 characters with the rest of the packet). I'd probably end up overrunning
the buffers too, if the serial traffic went up 20 times. This is why I was
considering an interrupt driven transmit. I make my own emit that puts
characters in a buffer, and the ISR periodically gathers up whatever's in
the buffer, builds a packet and sends it to the uart. Receive has the same
problem. I'm getting in packets and have to pull out the text from within
the packet.  The building/reading packet code is done, but I need to
somehow integrate this in to key/emit.

I guess I'm going to have to go through the source. I have found the files
in core/drivers. I think this is probably where I need to start...

Cheers,

David

Re: [Amforth] Latest version

[Matthias T. <mt...@we...>]

Hi Jan,

welcome back :)

> After a long delay will start agin to implement the lates version.
> Where do I find a compiled version

I don't maintain compiled versions except for some
very rare and very narrowly specified systems
(e.g. some arduinos).

All you need starts here: http://amforth.sf.net/

Matthias

[Amforth] Latest version

[Jan K. <kro...@ho...>]

Hello,

After a long delay will start agin to implement the lates version.
Where do I find a compiled version (sorry I forgot where to find it, its the age!!)

Thank for any help,
Cheers.

Jan kromhout
Sacharovlaan 3
3223HM Hellevoetsluis-NL