amforth-devel — Development discussion and user support

Re: [Amforth-devel] Reference Card

[Marcin C. <sa...@sa...>]

>> Erich Waelde <ew....@na...> wrote:
> Hi Matthias,
>
>>
>> http://amforth.sourceforge.net/refcard.pdf
>>
> Very cool! This is IMHO a good handout to folks
> attending a class :-)

Yes, very useful. I could have used that for the class,
too.

Few improvements to suggest: I see stack effects underlined,
I think this is unnecessary. They also take way
too much space. I think the text should be compressed
in six columns (2 x 3 columns), laid out in landscape mode.

//Marcin

Re: [Amforth-devel] Reference Card

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

Hi Matthias,

>
> http://amforth.sourceforge.net/refcard.pdf
>
Very cool! This is IMHO a good handout to folks
attending a class :-)
Definitely worth the effort. Thank you.

The text on the "Compiler" page is somewhat too big and
does not fit onto the page ... is "value" the last entry?

Cheers,
Erich

Re: [Amforth-devel] Editing command line - backspace issue

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

hi Pito,

> There are terminals sending 0x7f (delete) instead of 0x08
> (backaspace) when backspace key is hit.

And these terminals can be customized to work properly.

> Maybe 'accept' could be
> modified by Matthias to process 0x7f as well.

Terminals are a nightmare. Mine here sends a multi-byte
sequence if I hit the DEL key. The backspace key
sends the proper ascii 8 code byte. I dont want to dig deeper
into that....

Matthias

Re: [Amforth-devel] Editor and screens now working

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

hi Karl

> I now have a (very crude) screen-based editor working on my  
> ATmega328P target.  I added support for a Microchip 25LC512 serial  
> EEPROM, which not only lets me back up an image of my system, but  
> also supports 32 source screens.  I modified REFILL to check a newly  
> added user variable called BLK.  If BLK is -1, REFILL uses the  
> console for input.  If BLK is not -1, REFILL uses a newly added word,  
> ACCEPT_BUFFER, to take characters from a selected source screen.  I  
> select a screen to compile/interpret from using a newly added word,  
> LOAD.

Would it help to include a modified version of refill that checks
blk and calls a deferred word if blk is not -1? I dont want to
include block support into the core system but modifiying core
words is bad anyways. I'd prefer a simple refill that can be
extended to whatever is needed without changing the sources in
core/*


> 
> The editor right now is very crude.  It does little more than clear,  
> load, copy, or list screens, list a directory of screens (line 0 of  
> each screen), and let me add text, one line at a time, to a screen.   
> But it's a start, and it is so nice not having to sit through the  
> glacial serial download!

Is loading a screen really faster than communicating over the
serial line? I'd expect that the flash write is the main speed
limiting factor.. I'm just curious.

Matthias

[Amforth-devel] Reference Card

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

hi all,

I recently spent some time on updating the documentation
headers in many assembly files. The result is a pdf file
on the project home page 

http://amforth.sourceforge.net/refcard.pdf

please let me know if its worth the work or if I
should better drop it. It larger than expected (13 pages)
but I hope its not completly useless. Its not meant as
an replacement of the standard docs, but the contents may
be used for an "online" help as well.

Matthias

[Amforth-devel] Editor and screens now working

[Karl L. <kar...@se...>]

I now have a (very crude) screen-based editor working on my  
ATmega328P target.  I added support for a Microchip 25LC512 serial  
EEPROM, which not only lets me back up an image of my system, but  
also supports 32 source screens.  I modified REFILL to check a newly  
added user variable called BLK.  If BLK is -1, REFILL uses the  
console for input.  If BLK is not -1, REFILL uses a newly added word,  
ACCEPT_BUFFER, to take characters from a selected source screen.  I  
select a screen to compile/interpret from using a newly added word,  
LOAD.

The editor right now is very crude.  It does little more than clear,  
load, copy, or list screens, list a directory of screens (line 0 of  
each screen), and let me add text, one line at a time, to a screen.   
But it's a start, and it is so nice not having to sit through the  
glacial serial download!

Karl

Re: [Amforth-devel] amforth application development cycle

[Christian K. <ck...@pe...>]

Hi pito et al.,

thanks for all your suggestions. After a weekend with amforth this
turns out to be a minor issue that now comes naturally.

The marker hint proved valuable as well as the upload script. I had
to modify it to use the python serial lib to make it work on OpenBSD
though.

Thanks for all your help!

Christian

Re: [Amforth-devel] Editing command line - backspace issue

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

There are terminals sending 0x7f (delete) instead of 0x08
(backaspace) when backspace key is hit. Maybe 'accept' could be
modified by Matthias to process 0x7f as well. P.

[Amforth-devel] Editing command line - backspace issue

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

Hi, when I edit the line (as usual from amforth's prompt on very
left to the right ) and I need to backspace (to move left while
deleting the chars), the backspace does not move back continuosly -
only 'jumps' one char back to left, leaves there one space and then
moves back one to right on the previous place. It does this jumping
on the 'same place' for 10 to 20 times of 'backspacing' and then
suddenly moves as expected to the left deleting the chars. When then
I continue in writing and, after a while, I am trying to backspace
again, the above scenario repeats. What could be the reason? P.

Re: [Amforth-devel] amforth application development cycle

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

Hi Christian, I am using XP:
1. my editor is PN (programmers notepad)
2. terminal is Mosaic Terminal (tuned for forth, drag and drop
capab., promt history)
3. editing in PN and draging files directly into MT, always "marker
-BLABLA" at the beginning of any forth code I do
4. when not happy do -BLABLA and you delete all the stuff you did
recently
5. When happy with my words I upload all final words I may need (my
"system setup", basically I have everything interesting from amforth
repository there as I have 128KB flash) and then I DOWNLOAD (via
avrdude) the whole image from atmega into a file called my.hex and
my.eep (currently ~20k, it takes ~30sek)
6. when a crash occures I burn back my.hex and my.eep only, it takes
40sec and I am fully back with everything I need.
7. So an incremental approach with periodic downloads of the atmega
flash and eeprom (!)images into a backup file. The way of flashing
the forth core and then upload of all the forth libs and then all my
own words via terminal is simply too langweilig for me. Pito

Re: [Amforth-devel] amforth application development cycle

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

Hi Christian,

On 10/21/2010 04:54 PM, Christian Kellermann wrote:
> Dear amforth'ers,
>
> During my playtime with amforth I always wonder how to develop
> longer dictionaries with the device.
>
> What I am doing now is:
>
> - try out wording at the amforth prompt.
> - transfer changes to a dictionary file.
> - flash the device with the standard image.
> - use a little program to insert my project's dictionary.
>
> I am wondering whether there is a more clever way to do it, especially
> the reflashing step annoys me (controller needs to be in place etc).
>
> How do you do it?

I'm trying out new words at the prompt (working with minicom).
Then I simultaneously write the working code into a file.
When I think, the current state has progressed to a useful point
again, then I remove the dictionary back to the first marker
and upload everything again. That takes 5 minutes if I load
my full featured data collector stuff. Time for a break.

I have to reflash amforth occasionally, takes a minute.

My brain is slow enough in the evening, so I'm not annoyed much
during uploading times. %->

And like Matthias, I have "production boards" which are updated
only after adding a new feature. And I have devel boards, one
is running 24h/day, so I see rare failures, too. Like currently
there seem to be destroyed bytes on the rs485 connection, like
once in 2 days.


Cheers,
Erich

Re: [Amforth-devel] '328p + 25LC512

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

Hi Karl,

its really difficult to communicate with you. I sent a lot of
emails recently, no-one seem to reach you...

> I can make the .asm files available if anyone is interested...


I am. 

And if you could please re-send your user guide to me again,
I've got only old versions from 2007 (at least 3times via 
different channels).

Matthias

Re: [Amforth-devel] amforth application development cycle

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

Hi,

First: I do development on my desk, not in the forest
or beneth the roof. Whenever I'm satisfied with a new
version, I copy the flash/eeprom content from the
working controller to hex files (avrdude can do reads 
as well as writes) and transfer those files to the final 
target systems (one by one, just in case).

> - try out wording at the amforth prompt.

This and with the help of marker which can reset the
controller state. 

> - transfer changes to a dictionary file.

I do my terminal work with minicom (a linux
application), it saves everything to a logfile, which
can be edited afterwards. For smaller test cases even 
a cut/paste from the terminal window to the editor 
window works well (X11 is much better then Windows ;=) )

Finally all code go into a code repository which tracks
any changes (subversion and recently git).

I do use the appl/... directories, the published
files are a small subset of my internal file system,
stripped down for simplicity. core/ is almost identical, 
lib/ as well.

Whenever I need some library code, I use the python scripts
for uploading them and do a backup to hexfiles afterwards.
These hex files can be used to re-flash the customized
setup easily. But marker does basically the same is is 
faster.

> - flash the device with the standard image.

as mentioned above: marker does its job (well, most of
the time). Therefore I reflash the controller only if
I make changes to the core system. Currently I'm playing
more with the core system and this leads to frequent re-flashing
of the controllers. With a proper programmer this is done
within a minute, or faster. Uploading the libs afterwards
takes more time. (the hayes test for core needs approx 400 
seconds to complete, a good coffee break).

Whenever I work on applications, the amforth core is almost never
re-flashed. Maybe, I circumvent all pitfalls..

HTH
Matthias

Re: [Amforth-devel] amforth application development cycle

[Karl L. <kar...@se...>]

I can't speak for all of the amforth'ers, but I can tell you what I do.

I have a set of words (in assembler) that support the Microchip  
25LC512 serial EEPROM.  These words allow me to save and restore a  
full system image on my ATmega328P.  By "full system image" I mean  
flash from 0 to dp and EEPROM from 0 to edp.

I have modified my amforth file to detect a low state on a given I/O  
pin at reset.  If the pin is low, the amforth startup code refreshes  
flash and EEPROM from the serial EEPROM, then performs a normal startup.

It takes about three seconds to do a system save and about 0.5  
seconds to do a restore on reset.  Makes life a lot easier during  
development.

However, this does not answer one of your implied questions.  I still  
have to download my programs under development using the serial  
port.  There is enough leftover serial EEPROM to hold at least 32  
Forth screens, but I have not been able to hook the serial EEPROM  
contents into the Forth interpreter.  Key words, such as LOAD and BLK  
are missing, which means the interpreter cannot switch between  
interpreting from TIB and interpreting from a buffer.

If these changes are made, I would be able to develop on the target.   
Until then, it's the old-fashioned way.  I'm looking into how best to  
make the needed changes, but guidance from the amforth community  
would be most welcome.

Karl


On Oct 21, 2010, at 7:54 AM, Christian Kellermann wrote:

> Dear amforth'ers,
>
> During my playtime with amforth I always wonder how to develop
> longer dictionaries with the device.
>
> What I am doing now is:
>
> - try out wording at the amforth prompt.
> - transfer changes to a dictionary file.
> - flash the device with the standard image.
> - use a little program to insert my project's dictionary.
>
> I am wondering whether there is a more clever way to do it, especially
> the reflashing step annoys me (controller needs to be in place etc).
>
> How do you do it?
>
> Kind regards,
>
> Christian
>
> ---------------------------------------------------------------------- 
> --------
> Nokia and AT&T present the 2010 Calling All Innovators-North  
> America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and  
> Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in  
> marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi  
> Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth-devel] amforth application development cycle

[Christian K. <ck...@pe...>]

Dear amforth'ers,

During my playtime with amforth I always wonder how to develop
longer dictionaries with the device.

What I am doing now is:

- try out wording at the amforth prompt.
- transfer changes to a dictionary file.
- flash the device with the standard image.
- use a little program to insert my project's dictionary.

I am wondering whether there is a more clever way to do it, especially
the reflashing step annoys me (controller needs to be in place etc).

How do you do it?

Kind regards,

Christian

Re: [Amforth-devel] '328p + 25LC512

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

Hi Karl, great news! Of course the code would be welcomed!
> The save_system word copies the full image,
> including the contents of  
> EEPROM, to flash.
Q: it saves full flash image. Is there any crc or xor sum validating
the image integrity ?
Q: is there a mechanism for checking the actual flash content
against to that stored in ext. eeprom?
Q: did you think to use the fast spi at45dbxxx 8pin flash for
storing images (I'am still looking for a ready forth driver for
those chips..)?
Q: for large chips (128,256) maybe the saving the "actual flash
used" instead of "full flash image" would be interesting as well.
Pito.

[Amforth-devel] '328p + 25LC512

[Karl L. <kar...@se...>]

I now have a two-chip system (ATmega328P + 25LC512 serial EEPROM)  
that lets me save a working amforth image to serial EEPROM and  
selectively restore that system to flash on reset.  This makes a huge  
difference in development, since I was forever lancing the kernel and  
having to drag out the AVR programming dongle.  Now, I just hold down  
the LOAD button on my target, hit reset, and the system is restored  
to the previous save.

The save_system word copies the full image, including the contents of  
EEPROM, to flash.  So I can extend the dictionary as much as I want;  
the restored system works just like it did immediately prior to the  
save.  (Warning: This hasn't been extensively tested, but I'm pretty  
sure it works.  :-) )

I've created a set of .asm files that support this system.  The  
serial EEPROM words are compiled into the kernel at build-time and I  
had to make some changes to the amforth.asm file, so the final image  
needs at least a '328p to hold the larger bootloader code.  Total  
size, including EEPROM data, is slightly over 11 KB.

I can make the .asm files available if anyone is interested...

Karl

Re: [Amforth-devel] 2constant, 2variable, 2!, 2@, 2drop, 2dup and (2variable) words

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

Hi Marcin,
I included the asm vesrsion in my compilation, but it seems
2constant does not create a word. Can you double check this lib,
please? Thanks, Pito.

Re: [Amforth-devel] amforth user's manual

[Karl L. <kar...@se...>]

Yes, Al, I did N&V for quite a while; great fun.  And I saw your DDJ  
blog regarding amforth and remember wondering where I had seen that  
name before.  Must have been some of your N&V articles.

The updated document is ready to go.  I'm just trying to figure out  
the best way to get it reviewed by others in the dev team and then  
into the distro.  It seems that many on the dev team live on the  
other side of the Pond, and the time delta makes simple things take  
forever.  Maybe I should move to Germany...

Karl

On Oct 12, 2010, at 6:33 AM, Al Williams wrote:

> Say Karl are you the former N&V columnist? I used to do a little  
> for them
> although I've been associated more with DDJ over the years (and  
> still am
> http://www.ddj.com/embedded).
>
> Enjoyed your first document on this and looking forward to seeing  
> the 2nd one.
>
> Al Williams
>
>
> On Tuesday, October 12, 2010 07:47:24 am Karl Lunt wrote:
>> Like the original, this is an OpenOffice document; this doc was
>> written with OO v3.1.1.
>>
>> I updated the sections that describe the main files in an amforth
>> disbro.  However, I need someone to fill in some details regarding
>> the files that are generated by Python and the Python tool itself.  I
>> have left spots in the document (highlighted in yellow) for someone
>> to provide details.
>>
>> Should I simply attach this document to an email to the list?  Since
>> this is a dev document, it seems like it should be OK for everyone on
>> the dev list to see/edit it...
>>
>> Karl
>>
>> On Oct 12, 2010, at 1:49 AM, Marcin Cieslak wrote:
>>>>> Karl Lunt <kar...@se...> wrote:
>>>> I have tried without success to contact Matthias regarding a new
>>>> amforth user's manual that I have completed.  This document is a
>>>> complete rewrite, up to date with amforth v4.2, and includes a full
>>>> working amforth design.  I would like to pass this along to  
>>>> Matthias,
>>>> or at least to someone else on the list, for inclusion in the  
>>>> amforth
>>>> distro.  Can anyone help me in this effort?
>>>
>>> What format it is? XML, LaTeX?
>>>
>>> //Marcin
>>>
>>>
>>> -------------------------------------------------------------------- 
>>> --
>>> --------
>>> Beautiful is writing same markup. Internet Explorer 9 supports
>>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>>> Spend less time writing and  rewriting code and more time creating
>>> great
>>> experiences on the web. Be a part of the beta today.
>>> http://p.sf.net/sfu/beautyoftheweb
>>> _______________________________________________
>>> Amforth-devel mailing list
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>> --------------------------------------------------------------------- 
>> ------
>> --- Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating  
>> great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> Amforth-devel mailing list
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
> ---------------------------------------------------------------------- 
> --------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating  
> great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth user's manual

[Al W. <al....@aw...>]

Say Karl are you the former N&V columnist? I used to do a little for them 
although I've been associated more with DDJ over the years (and still am 
http://www.ddj.com/embedded).

Enjoyed your first document on this and looking forward to seeing the 2nd one.

Al Williams


On Tuesday, October 12, 2010 07:47:24 am Karl Lunt wrote:
> Like the original, this is an OpenOffice document; this doc was
> written with OO v3.1.1.
> 
> I updated the sections that describe the main files in an amforth
> disbro.  However, I need someone to fill in some details regarding
> the files that are generated by Python and the Python tool itself.  I
> have left spots in the document (highlighted in yellow) for someone
> to provide details.
> 
> Should I simply attach this document to an email to the list?  Since
> this is a dev document, it seems like it should be OK for everyone on
> the dev list to see/edit it...
> 
> Karl
> 
> On Oct 12, 2010, at 1:49 AM, Marcin Cieslak wrote:
> >>> Karl Lunt <kar...@se...> wrote:
> >> I have tried without success to contact Matthias regarding a new
> >> amforth user's manual that I have completed.  This document is a
> >> complete rewrite, up to date with amforth v4.2, and includes a full
> >> working amforth design.  I would like to pass this along to Matthias,
> >> or at least to someone else on the list, for inclusion in the amforth
> >> distro.  Can anyone help me in this effort?
> > 
> > What format it is? XML, LaTeX?
> > 
> > //Marcin
> > 
> > 
> > ----------------------------------------------------------------------
> > --------
> > Beautiful is writing same markup. Internet Explorer 9 supports
> > standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> > Spend less time writing and  rewriting code and more time creating
> > great
> > experiences on the web. Be a part of the beta today.
> > http://p.sf.net/sfu/beautyoftheweb
> > _______________________________________________
> > Amforth-devel mailing list
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> ---------------------------------------------------------------------------
> --- Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth user's manual

[Karl L. <kar...@se...>]

Like the original, this is an OpenOffice document; this doc was  
written with OO v3.1.1.

I updated the sections that describe the main files in an amforth  
disbro.  However, I need someone to fill in some details regarding  
the files that are generated by Python and the Python tool itself.  I  
have left spots in the document (highlighted in yellow) for someone  
to provide details.

Should I simply attach this document to an email to the list?  Since  
this is a dev document, it seems like it should be OK for everyone on  
the dev list to see/edit it...

Karl

On Oct 12, 2010, at 1:49 AM, Marcin Cieslak wrote:

>>> Karl Lunt <kar...@se...> wrote:
>> I have tried without success to contact Matthias regarding a new
>> amforth user's manual that I have completed.  This document is a
>> complete rewrite, up to date with amforth v4.2, and includes a full
>> working amforth design.  I would like to pass this along to Matthias,
>> or at least to someone else on the list, for inclusion in the amforth
>> distro.  Can anyone help me in this effort?
>
> What format it is? XML, LaTeX?
>
> //Marcin
>
>
> ---------------------------------------------------------------------- 
> --------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating  
> great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] amforth user's manual

[Marcin C. <sa...@sa...>]

>> Karl Lunt <kar...@se...> wrote:
> I have tried without success to contact Matthias regarding a new  
> amforth user's manual that I have completed.  This document is a  
> complete rewrite, up to date with amforth v4.2, and includes a full  
> working amforth design.  I would like to pass this along to Matthias,  
> or at least to someone else on the list, for inclusion in the amforth  
> distro.  Can anyone help me in this effort?

What format it is? XML, LaTeX?

//Marcin

[Amforth-devel] amforth user's manual

[Karl L. <kar...@se...>]

I have tried without success to contact Matthias regarding a new  
amforth user's manual that I have completed.  This document is a  
complete rewrite, up to date with amforth v4.2, and includes a full  
working amforth design.  I would like to pass this along to Matthias,  
or at least to someone else on the list, for inclusion in the amforth  
distro.  Can anyone help me in this effort?

Karl Lunt

[Amforth-devel] evaluate

[Kalus M. <mic...@on...>]

Hi.

Is there an evaluate for amforth?

Michael 

Re: [Amforth-devel] ATXmega - a practical experience

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

a pity. there is a nice gadget called Xplain (25bugs, atxmega128a1,
8MB SRAM, 8MB flash), maybe we will try with pforth then..P.