amforth-devel — Development discussion and user support

[Amforth] Bootloader + AmForth

[Tristan W. <ho...@tj...>]

Is it possible to build the current AVR AmForth so that it can
co-exist with a bootloader?

There is a reference in the documentation to changes that would be
required 

http://amforth.sourceforge.net/TG/AVR8.html?highlight=bootloader

and some older discussions in the mailing list 

https://sourceforge.net/p/amforth/mailman/message/32235234/

but nothing since. I was wondering whether this might be a way to use
AmForth with the ATmega32u4 and USB.

Tristan 

Re: [Amforth] avr8

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

Hello Brian,

thanks for your message!

> ... to the arm based systems where the  'real' work can be
> done.
Well observed imho. I read a book on PIC microcontrollers many
years back, where the authors made a case that if need be,
counted loops (in asm, no matter which way through the if
statements the code executes, it will always take exactly the
same time) are your tool to make the 8 bitter
- sing a song
- dim a 50/60 Hz lamp
- do one more job i forgot by now
- all at the same time and organize these three jobs well.

Eye opening and jaw droping at the same time. It has made a
lasting impression on me.


> So I ask that you don't eliminate the ability
> to build from source, even if it means using wine and the atmel
> (micochip) assembeler.

Rest assured. First of all *I* want to build from source any
time, because I still play with stuff written in assembly. And I
don't want this project to die, just because I happen to use it
myself! Who would have thought :-)

And most importantly: this is GPL software. The source ist the
fundamental representation of the whole project. It always must
be possible to build from source. I'm just a whee bit uneasy
that this fine project depends on non-free components for this
very step. And I had good discussions with Matthias about this.
There is just no /easy/ way out, I'm afraid.

But: lurking folks on the list resorted to writing emails!
Even sending patches! Definitely progress around here.
Thank you!

Cheers,
Erich


-- 
May the Forth be with you ...

Re: [Amforth] avr8

[Tristan W. <ho...@tj...>]

Hello Brian,

My suggestion was just that the prebuilt AVR hex files in the
distribution should include more assembler words as standard. 

Being able to build from source means being able to do things that
might otherwise prove impossible. Not something I would want to
change. 

Best wishes,
Tristan

On 06Jul20 10:08, Brian wrote:
> Sending this again
> 
> Hello,
> 
> I'm an avr8 user and love amforth. This is the best system for an eight bit
> micro that lets you have interactive use of the chip. Things like circuit
> python and ulisp are cool but so resource intensive or tied to the arduino
> ecosystem that they become fun toy environments (on the 8 bit platforms)
> meant to move you on to the arm based systems where the 'real' work can be
> done. So I ask that you don't eliminate the ability to build from source,
> even if it means using wine and the atmel (micochip) assembeler. These tools
> allowed me to build and run the current amforth on the avrbutterfly. I think
> this is a great project. I would love to help, especially in the
> documentation. I'll keep my eyes open to how to submit patches. Thanks for
> everything.
> 
> brian-in-ohio
> 
> On 7/1/20 2:17 AM, Tristan Williams wrote:
> Hello,
> 
> > Who of you is using which target controller?
> I use AVR atmega328p, atmega1284p, atmega2560
> 
> > Can we get rid of the Atmel/Microchip Avrasm Assembler?
> Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
> that would be a lot of work and wine does run it very well.
> 
> Having "fuller" hex files in the distribution that have assembly words
> like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
> delay the need to build AmForth. AVR flash and ram are not the limited
> resource they once were. It might be worth updating the documentation
> to say which hex files are available.
> 
> > Would it be feasible to drop msp430, arm, risc-v in order to simplify
> > the whole thing? yes/no?
> I think that depends on the collective response to the first question.
> 
> > amforth-shell.py and python3
> amforth-shell.py is a great tool for AmForth. I have modified it to
> run under python3 and it works well for me. I will put up a patch but
> it really needs testing in a python os/environment other than mine.
> 
> > ticket system or mailing list ?
> I would prefer a mailing list.
> 
> Thank you Erich for AmForth Weekend #1 - I look forward to #2
> 
> Best wishes,
> Tristan
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] avr8

[Brian <bkn...@gm...>]

Sending this again

Hello,

I'm an avr8 user and love amforth. This is the best system for an eight 
bit micro that lets you have interactive use of the chip. Things like 
circuit python and ulisp are cool but so resource intensive or tied to 
the arduino ecosystem that they become fun toy environments (on the 8 
bit platforms) meant to move you on to the arm based systems where the 
'real' work can be done. So I ask that you don't eliminate the ability 
to build from source, even if it means using wine and the atmel 
(micochip) assembeler. These tools allowed me to build and run the 
current amforth on the avrbutterfly. I think this is a great project. I 
would love to help, especially in the documentation. I'll keep my eyes 
open to how to submit patches. Thanks for everything.

brian-in-ohio

On 7/1/20 2:17 AM, Tristan Williams wrote:
Hello,

> Who of you is using which target controller?
I use AVR atmega328p, atmega1284p, atmega2560

> Can we get rid of the Atmel/Microchip Avrasm Assembler?
Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
that would be a lot of work and wine does run it very well.

Having "fuller" hex files in the distribution that have assembly words
like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
delay the need to build AmForth. AVR flash and ram are not the limited
resource they once were. It might be worth updating the documentation
to say which hex files are available.

> Would it be feasible to drop msp430, arm, risc-v in order to simplify
> the whole thing? yes/no?
I think that depends on the collective response to the first question.

> amforth-shell.py and python3
amforth-shell.py is a great tool for AmForth. I have modified it to
run under python3 and it works well for me. I will put up a patch but
it really needs testing in a python os/environment other than mine.

> ticket system or mailing list ?
I would prefer a mailing list.

Thank you Erich for AmForth Weekend #1 - I look forward to #2

Best wishes,
Tristan

Re: [Amforth] amforth-shell.py and python3

[Mark R. <cab...@gm...>]

Super. I just patched my local repo. All I had to do was to add the
python3-serial package (debian buster) and change the defaults for the
serial port and it fired right up. I'll try it next time I'm passing files
around to see how things go here.

Thank you,
Mark

On Mon, Jul 6, 2020 at 12:53 PM Tristan Williams <ho...@tj...> wrote:

> Hello,
>
> I have modified amforth-shell.py to run under python3 and put up a
> patch here
>
> https://tjnw.co.uk/new-shell/doc/
>
> as the patch seemed a little too large for a mailing list.
>
> Best wishes,
> Tristan
>
>
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] amforth-shell.py and python3

[Tristan W. <ho...@tj...>]

Hello,

I have modified amforth-shell.py to run under python3 and put up a
patch here

https://tjnw.co.uk/new-shell/doc/

as the patch seemed a little too large for a mailing list.

Best wishes,
Tristan

Re: [Amforth] Reference Card page now missing

[Mark R. <cab...@gm...>]

Okay, I got a little bit of a chance to play with this tonight. I wanted to
hack out the $prevline variables and forcibly replace them with the actual
beginning lines from the file. This then shows all the asm files in
common/words that have issues that need to be dealt with. It's at best a
hack before really fixing the script, but I wanted to see if that was how
those prevlines were working. I'll attach the hacked up make-refcard-rst
below. Once it is in place it can be run after which building the htdocs
with make htdocs will create the new refcard.html file. As you can see
there are a number of errors. Looking at the common/asm files shows them to
be ones with non-conformant comment lines at the top. The files with the 3
comment lines at the top, even if they have the ".if cpu_" stuff in them
now generate correctly though. I'll try to make more progress during the
week, but bear in mind that I've never looked at a Perl script before a day
or two ago. :P

make-refcard-rst ================================================== START

#!/usr/bin/perl
use strict;

# local hashes
my %XT;
my %VOC;
my %ASM;
my %USEDBY;
my %DESCRIPTION;
my %DSTACK;
my %RSTACK;
my %CSTACK;
my %CATEGORY;
my %TYPEOF;

# current version. There should be a version variable
# stored somewhere in the source tree that could be pulled
# by any of the build tools. TODO.
my $version="6.9";

# relative location of refcard.rst output file for building
my $texdir="../doc/source/TG";

# location of the core words
# currently the core .asm files are parsed incorrectly
# due to adding various platforms. The platform ones work.
# TODO: add platform specific output to refcard.
#my $asmdir="../avr8/words";
my $asmdir="../common/words";

sub readASM {
    my ($filename) = @_;
    open(ASM, $filename) or die ("$filename: $!\n");
    my @ASM = <ASM>;
    close(ASM);
    my $ASM = "";
    my ($lbl, $state, $voc, $xt, $dstack, $rstack, $cstack, $category,
$typeof);
    my ($prevline1, $prevline2, $prevline3, $description) = ("","","", "");

    # Added to try and remove the prevline issues
    # before fixing correctly.
    my $line1 = $ASM[0];
    my $line2 = $ASM[1];
    my $line3 = $ASM[2];

    # From this point on all prevline vars are now:
    # prevline3 is now $line1
    # prevline2 is now $line2
    # prevline1 is now $line3

    foreach my $line (@ASM) {
chomp($line);
#
next if $line=~/\.if/;
$line =~ s/_VE_HEAD/VE_HEAD/;
$ASM .= $line;
if($line=~/^VE_(.*):/) {
   # start a new definition
   $ASM = "";
   $lbl = "XT_$1";
   $state = "new_header_found";
   $voc   = "(unnamed)";
   $category = "unclassified";
   $dstack = "( -- )";
   $dstack = "($1)" if $line1=~/\([S]?:?([^\)]+)/;
   $rstack = "";
   $rstack = "(R: $1)" if $line1=~/R:\s+([^)]+)\)/;
   $cstack = "";
   $cstack = "(C: $1)" if $line1=~/C:\s+([^)]+)\)/;
            $description = $1 if $line3=~/^;(.*)/;
   if( $line2=~/;(.+)$/) {
       $category = $1;
   }
#    print "***\n$prevline3\n$prevline2\n$prevline1\n$line\n***\n";
#    print "$prevline3 : $category\n";
#    die;
   next;
}
if($line=~/^;VE_(.*):/) {
   # start a new definition
   $ASM = "";
   $lbl = "XT_$1";
   $state = "new_header_found";
   $voc   = "(hidden)";
   $dstack = $line1;
   $dstack = "( -- )";
   $dstack = "($1)" if $line1=~/\([S]?:?([^\)]+)/;
   $rstack = "";
   $rstack = "R($1)" if $line1=~/R:\s+(.+)\)/;
   $cstack = "";
   $cstack = "(C: $1)" if $line1=~/C:\s+(.+)\)/;
            $description = $1 if $line3=~/^;(.*)/;
   if( $line2=~/;(.+)$/) {
       $category = $1;
   }
   $category = "internal/hidden";
   next;
}
if($state =~ /new_header_found/ && $line=~/.dw\s*(.*)/) {
   $state = "new_voc_header";
   next;
}
if ($state =~ /new_voc_header/ && $line=~/.db\s*(.*)/) {
   my @voc = split/,/, $1;
   my $i=0;
   $voc = "";
   foreach my $v (@voc) {
# next if $i++ == 0;
print "[$v]";
$voc .= chr(hex($1)) if $v=~/\$([\da-fA-F]+)/;
$voc .= $1 if $v=~/"(\S+)"/;
   }
   $state = "vocabulary entry found";
   next;
}
if($line=~/^XT_(.*)/){
   $state = "xt_found";
   next;
}
if($state=~/xt_found/ && $line=~/.dw\s+(\w+)/) {
   $xt = $1;
   $state = "header_complete";
   next;
}
if($state =~ /header_complete/) {
   $DSTACK{$lbl} = $dstack;
   $RSTACK{$lbl} = $rstack;
   $CSTACK{$lbl} = $cstack;

   $XT{$lbl} = $xt;
   $VOC{$lbl} = $voc;
            $DESCRIPTION{$lbl} = $description;
   push @{$CATEGORY{$category}}, $lbl;
   $state = "parsing_body";
   next;
}
        $prevline3 = $prevline2;
        $prevline2 = $prevline1;
        $prevline1 = $line;

if($state =~ /parsing_body/) {
   $ASM{$lbl} = $ASM if $ASM=~/\w/;
}
    }
}

sub _head {
    my ($title) = @_;
    my ($r);
    open(I, "refcard-head.rst") or die "refcard header not found";
    while(<I>) {
      s/\*VERSION\*/$version/g;
      $r .= $_
    }
    close(I);
    return $r;
}

sub _foot {
}

sub printLaTeX {
    my ($title) = @_;
    open(LATEX, ">$texdir/refcard.rst") or die "$!\n";;
    print LATEX _head($title);
    foreach my $category (sort keys %CATEGORY) {
    next if $category=~/^\s*$/;
    next if $category=~/internal/;

print "$category\n";
my $cattxt = $category;
$cattxt =~s/\s+(.*)/$1/;
print LATEX "\n$cattxt\n". "-" x length($cattxt) . "\n\n";
foreach my $lbl (sort @{$CATEGORY{$category}}) {
   my $xt  = $XT{$lbl};
   my $voc = $VOC{$lbl};
   my $shortlbl = substr($lbl, 3);
   my $descr = $DESCRIPTION{$lbl};

   my $dstack = $DSTACK{$lbl};
   my $rstack = $RSTACK{$lbl};
   my $cstack = $CSTACK{$lbl};
   my $verbdelim = "|";
   $verbdelim = "/" if $dstack=~/$verbdelim/;
   # print LATEX ".. _ $lbl:\n";
   #$voc =~ s/\\/\\textbackslash/g;
   #$voc =~ s/\#/\\#/g;
   # $voc =~ s/]/{]}/g;
   ##voc =~ s/\[/{[}/g;
   $voc =~ s/\$/\\\$/g;
   #$voc =~ s/_/\\_/g;
   $voc =~ s/"/''/g; # '"
   #$voc =~ s/\+/\\\+/g;
   #$voc =~ s/-/\\-/g;
   #$voc =~ s/\*/\\\*/g;
   $voc =~ s/\\/\\\\/g;
   #$descr =~ s/_/\\_/g;
   print LATEX "* :command:`$voc`\n";
   print LATEX "  $dstack\n";
   print LATEX "  $rstack\n" unless $rstack =~ /^\s*$/;
   print LATEX "  $cstack\n" unless $cstack =~ /^\s*$/;
   print LATEX " $descr\n\n";

 }
print LATEX "\n\n";
    }
    print LATEX _foot();
}

opendir(CWD, $asmdir);
foreach (reverse sort readdir(CWD)) {
        next unless -f "$asmdir/$_";
        next unless /(.*).asm$/;
        my $basename = "$asmdir/$_";
        print "$basename\n";
        readASM($basename);
}
print "\n";
printLaTeX($version);
print "\n";

make-refcard-rst ================================================== FINISH

While it may be a butchery at the moment, I think it does show a way
forward. Stripping out all the excess dancing in readASM should make it
easier to add additional directories to scan then figure out how to
display. In all fairness, if there were multiple refcards, one for the core
and one for any platforms, a user would only need to look at the two they
cared about. In that case, they whole thing could be done without smashing
everything together and making the refcard gigantic. Just something to
think about.

All the best,
Mark

Re: [Amforth] Reference Card page now missing

[Mark R. <cab...@gm...>]

Actually not really impressive, yet at least. Mostly I just changed the
locations for:

my $texdir="../doc/source/TG";
#my $asmdir="../avr8/words";
my $asmdir="../common/words";

so they pointed at the right place to be built. Then I yanked some old asm
files from release/5.1 to find out why the new ones were failing. Had I
tried the avr8 ones first I could have skipped that step. Pretty much from
that point I just put one file that worked and one that didn't next to each
other in common/words (the existing 2swap.asm and the old one of the same
name but with a "2" added to the end of the filename and inside the file).
Then I'd fire off make-refcard-rst and make htdocs from their respective
locations. Examine output, look up Perl term, lather rinse repeat. If I
manage to make some actual progress with the Perl file I'll post it here.


> I'm still fairly fluent in perl, so I expect this can be fixed
> to produce a refcard again. And yes I also expect to fix up the
> source .asm files. Regarding those headers: IFF the files were
> indeed generated from forth code, then I would like to include
> said forth code in the comment section, and add a line, how it
> was generated (I think this is a must for generated files
> anyhow).
>

This bit is what I was really looking for advice on. After playing around
with g4 a bit to find out how to include my own files in the hex build I
realized that the asm files in common/words and avr8/words look very
similar to g4's output. Maybe they were just generated from AmForth's
compiler? In any case, if they are end-of -he-road files and not something
repeatedly regenerated, fixing them to be compliant to whatever they should
be would be easy enough.  The format that the avr8 ones use was what the
older versions had as well. That is to say, Three comment lines in order at
the top. Then whatever else will be added as far as comments go, finally
followed by the actual code. This is what I'm spelunking in the script for.
It most certainly needs to be much more robust. I'll almost certainly need
a hand to do multiple directories though.

So the takeaway would be to define a format of the first 3 lines having to
be how they are, or some other way to tag the stack--effect, category,
description and processor flavor. The first way is easier and the first 3
lines could just be jammed into what is now this clever, but touchy setup.

        $prevline3 = $prevline2;
>         $prevline2 = $prevline1;
>         $prevline1 = $line;


That is why everything is broken.  It almost seems if the idea was to be
able to have the 4 lines of comment, comment, comment, VE_NAME: be able to
be placed anywhere. Almost everything in the readASM subroutine keys off of
those. The only thing that does any other work is finding the actual name
from the .db "name",0 line, making sure everything closes, then shoving the
whole mess into a hash to be dealt with. At least I think that is what is
going on.

The decision to make is what should the header of the asm file have in it
and make them all conform. Like I said, I'll keep at it this week and post
here if I have anything helpful to add. As far as putting all the Forth
code in comments of the asm file, I don't know. Wouldn't it be better to
just have a forth source file somewhere in the tree? The asm files are nice
and tight and easy to read. If there is a bunch of extra info in there it
could make it messier to look through. I'm thinking more like when you have
a .c file and an .o file next to each other. They don't hurt each other but
since one can be generated from the other it would be easy enough to
automate the whole thing if there was a newer assembler and you wanted to
regenerate all of the asm files. Come to think of it, I guess that is where
the windows exe comes in to play.

In any case, define the header for the asm and I'll help out wherever (or
whenever) I can and have the time.

Mark

Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)

[Ian J. <ij...@sa...>]

Thanks for the thought stream Erich.

I have one other wacky idea for the list.  Maybe for next year when life in theory will settle or possibly over the 2020-2021 winter.  

I’d like to re-engineer a device called the CNC FROG.  It was originally a kind of 1.5 or 2.5 axis CNC gizmo but really it was just a flexible stepper motor controller and driver built into a single quite ingenious UI.  I think it sold for around $USD 150 with some bits of hardware for Sherline and Taig lathes.  You could do ordinary turning and threading with it.

As it turned out though what it was really good at was just driving random bits of machinery via stepper motor.  The UI (a generous term) was very clever and flexible so you could configure it to operate in any units you liked after a short setup period.  So you could advance a machine in thousands of an inch of hundredths of a millimeter or fractions of degrees or radians or anything else you could cook up.  This flexibility had it selling into light industry for operating turntables, indexers, etc.

There were and are lots of solutions for the very computer literate but this was for the illiterate.

The flavour of the FROG reminds me of forth somewhat.  Small, fast, flexible and a bit obscure.   A niche in other words.

The project would need a new hardware platform - probably an open source hobby platform with PCB’s and assembled gizmos with options and cases which would be fun but the key functionality would be the firmware.  Developing a small, simple, elegant UI I suspect would be very controversial and difficult.  There is something of a template in the original but much could be done to introduce more elegance.  

I’d try to fund the project so it would be a paying proposition for major participants.  

If you are interested in the FROG CNC it is hard to find now.  This might get you started.  http://www.cartertools.com/frog.html 



> On Jun 28, 2020, at 10:29 AM, Erich Wälde <ew....@na...> wrote:
> 
> - Whacky Ideas
> 
>  - git? -- With all the cool kids using git repositories, should
>    I attempt do convert the existing repositories, webpage, etc?
>    does sourceforge.net <http://sourceforge.net/> provide git repositories? Can the
>    existing svn repository be converted on the server side?
> 

sourceforge is OK but github seems easier to use to me.  The thing that occurs to me is perhaps in github we would get more exposure?  I’m so out of date.

>  - Should we use a ticket system rather than mailing list?
> 
>  - Who of you is using which target controller? Would it be
>    feasible to drop msp430, arm, risc-v in order to simplify the
>    whole thing? yes/no?

I’m Atmel but have not touched embedded really for a few years.  Life needs to settle down. Will it?  I don’t know. 

> 
>  - Can we get rid of the Atmel/Microchip Avrasm Assembler?
> 
>    One big difference between the avr8 and the risc-v tree is
>    the assembly language. avr8 is using Atmels assembly. Which
>    is good, because it is thoroughly documented. And which is
>    bad, because there is no working free/libre alternative to
>    avrasm.exe. Yes there is the "avra" project but it has been
>    abandoned long ago. I have been able to assemble AmForth with
>    avra way back in releases 4.2 up until maybe 4.9. I have even
>    contributed a small patch to make atmega644p working.
>    https://sourceforge.net/projects/avra/ <https://sourceforge.net/projects/avra/>
> 
>    Matthias has contemplated the idea to port AmForth/avr8 to
>    use gnu assembly. He might even have produced a working
>    branch, I don't know.
> 
>    For risc-v there is no avr assembly, naturally. That's where
>    all the .s assembly files come into the game.
> 
>    I personally would love to have a free/libre assembler for
>    avr assembly. AVRASM.EXE is the only thing that forces me to
>    install wine on my system.

I agree.  I’m sorry that the opensource AVR assembler has gone by the wayside also.  I used it in early days.  I’m somewhat surprised that it is in suspended animation given the popularity of Arduino as a platform.   I find virtualization a big complicated hammer to solve problems that could be resolved in a more elegant manner.  Simplification isn’t very popular today though.


Ian - lurking on.   

Re: [Amforth] Reference Card page now missing

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

Hello Mark,

short answer: I'm impressed!

I'm still fairly fluent in perl, so I expect this can be fixed
to produce a refcard again. And yes I also expect to fix up the
source .asm files. Regarding those headers: IFF the files were
indeed generated from forth code, then I would like to include
said forth code in the comment section, and add a line, how it
was generated (I think this is a must for generated files
anyhow).

So, if you would please be so kind as to send your changed
script along the mailing list, that would be grand!

Thank you very much for looking into this.
And then my secret plan also worked out: give the folks
something to chew on :-)))

Cheers,
Erich

Mark Roth writes:

> Hopefully this will get sent to the right place...
>
> I have been poking around the Perl script that creates the Refcard and
> managed to get it to spit out a new (well, not quite but...) refcard.rst
> which can then be build into the webpage when using make to create the
> htdocs. It works if I change the asm source directory to the avr8 one but
> not with the common/words. The problem is that the Perl regexes are so
> tightly bound with the file having 4 line in exactly the right place. It
> looks for the "VE_" + name + ":" line then uses the three prior lines to
> fill the name, stack effect and description. The files in the common/words
> don't have the same layout since they contain the ".if cpu_" etc lines to
> handle the msp430 and avr8 flavors.
>
> Now for the good news. It seems that every file in the common/words has a
> variant for both the msp430 and avr8. Any of those could just be
> tagged with a new hash called %TYPEOF or something to that effect. Then the
> avr8/words could be parsed since they have the same top 3 lines and be
> tagged for the avr8. As I mentioned, those already work just fine. I've
> created a new refcard.html for those. Now, the msp430 is a whole other bag
> of worms. The information that is being parsed is all mashed up in the
> first line and doesn't contain a section name.
>
> So, to start out with. The msp430 asm files could be fixed by hand to have
> the proper information in the top 3 lines, but only if they are not
> generated somehow that will undo the work. Perhaps whatever spits out those
> asm files could be convinced to put that info there? I have no idea. I know
> that with g4 I could easily convince it to place those 3 lines as needed
> just by putting them as comments in the file. It works quite nicely. So,
> since I don't know anything about the 430 stuff I'll leave that for now.
>
> The bigger issue is the way the asm files are searched to create the
> refcard. That could be fixed without too much of a problem I think. Well,
> apart from having to figure out the right place to add in for the new type
> thing. Perl is Perl. I didn't have any idea about how to read it before
> this and at least can now follow the internal logic. It reminds me of a
> project to find solutions from every permutation of some packing puzzles I
> made. I wrote one bash script that fed off another and another etc. It
> works, but I don't hardly dare breathe too hard on it. ;)
> This has the same feel. It works but only because it works. I can keep
> playing with it this week and try to make some progress on it. Perl is easy
> enough to pick up enough. However, if I spoke Python I'd probably just
> rewrite the whole mess and fix the comments in the common/words to conform
> with the rest of them. Most of it is just scut work with the addition of
> tagging the crossover words with their proper flavor.
>
> So, if anyone is still this far along. I can use the scripts to create the
> stuff to make the htdocs for the site and the epub file. I tried to do the
> pdf but after adding package after package after package of the texlive
> stuff I gave up and just wrote a new rule to create the epub but not the
> pdf. It shouldn't matter except I can't test the pdf output. I will gladly
> continue to pursue this as I do find Perl interesting enough to muck with.
> It's pretty amazing apart from the fact that it is like reading a book that
> is printed entirely in stereogram.
>
> That's that for now. It seems that AmForth Weekend 1 is still bearing fruit
> (such as it is).
>
> Mark
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...

Re: [Amforth] Reference Card page now missing

[Mark R. <cab...@gm...>]

Hopefully this will get sent to the right place...

I have been poking around the Perl script that creates the Refcard and
managed to get it to spit out a new (well, not quite but...) refcard.rst
which can then be build into the webpage when using make to create the
htdocs. It works if I change the asm source directory to the avr8 one but
not with the common/words. The problem is that the Perl regexes are so
tightly bound with the file having 4 line in exactly the right place. It
looks for the "VE_" + name + ":" line then uses the three prior lines to
fill the name, stack effect and description. The files in the common/words
don't have the same layout since they contain the ".if cpu_" etc lines to
handle the msp430 and avr8 flavors.

Now for the good news. It seems that every file in the common/words has a
variant for both the msp430 and avr8. Any of those could just be
tagged with a new hash called %TYPEOF or something to that effect. Then the
avr8/words could be parsed since they have the same top 3 lines and be
tagged for the avr8. As I mentioned, those already work just fine. I've
created a new refcard.html for those. Now, the msp430 is a whole other bag
of worms. The information that is being parsed is all mashed up in the
first line and doesn't contain a section name.

So, to start out with. The msp430 asm files could be fixed by hand to have
the proper information in the top 3 lines, but only if they are not
generated somehow that will undo the work. Perhaps whatever spits out those
asm files could be convinced to put that info there? I have no idea. I know
that with g4 I could easily convince it to place those 3 lines as needed
just by putting them as comments in the file. It works quite nicely. So,
since I don't know anything about the 430 stuff I'll leave that for now.

The bigger issue is the way the asm files are searched to create the
refcard. That could be fixed without too much of a problem I think. Well,
apart from having to figure out the right place to add in for the new type
thing. Perl is Perl. I didn't have any idea about how to read it before
this and at least can now follow the internal logic. It reminds me of a
project to find solutions from every permutation of some packing puzzles I
made. I wrote one bash script that fed off another and another etc. It
works, but I don't hardly dare breathe too hard on it. ;)
This has the same feel. It works but only because it works. I can keep
playing with it this week and try to make some progress on it. Perl is easy
enough to pick up enough. However, if I spoke Python I'd probably just
rewrite the whole mess and fix the comments in the common/words to conform
with the rest of them. Most of it is just scut work with the addition of
tagging the crossover words with their proper flavor.

So, if anyone is still this far along. I can use the scripts to create the
stuff to make the htdocs for the site and the epub file. I tried to do the
pdf but after adding package after package after package of the texlive
stuff I gave up and just wrote a new rule to create the epub but not the
pdf. It shouldn't matter except I can't test the pdf output. I will gladly
continue to pursue this as I do find Perl interesting enough to muck with.
It's pretty amazing apart from the fact that it is like reading a book that
is printed entirely in stereogram.

That's that for now. It seems that AmForth Weekend 1 is still bearing fruit
(such as it is).

Mark

Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)

[Tristan W. <ho...@tj...>]

Hello,

> Who of you is using which target controller?

I use AVR atmega328p, atmega1284p, atmega2560

> Can we get rid of the Atmel/Microchip Avrasm Assembler?

Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine
that would be a lot of work and wine does run it very well.

Having "fuller" hex files in the distribution that have assembly words
like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would
delay the need to build AmForth. AVR flash and ram are not the limited
resource they once were. It might be worth updating the documentation
to say which hex files are available.

> Would it be feasible to drop msp430, arm, risc-v in order to simplify
> the whole thing? yes/no?

I think that depends on the collective response to the first question.

> amforth-shell.py and python3

amforth-shell.py is a great tool for AmForth. I have modified it to
run under python3 and it works well for me. I will put up a patch but
it really needs testing in a python os/environment other than mine.

> ticket system or mailing list ?

I would prefer a mailing list. 

Thank you Erich for AmForth Weekend #1 - I look forward to #2

Best wishes,
Tristan

Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)

[Charley S. <csh...@su...>]

I only recently learned about amforth (I guess I'd heard of it, but hadn't looked at it yet). I was especially interested in having it run on ARM, but I don't have the experience it would take to figure out all the standard assembler stuff. I've always used Forth target compilers/assemblers in the past. If I could learn to install amforth on various ARM chips, that would be awesome. So far I prefer amforth to Mecrisp-Stellaris because it's so simple and easy to understand, like the old days on the Atari 800.

I've played with amforth a bit on an Arduino UNO and liked it a lot. I do wish there were more memory for block buffers, but that's a minor complaint.

I'd be happy if there were a community of ARM amforth users to confer with and if I could get it going on various ARM boards. But if there isn't enough interest in that, then sticking with AVR is probably fine.

Does anybody out there know how to get USB-HID working on an AVR 32u4 via amforth? That would be so wonderful!

Thanks Erich for what you're doing!

Charley

On 6/28/2020 7:29 AM, Erich Wälde wrote:
> Dear AmForthers,
>
> due to some unlikely fluctuation in probability space (or some
> other excuse) I declared this weekend to be "AmForth weekend 1"
> --- for me at least. While being working on this I decided to let
> you know, what is happening, and what is going around in my head
> regarding AmForth.
>
>
> - Contributions
>
>    I am very grateful for everyone who is sending anything to the
>    mailing list. Thank you! This is imho an important way to show
>    that this project is not dead. I am also very grateful that
>    Tristan W. and Martin N. have been helping out answering
>    questions. I will not be able to keep this project alive on my
>    own, so "Thank you!"
>
>    Along the same lines: "Welcome to all newcomers!"
>
>    That being said: I have been asked whether I accept email to my
>    private address. Yes I do. HOWEVER, every email not going
>    through the list, for whatever reason, does not add to the
>    "this project is alive" feature, does not inform all the others
>    on the list. I admit that I have been guilty of this myself
>    much too often. I herewith sincerely apologize --- while being
>    practical and easy it will be wrong in the long run.
>
>
> - Commits
>
>    r2443: added one-line patch to amforth-shell.py, provided by
>           Tristan Williams. Will now report filenames which occur
>           more than once.
>
>    r2444: AVR8: restored avr8/words/no-jtag.asm from release 5.5;
>           removed not functional avr8/devices/*/words/no-jtag.asm
>           files.
>
>    r2445: added comment about last commit to index.rst
>
>    r2446: Added refcard manually generated from 5.5 with a
>           warning! This is outdated!
>
>           Commented Projects/ClockWorks: added version from
>           2018-12-15; they were apparently lost or never published
>           on the website. This version features a clock reading
>           the DCF77 time radio signal.
>
>
> - Open Issues
>
>    as far as I'm aware:
>
>    - WDT (Martin Nicholas) patch
>
>      Martin has provided a small patch (.asm) regarding the
>      startup of the WDT (watch dog timer) on atmega2560
>      controllers. I have honestly no idea, whether or not this
>      will break something else, and under which conditions exactly
>      this is needed.
>      link to email archive (Martin Nicholas, June 2019)
>      https://sourceforge.net/p/amforth/mailman/message/36682958/
>
>    - Multitasker documentation
>
>      This needs to be tested and enhanced in a few ways. It might
>      be that the current example in the Cookbook section is simply
>      broken. There have been questions about how to better
>      populate the task local user area. Maybe this could be
>      answered by a more complex example. There has been the
>      question about producing output from a task (not the cmd
>      loop), its collision with the shared HLD/TAB area, and
>      possible ways to solve this (semaphores, task local HLD/TAB).
>      link to email archive (Jan Kromhout Feb 2019)
>      https://sourceforge.net/p/amforth/mailman/message/36596842/
>
>    - " du< " is missing
>      link to email archive (Martin Nicholas August 2019)
>      https://sourceforge.net/p/amforth/mailman/message/36748496/
>
>    - amforth-upload.py is broken for me, I use the file from 4.0.
>      But I have not bothered to find out exactly what breaks on
>      me/my code.
>
>    - both amforth-upload.py and amforth-shell.py are using
>      "python", which means python2. Since python2 is being
>      discontinued, these should be ported to python3. Anyone
>      interested?
>
>    - The refcard generator is broken probably since release 5.6
>      link to email archive (Martin Nicholas June 2020)
>      https://sourceforge.net/p/amforth/mailman/message/37047630/
>
>
> - Open Questions
>
>    Apart from the code/documentation issues above there are more
>    open questions for me:
>
>    - How do I /reliably/ create the content of the webpage? How do
>      I synchronize my local version effortlessly with the official
>      copy? How can I diagnose changes, when sphinx upon generation
>      changes /every/ file somehow? Did I say I'm not a web person?
>      %^>
>
>    - How do I actually create a new release? Copying the files is
>      one thing, but where do I need to change the version? There
>      is more than one place, I'm afraid. I also happen to know
>      that after 6.9 there cannot be 6.10 due to a limitation
>      created very early. Matthias told me that, otherwise I would
>      be clueless.
>
>    - How to run the testcases? How many test files are there? Can
>      they be run reliably? Will errors show up in such a way that
>      they will not be lost? Where should the test cases go? How
>      about msp430, arm, risc-v? Folks, I break into cold sweat
>      when I work on the source code and hit "commit".
>
>
> - Whacky Ideas
>
>    - git? -- With all the cool kids using git repositories, should
>      I attempt do convert the existing repositories, webpage, etc?
>      does sourceforge.net provide git repositories? Can the
>      existing svn repository be converted on the server side?
>
>    - Should we use a ticket system rather than mailing list?
>
>    - Who of you is using which target controller? Would it be
>      feasible to drop msp430, arm, risc-v in order to simplify the
>      whole thing? yes/no?
>
>    - Can we get rid of the Atmel/Microchip Avrasm Assembler?
>
>      One big difference between the avr8 and the risc-v tree is
>      the assembly language. avr8 is using Atmels assembly. Which
>      is good, because it is thoroughly documented. And which is
>      bad, because there is no working free/libre alternative to
>      avrasm.exe. Yes there is the "avra" project but it has been
>      abandoned long ago. I have been able to assemble AmForth with
>      avra way back in releases 4.2 up until maybe 4.9. I have even
>      contributed a small patch to make atmega644p working.
>      https://sourceforge.net/projects/avra/
>
>      Matthias has contemplated the idea to port AmForth/avr8 to
>      use gnu assembly. He might even have produced a working
>      branch, I don't know.
>
>      For risc-v there is no avr assembly, naturally. That's where
>      all the .s assembly files come into the game.
>
>      I personally would love to have a free/libre assembler for
>      avr assembly. AVRASM.EXE is the only thing that forces me to
>      install wine on my system.
>
>
> - Happy Häcking
>
>    I have been working with AmForth lately. Yes really!
>
>    The Code in my RS485 bus project is showing its age.
>    http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html
>    First, I was able to reduce the assembly part of this game
>    considerably, after Matthias has included a few goodies just
>    for my beloved use case :-) That is working and needs to be
>    documented again.
>
>    Along the way I was bitten by the "because I can" bug and
>    created my own hardware:
>    https://erwaelde.gitlab.io/posts/0005-avr-boards.html
>    Two iterations down the road I do have functional boards.
>    Another board with rs485 and power is needed, but heck, one
>    thing at a time.
>
>    So I have a few controllers distributed about my home. They are
>    taking measurements. There is a collector (perl script)
>    collecting the measurements periodically. The data is going to
>    a sqlite database. The data is viewed using another perl script
>    with a very old extension: pgplot5. This has been working for
>    10 years or more, however, pgplot5 is not being ported to the
>    new worlds of visualization, so a replacement is clearly
>    needed.
>
>    My current plan is to rewrite the collector script, (perl plus
>    EV, AnyEvent, MQTT) let it report the data to a mosquitto
>    daemon. A component called telegraf will subscribe to mosquitto
>    and report all configured messages into a new and shiny influx
>    database. The visualization is currently done with grafana, but
>    I am aiming for R and some javascript component to make it
>    interactive. The results to be shown on a MagicMirror2 info
>    terminal. This is all working in principle, but not yet in the
>    desired detail.
>
>    Yes, yes, there is still a long way to go. But that keeps me
>    out of trouble :-)
>
>
>    That being said, I would love to hear from you, what you are
>    using AmForth for. Show off your projects, even if too small or
>    too unpolished to show anyone else. We will all be kind to each
>    other, promised!
>
>
>
>
>
> One last thing: Matthias was a regular participant in the net2o
> forth chat. I'm there almost every Thursday (20h Germany local
> time). This chat round is open to anyone, however, since the
> technology used resembles a "dark" net ;-) you need to get your
> key "invited". Feel free to join and bother me about how to
> participate, details are here:
> https://fossil.net2o.de/net2o/doc/trunk/wiki/net2o.md
> https://fossil.net2o.de/net2o/doc/trunk/wiki/get-it.md
> https://fossil.net2o.de/net2o/doc/trunk/wiki/try-it.md
>
>
>
> Still reading? Yes?
> That's very kind of you.
> Thank you for your precious time.
>
> I would be very grateful for any comments, ideas, contributions
> from you. I would love to hear what you are using AmForth for.
> Thanks.
>
> I herewith declare the next AmForth Weekend to be on
> 2020-08-01,02, right after "SysAdmin Day".
> https://en.wikipedia.org/wiki/Sysadmin_day
>
>
> Cheers,
> Erich
>
> PS: Halfway through this weekend I can only express deepest
> admiration for Matthias juggling all these pieces so well!
>
>

Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)

[Mark R. <cab...@gm...>]

On Sun, Jun 28, 2020 at 5:29 PM Erich Wälde <ew....@na...> wrote:

>
> Dear AmForthers,
>
> due to some unlikely fluctuation in probability space (or some
> other excuse) I declared this weekend to be "AmForth weekend 1"
> --- for me at least. While being working on this I decided to let
> you know, what is happening, and what is going around in my head
> regarding AmForth.
>

I've never been very good with trying to meld modern email with these
mailing lists. It seems those little time spigots have been working
overtime. I will give it my best go though. (also, it probably doesn't hurt
the sentiment that I just finished reading, The Man Who Folded Himself,
last week.)
I do like that I am standing here for AmForth Weekend $01 very much.


> - Contributions
>
>   I am very grateful for everyone who is sending anything to the
>   mailing list. Thank you! This is imho an important way to show
>   that this project is not dead. I am also very grateful that
>   Tristan W. and Martin N. have been helping out answering
>   questions. I will not be able to keep this project alive on my
>   own, so "Thank you!"
>
>   Along the same lines: "Welcome to all newcomers!"
>

Indeed. Without a community it is just a public facing private project. I
found it very promising that, upon asking the list something, a reply
appeared. Having seen a lot of names over and over again as I have been
doing searches (or just reading backwards in a linear fashion) of the
mailing list, it does seem that there are some old regulars here. This
project has been around for quite some time now.


>   That being said: I have been asked whether I accept email to my
>   private address. Yes I do. HOWEVER, every email not going
>   through the list, for whatever reason, does not add to the
>   "this project is alive" feature, does not inform all the others
>   on the list. I admit that I have been guilty of this myself
>   much too often. I herewith sincerely apologize --- while being
>   practical and easy it will be wrong in the long run.
>

Yeah, unless there is some strong reason for it to be private I suppose.
But when it's not public, it doesn't serve to help the community. Unless it
is something that needed to be private to be dealt with then released to
the list. Most of the time though, I think anyhow, those types of things
are for personal communication anyhow. It's not like people don't become
friends and do stuff off to the side.

+++++++++++++++START CLIP+++++++++++++++++++++++++++++

>  - Commits
>
>   r2443: added one-line patch to amforth-shell.py, provided by
>          Tristan Williams. Will now report filenames which occur
>          more than once.
>
> ...........(BUNCH OF CLIPPED CONTENT)
>
>   - " du< " is missing
>     link to email archive (Martin Nicholas August 2019)
>     https://sourceforge.net/p/amforth/mailman/message/36748496/

+++++++++++++++END CLIP+++++++++++++++++++++++++++++


> - amforth-upload.py is broken for me, I use the file from 4.0.
>     But I have not bothered to find out exactly what breaks on
>     me/my code.
>
>   - both amforth-upload.py and amforth-shell.py are using
>     "python", which means python2. Since python2 is being
>     discontinued, these should be ported to python3. Anyone
>     interested?
>

I wish I would have learned Python 15 years ago when a guy I worked with at
a forum was talking about how it was the future. I think he has 2 or 3
books published now. Oh well...

amforth-upload.py seemed broken to me as well. I tried to use that after
reading something somewhere in the online docs. Luckily I gave
amforth-console.py a try since that did work really well for me once I got
it to connect. It doesn't seem perfect, but pretty close. And the thing it
does where it pulls port names (well, their values) in as needed is pretty
handy. It did confuse me though when trying to follow the flow of the code
and wondering why the port name, that is right there in the source,
wouldn't work for me from the interpreter. I suppose had I known to read
the docs in the script itself first I could have saved myself some
headaches.


>   - The refcard generator is broken probably since release 5.6
>     link to email archive (Martin Nicholas June 2020)
>     https://sourceforge.net/p/amforth/mailman/message/37047630/
>
>
> - Open Questions
>
>   Apart from the code/documentation issues above there are more
>   open questions for me:
>
>   - How do I /reliably/ create the content of the webpage? How do
>     I synchronize my local version effortlessly with the official
>     copy? How can I diagnose changes, when sphinx upon generation
>     changes /every/ file somehow? Did I say I'm not a web person?
>     %^>
>
>   - How do I actually create a new release? Copying the files is
>     one thing, but where do I need to change the version? There
>     is more than one place, I'm afraid. I also happen to know
>     that after 6.9 there cannot be 6.10 due to a limitation
>     created very early. Matthias told me that, otherwise I would
>     be clueless.
>
>   - How to run the testcases? How many test files are there? Can
>     they be run reliably? Will errors show up in such a way that
>     they will not be lost? Where should the test cases go? How
>     about msp430, arm, risc-v? Folks, I break into cold sweat
>     when I work on the source code and hit "commit".
>

All this (waves arms around randomly) that you are talking about needs to
be documented. When I realized that my command line (later to find it was
the ver word) was spitting out 6.7 when I knew that I had downloaded 6.8
seemed like an easy thing to handle. Then my head exploded. Luckily my kid
was nearby and mopped up the mess, tossed it in a bucket then into the
freezer to reconstitute. I can't say that I know how Sourceforge does all
that. I could probably dedicate some time to looking into all those webpage
source files in the source tree. I could look a little more into sphinx and
see if I can't get it to run on my local svn copy. I can't promise
anything, but one thing I do have to barter with is time.
Having spent quite a bit of the last couple weeks (or so, who knows how
time flies) I have noticed a lot of minor typos that are probably generated
by working in a second (third, fourth whatever) language. If I can remember
how to do the patch thing for svn I'll try and keep track of them as I go.


> - Whacky Ideas
>
>   - git? -- With all the cool kids using git repositories, should
>     I attempt do convert the existing repositories, webpage, etc?
>     does sourceforge.net provide git repositories? Can the
>     existing svn repository be converted on the server side?
>
>   - Should we use a ticket system rather than mailing list?
>

I like git a lot more than svn but I don't remember hating svn when I
noodled around with the FLTK group way back in the stone ages. (cvs on the
other hand could get you hit with a shovel) At any rate, I had toyed around
with pulling the svn source into a git repo. I almost got it to work but I
couldn't get your latest commits to fetch. Apparently I didn't get it quite
right. I did make up a contributors file though that seemed to catch all
the committers.

Sourceforge has a more thread based thing as well for bug reports and
questions. That seems to be easier for most people to use imho. I like the
way github does it since those threads are so tightly bound with the repo
but, once again, that is a personal preference. I'm never quite sure if I'm
doing the mailing list thing correctly, which is odd considering I lived
through the no internet - weird message boards - bbs - modern internet
thing. I've found the mailing list to be clunky when I've been doing
searches and reading and doing more searches (lather rinse repeat) and I'll
just have to put it aside before picking it up again. Being able to scan
threads for me makes doing blind or mass quests less painful.


>   - Who of you is using which target controller? Would it be
>     feasible to drop msp430, arm, risc-v in order to simplify the
>     whole thing? yes/no?
>

I've been a fan of the AVR stuff for some time now ever since I finally
stopped flogging my old SX(28/48)s. I tried the arduino thing for a bit but
found it to be too much of a pain overall. Last year I started playing
around with the avr chips by themselves thanks to the Make avr book. Once I
got back to doing things from the command line with make (which I've always
been partial to) I enjoyed it more. When I found AmForth it seemed a
perfect fit to build something like those neat backplane z80 boards, but
using a modern center. Everytime I tip into it, I can't help but think how
much it is like my commodore 64 (then 128 then 4000 with toaster) where you
get a prompt and what you do from there is entirely up to you. To me, as a
neophyte, AmForth seemed to be for the AVR and FlashForth seemed to be for
the PIC. I could be over simplifying things since there are other platforms
here, but that was why I took the plunge here.


>   - Can we get rid of the Atmel/Microchip Avrasm Assembler?
>

This was the only thing that concerned me since the only other thing I use
wine for is the Parallax IDE for the SX chips. Luckily though, it Just
Worked so, while it would be nice to have a gcc based assembler, there just
doesn't seem to be one that works.

I'm going to wrap up here for now but I will add that I am trying to use
AmForth as an OS of sorts for something like those z80 backplane computers.
It seems like a great fit to make a nice learning board for me and my son
to play with. Right now I just have an atmega1284p running from a 20mhz
clock with a bank of leds and an eeprom. I do have a 2221 usb bridge that
will replace the usb-ttl board I use for communication right now. I use a
usbasp for reprogramming the chip. Once I get the memory thing worked out
I'll work on adding an lcd then keyboard. Open ended project ftw!

I like this (your and our) project a lot. I'm still learning Forth more and
more every day plus having to work out just what things are doing with the
eeprom code has helped a lot. Once I got my brain bent around how things
like bitmask: actually worked (it got it's name how, wait what did it just
do there) I was able to make progress. The language itself it really pretty
amazingly cool.

Until the next AmForth Weekend!
All the best,
Mark


>     One big difference between the avr8 and the risc-v tree is
>     the assembly language. avr8 is using Atmels assembly. Which
>     is good, because it is thoroughly documented. And which is
>     bad, because there is no working free/libre alternative to
>     avrasm.exe. Yes there is the "avra" project but it has been
>     abandoned long ago. I have been able to assemble AmForth with
>     avra way back in releases 4.2 up until maybe 4.9. I have even
>     contributed a small patch to make atmega644p working.
>     https://sourceforge.net/projects/avra/
>
>     Matthias has contemplated the idea to port AmForth/avr8 to
>     use gnu assembly. He might even have produced a working
>     branch, I don't know.
>
>     For risc-v there is no avr assembly, naturally. That's where
>     all the .s assembly files come into the game.
>
>     I personally would love to have a free/libre assembler for
>     avr assembly. AVRASM.EXE is the only thing that forces me to
>     install wine on my system.
>
>
> - Happy Häcking
>
>   I have been working with AmForth lately. Yes really!
>
>   The Code in my RS485 bus project is showing its age.
>   http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html
>   First, I was able to reduce the assembly part of this game
>   considerably, after Matthias has included a few goodies just
>   for my beloved use case :-) That is working and needs to be
>   documented again.
>
>   Along the way I was bitten by the "because I can" bug and
>   created my own hardware:
>   https://erwaelde.gitlab.io/posts/0005-avr-boards.html
>   Two iterations down the road I do have functional boards.
>   Another board with rs485 and power is needed, but heck, one
>   thing at a time.
>
>   So I have a few controllers distributed about my home. They are
>   taking measurements. There is a collector (perl script)
>   collecting the measurements periodically. The data is going to
>   a sqlite database. The data is viewed using another perl script
>   with a very old extension: pgplot5. This has been working for
>   10 years or more, however, pgplot5 is not being ported to the
>   new worlds of visualization, so a replacement is clearly
>   needed.
>
>   My current plan is to rewrite the collector script, (perl plus
>   EV, AnyEvent, MQTT) let it report the data to a mosquitto
>   daemon. A component called telegraf will subscribe to mosquitto
>   and report all configured messages into a new and shiny influx
>   database. The visualization is currently done with grafana, but
>   I am aiming for R and some javascript component to make it
>   interactive. The results to be shown on a MagicMirror2 info
>   terminal. This is all working in principle, but not yet in the
>   desired detail.
>
>   Yes, yes, there is still a long way to go. But that keeps me
>   out of trouble :-)
>
>
>   That being said, I would love to hear from you, what you are
>   using AmForth for. Show off your projects, even if too small or
>   too unpolished to show anyone else. We will all be kind to each
>   other, promised!
>
>
>
>
>
> One last thing: Matthias was a regular participant in the net2o
> forth chat. I'm there almost every Thursday (20h Germany local
> time). This chat round is open to anyone, however, since the
> technology used resembles a "dark" net ;-) you need to get your
> key "invited". Feel free to join and bother me about how to
> participate, details are here:
> https://fossil.net2o.de/net2o/doc/trunk/wiki/net2o.md
> https://fossil.net2o.de/net2o/doc/trunk/wiki/get-it.md
> https://fossil.net2o.de/net2o/doc/trunk/wiki/try-it.md
>
>
>
> Still reading? Yes?
> That's very kind of you.
> Thank you for your precious time.
>
> I would be very grateful for any comments, ideas, contributions
> from you. I would love to hear what you are using AmForth for.
> Thanks.
>
> I herewith declare the next AmForth Weekend to be on
> 2020-08-01,02, right after "SysAdmin Day".
> https://en.wikipedia.org/wiki/Sysadmin_day
>
>
> Cheers,
> Erich
>
> PS: Halfway through this weekend I can only express deepest
> admiration for Matthias juggling all these pieces so well!
>
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] AmForth Weekend 1 (2020-06-27/28)

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

Dear AmForthers,

due to some unlikely fluctuation in probability space (or some
other excuse) I declared this weekend to be "AmForth weekend 1"
--- for me at least. While being working on this I decided to let
you know, what is happening, and what is going around in my head
regarding AmForth.


- Contributions

  I am very grateful for everyone who is sending anything to the
  mailing list. Thank you! This is imho an important way to show
  that this project is not dead. I am also very grateful that
  Tristan W. and Martin N. have been helping out answering
  questions. I will not be able to keep this project alive on my
  own, so "Thank you!"

  Along the same lines: "Welcome to all newcomers!"

  That being said: I have been asked whether I accept email to my
  private address. Yes I do. HOWEVER, every email not going
  through the list, for whatever reason, does not add to the
  "this project is alive" feature, does not inform all the others
  on the list. I admit that I have been guilty of this myself
  much too often. I herewith sincerely apologize --- while being
  practical and easy it will be wrong in the long run.


- Commits

  r2443: added one-line patch to amforth-shell.py, provided by
         Tristan Williams. Will now report filenames which occur
         more than once.

  r2444: AVR8: restored avr8/words/no-jtag.asm from release 5.5;
         removed not functional avr8/devices/*/words/no-jtag.asm
         files.

  r2445: added comment about last commit to index.rst

  r2446: Added refcard manually generated from 5.5 with a
         warning! This is outdated!

         Commented Projects/ClockWorks: added version from
         2018-12-15; they were apparently lost or never published
         on the website. This version features a clock reading
         the DCF77 time radio signal.


- Open Issues

  as far as I'm aware:

  - WDT (Martin Nicholas) patch

    Martin has provided a small patch (.asm) regarding the
    startup of the WDT (watch dog timer) on atmega2560
    controllers. I have honestly no idea, whether or not this
    will break something else, and under which conditions exactly
    this is needed.
    link to email archive (Martin Nicholas, June 2019)
    https://sourceforge.net/p/amforth/mailman/message/36682958/

  - Multitasker documentation

    This needs to be tested and enhanced in a few ways. It might
    be that the current example in the Cookbook section is simply
    broken. There have been questions about how to better
    populate the task local user area. Maybe this could be
    answered by a more complex example. There has been the
    question about producing output from a task (not the cmd
    loop), its collision with the shared HLD/TAB area, and
    possible ways to solve this (semaphores, task local HLD/TAB).
    link to email archive (Jan Kromhout Feb 2019)
    https://sourceforge.net/p/amforth/mailman/message/36596842/

  - " du< " is missing
    link to email archive (Martin Nicholas August 2019)
    https://sourceforge.net/p/amforth/mailman/message/36748496/

  - amforth-upload.py is broken for me, I use the file from 4.0.
    But I have not bothered to find out exactly what breaks on
    me/my code.

  - both amforth-upload.py and amforth-shell.py are using
    "python", which means python2. Since python2 is being
    discontinued, these should be ported to python3. Anyone
    interested?

  - The refcard generator is broken probably since release 5.6
    link to email archive (Martin Nicholas June 2020)
    https://sourceforge.net/p/amforth/mailman/message/37047630/


- Open Questions

  Apart from the code/documentation issues above there are more
  open questions for me:

  - How do I /reliably/ create the content of the webpage? How do
    I synchronize my local version effortlessly with the official
    copy? How can I diagnose changes, when sphinx upon generation
    changes /every/ file somehow? Did I say I'm not a web person?
    %^>

  - How do I actually create a new release? Copying the files is
    one thing, but where do I need to change the version? There
    is more than one place, I'm afraid. I also happen to know
    that after 6.9 there cannot be 6.10 due to a limitation
    created very early. Matthias told me that, otherwise I would
    be clueless.

  - How to run the testcases? How many test files are there? Can
    they be run reliably? Will errors show up in such a way that
    they will not be lost? Where should the test cases go? How
    about msp430, arm, risc-v? Folks, I break into cold sweat
    when I work on the source code and hit "commit".


- Whacky Ideas

  - git? -- With all the cool kids using git repositories, should
    I attempt do convert the existing repositories, webpage, etc?
    does sourceforge.net provide git repositories? Can the
    existing svn repository be converted on the server side?

  - Should we use a ticket system rather than mailing list?

  - Who of you is using which target controller? Would it be
    feasible to drop msp430, arm, risc-v in order to simplify the
    whole thing? yes/no?

  - Can we get rid of the Atmel/Microchip Avrasm Assembler?

    One big difference between the avr8 and the risc-v tree is
    the assembly language. avr8 is using Atmels assembly. Which
    is good, because it is thoroughly documented. And which is
    bad, because there is no working free/libre alternative to
    avrasm.exe. Yes there is the "avra" project but it has been
    abandoned long ago. I have been able to assemble AmForth with
    avra way back in releases 4.2 up until maybe 4.9. I have even
    contributed a small patch to make atmega644p working.
    https://sourceforge.net/projects/avra/

    Matthias has contemplated the idea to port AmForth/avr8 to
    use gnu assembly. He might even have produced a working
    branch, I don't know.

    For risc-v there is no avr assembly, naturally. That's where
    all the .s assembly files come into the game.

    I personally would love to have a free/libre assembler for
    avr assembly. AVRASM.EXE is the only thing that forces me to
    install wine on my system.


- Happy Häcking

  I have been working with AmForth lately. Yes really!

  The Code in my RS485 bus project is showing its age.
  http://amforth.sourceforge.net/Projects/RS485/RS485Bus.html
  First, I was able to reduce the assembly part of this game
  considerably, after Matthias has included a few goodies just
  for my beloved use case :-) That is working and needs to be
  documented again.

  Along the way I was bitten by the "because I can" bug and
  created my own hardware:
  https://erwaelde.gitlab.io/posts/0005-avr-boards.html
  Two iterations down the road I do have functional boards.
  Another board with rs485 and power is needed, but heck, one
  thing at a time.

  So I have a few controllers distributed about my home. They are
  taking measurements. There is a collector (perl script)
  collecting the measurements periodically. The data is going to
  a sqlite database. The data is viewed using another perl script
  with a very old extension: pgplot5. This has been working for
  10 years or more, however, pgplot5 is not being ported to the
  new worlds of visualization, so a replacement is clearly
  needed.

  My current plan is to rewrite the collector script, (perl plus
  EV, AnyEvent, MQTT) let it report the data to a mosquitto
  daemon. A component called telegraf will subscribe to mosquitto
  and report all configured messages into a new and shiny influx
  database. The visualization is currently done with grafana, but
  I am aiming for R and some javascript component to make it
  interactive. The results to be shown on a MagicMirror2 info
  terminal. This is all working in principle, but not yet in the
  desired detail.

  Yes, yes, there is still a long way to go. But that keeps me
  out of trouble :-)


  That being said, I would love to hear from you, what you are
  using AmForth for. Show off your projects, even if too small or
  too unpolished to show anyone else. We will all be kind to each
  other, promised!





One last thing: Matthias was a regular participant in the net2o
forth chat. I'm there almost every Thursday (20h Germany local
time). This chat round is open to anyone, however, since the
technology used resembles a "dark" net ;-) you need to get your
key "invited". Feel free to join and bother me about how to
participate, details are here:
https://fossil.net2o.de/net2o/doc/trunk/wiki/net2o.md
https://fossil.net2o.de/net2o/doc/trunk/wiki/get-it.md
https://fossil.net2o.de/net2o/doc/trunk/wiki/try-it.md



Still reading? Yes?
That's very kind of you.
Thank you for your precious time.

I would be very grateful for any comments, ideas, contributions
from you. I would love to hear what you are using AmForth for.
Thanks.

I herewith declare the next AmForth Weekend to be on
2020-08-01,02, right after "SysAdmin Day".
https://en.wikipedia.org/wiki/Sysadmin_day


Cheers,
Erich

PS: Halfway through this weekend I can only express deepest
admiration for Matthias juggling all these pieces so well!


-- 
May the Forth be with you ...

Re: [Amforth] Reference Card page now missing

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

Hello,

after an hour of digging:

The refcard was not regenerated by me when updating the web
page. So that explains why the link entry is missing on the
page.

The refcard page itself, namely
>> http://amforth.sourceforge.net/TG/refcard.html
is still there, because I did not dare to start with an empty
directory. Strictly speaking his page is a "leftover".

There is a script trunk/tools/make-refcard-rst which looks
suspiciously like it had been used to generate this particular
page. However, this script is not referenced anywhere :-(

There is a piece of dokumentation
> http://amforth.sourceforge.net/TG/Tools.html
which mentions "makerefcard" and "make-htmlwords" scripts.
The first I cannot find in the available repository. The second
is still there.

Found in trunk/tools, the scripts make-refcard-rst,
make-refcard, and make-htmlwords are perl scripts. All three
define this:
> my $asmdir="../core/words";
The trunk/core directory was moved elsewhere in release 5.6.
make-refcard defines:
> my $version="5.4";
and make-refcard-rst defines:
> my $version="5.1";
So I suspect that these tools have been broken for a long time.

Release 5.6 added the msp430 target and thus the tree layout was
rearranged.


So this does not look like "easily fixable" at all, I'm afraid.



- the refcard needs to accomodate the "common" case and words
  specific to 4 target controllers.

- the refcard must be generated from the source files, anything
  else is asking for trouble and errors. The existing script did
  cover the asm sources only, not any available forth commands.

- the refcard needs to be generated as .rst, and then converted
  to html for the web page. There are also latex and epub files
  in the tree, which are probably generated from the .rst files.


Possible paths forward?

Can we understand in detail, how the scripts did work before
release 5.6? Probably.

Can we understand, how the tree layout and the code has changed?
And what we need to do in order to generate the refcard from
sources? Probably, it just sounds like quite a bit of work.

After that we can see, how to accomodate the generation of the
refcard across targets.


If anyone feels like spending some time on this, please go ahead
and please report your findings here on this list.


Cheers,
Erich



Erich Wälde writes:

> Hello Martin,
>
>
> Martin Nicholas via Amforth-devel writes:
>
>> Somehow this has gone from the RH menu:
>> http://amforth.sourceforge.net/TG/refcard.html
>
> Good point, thanks for the report.
>
> Some time back I had a conversation with Matthias about the
> reference card.
> - it has grown unbelievably
> - it should be generated automatically from the source files
>   /somehow/
> - it might be out of date at any place.
>
> So, please folks, feel free to report anything that looks wrong.
>
> Cheers,
> Erich


-- 
May the Forth be with you ...

Re: [Amforth] Reference Card page now missing

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

Hello Martin,


Martin Nicholas via Amforth-devel writes:

> Somehow this has gone from the RH menu:
> http://amforth.sourceforge.net/TG/refcard.html

Good point, thanks for the report.

Some time back I had a conversation with Matthias about the
reference card.
- it has grown unbelievably
- it should be generated automatically from the source files
  /somehow/
- it might be out of date at any place.

So, please folks, feel free to report anything that looks wrong.

Cheers,
Erich


-- 
May the Forth be with you ...

[Amforth] Reference Card page now missing

[Martin N. <amf...@mg...>]

Somehow this has gone from the RH menu:
http://amforth.sourceforge.net/TG/refcard.html

-- 
Regards,

Martin Nicholas.

E-mail: rep...@mg... (Address will be valid throughout 2020).

Re: [Amforth] Stack pointer

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

Hello,

tur bine writes:

> Hi just wished to expand my knowledge base with forth, the stack pointer
> increases during runtime and does not decrease unless using certain
> commands if etc, can somebody explain what happens when sp and thus the
> stack gets full please

Martin has answered your question already. I would like to add a
a few bits.

1.

The exact region, how memory (RAM) is used, is documented in
> http://amforth.sourceforge.net/TG/AVR8.html
(similar for the other targets). More precisely
> http://amforth.sourceforge.net/TG/AVR8.html#ramfigure
shows that in this partcular case, the datastack grows towards
the HLD/PAD area. This might be quite some distance, but Martins
answer holds: if you overwrite something "important", then most
likely your programm will crash.

I cannot yet explain the purpose of the two different layouts,
but I assume that the latter is needed to accomodate one or more
of the other hardware targets. I have not tried to understand
this so far. I do have a hifive1 board, so it is on the list to
understand better, what the boundary conditions are (beside
using a different asm format).


2.

When using the multitasker, you will run into finite stack space
conditions much sooner. To define a task, you specifiy the size
of the data/return stacks explicitly. If your nice programm
crashes once in a while, I would strongly recommend to increase
stack sizes as a first experiment. Been there, done that. :-)

The command " .res " does actually output some information about
stack usage. And it's worthwile to study its code.
> .../avr8/lib/dot-res.frt


3.

When using the multitasker, the above mentioned HLD/PAD area is
interesting as well, because currently there is only one such
area shared between all tasks. I have been bitten by this: Task
A runs the command loop on usart0; Task B runs a function, which
writes to an LCDisplay via spi or i2c. Please note: two tasks
using different hw periphery with distinct versions of " emit ".
However, both tasks used pictured numeric output (this is
actually quite hard to avoid :-) And once in a while, the
formated output bound for the LCD would overwrite the output
bound for the serial interface. It "looked" like amforth was
doing calculation errors once in a while ...

As I have mentioned a while back, I would like to either provide
task-local areas for HLD/PAD  or play with semaphores to solve
this.

However, my days are much too short --- as I'm sure everyone
elses are as well :-)


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

While rereading your question, it occurs to me that you might
talk about FLASH rather than RAM.

When compiling a word, the new word will consume some flash
space. DP points to the next available position. The dictionary
grows from low flash addresses towards higher ones.

On AVR8 it will eventually hit the NRWW section boundary. I
expect that compiling will fail at this point, because the NRWW
section is kind of protected. I have not tried this.

In order to reclaim FLASH memory without erasing/flashing the
controller, you can use the word " marker " (which you need to
load first) Example:

> my_code.frt
>| \ maybe more includes needed here ...
>| include lib-avr8/forth2012/core-ext/marker.frt
>| 
>| marker --main--
>| 
>| \ ... your code goes here


Now when you don't like your code anymore, you can call

> --main-- ok
>
on the serial connection. This word will reset book-keeping in
such a way, that everything from " --main-- " and onward is not
available any more. Please note that " --main-- " itself
vanishes as well and needs to be set anew.

There is one symptom related to this. If you load a lengthy
programm for the first time, it takes so long. If you load it
again, without reclaiming flash by calling the marker before ---
then it will take a little longer every time. This is noticable.
This is caused by the increasing length of the wordlist. To
find a word at the low end of the list, it will take
increasingly longer, because the length of the wordlist
increases. And guess what, all the important words stay at the
low end of the wordlist.



Thanks for reading,
and welcome to the list!

Cheers,
Erich


-- 
May the Forth be with you ...

Re: [Amforth] defer.frt

[Mark R. <cab...@gm...>]

Okay, maybe I figured out why the i2c-eeprom-blocks.frt wasn't working
right for me.

I re-flashed my 1284 to get a fresh start, then started working on the
simpler i2c-eeprom.frt from the python console. It would sort of work then
get stuck. So I ended up just making a list of inclusions and working
backward manually, only adding a local version when the #include directive
couldn't find the file because it didn't seem to be in the search path. No
problem. It was even nice enough to tell me when I had too many versions of
the file. It is possible I'm not using the tool properly I suppose. In any
case, it seems that I (should) now have a way to play around with an I2C
bus.

Onward (until next time...)

Mark

On Sat, Jun 27, 2020 at 1:32 AM Mark Roth <cab...@gm...> wrote:

> Thank you Tristan for the welcome and all of it.
>
> Yeah, I had done that. I guess pointing out that was missing was just an
> easy way to start. What I had actually done was to move everything into my
> app directory to try and get things to import. The changes you mention do
> work. Where I am getting stuck is in the flash-block.frt file at line 33.
> After making some changes (well adding #requires) I'm also seeing it in
> i2c-eeprom-block.frt at line 76 which is the same issue.
>
> S|   76|   ['] i2c.ee.load-buffer is load-buffer
>
> which is about the same type of line in flash-block. That makes me think
> it is something that is not included yet.
>
> It's late here. Tomorrow is another day. Thanks again for the welcome.
> Really :)
>
> On Sat, Jun 27, 2020 at 12:41 AM Tristan Williams <ho...@tj...> wrote:
>
>> Hello Mark,
>>
>> Welcome to the list.
>>
>> > Should I be concentrating more on following along with the I2C EEPROM
>> > recipe in the cookbook instead?
>>
>> It depends upon what you want to achieve - but perhaps. At the end of
>> cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
>> and be able to write/read a byte/word to/from an address on the
>> eeprom. If you put multiple eeproms on the bus make sure they have
>> different I2C addresses. i2c.detect is very useful as an interactive
>> check to see if things are as you expect.
>>
>> > The problem is that it seems there is no defer.frt anymore
>>
>> You are correct.
>>
>> i2c-eeprom-block.frt requires blocks.frt which
>> in turn requires defer.frt - which does not exist.
>>
>> I think the word Rdefer used in blocks.frt is now in this file
>>
>> amforth-6.8/common/lib/forth2012/core-ext/defers.frt
>>
>> I have not tested this, but changing
>>
>> #require defer.frt
>>
>> to
>>
>> #require defers.frt
>>
>> in
>>
>> amforth-6.8/common/lib/forth2012/blocks/blocks.frt
>>
>> may help.
>>
>> Best wishes,
>> Tristan
>>
>> [1]
>> http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom
>>
>> On 26Jun20 22:04, Mark Roth wrote:
>> > Hello,
>> > I have been working (and reading extensively) with AmForth this past
>> week
>> > or so as I learn Forth from Starting Forth. I wanted to try to play with
>> > some eeproms on an I2C bus and from reading here I drifted toward the
>> > i2c-eeprom-block.frt
>> > post. The problem is that it seems there is no defer.frt anymore?
>> Should I
>> > be concentrating more on following along with the I2C EEPROM recipe in
>> the
>> > cookbook instead? I tried to upload the requirements with the
>> > amforth-shell.py script and that gave me the error message of:
>> > E=file defer.frt not found in search path
>> > I am running 6.8 on an atmega1284p if that  makes a difference.
>> >
>> > It was a little tricky getting started since I was following the linux
>> > instructions, but once I read through the windows stuff (and just the
>> docs
>> > in general) I was able to get my chip set up correctly. It really is a
>> > pretty cool system that reminds me of my old computers back in the olden
>> > days. :)
>> >
>> > Mostly I've been using the e4thcom console, but I couldn't manage to
>> get it
>> > to search for the sources correctly. The python script seems to work a
>> > treat for that.
>> >
>> > Also, I'm sorry I just missed out on the creator of all this. It's
>> always
>> > nice to see a project live on though. That's really why they are open
>> imho.
>> >
>> > All the best,
>> > Mark
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] defer.frt

[Mark R. <cab...@gm...>]

Thank you Tristan for the welcome and all of it.

Yeah, I had done that. I guess pointing out that was missing was just an
easy way to start. What I had actually done was to move everything into my
app directory to try and get things to import. The changes you mention do
work. Where I am getting stuck is in the flash-block.frt file at line 33.
After making some changes (well adding #requires) I'm also seeing it in
i2c-eeprom-block.frt at line 76 which is the same issue.

S|   76|   ['] i2c.ee.load-buffer is load-buffer

which is about the same type of line in flash-block. That makes me think it
is something that is not included yet.

It's late here. Tomorrow is another day. Thanks again for the welcome.
Really :)

On Sat, Jun 27, 2020 at 12:41 AM Tristan Williams <ho...@tj...> wrote:

> Hello Mark,
>
> Welcome to the list.
>
> > Should I be concentrating more on following along with the I2C EEPROM
> > recipe in the cookbook instead?
>
> It depends upon what you want to achieve - but perhaps. At the end of
> cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
> and be able to write/read a byte/word to/from an address on the
> eeprom. If you put multiple eeproms on the bus make sure they have
> different I2C addresses. i2c.detect is very useful as an interactive
> check to see if things are as you expect.
>
> > The problem is that it seems there is no defer.frt anymore
>
> You are correct.
>
> i2c-eeprom-block.frt requires blocks.frt which
> in turn requires defer.frt - which does not exist.
>
> I think the word Rdefer used in blocks.frt is now in this file
>
> amforth-6.8/common/lib/forth2012/core-ext/defers.frt
>
> I have not tested this, but changing
>
> #require defer.frt
>
> to
>
> #require defers.frt
>
> in
>
> amforth-6.8/common/lib/forth2012/blocks/blocks.frt
>
> may help.
>
> Best wishes,
> Tristan
>
> [1]
> http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom
>
> On 26Jun20 22:04, Mark Roth wrote:
> > Hello,
> > I have been working (and reading extensively) with AmForth this past week
> > or so as I learn Forth from Starting Forth. I wanted to try to play with
> > some eeproms on an I2C bus and from reading here I drifted toward the
> > i2c-eeprom-block.frt
> > post. The problem is that it seems there is no defer.frt anymore? Should
> I
> > be concentrating more on following along with the I2C EEPROM recipe in
> the
> > cookbook instead? I tried to upload the requirements with the
> > amforth-shell.py script and that gave me the error message of:
> > E=file defer.frt not found in search path
> > I am running 6.8 on an atmega1284p if that  makes a difference.
> >
> > It was a little tricky getting started since I was following the linux
> > instructions, but once I read through the windows stuff (and just the
> docs
> > in general) I was able to get my chip set up correctly. It really is a
> > pretty cool system that reminds me of my old computers back in the olden
> > days. :)
> >
> > Mostly I've been using the e4thcom console, but I couldn't manage to get
> it
> > to search for the sources correctly. The python script seems to work a
> > treat for that.
> >
> > Also, I'm sorry I just missed out on the creator of all this. It's always
> > nice to see a project live on though. That's really why they are open
> imho.
> >
> > All the best,
> > Mark
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] defer.frt

[Tristan W. <ho...@tj...>]

Hello Mark,

Welcome to the list.

> Should I be concentrating more on following along with the I2C EEPROM
> recipe in the cookbook instead?

It depends upon what you want to achieve - but perhaps. At the end of
cookbook recipe[1] you should have an I2C eeprom connected to the I2C bus
and be able to write/read a byte/word to/from an address on the
eeprom. If you put multiple eeproms on the bus make sure they have
different I2C addresses. i2c.detect is very useful as an interactive
check to see if things are as you expect.

> The problem is that it seems there is no defer.frt anymore

You are correct. 

i2c-eeprom-block.frt requires blocks.frt which
in turn requires defer.frt - which does not exist.

I think the word Rdefer used in blocks.frt is now in this file

amforth-6.8/common/lib/forth2012/core-ext/defers.frt

I have not tested this, but changing

#require defer.frt

to

#require defers.frt

in

amforth-6.8/common/lib/forth2012/blocks/blocks.frt

may help.

Best wishes,
Tristan

[1] http://amforth.sourceforge.net/TG/recipes/I2C-EEPROM.html?highlight=eeprom

On 26Jun20 22:04, Mark Roth wrote:
> Hello,
> I have been working (and reading extensively) with AmForth this past week
> or so as I learn Forth from Starting Forth. I wanted to try to play with
> some eeproms on an I2C bus and from reading here I drifted toward the
> i2c-eeprom-block.frt
> post. The problem is that it seems there is no defer.frt anymore? Should I
> be concentrating more on following along with the I2C EEPROM recipe in the
> cookbook instead? I tried to upload the requirements with the
> amforth-shell.py script and that gave me the error message of:
> E=file defer.frt not found in search path
> I am running 6.8 on an atmega1284p if that  makes a difference.
> 
> It was a little tricky getting started since I was following the linux
> instructions, but once I read through the windows stuff (and just the docs
> in general) I was able to get my chip set up correctly. It really is a
> pretty cool system that reminds me of my old computers back in the olden
> days. :)
> 
> Mostly I've been using the e4thcom console, but I couldn't manage to get it
> to search for the sources correctly. The python script seems to work a
> treat for that.
> 
> Also, I'm sorry I just missed out on the creator of all this. It's always
> nice to see a project live on though. That's really why they are open imho.
> 
> All the best,
> Mark
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth] defer.frt

[Mark R. <cab...@gm...>]

Hello,
I have been working (and reading extensively) with AmForth this past week
or so as I learn Forth from Starting Forth. I wanted to try to play with
some eeproms on an I2C bus and from reading here I drifted toward the
i2c-eeprom-block.frt
post. The problem is that it seems there is no defer.frt anymore? Should I
be concentrating more on following along with the I2C EEPROM recipe in the
cookbook instead? I tried to upload the requirements with the
amforth-shell.py script and that gave me the error message of:
E=file defer.frt not found in search path
I am running 6.8 on an atmega1284p if that  makes a difference.

It was a little tricky getting started since I was following the linux
instructions, but once I read through the windows stuff (and just the docs
in general) I was able to get my chip set up correctly. It really is a
pretty cool system that reminds me of my old computers back in the olden
days. :)

Mostly I've been using the e4thcom console, but I couldn't manage to get it
to search for the sources correctly. The python script seems to work a
treat for that.

Also, I'm sorry I just missed out on the creator of all this. It's always
nice to see a project live on though. That's really why they are open imho.

All the best,
Mark

Re: [Amforth] documentation error

[Tristan W. <ho...@tj...>]

Hello Brian,

Welcome to the list. Seems like you got a bargain. I was surprised to
see I could still buy a new AVR butterfly in the UK, but it would cost
me quite a bit more than 8 USD!

> How would I submit this as a patch for the documentation?

Emailing this mailing list is the way I have done it in the past.

Best wishes,
Tristan


On 16Jun20 20:46, Brian wrote:
> begin
>        ASSR c@
>        1 2 lshift    \ TCN2UB
>        1 0 lshift or \ TCR2UB
>        1 1 lshift or \ OCR2UB
>        and
>    until
> 
> I am new to the forth world and i'm loving it. I was on the newark ( an
> electronics parts distributor ) a few months ago and they were selling
> avrbutterflys for 8 US dollars. So I bought a few and while thinking about
> what to do with them I found forth and fell into the rabbit hole. That being
> said, in the cookbook section/popular boards/avr butterfly section it gives
> an rtc example code. The problem is that the above loop should wait until
> those three registers are 0. If you leave a 0 on the stack you end up in an
> infinite loop, and yet surprisingly the +32kHz function that loop comes from
> works. Well if you dump the ASSR register value ( using .s ) you see that
> the first look at the register that the TCRTUB flag is set so the value on
> the stack is one and the loop ends. This is not what the exit condition you
> want for this loop. Those last three bits in ASSR should be 0 according to
> the data sheet for the atmega169 (and I also for the atmega328) before
> moving on. A simple fix is:
> 
>   begin
>        ASSR c@
>        1 2 lshift    \ TCN2UB
>        1 0 lshift or \ TCR2UB
>        1 1 lshift or \ OCR2UB
>        and
>        0=  \ add this line
>    until
> 
> How would I submit this as a patch for the documentation?
> Thanks,
> Brian-in-ohio
> 
> ps used this loop to see the values on the stack
>  begin
>     ASSR c@
>     1 2 lshift    \ TCN2UB
>     1 0 lshift or \ TCR2UB
>     1 1 lshift or \ OCR2UB
>     bin .s cr hex
>     and
>     0=
>   until
> 
> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] documentation error

[Brian <bkn...@gm...>]

begin
        ASSR c@
        1 2 lshift    \ TCN2UB
        1 0 lshift or \ TCR2UB
        1 1 lshift or \ OCR2UB
        and
    until

I am new to the forth world and i'm loving it. I was on the newark ( an 
electronics parts distributor ) a few months ago and they were selling 
avrbutterflys for 8 US dollars. So I bought a few and while thinking 
about what to do with them I found forth and fell into the rabbit hole. 
That being said, in the cookbook section/popular boards/avr butterfly 
section it gives an rtc example code. The problem is that the above loop 
should wait until those three registers are 0. If you leave a 0 on the 
stack you end up in an infinite loop, and yet surprisingly the +32kHz 
function that loop comes from works. Well if you dump the ASSR register 
value ( using .s ) you see that the first look at the register that the 
TCRTUB flag is set so the value on the stack is one and the loop ends. 
This is not what the exit condition you want for this loop. Those last 
three bits in ASSR should be 0 according to the data sheet for the 
atmega169 (and I also for the atmega328) before moving on. A simple fix is:

   begin
        ASSR c@
        1 2 lshift    \ TCN2UB
        1 0 lshift or \ TCR2UB
        1 1 lshift or \ OCR2UB
        and
        0=  \ add this line
    until

How would I submit this as a patch for the documentation?
Thanks,
Brian-in-ohio

ps used this loop to see the values on the stack
  begin
     ASSR c@
     1 2 lshift    \ TCN2UB
     1 0 lshift or \ TCR2UB
     1 1 lshift or \ OCR2UB
     bin .s cr hex
     and
     0=
   until