Hello all, good to see some interest in this project again.
Mark Roth <cablegu...@gmail.com> 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. 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 :) 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? > 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 still have a file which documents the steps to build a release and the associated web site. (I'll stuff this into a separate email) I am not a friend of prebuilt hex files, but again, other people have different preferences. I'd rather push someone through creating their .hex files, because it opens the world for them. > 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. I have created a personal fork of amForth starting at version 5.0, because it did build with avra, and it is before the other target platforms were included - MSP430 at version 5.6 - RV32 at version 6.7 - ARM at version 6.8 I have yet to find a stability problem in my use/setup on avr amForth, which has not surfaced. I decided to go back to a version with simpler overall structure (and some known bugs :) I agree that risc-v is the most appealing future target, I would not hesitate to remove msp430 and arm and point users to mecrisp. > > 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 that the AVR blanks to $ffff (I think). Perhaps then the > refcard could once again be brought up to date from scratch giving yet > another good thing for new people to access. I did have a look at the test > host that Tristan put up temporarily at > https://www.mostlymostly.uk/amforthdocs and it does seem to work perfectly. > So keeping the RST stuff (of which there is a lot in the repo) is a very > viable option no matter where things end up. I also was reading a gist > about converting from that to markdown that I have been meaning to try to > see how well it works. > > Okay, that went on way too long. But I did want to address the group since > I have found so much value here in the last couple of years. I'll leave the > quoted bit below from the original message since Tristan was very concise > about things. I hope there are no hard feelings for dicing up this message > to make it as legible as possible. I would like to see a more lively > official AmForth home wherever and however it will end up. > > All the best, > Mark > > What would I like to see longer term? >> >> 1. For avr8. The ATmega328 (like me) is no longer a spring chicken. It >> would be great to see AmForth running on, say, an ATmega4809 [1]. It >> is one of the megaAVR 0-series with newer peripherals, including a >> CCL. I've used similar on newer PIC mcus and they are very nice to >> have. Why the ATmega4809 in particular? (a) There is some support for >> it in avra (b) it is on the Arduino Nano Every [2] (c) it is available >> in 40 Pin DIP (48 pin die, minus some pads). I would be interested to >> know if anyone has done it/similar or how hard it might be ;) >> >> 2. For RISC-V. Of AmForth's non-avr8 branches it is the one that >> interests me most. The hardware used to be relatively expensive and >> hard to come by. Now it is not, which presents the problem of >> choice. It would be nice to have an approachable build for AmForth >> RISC-V on an inexpensive but obtainable board - but which one? Again, >> I would be interested in what people have done and opinions as to what >> might work. Additionally, has anyone got AmForth RISC-V running in a >> simulator? >> >> > There is something about thinking in forth that seems to be good for >> > my aging brain. >> >> I feel the same way. >> >> Best wishes, >> Tristan >> >> [1] https://www.microchip.com/en-us/product/atmega4809 >> [2] https://docs.arduino.cc/hardware/nano-every >> [3] https://docs.github.com/pages >> _______________________________________________ >> 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 So. Epilogue of sorts. I still like to work with amForth, I am still in no position to really understand, how the core works. I could get there if absolutely needed. Matthias mentioned, that he was developing it in the AVR Simulator that comes with the Atmel tools. I accept that I have to write ISR callback functions entirely in assembly, because of that bug that got fixed in 6.9 iirc. I still do simple stuff, and a atmega644pa is "big". 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
