You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
|
Feb
(6) |
Mar
(41) |
Apr
(23) |
May
(11) |
Jun
(2) |
Jul
|
Aug
|
Sep
(9) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2008 |
Jan
(6) |
Feb
(1) |
Mar
(23) |
Apr
(18) |
May
(21) |
Jun
(13) |
Jul
(34) |
Aug
(5) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
(4) |
2009 |
Jan
|
Feb
(5) |
Mar
(5) |
Apr
(10) |
May
(1) |
Jun
(11) |
Jul
(1) |
Aug
|
Sep
|
Oct
(2) |
Nov
(3) |
Dec
(13) |
2010 |
Jan
(10) |
Feb
(4) |
Mar
(28) |
Apr
(3) |
May
(38) |
Jun
(22) |
Jul
(92) |
Aug
(154) |
Sep
(218) |
Oct
(45) |
Nov
(20) |
Dec
(1) |
2011 |
Jan
(33) |
Feb
(15) |
Mar
(32) |
Apr
(33) |
May
(48) |
Jun
(35) |
Jul
(7) |
Aug
|
Sep
(11) |
Oct
(5) |
Nov
|
Dec
(7) |
2012 |
Jan
(56) |
Feb
(11) |
Mar
(6) |
Apr
|
May
(128) |
Jun
(59) |
Jul
(21) |
Aug
(16) |
Sep
(24) |
Oct
(39) |
Nov
(12) |
Dec
(12) |
2013 |
Jan
(14) |
Feb
(61) |
Mar
(97) |
Apr
(46) |
May
(13) |
Jun
(23) |
Jul
(12) |
Aug
(25) |
Sep
(9) |
Oct
(81) |
Nov
(73) |
Dec
(45) |
2014 |
Jan
(36) |
Feb
(57) |
Mar
(20) |
Apr
(41) |
May
(43) |
Jun
(11) |
Jul
(14) |
Aug
(32) |
Sep
(9) |
Oct
(27) |
Nov
(21) |
Dec
(6) |
2015 |
Jan
(14) |
Feb
(23) |
Mar
(1) |
Apr
(19) |
May
(40) |
Jun
(11) |
Jul
(1) |
Aug
(2) |
Sep
(14) |
Oct
(10) |
Nov
(9) |
Dec
(13) |
2016 |
Jan
(4) |
Feb
(3) |
Mar
(7) |
Apr
|
May
(4) |
Jun
(13) |
Jul
(8) |
Aug
(3) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
|
2017 |
Jan
(6) |
Feb
(1) |
Mar
(1) |
Apr
(7) |
May
(10) |
Jun
(5) |
Jul
(7) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(54) |
Nov
(47) |
Dec
(53) |
2019 |
Jan
(23) |
Feb
(24) |
Mar
(19) |
Apr
(15) |
May
(5) |
Jun
(34) |
Jul
(9) |
Aug
(9) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(7) |
Apr
(7) |
May
(5) |
Jun
(15) |
Jul
(22) |
Aug
(28) |
Sep
(13) |
Oct
(9) |
Nov
(17) |
Dec
(13) |
2021 |
Jan
(5) |
Feb
(1) |
Mar
(1) |
Apr
(9) |
May
(21) |
Jun
(9) |
Jul
|
Aug
(6) |
Sep
(16) |
Oct
|
Nov
(1) |
Dec
(6) |
2022 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(21) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
2024 |
Jan
(1) |
Feb
(4) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Keith A. <ca...@pi...> - 2023-09-29 14:25:52
|
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. > 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! > 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-scratcher for me since I wanted to enclose it in the > AmForth repo in a stable state. There is virtually no activity for years on > either the Rob3rt repo or the other fix fork by srtlg. The thing is, just > as with the conversion from AmForth CVS to git, I want all the histories > maintained but not so much the hassle of an unknown repo. The best solution > I came up with my brother (who is a developer) is to fork it to a personal > repo then use that. That is sort of but not exactly what I tried. I forked > it, updated it then yanked out just enough of the code and put it in a new > location in my AmForth git repo with the windows version and allowed for > building it from the appl makefile if needed. That still needs work but as > a process it works pretty well. The real way to do it would be to create > the repo as a submodule within the AmForth tree. If people are going to > want to use avra they are going to have to build it locally anyhow. Plus, > then they have the source which is what it is really about. I also think that the avra build is important. The complexity of getting a working build environment on Linux was the biggest stumbling block I had in getting going for the project where I did use amforth. One thing I would be interested in finding time to do (for myself even if no-one else is interested) is create a nix-shell <https://nixos.wiki/wiki/Development_environment_with_nix-shell> environment that would make all of the build tooling conveniently available to anyone using Nix. I have found this to be an incredibly powerful method for creating reproducible build environments that are easy to use. Note that Nix has good support for OS-X and I believe these days can even be used in the Windows Subsystem for Linux, so it could help more than just Linux users. >> 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. FWIW, it was the availability of pre-built hex files that caused me to start my project with amforth to begin with, because it gave me something I could get running quickly to experiment with before figuring out all of the complexities of the build environment. I think everyone has to graduate to building their own .hex files relatively quickly but having pre-built files is a great onboarding first-step. Following that up with an easy-to-obtain build environment I think would really help with adoption. >> 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. I also think RISC-V is the most interesting future target. > That's all I have for this morning. Anyone reading this, particularly > someone not usually heard here please let it be known what you would like > or not like. Or what you do or don't like about the current state of > things. I'd like to see AmForth around for a long time even in it's more or > less current state. And adding some new chips like Tristan mentioned would > be a good way to start once we can all come to some agreement on how to > move into the near future. Whatever happens from this discussion, I'd like to say a big thank you to everyone that is interested in keeping amforth alive into the future. I'm very fond of it and would really like to see it continue to be a tool for those curious about how to work efficiently with their hardware. Thanks! Keith |
From: Mark R. <cab...@gm...> - 2023-09-27 06:33:26
|
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 <ew....@na...> wrote: > Hello all, > > good to see some interest in this project again. > > > > Mark Roth <cab...@gm...> 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 that can serve as a forum of sorts. To me, the AmForth SF website is the biggest thing to really be concerned with. It is full of pretty much everything but the code base that can get anyone going. It just needs some maintenance as there are parts that are glaringly out of date. The other side of that coin is that the SVN repo seems like a whole separate thing. If you jump over to the download section there is no obvious way back. SVN I'm not a fan anymore of this. Many years ago I was but once you get git you're got in my opinion. I use it locally for most anything. Is there anything else for interaction at SF with users and/or developers? I thought they used to have a rudimentary form sort of thing. Not really a forum but a set of lists that could be used like that. That could be used as a discussion, request and/or bug tracking thing right on SF. GIT Erich has put a great effort in transferring the svn repo into git. Having done so myself a couple years ago I can say his looks like a pretty clean piece of work. Preserving the history of commits is really what it came down to and it appears to be a nearly flawless job. My vote is that the releases version be used moving forward. Personally, I would like to see everything continue on as an organization. Having to work all the documentation into MD might be tedious, but only once. This is something I was getting ready to play with to see if it actually works as expected. https://nimblehq.co/blog/create-github-wiki-pull-request > 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-scratcher for me since I wanted to enclose it in the AmForth repo in a stable state. There is virtually no activity for years on either the Rob3rt repo or the other fix fork by srtlg. The thing is, just as with the conversion from AmForth CVS to git, I want all the histories maintained but not so much the hassle of an unknown repo. The best solution I came up with my brother (who is a developer) is to fork it to a personal repo then use that. That is sort of but not exactly what I tried. I forked it, updated it then yanked out just enough of the code and put it in a new location in my AmForth git repo with the windows version and allowed for building it from the appl makefile if needed. That still needs work but as a process it works pretty well. The real way to do it would be to create the repo as a submodule within the AmForth tree. If people are going to want to use avra they are going to have to build it locally anyhow. Plus, then they have the source which is what it is really about. > 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. > > The build document from the other message really needs to be put into the repo somewhere. Well, the TS stuff for the website side I mean. But then things are diverging from your git so we seem to have a race condition. Your points about the hex files are valid, but I do think there are people that will just want to load it up with as little fuss as possible and start working with forth. I could be wrong but I don't see the harm in including them. Once someone starts working from the template project they will be building anyhow. Having prebuilt hex files for known popular platforms isn't going to hurt, it just creates more access. That's all I have for this morning. Anyone reading this, particularly someone not usually heard here please let it be known what you would like or not like. Or what you do or don't like about the current state of things. I'd like to see AmForth around for a long time even in it's more or less current state. And adding some new chips like Tristan mentioned would be a good way to start once we can all come to some agreement on how to move into the near future. All the best, Mark > > > > 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/ > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > 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/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Erich W. <ew....@na...> - 2023-09-26 16:05:54
|
Hello all, good to see some interest in this project again. Mark Roth <cab...@gm...> 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/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel 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 ... |
From: Erich W. <ew....@na...> - 2023-09-26 15:59:29
|
As promised. The file is plain ascii .org mode format: --- Howto-make-a-release.org ----------------------------------- # 2020-10-12 amforth/erwaelde * How to properly make a release? Somewhat machine readable version. ** Intro #+begin_quote 1. check all version numbers in trunk - doc/Makefile being one place. This seems to be used in all generated documentation, which is nice. - common/words/env-forthversion.asm is another place with different syntax! Judging by commit r2271, these are all places indeed. Yay! 2. update doc/source/index.rst and optionally history.rst in trunk and commit 3. "svn copy" trunk to releases/$VERSION; commit message collects the accumulated one line change descriptions This is the most visible change in the source tree e.g. see commit r2244 (rel 6.5) 4. create all .hex files for target boards in appl/ arduino,atmega2561,eval-pollin,hifive1,launchpad-arm,launchpad430, template I had forgotten that these exsisted. They are in the release archive only, not in the source tree. Now I understand, why people sometimes ask about them. This step is detailed in a few .xml files. Matthias used ant to build them. I have not built these before, but this looks doable, provided I get all relevant toolchains up and running. 5. create the documentation - htdocs, the web page - books, did you know that all the content of the webpage shows up in amforth.pdf (made with pdflatex) and AmForth.epub (made with sphinx-build)? Amazing! These books are part of the download .zip archive. This step is a "cd doc; make all" --- provided sphinx pdflatex and all the good stuff is installed. 6. create a new temporary tree to collect everything, that goes into the release archive: - sources - some of the scripts, tools, meta-files - the generated documentation from releases/$VERSION, without the document sources, but including the "books" I have not found anything that looks like doing this. 7. create the .zip and .tar.gz archives (the easy part), and upload them to their correct location in the sourceforge.net file tree (the not so obvious part). I found out that these release archives were built by Matthias. The files for 6.8 are about 7 MB in size. Whereas if you download "the latest sources", sourceforge will generate a snapshot of "trunk". This is a plain copy, without all the niceties included in the archives mentioned here. This archive is currently 35 MB in size. 8. sync the generated documentation with the online website I have done this a few times now, but I'm still asking myself, if I see all relevant pieces or not. 9. Increment the version numbers in trunk and commit So nine easy steps to code nirvana? Hmmm. #+end_quote ** Go to the correct directory #+begin_src sh cd ~/eGeek/sourceforge.net/amforth-code #+end_src ** Check current Version Strings Fortunately only three files: #+begin_src sh ( cd trunk grep '^VERSION' doc/Makefile cat common/words/env-forthversion.asm cat shared/words/env-forthversion.s ) #+end_src ** update doc/source/index.rst Do /not/ delete any blank lines in this file, they are sorely needed! #+begin_src diff ew@ceres:~/eGeek/sourceforge.net/amforth-code 7 > svn diff trunk/ Index: trunk/doc/source/index.rst =================================================================== --- trunk/doc/source/index.rst (revision 2451) +++ trunk/doc/source/index.rst (working copy) @@ -36,6 +36,9 @@ See the code section at Sourceforge to get the `most recent sources <http://sourceforge.net/p/amforth/code/HEAD/tree/trunk/>`__ +18.10.2020: release 6.9 +....................... + * tools/amforth-shell.py fixed python3 error (in --no-error-on-output option path), fix provided by Tristan Williams. * tools/amforth-shell.py fixed indentation error in line 1146, fix provided by Tristan Williams. #+end_src : svn commit trunk/doc/source/index.rst -m 'call it version 6.9' : svn up ** create releases/$Version #+begin_src sh svn cp trunk/ releases/6.9 #+end_src Alle ? Dateien werden hier mitkopiert, aber wenigstens nicht mit add verziert. Aha. edit svn.msg, collect all comments from index.rst since last release : svn commit . --file svn.msg : svn up ** increment $Version : vi trunk/doc/Makefile : vi trunk/common/words/env-forthversion.asm : vi trunk/shared/words/env-forthversion.s : svn commit trunk/doc/Makefile trunk/common/words/env-forthversion.asm trunk/shared/words/env-forthversion.s -m 'Increment version to 7.0' ** commit see e.g. r2432 .. r2434 ** checkout a temp. release tree #+begin_src sh cd ~ mkdir tmp-amforth-code cd tmp-amforth-code svn checkout svn://svn.code.sf.net/p/amforth/code/releases/6.9 cd 6.9 # add Atmel AvrAsm2 tree wget https://sourceforge.net/projects/amforth/files/Atmel-AVR8-Assembler/Atmel-Assembler.tgz tar xf Atmel-Assembler.tgz # unpacks into ./avr8/Atmel ( cd appl ( cd hifive1 && make ) # hifive1, riscv64-linux-gnu-as ( cd linux-arm && make ) # linux-arm, arm-linux-gnueabi-as ( cd launchpad-arm && make ) # launchpad-arm, arm-none-eabi-as ( # several, wine AvrAsm2 for DIR in arduino atmega2561 eval-pollin template do ( cd $DIR; ant compile ) done ) ) #+end_src ** in release/$Version create .hex files Das hab ich neulich mal ausgetüftelt: #+begin_src sh # once, on Debian 10 at this moment: ( sudo -i apt install binutils-riscv64-linux-gnu binutils-arm-linux-gnueabi binutils-arm-none-eabi ) ( cd ~/Projekte/17_naken_asm git clone https://github.com/mikeakohn/naken_asm cd naken_asm ./configure make ./naken_asm | grep -i version # Version: March 15, 2020 # BROKEN ??? cp ./naken_asm ~/bin/ naken_asm | grep -i version # Version: December 28, 2015 ) tar xf ~/Forth/amforth/Atmel-Assembler.tgz mv avr8/Atmel/ . rmdir avr8 # always: ( cd release/6.9 ( cd avr8 && ln -snf ../../../Atmel . ) cd appl ( cd hifive1 && make ) # hifive1, riscv64-linux-gnu-as ( cd linux-arm && make ) # linux-arm, arm-linux-gnueabi-as ( cd launchpad-arm && make ) # launchpad-arm, arm-none-eabi-as ( # several, wine AvrAsm2 for DIR in arduino atmega2561 eval-pollin template do ( cd $DIR; ant compile ) done ) # launchpad430, naken_asm ( cd launchpad430 && make lp-2553.hex lp-5529.hex lp-5969.hex ) ) #+end_src TEST them!!! This is the unresolved bit at this moment ... no need to commit the artefacts. They are included in the release-$version.tar.gz archive. ** in release/$Version build the documentation #+begin_src sh ( cd release/6.9/ rm -fr ./avr8/Atmel ./doc/Projects ./doc/build cd doc make all sitemap ) #+end_src ** create a new release tar archive #+begin_src sh ( version=6.9 cd release/${version} mkdir ../amforth-${version} cp -a examples/ avr8/ LICENSE.txt \ risc-v/ appl/ shared/ common/ arm/ readme.txt msp430/ tests/ \ ../amforth-${version}/ mkdir ../amforth-${version}/tools cp -a tools/{am4up.c,amforth-upload.py,amforth-shell.py} ../amforth-${version}/tools mkdir ../amforth-${version}/doc cp -a doc/build/htdocs/ ../amforth-${version}/doc/ mkdir ../amforth-${version}/doc/tools cp -a doc/tools/{forth.py,_mapping.py} ../amforth-${version}/doc/tools/ mv ../amforth-${version}/doc/htdocs/AmForth.epub ../amforth-${version}/doc/ mv ../amforth-${version}/doc/htdocs/amforth.pdf ../amforth-${version}/doc/ cd .. tar -czvf amforth-${version}.tar.gz ./amforth-${version} zip -r amforth-${version}.zip amforth-${version} ) #+end_src Wenn man die Unterschiede zum 6.8 tar.gz anguckt: - -104 ich hab viele no-jtag.asm weggeschmissen. - +4 ich hab in launchpad430 hex files gebaut, die fehlen in 6.8 - +4 Opinion - +58 Projects/ClockWorks - +2 Projects/RS485 - +2 refcard - +3 .js .css - +20 doc/_images Die Zahl kann ich jetzt nicht komplett nachvollziehen, aber die Unterschiede sind plausibel. Das passt so schon einigermaßen. ** create the new website and sync die wohnt jetzt unter : releases/6.9/doc/build/htdocs oder? ** Increment Version numbers in trunk and commit #+begin_src sh ( cd trunk/doc sed -i.bak -e '/^VERSION/s/6.9/7.0/' Makefile ) ( cd trunk/common/words sed -i.bak -e 's/\.dw 69/\.dw 70/' env-forthversion.asm ) svn st svn commit trunk/doc/Makefile trunk/common/words/env-forthversion.asm -m 'start version 7.0' #+end_src ** upload release tar archive(s) ** send announcement ** update the website!!! #+begin_src sh cd ~ mkdir tmp-amforth-website cd tmp-amforth-website svn checkout svn://svn.code.sf.net/p/amforth/code/trunk cd trunk/doc make htdocs cd ~/eGeek/sourceforge.net/amforth-web/ mkdir amforth-2020-10-18-upload cp -a amforth/amforth_config.xml amforth/cgi-bin/ amforth/upload amforth-2020-10-18-upload/ cp -a ~/tmp-amforth-website/trunk/doc/build/htdocs/ amforth-2020-10-18-upload/ cd amforth-2020-10-18-upload/ rsync -vax --delete . erw...@we...:/home/project-web/amforth #+end_src puhh. ---------------------------------------------------------------- -- May the Forth be with you ... |
From: Mark R. <cab...@gm...> - 2023-09-26 07:44:56
|
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 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/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Erich W. <ew....@na...> - 2023-09-25 18:21:47
|
Hi Mark, Mark Roth <cab...@gm...> writes: > Here is the clean link. > > https://github.com/CableGuy67/avra Thanks for pulling this together. I can successfully build the executable on debian 12, gcc 13.2 on a riscv64 machine. :) I would kindly suggest to increase the version number, or add some local suffix. Thanks, Erich > On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> wrote: > >> >> >> > Talking of maintenance, I note that avra (on Sourceforge) hasn't been >> >>> > updated since 2019. Maybe it's completed? PS: to me it seems, that Robert Russel has ceased all activity on github. Whatever that means. |
From: Mark R. <cab...@gm...> - 2023-09-25 05:38:40
|
Here is the clean link. https://github.com/CableGuy67/avra On Mon, Sep 25, 2023 at 8:30 AM Mark Roth <cab...@gm...> 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 > |
From: Mark R. <cab...@gm...> - 2023-09-25 05:31:17
|
> 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 |
From: Malte F. G. <mal...@gm...> - 2023-09-24 18:47:17
|
Martin Nicholas via Amforth-devel <amf...@li...> writes: > On Sun, 10 Sep 2023 17:04:01 +0200 > tristan <ho...@tj...> 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? > > I would be happy to make some sort of contribution, but being > essentially a hobbyist programmer, I'm not sure how useful I could be. > I've never worked in any type of devlopment team. > > Documentation is something I could contribute to, but not until next > year due to on-going commitments in 2023. > > Certainly an "advert" for maintiners on AmForth's new home would be a > good thing; together messages on the socials. > > 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. mfg² |
From: Martin N. <amf...@mg...> - 2023-09-24 14:50:21
|
On Sun, 10 Sep 2023 17:04:01 +0200 tristan <ho...@tj...> 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? I would be happy to make some sort of contribution, but being essentially a hobbyist programmer, I'm not sure how useful I could be. I've never worked in any type of devlopment team. Documentation is something I could contribute to, but not until next year due to on-going commitments in 2023. Certainly an "advert" for maintiners on AmForth's new home would be a good thing; together messages on the socials. Talking of maintenance, I note that avra (on Sourceforge) hasn't been updated since 2019. Maybe it's completed? -- Regards, Martin Nicholas. E-mail: rep...@mg... (Address will be valid throughout 2023). |
From: tristan <ho...@tj...> - 2023-09-24 12:56:16
|
Hello Mark and fellow AmForth'ers, > 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. > 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? 1. A decision as to whether the SF AmForth repo, website and mailing list should remain at SF or move elsewhere. Moving it will take some effort, but some arguments and provisions for moving it have been put forward and made. 2. A release adding avra as a build option. 3. Prebuilt hex files for UNO and MEGA added to release by default. 4. Update the docs where the passage of time has not been kind. Whilst I'm new to sphinx and reStructuredText, the AmForth distribution documentation does build easily and only minor changes would be needed to host it pretty much anywhere. To verify this I have put it up temporarily at https://www.mostlymostly.uk/amforthdocs and done some tests with github pages [3] I'm reasonably sure that a good chunk of the above (excepting point 1) has already been done by individuals on the list, so it is more coordination and administration than anything else. Elements of the above that have not been done, I am happy to do. 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 On 2023-09-14 11:11, Mark Roth wrote: > 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 <ho...@tj...> 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/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: Erich W. <ew....@na...> - 2023-09-22 06:58:50
|
Hello Mark, hello all, congrats to your hack-box! :) 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 <cab...@gm...> 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/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel -- May the Forth be with you ... |
From: Mark R. <cab...@gm...> - 2023-09-21 21:08:56
|
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 |
From: Mark R. <cab...@gm...> - 2023-09-14 10:11:56
|
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 <ho...@tj...> 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/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: tristan <ho...@tj...> - 2023-09-10 15:04:25
|
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/ |
From: Mark R. <cab...@gm...> - 2023-09-09 14:08:09
|
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 |
From: Mark R. <cab...@gm...> - 2023-08-28 13:53:13
|
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 < > amf...@li...> 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 <cab...@gm...> 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 <ho...@tj...> 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 staff 239 26 Aug 17:53 uno.eep.hex > > >>> -rw-r--r-- 1 tw staff 239 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 <ew....@na...> > > 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 <bkn...@gm...> writes: > > >>>>> > > >>>>>> That is awesome news! > > >>>>>> Brian-in-ohio > > >>>>>> > > >>>>>> > > >>>>>> On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> > > >> 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/ > > >>>>>>> Amf...@li... > > >>>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>>>>>> > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>>>>> Amf...@li... > > >>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>>>> > > >>>>> > > >>>>> -- > > >>>>> May the Forth be with you ... > > >>>>> > > >>>>> > > >>>>> _______________________________________________ > > >>>>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>>>> Amf...@li... > > >>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>>>> > > >>>> > > >>>> _______________________________________________ > > >>>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>>> Amf...@li... > > >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>> > > >>> > > >>> _______________________________________________ > > >>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>> Amf...@li... > > >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >> > > >> > > >> _______________________________________________ > > >> Amforth-devel mailing list for http://amforth.sf.net/ > > >> Amf...@li... > > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >> > > > > > > _______________________________________________ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > Amf...@li... > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Brian K N. <bkn...@gm...> - 2023-08-28 12:58:08
|
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. Brian-in-ohio On Mon, Aug 28, 2023 at 7:47 AM Jan Kromhout via Amforth-devel < amf...@li...> 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 <cab...@gm...> 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 <ho...@tj...> 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 staff 239 26 Aug 17:53 uno.eep.hex > >>> -rw-r--r-- 1 tw staff 239 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 <ew....@na...> > 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 <bkn...@gm...> writes: > >>>>> > >>>>>> That is awesome news! > >>>>>> Brian-in-ohio > >>>>>> > >>>>>> > >>>>>> On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> > >> 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/ > >>>>>>> Amf...@li... > >>>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Amforth-devel mailing list for http://amforth.sf.net/ > >>>>>> Amf...@li... > >>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >>>>> > >>>>> > >>>>> -- > >>>>> May the Forth be with you ... > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Amforth-devel mailing list for http://amforth.sf.net/ > >>>>> Amf...@li... > >>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Amforth-devel mailing list for http://amforth.sf.net/ > >>>> Amf...@li... > >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >>> > >>> > >>> _______________________________________________ > >>> Amforth-devel mailing list for http://amforth.sf.net/ > >>> Amf...@li... > >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > >> > >> _______________________________________________ > >> Amforth-devel mailing list for http://amforth.sf.net/ > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Jan K. <jan...@ic...> - 2023-08-28 11:47:02
|
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 <cab...@gm...> 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 <ho...@tj...> 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 staff 239 26 Aug 17:53 uno.eep.hex >>> -rw-r--r-- 1 tw staff 239 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 <ew....@na...> 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 <bkn...@gm...> writes: >>>>> >>>>>> That is awesome news! >>>>>> Brian-in-ohio >>>>>> >>>>>> >>>>>> On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> >> 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/ >>>>>>> Amf...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Amforth-devel mailing list for http://amforth.sf.net/ >>>>>> Amf...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>>>> >>>>> >>>>> -- >>>>> May the Forth be with you ... >>>>> >>>>> >>>>> _______________________________________________ >>>>> Amforth-devel mailing list for http://amforth.sf.net/ >>>>> Amf...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>>>> >>>> >>>> _______________________________________________ >>>> Amforth-devel mailing list for http://amforth.sf.net/ >>>> Amf...@li... >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >>> >>> >>> _______________________________________________ >>> Amforth-devel mailing list for http://amforth.sf.net/ >>> Amf...@li... >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: Mark R. <cab...@gm...> - 2023-08-28 07:01:29
|
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 <ho...@tj...> 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 staff 239 26 Aug 17:53 uno.eep.hex > > -rw-r--r-- 1 tw staff 239 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 <ew....@na...> 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 <bkn...@gm...> writes: > >> > > >> > > That is awesome news! > >> > > Brian-in-ohio > >> > > > >> > > > >> > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> > 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/ > >> > >> Amf...@li... > >> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > >> > >> > > > >> > > _______________________________________________ > >> > > Amforth-devel mailing list for http://amforth.sf.net/ > >> > > Amf...@li... > >> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > >> > > >> > -- > >> > May the Forth be with you ... > >> > > >> > > >> > _______________________________________________ > >> > Amforth-devel mailing list for http://amforth.sf.net/ > >> > Amf...@li... > >> > https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > >> > >> _______________________________________________ > >> Amforth-devel mailing list for http://amforth.sf.net/ > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: tristan <ho...@tj...> - 2023-08-28 06:53:36
|
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 staff 239 26 Aug 17:53 uno.eep.hex > -rw-r--r-- 1 tw staff 239 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 <ew....@na...> 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 <bkn...@gm...> writes: >> > >> > > That is awesome news! >> > > Brian-in-ohio >> > > >> > > >> > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> 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/ >> > >> Amf...@li... >> > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > >> >> > > >> > > _______________________________________________ >> > > Amforth-devel mailing list for http://amforth.sf.net/ >> > > Amf...@li... >> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > >> > >> > -- >> > May the Forth be with you ... >> > >> > >> > _______________________________________________ >> > Amforth-devel mailing list for http://amforth.sf.net/ >> > Amf...@li... >> > https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > >> >> _______________________________________________ >> Amforth-devel mailing list for http://amforth.sf.net/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: Tristan W. <ho...@tj...> - 2023-08-27 05:45:12
|
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 staff 239 26 Aug 17:53 uno.eep.hex -rw-r--r-- 1 tw staff 239 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 <ew....@na...> 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 <bkn...@gm...> writes: > > > > > That is awesome news! > > > Brian-in-ohio > > > > > > > > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> 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/ > > >> Amf...@li... > > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >> > > > > > > _______________________________________________ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > Amf...@li... > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > -- > > May the Forth be with you ... > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel |
From: George H. <jac...@gm...> - 2023-08-25 09:12:30
|
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 <ew....@na...> 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 <bkn...@gm...> writes: > > > That is awesome news! > > Brian-in-ohio > > > > > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> 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/ > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Mark R. <cab...@gm...> - 2023-08-25 09:02:55
|
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 <bkn...@gm...> writes: > > > That is awesome news! > > Brian-in-ohio > > > > > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> 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/ > >> Amf...@li... > >> https://lists.sourceforge.net/lists/listinfo/amforth-devel > >> > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > Amf...@li... > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > -- > May the Forth be with you ... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Erich W. <ew....@na...> - 2023-08-25 07:14:52
|
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 <bkn...@gm...> writes: > That is awesome news! > Brian-in-ohio > > > On Thu, Aug 24, 2023 at 2:59 PM Mark Roth <cab...@gm...> 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/ >> Amf...@li... >> https://lists.sourceforge.net/lists/listinfo/amforth-devel >> > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel -- May the Forth be with you ... |