Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)
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)
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? Ho
Re: [Amforth] AmForth Weekend 1 (2020-06-27/28)
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 that,
