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

[Ian Jefferson]

Thanks for the thought stream Erich.

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

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

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

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

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

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

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

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



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

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

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

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

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

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


Ian - lurking on.   



___
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)

[Tristan Williams]

Hello,

> Who of you is using which target controller?

I use AVR atmega328p, atmega1284p, atmega2560

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

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

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

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

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

> amforth-shell.py and python3

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

> ticket system or mailing list ?

I would prefer a mailing list. 

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

Best wishes,
Tristan










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

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

[Charley Shattuck via Amforth-devel]

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

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

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

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

Thanks Erich for what you're doing!

Charley

On 6/28/2020 7:29 AM, Erich Wälde wrote:

Dear AmForthers,

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


- Contributions

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

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

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


- Commits

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

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

   r2445: added comment about last commit to index.rst

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

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


- Open Issues

   as far as I'm aware:

   - WDT (Martin Nicholas) patch

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

   - Multitasker documentation

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

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

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

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

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


- Open Questions

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

   - How do I /reliably/ create the content of the webpage? How do
 I synchronize my local version effortlessly with the official
 copy? 

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