Re: [Amforth] A RISC-V update

[Mark Roth]

This is really great to see Tristan. Bravo to your efforts getting this
going!

On Sat, Apr 13, 2024 at 7:24 PM  wrote:

> A RISC-V update.
>
> AmForth-RV is now self-supporting (no C libraries required) for the
> WCH CH32V307. Source and a pre-built hex file are here [0]
>
> Best wishes,
> Tristan
>
> [0] https://tjnw.co.uk/amforth-rv
>
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avra on a raspi zero v1

[Mark Roth]

On Wed, Oct 4, 2023 at 2:37 PM Tristan Williams wrote:

> Hello Mark,
>
> I took a local clone of your repo and the new template built for an uno
> without issue. Thank you.
>
> Are you open to a pull request?
>

Of course. I do believe that last night I fixed the last of the little bits
that were giving me trouble after trying to take care of the zero byte
padding issues. For some odd reason one of them played havoc with Evalue in
so that it just didn't work. It was in the word list, but was just hanging.
That is fine now as far as I can tell. I tested quite a bit with my word
list that is pretty extensive.


>
> Seeing that we are dealing with makefiles, it seemed a good time to
> address prebuilt binaries. I have blended/amended your template with
> the existing makefile in appl/arduino to output hex files for the m328
> based UNO and the 2561 based mega.


I agree. Any of the projects in appl should be able to be built and/or have
a prebuilt hex in them. Since today was the first day I was able to stop
looking at the repo and look at my own project to clean up the next thing I
did want to do is to cull and clean those. I have an uno or three and a
mega from an old disassembled  3D printer around here so I can try those
next. I also have a few other atmegas to work with from various interests
over the years. I need to look and see if any of them (atmega8, 16 etc) are
even able to take AmForth. So yes, any info put up at the repo will most
certainly be seen and considered by me for now unless something else
happens to move that focus.


> Separately, I have written a script to produce a simple html build
> specific reference-card that lists the words built into the respective
> pre-built hex files. It searches the .lst file produced by the
> assembler (in this case avra) for the assembler source files used and
> then searches them for the documentation. This has been discussed [1]
> on the mailing list before. However, if there are going to be prebuilt
> hex files in the repo, then a reference-card for those builds will be
> helpful for the person trying them out. It is not intended to be a
> substitute for the reference-card for AmForth as a whole.
>
> I have put up the html here as an idea.
>
> https://www.mostlymostly.uk/amforthdocs/prebuilt.html
>
> The page uses material from the existing site. It is not plumbed
> into the rst source (but it could be).


This looks great. A few times after you put up the link I accidentally
ended up there and wondered why the SF site was so snappy. I see you have
kept up with the refcard thing over the years from when we played around
with it. It's done with python I'm guessing. I really like your idea of
making them from the .lst files. It's something I've always thought would
be a great addition inside of the project directories if someone so
desired.


> Best wishes,
> Tristan
>
> [1] https://sourceforge.net/p/amforth/mailman/message/37112236/


All the best to you as well. It feels good to be polishing up the tools to
polish up the Forth that was starting to bit rot in my brain.
Mark


>
>
> On 30Sep23 22:30, Mark Roth wrote:
> > On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> >
> > > On 9/30/23 03:17, Mark Roth wrote:
> > > > Hello weekend AmForth'ers
> > > >
> > > > So, while waiting to see what will happen with the repo I have
> continued
> > > to
> > > > play with a git version for my own use. I have reworked the makefile
> and
> > > > made some changes to the repo structure to accommodate for the new
> avra
> > > > code (which is still only a placeholder until I get that repository
> in
> > > > properly). I think that the new makefile should make it very easy to
> get
> > > > started and there is a bit of a long winded readme to explain
> anything
> > > that
> > > > has changed. If anyone wants to take a look and give feedback that
> would
> > > be
> > > > great.
> > > >
> > > > https://github.com/CableGuy67/AmForth
> > >
> > > I took a quick look at the makefile and related fines in the
> > > appl/template directory, which I believe is what you're referring to
> > > here. I have two minor suggestions:
> > >
> > >  1. How about renaming "template.asm" as "app.asm" and making the
> > > corresponding changes to the makefile? I think this would make a
> > > workflow of copying the template directory to one named for a new
> > > application without updating names within the template directory
> > > very natural. I would feel weird leaving around a file called
> > > "template.asm" because that do

Re: [Amforth] avra on a raspi zero v1

[Mark Roth]

On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:

> On 9/30/23 03:17, Mark Roth wrote:
> > Hello weekend AmForth'ers
> >
> > So, while waiting to see what will happen with the repo I have continued
> to
> > play with a git version for my own use. I have reworked the makefile and
> > made some changes to the repo structure to accommodate for the new avra
> > code (which is still only a placeholder until I get that repository in
> > properly). I think that the new makefile should make it very easy to get
> > started and there is a bit of a long winded readme to explain anything
> that
> > has changed. If anyone wants to take a look and give feedback that would
> be
> > great.
> >
> > https://github.com/CableGuy67/AmForth
>
> I took a quick look at the makefile and related fines in the
> appl/template directory, which I believe is what you're referring to
> here. I have two minor suggestions:
>
>  1. How about renaming "template.asm" as "app.asm" and making the
> corresponding changes to the makefile? I think this would make a
> workflow of copying the template directory to one named for a new
> application without updating names within the template directory
> very natural. I would feel weird leaving around a file called
> "template.asm" because that doesn't communicate well the purpose of
> the file in the ultimate project. But "app.asm" seems like it could
> usually fit. Having a consistent name like this could also simplify
> documentation.
>

Yeah, that does sound like a good idea. I like the way it implies intent.


>  2. This is really just a template for an avr8 project, right? Perhaps
> the directory containing this sub-tree should be named
> "avr8-template" instead of "template"? It seems to me that really
> all the directories under "/appl" are currently templates for
> different targets? Is that right?
>
> Note that I haven't tried anything here, these all come from code
> inspection and may be due to misunderstandings on my part.
>
> Cheers!  Keith
>

You're not wrong in that. Since I only use the avr-8 chips I only recently
even looked into those other appl directories. It seems that it just sort
of grew like mushrooms (appl that is) and never had any cohesiveness.
Indicating that it is the appl template for avr8 is a no brainer. I have to
wonder if the makefile at one point in time was supposed to be more
inclusive with the other platforms but just never got there.

Thanks for the suggestions. Different eyes and all.

All the best,
Mark


>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

On Fri, Sep 29, 2023 at 5:26 PM Keith Amidon wrote:

> On 9/26/23 23:33, Mark Roth wrote:
> > Hello AmForth'ers. I like to see this little blip of activity and hope
> more
> > of the less than usual suspects join in with their thoughts!
>
> I'm one of those "less usual" suspects, so l'll jump in. For those with
> long memories my one claim to fame in the amforth community is that I
> wrote the original version of amforth-shell.py. The project I originally
> wrote that for wrapped up many years ago now and I have not had time to
> do much of anything with my list of microcontroller project ideas where
> amforth is most applicable since. I hope to get back to it though, which
> is why I continue to follow the mailing list.
>

Hello Keith. I'm glad you mentioned the shell (and that you wrote it in the
way back when) because it had slipped my mind to get back to trying it.
I've gotten so used to using e4thcom that the tool in the repo is just
collecting figurative dust for me. Tristan W brought it up into the python3
realm some time back and I think sorted some bug or another after that.
I get the feeling there are a number of the back in the old days folks
doing the same and glancing at the mailing list. One would hope anyway.
Seeing the dates on the really old commits this past week really drove it
home just how long this project has been around. :)


> > I have played around with your git repos quite a lot this summer. I
> really
> > wanted the branches one to work so that each branch could have been
> tagged
> > and merged upward to the current state. That just won't work. There are
> far
> > too many breaking changes, or things that just didn't get captured as
> > commits or something. While it is nice to have all the releases easy to
> > swap to by changing branches, it's not really what branches are for. I
> have
> > to agree that the way things are with the releases off to the side is the
> > best solution.
> >
> > I have not spent as much time poking around sourcehut but from what I did
> > see it is pretty much as listed on the tin, a git repo. If the cost is
> > relatively low I guess that isn't much of an issue but it would still
> need
> > to be integrated with the rest of the tools for bug reporting,
> discussions
> > etc. It seems like it could end up making more work and be even more
> > difficult to maintain long term or when more or less dormant.
> On this topic, I would say that I am very much for moving to some
> git-based source control system. I'm not particular about which "forge"
> hosts it.
> > That being said: I am still somewhat hesitant to move everything
> It definitely looks like a fair amount of work!
>

The problem is that is only the half of it. One thing I didn't consider
when suggesting to move to a git based repo is the tools that do things
like generate the docs. That has always been one of the things I really
liked. The pdf version in particular is really well done. The epub is,
well, it is usable but the format isn't the best for things with codeblocks
etc. It works but even when reading on my phone I've found myself reading
pdfs more and more. Reflowable works great for novels but less great on a
small screen for manuals. So that is a thing that would have to be
addressed. Or it would have to be done locally and then just added to the
repo as part of the workflow.


> > lol, by definition '3' is probably too many to merely constitute a
> majority
> > ;)
> > The point I was, as I'm sure you sussed out, is that I'd really like to
> > find out what people want to do, but also that something needs to be done
> > sooner rather than later. If it is only one person it is nothing more
> than
> > another splinter fork.
> It would be great to see a group of maintainers form who collectively
> could contribute enough time to build more momentum in the project
> again. I personally can't commit to doing much in the near-term
> unfortunately.
> >> 2. Make a 7.0 release at that time including
> >>>> a. the avra build
> >>>> b. an up to date version of the project makefile
> >>>> c. at least the first layers of documentation brought up to date
> >>>> d. the prebuilt hex files (really just a cleaning of the project
> >>>> directory in general)
> >> I personally think, the avra build is important. This was the
> >> remaining head ache for me, relying on a piece of proprietary
> >> software, which might break at the least convenient time. Now I
> >> do accept, that not everyone is on Linux/*BSD.
> >>
> > I totally agree and Tristan has also voiced the same. The avra stuff is a
> > little bit of a head-scra

Re: [Amforth] avra on a raspi zero v1

[Mark Roth]

> congrats to your hack-box! :)
>

Thanks! Slowly but surely I am collecting some better cables so I can put
it in an enclosure. :)

Hello weekend AmForth'ers

So, while waiting to see what will happen with the repo I have continued to
play with a git version for my own use. I have reworked the makefile and
made some changes to the repo structure to accommodate for the new avra
code (which is still only a placeholder until I get that repository in
properly). I think that the new makefile should make it very easy to get
started and there is a bit of a long winded readme to explain anything that
has changed. If anyone wants to take a look and give feedback that would be
great.

https://github.com/CableGuy67/AmForth

All the best,
Mark



> This is very close to what I am currently using (software wise).
> I had ordered a Hifive Unmatched, a riscv64 computer in miniITX
> Format. And once I got it going with Debian unstable, I
> installed: avra, minicom (terminal), avrdude (burner), perl and
> my scripts to use it for dabbling with amForth. No wine and
> avrasm.exe involved. I have not upgraded my avra along the lines
> mentioned recently, but I plan to. Granted, it is a much bigger
> machine, but at least it is not collecting dust.
>
> The warning with "'" missing a closing ' ... yes well. It does
> work in the end, so no sweat.
>
> Cheers,
> Erich
>
> Mark Roth  writes:
>
> > Hello all.
> >
> > I managed to day to cobble together my AmForth "computer" which is pretty
> > much the reason for avoiding using wine to build things. It consists of a
> > raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian
> lite
> > on it. That has a usb hub, an old palm pilot folding keyboard the
> > connection to my uart for the controller and the usbasp to program. The
> > display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
> > that makes it possible to actually use it for real.
> >
> > Tonight I managed to get all the cobbled bits to work together and to
> build
> > everything including avra on the zero then flash the controller. So, no
> > real computer but using e4thcom after flashing let me get in and use that
> > nice big screen as a terminal.
> >
> > I still haven't sorted out the single tick thing but I can kind of see
> > where it is coming from in avra. Pretty sure my C skills have faded over
> > the decades that it may just be a problem to look past.
> >
> > I guess now it's time to work on a nice box for the whole thing so I
> could
> > sit anywhere, plug in a powerbank and hack away. I'll try and get some
> > better documentation up soon but it really wasn't terribly difficult. It
> > was really really nice to do everything from Raspian knowing that wine
> > wasn't an option.
> >
> > Enjoy the weekend,
> > Mark
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> --
> May the Forth be with you ...
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

Hello AmForth'ers. I like to see this little blip of activity and hope more
of the less than usual suspects join in with their thoughts!

On Tue, Sep 26, 2023 at 7:06 PM Erich Wälde  wrote:

> Hello all,
>
> good to see some interest in this project again.
>
>
>
> Mark Roth  writes:
>
> > Good morning AmForth'ers (feel free to adjust the greeting with your
> RTC).
>
> >snip<<<<<<
>
> >> Tristan wrote, if I'm not mistaken
> >>
> >> The fact is that this project is still useful.
> >>
> >> I completely agree. AmForth is quite special as an embedded Forth in
> >> that it has wordlists, recognizers and comprehensive documentation.
> >>
> >> In suggesting a maintainer group the idea was that the effort required
> >> to preserve and update AmForth could be divided up, and perhaps if
> >> some of the more mundane aspects of avoiding bit rot are done, then
> >> people with more specialised skills, but less time, might feel more
> >> able to help.
> >>
> >> What would I suggest for the near term?
> >>
> >
> > This seems to me to pretty much sum up a good mission statement of what
> > AmForth is and why it can continue to be viable. Even with ONLY the focus
> > on the AVR8 side of the repo, which is the core of it, adding more up to
> > date chips as Tristan mentions later is a great way to interest new
> people
> > and keep things from going to seed. So I'll sum up the points made and
> > expand where needed.
>
>
> So, jumping right into the TODO section
> >
> > 0. Where should the official repo be?
> in December 2020 I have created a git based version of the
> repository at
>   https://git.sr.ht/~amforth/
>
> it comes in two flavours:
> - code-tree :: the releases tree is preserved as is, since it is
> a lot simpler for me to find changes across versions with find,
> grep et al.
> - code :: the releases tree is converted to git branches, which
> just proves, that it can be done.
>
> The repository at sourcehut is currently paid by me. Sourcehut
> has integration with email workflows, it is possible to have
> tickets and commits be handled by email to some extent, maybe
> completely. The web frontend works without javascript, which is
> why I am there with my private stuff as well.
>

I have played around with your git repos quite a lot this summer. I really
wanted the branches one to work so that each branch could have been tagged
and merged upward to the current state. That just won't work. There are far
too many breaking changes, or things that just didn't get captured as
commits or something. While it is nice to have all the releases easy to
swap to by changing branches, it's not really what branches are for. I have
to agree that the way things are with the releases off to the side is the
best solution.

I have not spent as much time poking around sourcehut but from what I did
see it is pretty much as listed on the tin, a git repo. If the cost is
relatively low I guess that isn't much of an issue but it would still need
to be integrated with the rest of the tools for bug reporting, discussions
etc. It seems like it could end up making more work and be even more
difficult to maintain long term or when more or less dormant.

That being said: I am still somewhat hesitant to move everything
> over, since I fear that the small community (think mailing list)
> might not resubscribe at the new place. I could be wrong though.
> And if a quorum of '3' is sufficient, go for it :)
>

lol, by definition '3' is probably too many to merely constitute a majority
;)
The point I was, as I'm sure you sussed out, is that I'd really like to
find out what people want to do, but also that something needs to be done
sooner rather than later. If it is only one person it is nothing more than
another splinter fork.


> I still offer to send authentication stuff regarding
> sourceforge.net to folks on this list. However, at the time
> nobody expressed interest.
>
>
> > 1. At least two people with write access to the repo for
> > redundancy.
> Tristan? Mark? Else?
>

If push comes to shove I 'can' probably manage to keep the lights on at SF.
I wouldn't like that to be the option we go with, but if there is no other
option than I will step up. But I do find SF to be dated and sort of
clunky. Also, as stated before, I detest this mailing list as the only way
to maintain a flow of communication with users and development. I do find
it a very handy resource to search though when having a problem but most of
that information could be integrated into the wiki pages that exist in
either an extension to the recipe section or similar. Not having a bug
tracker to me is a deal breaker. Even tha

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

Good morning AmForth'ers (feel free to adjust the greeting with your RTC).

disclaimer: I am going to cherry pick the commentary by Tristan for this
post. You can safely assume that the single quotes are their's and any
quoted quotes are mine unless noted. This thread is getting a little wound
up and I think it is important to be clear for anyone wanting to toss in
their vote about what to do. But we need to do something or I fear the
group will just finish dissolving.

> I am guessing you mean the SourceForge repo and the mailing list?
>
> Yes, my primary focus is the SF AmForth repo, website, community and
> mailing list.
>

This is I think the core of it all. When I first talked about getting a
working version of avra working with linux I was pleasantly surprised to
find a number of people pop in to talk about it. I fully expected to hear
from Tristan and Erich (hoped so anyway) since you both were the most
active at the end of the recent activity. That others are still subscribed
to this list and have an interest is great. This makes me think that we
very well could (should) form a quorum, which, in our depleted state could
be as little as 3. ;)

> The fact is that this project is still useful.
>
> I completely agree. AmForth is quite special as an embedded Forth in
> that it has wordlists, recognizers and comprehensive documentation.
>
> In suggesting a maintainer group the idea was that the effort required
> to preserve and update AmForth could be divided up, and perhaps if
> some of the more mundane aspects of avoiding bit rot are done, then
> people with more specialised skills, but less time, might feel more
> able to help.
>
> What would I suggest for the near term?
>

This seems to me to pretty much sum up a good mission statement of what
AmForth is and why it can continue to be viable. Even with ONLY the focus
on the AVR8 side of the repo, which is the core of it, adding more up to
date chips as Tristan mentions later is a great way to interest new people
and keep things from going to seed. So I'll sum up the points made and
expand where needed.

0. Where should the official repo be?
1. At least two people with write access to the repo for redundancy.
2. Make a 7.0 release at that time including
> a. the avra build
> b. an up to date version of the project makefile
> c. at least the first layers of documentation brought up to date
> d. the prebuilt hex files (really just a cleaning of the project
directory in general)
3. Deciding on a better way to communicate be it built in like github has
or something that goes hand in hand.
4. Discussing what it would take to continue on with something like the
RISC-V side of the repo.

So, that is the way I see it. I'd like to add right up front that while I
am not very skilled with forth I have spent a good deal of time learning
how to get better with it. It is pretty much the only language I have
studied these last couple of years. I am time rich so I will volunteer a
portion of that time if there is a viable way to make AmForth feel more
modern. To me right now it feels like an old dusty attic. There are still
great things to be discovered, but they are up a creaky flight of stairs,
in a poorly lit room and covered in a bit of dusty age. A big part of that
for me is the Source Forge side. I use git locally and github publicly
(although I have used a couple other flavors of public git when needed). I
am painfully aware that there are issues in using github. I get that, but I
like the overall tool and the fact there is no cost outlay to have
something anyone can get at. A bugtracker, discussions, wiki etc are things
I put a lot of value in when it comes to the choice if moving happens.

At the very least though, some sort of better way to communicate is
required. I love email but am finding more and more that less and less
people use it as a primary means of communication. So coupling that with
the somewhat more difficult method of the mailing list could perhaps, or
I'd say probably, be a deterrent for people, in particular new people, to
participate. I would like to have read and search access to all of the past
mailing list text though since there are a lot of really good conversations
and problem solving that have been done. If only to use that when bringing
the documentation up to date.

And that brings up a really big part of things, the documentation.
The entire thing needs to be edited and overhauled. I honestly don't care
what flavor of markup it uses. Most that I have used are similar enough
that a small cheat sheet is all that is needed to be good at it. I will
happily take a big part of that project once a decision has been reached on
where it will live. While doing this the source tree should be cleaned up
as well. There are some inconsistencies with the comments and stack effect
diagrams, some things like should it be .dw $ff03 or .dw $0003. I'm pretty
sure the former is the desired way since the newer files are like that, as
well as the way 

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

Here is the clean link.

https://github.com/CableGuy67/avra

On Mon, Sep 25, 2023 at 8:30 AM Mark Roth  wrote:

>
>
> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been
>
>> > updated since 2019. Maybe it's completed?
>>
>> At least the home page points to https://github.com/Ro5bert/avra which
>> has seen some commits since 2019.
>>
>
>  There were some PRs for that one that led to a development branch for
> another fork. I took that one and pushed them into main. You can find it
> here here at my github fork <https://github.com/CableGuy67/avra>.
>
> It builds with just a simple 'make' easily enough for me on Debian. I've
> even built it for Raspian successfully. There are a few little things that
> could be fixed but it does work and build AmForth in its current state
> (both avra and AmForth).
>
> Cheers,
> Mark
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

> Talking of maintenance, I note that avra (on Sourceforge) hasn't been

> > updated since 2019. Maybe it's completed?
>
> At least the home page points to https://github.com/Ro5bert/avra which
> has seen some commits since 2019.
>

 There were some PRs for that one that led to a development branch for
another fork. I took that one and pushed them into main. You can find it
here here at my github fork .

It builds with just a simple 'make' easily enough for me on Debian. I've
even built it for Raspian successfully. There are a few little things that
could be fixed but it does work and build AmForth in its current state
(both avra and AmForth).

Cheers,
Mark

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] avra on a raspi zero v1

[Mark Roth]

Hello all.

I managed to day to cobble together my AmForth "computer" which is pretty
much the reason for avoiding using wine to build things. It consists of a
raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian lite
on it. That has a usb hub, an old palm pilot folding keyboard the
connection to my uart for the controller and the usbasp to program. The
display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
that makes it possible to actually use it for real.

Tonight I managed to get all the cobbled bits to work together and to build
everything including avra on the zero then flash the controller. So, no
real computer but using e4thcom after flashing let me get in and use that
nice big screen as a terminal.

I still haven't sorted out the single tick thing but I can kind of see
where it is coming from in avra. Pretty sure my C skills have faded over
the decades that it may just be a problem to look past.

I guess now it's time to work on a nice box for the whole thing so I could
sit anywhere, plug in a powerbank and hack away. I'll try and get some
better documentation up soon but it really wasn't terribly difficult. It
was really really nice to do everything from Raspian knowing that wine
wasn't an option.

Enjoy the weekend,
Mark

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Maintainer(s) for AmForth

[Mark Roth]

Hello, Tristan (and all the rest of the community).
I am guessing you mean the SourceForge repo and the mailing list? I wish I
could offer more help with this but I am at a loss with the assembly stuff.
It would be nice to have the website info protected (amforth.sourceforge.net)
since there is so much good information there. And what to do about the
mailing list? I still search them for help now and again. Can it be
archived in some way? I know the website information is in the svn repo and
could be pulled out easily enough.

My bigger issue with making any changes to the assembler files is that I
have no way to test the MSP430 stuff. I can't seem to locate one of the
chips or boards to at least make sure it would work. It's also a pity that
the risc-v stuff wasn't further along since that does seem to be something
that would be useful.

So I would support in what minimal way I can. I know there are those of you
that have been here for a long time. The fact is that this project is still
useful. It just seems to work. So long as I have access to 8 bit avr chips
I'm sure I'll be playing around with AmForth. There is something about
thinking in forth that seems to be good for my aging brain. And there is no
denying that having register level access is great.

Mark

On Sun, Sep 10, 2023 at 6:05 PM tristan  wrote:

> Fellow AmForth-ers,
>
> Perhaps it is time again to consider having a formal maintainer for
> AmForth. Back in May 2022 Erich stepped down [1] and put in place
> various resources that could be potentially be used to maintain
> AmForth (in addition to those that already exist at sourceforge)
>
> To my knowledge, nobody from the mailing list has volunteered
> individually. Additionally, having a single maintainer does have its
> own issues. So perhaps a way forward would be to have a small group of
> maintainers for AmForth. The revelation from Mark R [2] that the latest
> AmForth can be made using avra does make a difference to me, such that I
> would volunteer for such a group. So are there others on the mailing
> list who would be willing to join such a maintainers group?
>
> Kind regards and best wishes,
> Tristan
>
> [1] https://sourceforge.net/p/amforth/mailman/message/37656453/
> [2] https://sourceforge.net/p/amforth/mailman/message/37887282/
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] AmForth github repo with avra

[Mark Roth]

I've been playing around when I had some time and put up a mirror of the
git repo Erich put up with all the releases as branches.
It can be found at https://github.com/CableGuy67/AmForth

Everything is included to make a copy appl/template and work from that.
Granted, if you already have a project you should just be able to fill in
the new makefile and use that in an existing appl/project.

The device directory that used to be in Atmel is now in the avr8/devices
directory. It just seemed to make more sense. I added the MIT notice that
you get when downloading the Series Support Pack there. The avrasm2.exe has
been moved to avr8/tools/avrasm. Next to that a simplified avra directory
that can build avra if it doesn't exist when you make install or just make.

I'll be playing around with some odds and ends I have in my notebooks and
will fill in the wiki with things I'm constantly looking for on the SF
site. I'm sure that there may be issues but I have used it to build both
with avra and avrasm getting identical output for the hex files.

Have a great weekend AmForth'rs,
Mark

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] successful compilation with avra

[Mark Roth]

Perhaps a howto on the site not as an email thread would be in order. This

> may not be a big deal for windows users, but people that want to use
> free-libre software will be drawn to use amforth if the entire build
> toolchain is FLOSS.
>

That is a very good suggestion. The whole thing is ridiculously simple but
having the steps set down, or better yet, cooked into the amForth repo
itself.

All I did was to clone the repo we were talking about then run 'make' from
the top of it. Since I am extraordinarily lazy this summer I didn't even
bother to install it somewhere into my PATH. I just made a link and copied
that into my project directory so I could change my makefile to
'./avra_amforth' because I'm a lazy old man and Debian. Then everything
else just works like it always did with avrasm2.

But yes, the proper way would be to have a version of avra that works maybe
in the tools directory that could be built once then used from there. But I
am at best an old hack not a proper programmer. Personally, my thought was
to fork into a github repo from the git stuff that is already done by Erich
and use that. I'm honestly very pleasantly surprised to see a number of you
all talking about this. I feared I was just yelling into the void (or
shaking my fists at clouds, choose your metaphor) when I put this up here.
There is so much great stuff on the Sourceforge site that is really helpful
to get spun up from scratch. Adding a 'How to use avra' would most
certainly be beneficial.

But, even I, a dedicated lover of email no matter how much the kids mock,
find the mailing list clunky to carry on conversations. I miss the ease of
issue pages. I do understand though that some people would be turned off by
github.

So anyhow, that is my 40 degree C afternoon rant. For some reason the gods
have decided that we need more heat in Greece again. I think the moving
forward part has to be decided by Erich if they want to add the avra stuff
into the repo. I have a few days until the end of the week that I will be
time rich so maybe I'll try to get a clean copy of the git work that has
been done and the avra stuff. I wish there was a real avra repo that we
could just mash into the source tree properly so it could be updated
correctly, but it seems more like a one off at this point. I know my debian
one is way way way old and I don't see that changing.

As always, all the best. I wish I would have discovered this project long
before I did.
Mark



> Brian-in-ohio
>
> On Mon, Aug 28, 2023 at 7:47 AM Jan Kromhout via Amforth-devel <
> amforth-devel@lists.sourceforge.net> wrote:
>
> > Hello,
> >
> > Seems simple to use the avra compiler.
> > Is it posible to show example how the build is doing?
> >
> > Cheers,
> >
> > Jan
> >
> > Verstuurd vanaf mijn iPad
> >
> > > Op 28 aug. 2023 om 09:02 heeft Mark Roth  het
> > volgende geschreven:
> > >
> > > You are using the same repo I was for avra Tristan. I just cloned the
> > > issue-54 branch and built it here. Apart from a couple of 'zero byte
> in a
> > > .DB' warnings things do seem to be working fine here as well.
> > >
> > >> On Mon, Aug 28, 2023 at 9:54 AM tristan  wrote:
> > >>
> > >> Hello,
> > >>
> > >> I flashed the hex files created by avra to an uno and, to the extent
> > >> that getting a serial prompt, defining a word and executing it
> > >> constitutes a test, it worked perfectly.
> > >>
> > >>> All that being said, I would be very interested to see the
> > >>> changes, maybe, just maybe we can fix the amForth source tree
> > >>> enough to make avra happy.
> > >>
> > >> No changes to the source tree were needed to create the uno hex files.
> > >> The only change made was to edit the Makefile to use avra.
> > >>
> > >> Best wishes,
> > >> Tristan
> > >>
> > >>
> > >>> On 2023-08-27 06:29, Tristan Williams wrote:
> > >>> Hello Mark, Brian, Erich, George
> > >>>
> > >>> Thank you! A very welcome set of messages on a bank holiday
> > >>> weekend. For non-windows users having avra as the assembler in the
> > >>> build chain would go along way in making AmForth more approachable
> and
> > >>> maintainable.
> > >>>
> > >>> I think this is the repo for avra that does not have the macro/
> > >>> parenthesis issue you mention[1]
> > >>>
> > >>> https://github.com/srtlg/avra/tree/development
> > >>>
> > >>> I downloaded it and built it on macOS (requiring only typing 'make')

Re: [Amforth] successful compilation with avra

[Mark Roth]

You are using the same repo I was for avra Tristan. I just cloned the
issue-54 branch and built it here. Apart from a couple of 'zero byte in a
.DB' warnings things do seem to be working fine here as well.

On Mon, Aug 28, 2023 at 9:54 AM tristan  wrote:

> Hello,
>
> I flashed the hex files created by avra to an uno and, to the extent
> that getting a serial prompt, defining a word and executing it
> constitutes a test, it worked perfectly.
>
> > All that being said, I would be very interested to see the
> > changes, maybe, just maybe we can fix the amForth source tree
> > enough to make avra happy.
>
> No changes to the source tree were needed to create the uno hex files.
> The only change made was to edit the Makefile to use avra.
>
> Best wishes,
> Tristan
>
>
> On 2023-08-27 06:29, Tristan Williams wrote:
> > Hello Mark, Brian, Erich, George
> >
> > Thank you! A very welcome set of messages on a bank holiday
> > weekend. For non-windows users having avra as the assembler in the
> > build chain would go along way in making AmForth more approachable and
> > maintainable.
> >
> > I think this is the repo for avra that does not have the macro/
> > parenthesis issue you mention[1]
> >
> > https://github.com/srtlg/avra/tree/development
> >
> > I downloaded it and built it on macOS (requiring only typing 'make')
> > and updated the AmForth Makefile to run arva. The updated makefile
> > built the hex files for an uno with AmForth 6.9. I did not experience
> > any issues with d0< but I recall there were some changes in that
> > area between 6.8 and 6.9. I've not flashed it yet as I have to dig out
> > an uno from storage but the hex files are the same size and with zero
> > diffs when compared with my previous wine/avrasm32 builds.
> >
> > -rw-r--r--  1 tw  staff  29346 26 Aug 17:53 uno.hex
> > -rw-r--r--  1 tw  staff  29346 26 Aug 16:29 save.hex
> > -rw-r--r--  1 tw  staff239 26 Aug 17:53 uno.eep.hex
> > -rw-r--r--  1 tw  staff239 26 Aug 16:29 save.eep.hex
> >
> >
> > Best wishes,
> > Tristan
> >
> > [1] https://github.com/Ro5bert/avra/issues/54
> >
> >
> > On 25Aug23 17:12, George Herzog wrote:
> >> Thanks for your efforts.
> >>
> >> People don't often appreciate how much knowledge and effort goes into
> >> successful compilation of code.
> >>
> >>
> >>
> >> On Fri, Aug 25, 2023, 3:15 PM Erich Wälde  wrote:
> >>
> >> > Hello Brian and Mark,
> >> >
> >> > very nice to see emails on this list :)
> >> >
> >> > Compiling amforth with avra?
> >> >
> >> > I have made numerous experiments a long time ago and again more
> >> > recently. If memory serves me well:
> >> > - Amforth had been good with avra, at least in the 4.x range.
> >> > - However, avrasm2.exe could do more clever tricks, and Matthias
> >> > started using those.
> >> > - I did make a fork of amForth from Version 5.0, this can be
> >> > assembled with avra, see:
> >> > https://git.sr.ht/~ew/hbv3_am50forth
> >> > - avra received a bit of attention not so long ago (same repo
> >> > you found):
> >> > https://github.com/Ro5bert/avra
> >> > > $ avra --version
> >> > > AVRA: advanced AVR macro assembler (version 1.4.2)
> >> > which among other changes now includes my favourite atmega644p.
> >> >
> >> > So, I am currently dabbling with my fork again in the hope to
> >> > eventually catch that problem of long term stability. There is
> >> > absolutely no reason, why I have to reprogram one or two of my
> >> > controllers a few times per year, because they do not start up
> >> > after a power cycle, which in turn is done, because the
> >> > communication with that controller ceases to work. I went back
> >> > to amforth 5.0 for simplicity reasons.
> >> >
> >> >
> >> > All that being said, I would be very interested to see the
> >> > changes, maybe, just maybe we can fix the amForth source tree
> >> > enough to make avra happy.
> >> >
> >> >
> >> > Cheers,
> >> > Erich
> >> >
> >> > Brian K Navarette  writes:
> >> >
> >> > > That is awesome news!
> >> > > Brian-in-ohio
> >> > >
> >> > >
> >> > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth 
> wrote:
> >>

Re: [Amforth] successful compilation with avra

[Mark Roth]

very nice to see emails on this list :)

I couldn't agree with you more. :)


> Compiling amforth with avra?
>
> I have made numerous experiments a long time ago and again more
> recently. If memory serves me well:
> - Amforth had been good with avra, at least in the 4.x range.
>

What I am talking about is a fork of the Ro3ert/avra that fixes issues with
the way the macros are called. It seems it was the fault of avra, not
Amforth that was causing the problem. The only problem locally was the 'Y'
vs the 'y' it needed to be. The fork I refer to can be found by looking at
the issues page of Ro3ert's repo and then getting the fix branch. It's
merely a cherry-picked pr. My local Amforth is 6.8 but I think I hand
applied all the stuff that would make it effectively 6.9. Pretty sure about
that.


> - However, avrasm2.exe could do more clever tricks, and Matthias
> started using those.
>

This is interesting. I've not dug deep into the outputted hex files apart
from flashing my controller with them. I do need to look at the addresses
of both hex files to see if there are issues. Part of the thing is that
with avrasm2.exe I was packing my nwwr section to within 5 words of
overflow. I want to see (they should, it is all .asm files) if they live at
the same locations. I should try to use your git repos for that. I have
cloned them locally since I prefer using git than svn.

All that being said, I would be very interested to see the
> changes, maybe, just maybe we can fix the amForth source tree
> enough to make avra happy.
>

It seems that the 'Y' to 'y' fix and the forked branch does do just that.

All the best to the list (and a good finish to the summer)
Mark


> Brian K Navarette  writes:
>
> > That is awesome news!
> > Brian-in-ohio
> >
> >
> > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth  wrote:
> >
> >> Hello AmForth. It has been some time and quite weird things since last
> I've
> >> been here. I am still using AmForth with my trusty atmega1284p and
> learning
> >> the language as time permits. I remember having heard talk that avra had
> >> gotten (almost) to the point of being able to compile the source tree
> here.
> >> First I tried with 1.3 I think and it failed miserably. Then I found a
> repo
> >> on github (Ro5bert/avra) that seemed to almost but not quite do it. I
> was
> >> getting a pile of errors for macro calls. So looking into the issues I
> saw
> >> that someone had forked that repo and fixed the issue. Something to do
> with
> >> not having a space between the opening parenthesis and the macro name.
> So I
> >> tracked down the fix branch (srtlg/avra -b development-issue54 if I
> >> remember correctly) and built that locally. Then substituted that avra
> >> version with the wine one I had been using to build.
> >> It still didn't build. Very almost, but not quite.
> >> However, the issue was with errors in /avr8/words/d-lesszero.asm about
> the
> >> Y register not being declared and/or able to be used for the adiw call.
> >> Looking into the source tree I found other usages of y in those calls
> but
> >> they were all in lower case.
> >> Yeah, that did fix it. I'm not sure that I can flash my controller here
> >> since I'm on summer break but it does seem promising. Or maybe I did
> pack
> >> my programmer and can give it a go. The file sizes are the same or
> similar
> >> but there are differences. Granted, I've made changes that may not be
> >> represented in my working project and it may just be that.
> >> Time will tell but it would be great to get rid of the need to use wine
> to
> >> build AmForth here.
> >> Well well well. It appears to have worked. I make install'd the whole
> thing
> >> (since for some reason I did pack my usbasp and could try it out. I'm
> sure
> >> more testing is needed but this really is pretty cool.
> >>
> >> ___
> >> Amforth-devel mailing list for http://amforth.sf.net/
> >> Amforth-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> --
> May the Forth be with you ...
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] successful compilation with avra

[Mark Roth]

Hello AmForth. It has been some time and quite weird things since last I've
been here. I am still using AmForth with my trusty atmega1284p and learning
the language as time permits. I remember having heard talk that avra had
gotten (almost) to the point of being able to compile the source tree here.
First I tried with 1.3 I think and it failed miserably. Then I found a repo
on github (Ro5bert/avra) that seemed to almost but not quite do it. I was
getting a pile of errors for macro calls. So looking into the issues I saw
that someone had forked that repo and fixed the issue. Something to do with
not having a space between the opening parenthesis and the macro name. So I
tracked down the fix branch (srtlg/avra -b development-issue54 if I
remember correctly) and built that locally. Then substituted that avra
version with the wine one I had been using to build.
It still didn't build. Very almost, but not quite.
However, the issue was with errors in /avr8/words/d-lesszero.asm about the
Y register not being declared and/or able to be used for the adiw call.
Looking into the source tree I found other usages of y in those calls but
they were all in lower case.
Yeah, that did fix it. I'm not sure that I can flash my controller here
since I'm on summer break but it does seem promising. Or maybe I did pack
my programmer and can give it a go. The file sizes are the same or similar
but there are differences. Granted, I've made changes that may not be
represented in my working project and it may just be that.
Time will tell but it would be great to get rid of the need to use wine to
build AmForth here.
Well well well. It appears to have worked. I make install'd the whole thing
(since for some reason I did pack my usbasp and could try it out. I'm sure
more testing is needed but this really is pretty cool.

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Mark Roth]

On Wed, Jun 2, 2021 at 6:37 PM Tristan Williams  wrote:

> Hi Michael,
>
> I used
>
> FUSE : -U lfuse:w:0xff:m -U hfuse:w:0x99:m -U efuse:w:0xff:m
>
> Best wishes,
> Tristan
>
> That makes sense. It's the same high fuse setting as I suggested but with
the jtag interface activated. I don't use that so I turned it off. Where
did you get the 0xDC setting for that fuse from? It really does seem to be
incorrect for a chip with 4k bootloader. Having just looked back into the
atmega2561 appl directory I just realized there isn't a makefile (or I
suppose, a bat file for windows) with the amforth defauts in it. I was just
getting ready to burn this into old 3D printer mega when I saw Tristan had
already done just that.

Good luck with the project!
Mark



> On 02Jun21 07:14, Placerville.me wrote:
> > Hello Tristan,
> > Thank you for this!  I will give it a try later today.  What fuse
> settings did you use?
> >
> > Kind regards,
> >
> > Michael
> >
> > Sent from my iPhone
> >
> > > On Jun 2, 2021, at 01:18, Tristan Williams  wrote:
> > >
> > > Hi Michael,
> > >
> > > I hope you got AmForth to build successfully under windows for the
> > > atmega2560, but if not, I have built it for my Arduino MEGA using the
> > > most recent source (r2457).
> > >
> > > https://sourceforge.net/p/amforth/code/HEAD/tree/trunk/
> > >
> > > I have uploaded the resulting hex files to
> > >
> > > https://tjnw.co.uk/amforth-bin/
> > >
> > > I also loaded marker.frt onto the Arduino MEGA and checked that it
> > > does what it should do (see [1]).
> > >
> > > Best wishes,
> > > Tristan
> > >
> > > [1] http://amforth.sourceforge.net/TG/recipes/Forget.html
> > >
> > >> On 24May21 17:57, Michael Picco wrote:
> > >> Hello Martin,
> > >> Thank you for responding!
> > >> In my work directory, which is aptly named 'amforth-6.9', I don't see
> a copy
> > >> of the template.asm file with "amforth-low.asm" mentioned.  The
> > >> amforth-low.asm file is referenced in the avr8 subdirectory.  Is there
> > >> something I am missing?
> > >>
> > >> Kind regards,
> > >> Michael
> > >>
> > >>
> > >>
> > >>
> > >>> On 5/24/2021 10:19 AM, Martin Nicholas via Amforth-devel wrote:
> > >>> The crucial file to include for an ATmega is the confusingly named:
> > >>> "amforth-low.asm" which needs to be un-commented in template.asm.
> > >>>
> > >>> All the code is then in low flash memory apart from the flash burning
> > >>> routine which should be found at NRWW_START_ADDR (0x01f000).
> > >>>
> > >>> Often, with a new device, you need to burn the fuses "make
> write-fuse",
> > >>> before flashing (and burning fuses for a second time) with "make
> > >>> install".
> > >>>
> > >>
> > >>
> > >>
> > >> ___
> > >> Amforth-devel mailing list for http://amforth.sf.net/
> > >> Amforth-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >
> > >
> > > ___
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amforth-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Newbie with a mega2560

[Mark Roth]

Hello. If your High fuse is set to 0xDC that is probably your problem. From
what I see that gives you a 1k boot section and Amforth is probably trying
to blast past that. I have some strange fails when I first flashed my 1284p
chips. Checking with a fuse calculator it looks like that chip should be D9
for a 4k boot section.

Here is a link to the calculator I used.
http://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega2560=E0=D9=FC=FF

Hope that is a bit helpful,
Mark

On Mon, May 24, 2021 at 11:47 AM tristan  wrote:

> Hi Michael,
>
> AmForth uses a dictionary to store the words it knows about. When
> AmForth recognises it has received a word over the serial line it tries
> to lookup that word in its dictionary. If it finds the word, it executes
> that word. If it does not, then it reports an error.
>
> In the file marker.frt is the definition for the word marker. This word
> will create a word that will manipulate the dictionary. See this link
> below
>
> http://amforth.sourceforge.net/TG/recipes/Forget.html
>
> Your AmForth system is indeed corrupted (and will need to be
> re-flashed). Why it has become corrupted needs some more investigation.
> Perhaps there is a word that marker relies on that is missing from your
> hex build, perhaps you made a typo when typing in the definition,
> perhaps you have found a bug[a]. I would
>
> 1. Re-flash the board
> 2. Connect over serial, check that word lists the dictionary, define a
> trivial word e.g. : xx 1 + ; and check that it works and can be listed
> in the dictionary.
> 3. Use amforth-shell.py to load avr8/lib/forth2012/core-ext/marker.frt
> 4. Repeat 2.
> 5. Do the example in
> http://amforth.sourceforge.net/TG/recipes/Forget.html
>
> Best wishes,
> Tristan
>
> [a] I use marker very frequently on atmega328p but not on the atmega2560
>
>
>
> On 2021-05-24 00:02, Michael Picco wrote:
> > Thank you for that.
> > Reading up on them yields:
> > not found ... the position in the input line indicates the system
> > choked on the word 'words'.
> >
> > words is part of the flashed system.
> >
> > This indicates (to me) that something got corrupted.  I can only
> > wonder if memory got overwritten somehow.  Is there a setting required
> > prior to flashing that I'm failing to set properly?
> >
> > Thanks in advance!
> >
> > On 5/22/2021 9:51 PM, George Herzog wrote:
> >> There are AmForth error codes. Read up on them.
> >>
> >> On Sun, May 23, 2021, 12:42 Michael Picco 
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> I seem to have stumbled across an issue.
> >>>
> >>> First code I wrote was to blink the LED onboard.  This worked just
> >>> fine.
> >>> Then I went to add 'marker'.  Entered it line-by-line ... got the
> >>> 'Ok'
> >>> after each line.  After adding the last line (semicolon), the board
> >>> froze up.  Did a warm boot and then executed 'words' to see what was
> >>> there.  It came back with ?? -13 5.
> >>>
> >>> What came to mind is perhaps not enough memory is allocated prior to
> >>> flashing and I'm overwriting something I shouldn't.
> >>>
> >>> Any ideas?
> >>>
> >>> Kind regards,
> >>>
> >>> Michael
> >>>
> >>> On 5/21/2021 1:28 AM, tristan wrote:
>  Hi Michael,
> 
>  Apologies. My memory is failing me.
> 
>  The LED is on D13 for both UNO and MEGA, but D13 is mapped to PB5
>  (PORTB bit 5) on the UNO and PB7 (PORTB bit 7) on the MEGA.
> 
>  Best wishes,
>  Tristan
> 
> 
>  On 2021-05-21 08:54, tristan wrote:
> > Hi Michael,
> >
> >> I do not see the word 'marker' defined. Should it have been part
> >> of
> >> the basic system, or do I need to pull it from somewhere?
> > It is not part of the basic system, it is defined in this file.
> >
> > avr8/lib/forth2012/core-ext/marker.frt
> >
> > Using marker is efficient/good practice/etc. but it is not a
> > necessary
> > requirement to do below.
> >
> >> Then I'd like to see about doing something real simple, like
> >> turning
> >> an LED on/off.  It's sort of a hardware person's approach to
> >> 'Hello
> >> World!'  :)
> > http://amforth.sourceforge.net/TG/recipes/Arduino-HelloWorld.html
> >
> > IIRC the MEGA and UNO have the built-in led on the same pin (port
> > bit).
> >
> > The definitions for the chip can be found in this file
> >
> > avr8/devices/atmega2560/atmega2560.frt
> >
> > These, or extracts from, will need to be loaded into the basic
> > system.
> > So longer term, being able to load forth definition
> > non-interactively
> > from a file is very useful. There are programs in the tools
> > directory
> > - amforth-shell.py being the one I use.
> >
> >
> > Best wishes,
> > Tristan
> >
> >
> >
> > On 2021-05-21 05:25, Michael Picco wrote:
> >> Hello,
> >>
> >> As mentioned earlier, it's now working.
> >> I do not see the word 'marker' defined.  Should it have been 

Re: [Amforth] [Solved] @ vs c@ (was: rshift not zero padded)

[Mark Roth]

Hello Erich,

so you found the subtle difference between @ and c@, congrats! :-)
>
> Mark Roth writes:
> > So because of grabbing a word it seems that I was bringing in the PINB
> > register as well that had a value in it. So that is where the extra bits
> > came from.
>

Yeah that was just a rookie error there. I had it so stuck in my head that
the port register was 8 bits, where could the rest possibly be coming from?
Of course it grabbed it's neighbor. That was what I told it to do. It was a
good lesson about words though.

Numbers: Over time I have adopted the style to prefix each and
> every number except for 0 and 1. I have been in the situation
> too often, that base was not 10 like expected but rather 16.
>
> >: cylon
> > $ff ddra c! 1 porta c!
> > begin #40 ms
> > #7 0 do porta c@ 2* porta c! #40 ms loop
> > #7 0 do porta c@ 2/ porta c! #40 ms loop
> > key? until ;
>
>
This is good advice and serves to document in place just what you wanted
for when you have to come back to it. I'll have to try that from now on.
Thanks! I was going to add that perhaps I'll only do it with 2 digit
numbers, but it occured to me that you do it with anything higher than 1 so
that if the base is set to BIN your code could never accidentally choke.

>

> Cheers,
> Erich
> --
> May the Forth be with you ...
>

Slowly, ever so slowly it is. Since my son was playing along as well and
wanted to change the speeds we made a few modifications. With your other
advice and an added safety catch so we wouldn't have to reset so often. The
binary representations of the port values were to show him exactly what we
were doing. All in all a bit of learning all around.

: cy-delay( n -- n )
dup ms
;

: cylon( n -- )
depth if
% ddra c!  %0001 porta c!
begin
#7 0 do porta c@ 2* porta c! cy-delay loop
#7 0 do porta c@ 2/  porta c! cy-delay loop
key? until drop % porta c!
then
;

Now to make it smarter so it reverses when it hits the endstops. We are
following along with the Junk Box Arduino stuff since the projects are
pretty simple and make a nice bridge from C to Forth.

All the best,
Mark

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation quo vadis?

[Mark Roth]

st likely many already exist) and run the refcard script against
> > > them while building for the website (or perhaps even locally, it won't
> take
> > > much time) then using that to create an array of refcards that could be
> > > grouped together as web pages. The point is, that amforth.asm will
> dictate
> > > what a more or less default system will be and that can be used for the
> > > site.
> >
> > Yes, I would agree - with board level customisation in uno.asm etc as
> > it is currently. A refcard reflecting the built-in words of hex file
> > created, be that built locally or pre-built on the website.
> >
> > With the current AmForth and AVR8 it is likely the built-in refcards for
> > appl/arduino boards would be very similar - if not identical.
> >
> > So for an AVR8 builtin-ref card I think this is needed
> >
> > 1. Compliant doc headers for all the .asm files
> > 2. Modify the perl script to write out refcard as desired in the desired
> formats
> > 3. Connect this to the build system
> > 4. Connect the pre-built hex files and their refcards to the main
> documentation
> >
> > All can be done for a local build setup, but most value would be with
> > 1 and 4 done at the distribution/website level.
> >
> > Best wishes,
> > Tristan
> >
> > [1] https://sourceforge.net/p/amforth/mailman/message/37054617/
> > [2]
> http://amforth.sourceforge.net/faq.html#there-are-no-hexfiles-in-the-distribution-archive
> >
> >
> > On 08Sep20 13:14, Mark Roth wrote:
> > > Hello Tristan, Erich and fellow lurking AmForthers (I really do like
> this
> > > intro Tristan) :)
> > >
> > > It really does seem that you may have caught the tiger by the tail
> Tristan.
> > > For better or for worse even!
> > >
> > > For the better (hey, you caught the tiger) :
> > > I think your layout really goes a long way toward documenting the used
> > > words. The last few days before I saw your mail I had been thinking of
> this
> > > very thing, to use the local build for the refcard. I hadn't, however,
> seen
> > > the obvious which was to use the list file. I used it when I was
> trying to
> > > find what was compiled into the base system and then finding useful
> > > assembly files to build into my hex. It's funny how a new set of eyes
> sees
> > > the obvious. Well played indeed.
> > > A few things of note from your examples. Since the items will most
> likely
> > > be listed by category the "category:" would be redundant. It also would
> > > seem pretty trivial to remove the "C:" or "R:" from the stack effects
> if
> > > they were to be listed in the way you have. It makes it very clear
> what is
> > > going on as well as being consistent. Having the location of the asm
> file
> > > is super. Too many times I'm searching my local system for just that
> very
> > > thing. Of course it is listed in the lst file which makes perfect
> sense to
> > > show it. It could even open the door to having a location to forth
> source
> > > files there as well. It would just be a matter of putting the location
> in
> > > the comments in some way. I know you have shown interest in having that
> > > easy to find as well Erich. Perhaps something like that could be a good
> > > compromise?
> > > I have a file in my appl directory that I use to upload everything I
> add
> > > after burning a new hex into the controller. It is just a list of
> locations
> > > for files that get added after the fact. It would seem that something
> like
> > > this could even be added into the documentation process. Say perhaps,
> to
> > > give an upload file name to the script before running so it could
> parse out
> > > the frt files that will be added after. Of course, that would mean they
> > > would have to have some consistent system of comments as well... In any
> > > case, it does open that door.
> > >
> > > And for the worse:
> > > This does drastically change what the current refcard is. That is to
> say,
> > > right now it was just a dump of the base system without regard to
> usage,
> > > more to availability. For the website there would have to be cards
> > > generated for different architectures and perhaps even NWWR sizes. So,
> what
> > > to do? Maybe the easiest would be to have some generic setups in the
> appl
> > > dir (most likely many already exist) and run the refcard script again

Re: [Amforth] rshift not zero padded

[Mark Roth]

So because of grabbing a word it seems that I was bringing in the PINB
register as well that had a value in it. So that is where the extra bits
came from.

: cylon
> $ff ddra c! 1 porta c!
> begin 40 ms
> 7 0 do porta c@ 2* porta c! 40 ms loop
> 7 0 do porta c@ 2/ porta c! 40 ms loop
> key? until ;


So this works exactly as I wanted it to. I am really starting to understand
the value of interactive debugging by just running each line to see what is
going on. Once I looked at the stack while stepping it made perfect sense.

All the best,
Mark

On Sat, Sep 19, 2020 at 9:55 AM George Herzog 
wrote:

> It's a common display situation in Forth. Leading zeros aren't display,
> even when they exist.
>
> On Sat, Sep 19, 2020, 2:24 AM Mark Roth  wrote:
>
> > Is there a reason that when using rshift or 2/ the most significant bit
> > isn't zero padded? lshift and 2* do this correctly. I was trying to
> > implement a simple back and forth led on a port by starting with a value
> of
> > 1 in the the port. Moving from right to left in the port works perfectly
> > but when moving from left to right using either rshift or 2/ every other
> > bit is set high so after a couple of back and forths the port is filled
> > with 1s.
> >
> > I can see that the lshift says it is zero padded but the rshift doesn't
> say
> > that it is. Is there a reason for this? The 2012 specs seem to say that
> > rshift is zero padded as well.
> > http://lars.nocrew.org/forth2012/core/RSHIFT.html
> >
> > Perhaps it's just my noob code that is the problem.
> >
> > : cylon
> > > $ff ddra ! 1 porta !
> > > begin 40 ms
> > > 8 0 do porta @ 2* porta ! 40 ms loop
> > > 8 0 do porta @ 2/ porta ! 40 ms loop
> > > key? until ;
> >
> >
> > It appears to work correctly in one direction but not the other.
> >
> > Thanks,
> > Mark
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] rshift not zero padded

[Mark Roth]

Okay, hmm. It seems to be because even when I store a value of $80 in
PORTA, if I read it right back like that I'm getting a word. Which is
actually what I'm asking it for by using @. So I would read back $ED80.
Changing it to use the byte size  c* and c! was the problem there.

Thanks,
Mark

On Sat, Sep 19, 2020 at 9:55 AM George Herzog 
wrote:

> It's a common display situation in Forth. Leading zeros aren't display,
> even when they exist.
>
> On Sat, Sep 19, 2020, 2:24 AM Mark Roth  wrote:
>
> > Is there a reason that when using rshift or 2/ the most significant bit
> > isn't zero padded? lshift and 2* do this correctly. I was trying to
> > implement a simple back and forth led on a port by starting with a value
> of
> > 1 in the the port. Moving from right to left in the port works perfectly
> > but when moving from left to right using either rshift or 2/ every other
> > bit is set high so after a couple of back and forths the port is filled
> > with 1s.
> >
> > I can see that the lshift says it is zero padded but the rshift doesn't
> say
> > that it is. Is there a reason for this? The 2012 specs seem to say that
> > rshift is zero padded as well.
> > http://lars.nocrew.org/forth2012/core/RSHIFT.html
> >
> > Perhaps it's just my noob code that is the problem.
> >
> > : cylon
> > > $ff ddra ! 1 porta !
> > > begin 40 ms
> > > 8 0 do porta @ 2* porta ! 40 ms loop
> > > 8 0 do porta @ 2/ porta ! 40 ms loop
> > > key? until ;
> >
> >
> > It appears to work correctly in one direction but not the other.
> >
> > Thanks,
> > Mark
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] rshift not zero padded

[Mark Roth]

Is there a reason that when using rshift or 2/ the most significant bit
isn't zero padded? lshift and 2* do this correctly. I was trying to
implement a simple back and forth led on a port by starting with a value of
1 in the the port. Moving from right to left in the port works perfectly
but when moving from left to right using either rshift or 2/ every other
bit is set high so after a couple of back and forths the port is filled
with 1s.

I can see that the lshift says it is zero padded but the rshift doesn't say
that it is. Is there a reason for this? The 2012 specs seem to say that
rshift is zero padded as well.
http://lars.nocrew.org/forth2012/core/RSHIFT.html

Perhaps it's just my noob code that is the problem.

: cylon
> $ff ddra ! 1 porta !
> begin 40 ms
> 8 0 do porta @ 2* porta ! 40 ms loop
> 8 0 do porta @ 2/ porta ! 40 ms loop
> key? until ;


It appears to work correctly in one direction but not the other.

Thanks,
Mark

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] download.zip strangeness

[Mark Roth]

Because the zip is the Release package and the SVN is the Dev package I
would guess. The end user that isn't going to do anything more than grab
the zip, add the AVR stuff, quick scan the readme, go to the
APPL directory, make a copy of the template, hit make install (hopefully
after reading what needs to be changed to get the correct hex files) and
never do anything else but upload extra FRTs as needed.

To build the docs you need a lot (a real lot) of extra packages. The real
question is, "How are the zips created?"

All the best,
Mark

On Thu, Aug 27, 2020 at 10:50 PM Erich Wälde  wrote:

>
> Hello all,
>
> Martin B. found out that the content of the download.zip files
> is  different from the content of the svn checkout. For example
> ./doc/Makefile is not present. However, the zip file has more
> files alltogether:
>
>
> $ find releases/6.8 -type f | wc -l
> 2389
>
> $ find ./amforth-6.8 -type f | wc -l # from download-6.8.zip
> 2537
>
> So the content is different somehow.
>
> Anyone have any insight/ideas?
>
> This seems to be an item for the upcoming AmForth weekend,
> /me thinks ...
>
>
> Cheers,
> Erich
>
> --
> May the Forth be with you ...
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation quo vadis?

[Mark Roth]

On Sat, Aug 1, 2020 at 10:50 PM Erich Wälde  wrote:

> thread hijacked intentionally.
>
'Thar be pirates!


>
> today I spent some time trying to understand the "make-refcard*"
> scripts in some detail.
>
> The script works roughly like this:
>
> 

> - the first three lines are comments expected to produce
>   1. the stack effects (data, return, compile stacks)
>   2. the category to which this word belongs
>   3. a one line description, what this word is supposed to do.
>
>
Indeed. It also happens to be the reason the perl script works so well, as
well as being so easy to break. It's just too rigid. One thing that the
original has as well is that the 4th line needs to be the "VE" or "XT"
part. If it isn't it will fail. That was the reason for poking around with
the 3 prior lines part of the the script and hardwiring it for the first 3
lines.


>
> Now I could commit Marks patches and not look further. However, there
> are several shortcomings with the current state.
>
> Yeah, don't do that. I really just put up the diff as a reference for
someone that knows Perl. At best right now I would say you could replace
the very outdated refcard.html with the one my changes generate. It is an
improvement just because of the age difference (5.5 to 6.8). For the long
term however, this tool needs to either be fixed entirely or replaced with
something that the build system can use. Having a refcard generated
directly from the source tree is fantastic IMHO.


>
> - The script will currently only read "one" directory, whereas we have
>   several directories with /different/ asm styles!
>   - arm/words/-- gnu asm style
>   - avr8/words/   -- avr asm style
>   - common/words/ -- avr, msp430 asm style with .if directives
>   - msp430/words/ -- msp430 asm style
>   - risc-v/words/ -- riscv asm style
>   - shared/words/ -- looks like some macro style for generators
>
> - The generated output (LaTeX, ReST) is done with two different
>   scripts.
>
> - The generated output does currently not have any indication, on
>   which ports a particular word is available.
>
> This gets to the guts of how to march from here (Google's rendition of the
Latin in the title). Each of the flavors could be determined from their
location in the source tree. The additional information would have to be
added to the hash tables and the generation end would have to be made aware
of all this of course. But in those cases it would seem that you would just
end up with a mess of duplication. The script would need to determine if
something exists already then act accordingly. However, what would be
appropriate? How do you deal with differences in the stack effects because
of the platform? It seems that the end user would be better served if they
could just pull up their flavor of refcard and be done with it. As you
mentioned, right now it is the AVR8 refcard. I don't know how different
each platform is since I am personally only concerned with the AVR one. But
there is of course a wider audience out there and each needs to be dealt
with equally. Having individual refcards would seem to align with the way
that the website documents already work for the different platforms
(sections for linux and windows etc) so that is where I'd cast my vote.


> - The script will currently not read any forth code. And words like
>   "value" or "c," should show up in the refcard as well, shouldn't
>   they? And should the refcard not have the information that you have
>   to include one of these files:
>   :avr8/lib/forth2012/core/c-comma.frt
>   : msp430/lib/forth-2012/core/c-comma.frt
>
>   I kind of remember that Matthias decided to move some code from the
>   pre-assembled form /back/ to pure Forth. This was in order to help
>   dealing with the new, additional architectures.
>
> - in the .asm files I would also like to see a pure Forth equivalent
>   as a comment. I have missed this in the past already.
>
> It seems that the intent of the refcard was to document the things that
are compiled into the system. Since the Forth source code could be nearly
anything AND has to be uploaded after the hex files are uploaded to the
device you are now entering into the realm of full generated documentation.
In that case it may be better to look into something like Doxygen (or
whatever the kids are using these days) and properly generate all that. Of
course that would take a one time scouring of all the sources to align with
something of that nature.
As for the Forth source in the asm file I'm not sure about that. I think
I'd rather see the .frt file alongside the .asm file. That is just personal
preference though and I can see the value in having them together. It does
seem like it could complicate the build and/or uploading process.

;tldnr
Perl script needs to be updated entirely by someone fluent.
Sources need to be properly commented for the refcard/doc generation.
Maybe define the style to be used (indentation, tabs, spaces etc) for the
sources.
Forth source for 

Re: [Amforth] Ref Card Generation -- working hack

[Mark Roth]

I may as well be complete.
http://ipreferpi.eu/DL/padding.diff

Those are the fixes for the padding warnings while building. Not really
terribly important but better all the way than half-way there.
This one though actually supersedes the other for ud-star.asm and
q-negate.asm since they have a lesser change in the first diff I posted.
Their fixes of adding the ",0" are on lines 12 and 15 respectively and
could just be fixed manually.

Now I'm really done and the weekend is still half a day away.

On Fri, Jul 17, 2020 at 1:20 PM Mark Roth  wrote:

> ugh, ignore the ">" at the start of the script lines obviously. I had the
> whole mess quoted so it made a mockery of things.
>
> On Fri, Jul 17, 2020 at 12:40 PM Mark Roth  wrote:
>
>> I cleaned up my diff of the svn (amforth-code) and put it up to see if it
>> would be helpful. Be sure to look through the comments on the changed .asm
>> files. In particular the description on abort-string.asm. I'm not seeing
>> the -2 error and that is a set of comments I pulled from an older revision.
>> It can be found here.
>> http://ipreferpi.eu/DL/mywork.diff
>>
>> To build the refcard page using the (mostly) original script I had to
>> resort to dumping the avr8 and common words into a big pile and let the
>> perl voodoo do what it do.  So, that is my disclaimer that it is an avr8
>> AmForth Refcard only. One could use the same technique to make the other
>> flavors as well I suppose.  To do that I just made a little helper script
>> that I run from the doc directory.
>>
>> #!/bin/bash
>>> mkdir ../tempwords
>>> cp -r ../common/words ../tempwords
>>> cp -r ../avr8/words ../tempwords
>>> cd ../tools/ ; perl make-refcard-rst ; cd ../doc
>>> make htdocs
>>> #make onlyepub
>>> rm -r ../tempwords
>>
>>
>> It does the trick for me locally anyhow.
>>
>> So that completes my AmForth conversion via AmForth Weekend 1
>> :P
>>
>> All the best (until the next one),
>> Mark
>>
>>
>> On Thu, Jul 16, 2020 at 11:02 AM Mark Roth  wrote:
>>
>>> Of those you see in the list, there are about 20 .asm files that aren't
>>> included in even the 8k core build. I jammed about a dozen of them into my
>>> appl_core dictionary include file just to try and fill it up. Plus of
>>> course the hardware drivers that wouldn't be included anyhow if you don't
>>> need them. I should probably go through my notes and start making patches
>>> for all the files I changed so they can be vetted. I'm sure I made some
>>> errors (or just didn't know from looking at the comments) that would need
>>> to be sorted out. :)
>>>
>>> On Thu, Jul 16, 2020 at 9:53 AM Tristan Williams 
>>> wrote:
>>>
>>>> Hello Mark,
>>>>
>>>> Brilliant! There are AmForth words there I hadn't realised it had.
>>>>
>>>> Best wishes,
>>>> Tristan
>>>>
>>>> On 16Jul20 00:49, Mark Roth wrote:
>>>> > It's almost there at least as a page that can temporarily replace the
>>>> > temporary v5.5 one. This is generated from the current svn sources and
>>>> > consists of the avr8 and common words directories. I cleaned up as
>>>> many of
>>>> > the files that I could (and those will for sure need some Forth eyes
>>>> on
>>>> > them) by taking info from older versions when the comment block was
>>>> > missing. The entire thing is generated by copying the avr8/words and
>>>> > common/words into a temp directory then running the refcard python
>>>> file
>>>> > against that. You can take a look at it here.
>>>> > http://ipreferpi.eu/htdocs/TG/refcard.html
>>>> >
>>>> > On Mon, Jul 13, 2020 at 10:19 PM Mark Roth 
>>>> wrote:
>>>> >
>>>> > > I see there are a few duplicates but I'm not really sure why. Like
>>>> > > RECOGNIZE from recognize.asm. It must have something to do with the
>>>> way the
>>>> > > msp430 header is formatted that is different from other ones since
>>>> it isn't
>>>> > > all of them. I'm sure it is in that voodoo of slashes somewhere...
>>>> > >
>>>> > > all the best,
>>>> > > Mark
>>>> > >
>>>> > >>
>>>> > >> CLIPPED
>>>> >
>>>> > ___
>>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>>> > Amforth-devel@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> >
>>>>
>>>>
>>>> ___
>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> Amforth-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>>
>>>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation -- working hack

[Mark Roth]

I cleaned up my diff of the svn (amforth-code) and put it up to see if it
would be helpful. Be sure to look through the comments on the changed .asm
files. In particular the description on abort-string.asm. I'm not seeing
the -2 error and that is a set of comments I pulled from an older revision.
It can be found here.
http://ipreferpi.eu/DL/mywork.diff

To build the refcard page using the (mostly) original script I had to
resort to dumping the avr8 and common words into a big pile and let the
perl voodoo do what it do.  So, that is my disclaimer that it is an avr8
AmForth Refcard only. One could use the same technique to make the other
flavors as well I suppose.  To do that I just made a little helper script
that I run from the doc directory.

#!/bin/bash
> mkdir ../tempwords
> cp -r ../common/words ../tempwords
> cp -r ../avr8/words ../tempwords
> cd ../tools/ ; perl make-refcard-rst ; cd ../doc
> make htdocs
> #make onlyepub
> rm -r ../tempwords


It does the trick for me locally anyhow.

So that completes my AmForth conversion via AmForth Weekend 1
:P

All the best (until the next one),
Mark


On Thu, Jul 16, 2020 at 11:02 AM Mark Roth  wrote:

> Of those you see in the list, there are about 20 .asm files that aren't
> included in even the 8k core build. I jammed about a dozen of them into my
> appl_core dictionary include file just to try and fill it up. Plus of
> course the hardware drivers that wouldn't be included anyhow if you don't
> need them. I should probably go through my notes and start making patches
> for all the files I changed so they can be vetted. I'm sure I made some
> errors (or just didn't know from looking at the comments) that would need
> to be sorted out. :)
>
> On Thu, Jul 16, 2020 at 9:53 AM Tristan Williams  wrote:
>
>> Hello Mark,
>>
>> Brilliant! There are AmForth words there I hadn't realised it had.
>>
>> Best wishes,
>> Tristan
>>
>> On 16Jul20 00:49, Mark Roth wrote:
>> > It's almost there at least as a page that can temporarily replace the
>> > temporary v5.5 one. This is generated from the current svn sources and
>> > consists of the avr8 and common words directories. I cleaned up as many
>> of
>> > the files that I could (and those will for sure need some Forth eyes on
>> > them) by taking info from older versions when the comment block was
>> > missing. The entire thing is generated by copying the avr8/words and
>> > common/words into a temp directory then running the refcard python file
>> > against that. You can take a look at it here.
>> > http://ipreferpi.eu/htdocs/TG/refcard.html
>> >
>> > On Mon, Jul 13, 2020 at 10:19 PM Mark Roth 
>> wrote:
>> >
>> > > I see there are a few duplicates but I'm not really sure why. Like
>> > > RECOGNIZE from recognize.asm. It must have something to do with the
>> way the
>> > > msp430 header is formatted that is different from other ones since it
>> isn't
>> > > all of them. I'm sure it is in that voodoo of slashes somewhere...
>> > >
>> > > all the best,
>> > > Mark
>> > >
>> > >>
>> > >> CLIPPED
>> >
>> > ___
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amforth-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >
>>
>>
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation -- working hack

[Mark Roth]

Of those you see in the list, there are about 20 .asm files that aren't
included in even the 8k core build. I jammed about a dozen of them into my
appl_core dictionary include file just to try and fill it up. Plus of
course the hardware drivers that wouldn't be included anyhow if you don't
need them. I should probably go through my notes and start making patches
for all the files I changed so they can be vetted. I'm sure I made some
errors (or just didn't know from looking at the comments) that would need
to be sorted out. :)

On Thu, Jul 16, 2020 at 9:53 AM Tristan Williams  wrote:

> Hello Mark,
>
> Brilliant! There are AmForth words there I hadn't realised it had.
>
> Best wishes,
> Tristan
>
> On 16Jul20 00:49, Mark Roth wrote:
> > It's almost there at least as a page that can temporarily replace the
> > temporary v5.5 one. This is generated from the current svn sources and
> > consists of the avr8 and common words directories. I cleaned up as many
> of
> > the files that I could (and those will for sure need some Forth eyes on
> > them) by taking info from older versions when the comment block was
> > missing. The entire thing is generated by copying the avr8/words and
> > common/words into a temp directory then running the refcard python file
> > against that. You can take a look at it here.
> > http://ipreferpi.eu/htdocs/TG/refcard.html
> >
> > On Mon, Jul 13, 2020 at 10:19 PM Mark Roth  wrote:
> >
> > > I see there are a few duplicates but I'm not really sure why. Like
> > > RECOGNIZE from recognize.asm. It must have something to do with the
> way the
> > > msp430 header is formatted that is different from other ones since it
> isn't
> > > all of them. I'm sure it is in that voodoo of slashes somewhere...
> > >
> > > all the best,
> > > Mark
> > >
> > >>
> > >> CLIPPED
> >
> > ___
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation -- working hack

[Mark Roth]

It's almost there at least as a page that can temporarily replace the
temporary v5.5 one. This is generated from the current svn sources and
consists of the avr8 and common words directories. I cleaned up as many of
the files that I could (and those will for sure need some Forth eyes on
them) by taking info from older versions when the comment block was
missing. The entire thing is generated by copying the avr8/words and
common/words into a temp directory then running the refcard python file
against that. You can take a look at it here.
http://ipreferpi.eu/htdocs/TG/refcard.html

On Mon, Jul 13, 2020 at 10:19 PM Mark Roth  wrote:

> I see there are a few duplicates but I'm not really sure why. Like
> RECOGNIZE from recognize.asm. It must have something to do with the way the
> msp430 header is formatted that is different from other ones since it isn't
> all of them. I'm sure it is in that voodoo of slashes somewhere...
>
> all the best,
> Mark
>
>>
>> CLIPPED

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] Ref Card Generation -- working hack

[Mark Roth]

I do see that the lists don't get properly sorted either. Still very
rough...

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Ref Card Generation -- working hack

[Mark Roth]

I see there are a few duplicates but I'm not really sure why. Like
RECOGNIZE from recognize.asm. It must have something to do with the way the
msp430 header is formatted that is different from other ones since it isn't
all of them. I'm sure it is in that voodoo of slashes somewhere...

all the best,
Mark

On Mon, Jul 13, 2020 at 10:09 PM Mark Roth  wrote:

> So here is a working hack to make a refcard with both the avr8/works and
> common/words directory. Since I don't even sort of speak Perl I'll leave
> any real fixes to someone who does. However, I made a few notes pointing
> out the things that were the issue before.
> There is still the issue of files that don't have the 3 lines at the top
> of stack effects, category and description. It is easy to see which files
> need to be fixed so they can be scanned correctly. The ones in the
> unclassified group at the end can be a little tougher to find. I had to
> search for <.db "-1"> to find that one in num-constants.asm. Those did fail
> pretty gracefully though.
>
> tl;dnr
> This works in a hackish sort of way. Still work to do but closer now.
>
> = START make-refcard-rst ===
>
> #!/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;
>
> my $version="6.9";
>
> my $texdir="../doc/source/TG";
>
> my $asmdir="../common/words";
> my $devasmdir="../avr8/words";
>
> sub readASM {
>   my ($filename) = @_;
>   open(ASM, $filename) or die ("$filename: $!\n");
>   my @ASM = ;
>   close(ASM);
>   my $ASM = "";
>   my ($lbl, $state, $voc, $xt, $dstack, $rstack, $cstack, $category,
> $typeof);
>   my ($line1, $line2, $line3, $description) = ("","","", "");
>
>   # Added to try and remove the prevline issues
>   # before fixing correctly.
>   $line1 = $ASM[0]; # stack--effects
>   $line2 = $ASM[1]; # category
>   $line3 = $ASM[2]; # description
>
>   # From this point on all prevline vars are now:
>   # prevline3 is now $line1
>   # prevline2 is now $line2
>   # prevline1 is now $line3
>   # This change is just to clarify that the first three
>   # lines have to be the info we are looking for. It was
>   # how it worked before but more loosly bound.
>
>   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;
>   }
>   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";
&g

[Amforth] Ref Card Generation -- working hack

[Mark Roth]

So here is a working hack to make a refcard with both the avr8/works and
common/words directory. Since I don't even sort of speak Perl I'll leave
any real fixes to someone who does. However, I made a few notes pointing
out the things that were the issue before.
There is still the issue of files that don't have the 3 lines at the top of
stack effects, category and description. It is easy to see which files need
to be fixed so they can be scanned correctly. The ones in the unclassified
group at the end can be a little tougher to find. I had to search for <.db
"-1"> to find that one in num-constants.asm. Those did fail pretty
gracefully though.

tl;dnr
This works in a hackish sort of way. Still work to do but closer now.

= START make-refcard-rst ===

#!/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;

my $version="6.9";

my $texdir="../doc/source/TG";

my $asmdir="../common/words";
my $devasmdir="../avr8/words";

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

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

  # From this point on all prevline vars are now:
  # prevline3 is now $line1
  # prevline2 is now $line2
  # prevline1 is now $line3
  # This change is just to clarify that the first three
  # lines have to be the info we are looking for. It was
  # how it worked before but more loosly bound.

  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;
  }
  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;
}

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() {
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 = 

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

[Mark Roth]

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  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/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Reference Card page now missing

[Mark Roth]

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 = ;
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() {
  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) {
 

Re: [Amforth] Reference Card page now missing

[Mark Roth]

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

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Reference Card page now missing

[Mark Roth]

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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

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

[Mark Roth]

On Sun, Jun 28, 2020 at 5:29 PM 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.
>

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 

Re: [Amforth] defer.frt

[Mark Roth]

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  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  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/
>> > Amforth-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >
>>
>>
>> ___
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amforth-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] defer.frt

[Mark Roth]

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  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/
> > Amforth-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
>
> ___
> Amforth-devel mailing list for http://amforth.sf.net/
> Amforth-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

___
Amforth-devel mailing list for http://amforth.sf.net/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth] defer.frt

[Mark Roth]

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/
Amforth-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amforth-devel