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
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(7) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
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 ... |
From: Brian K N. <bkn...@gm...> - 2023-08-24 21:40:14
|
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 > |
From: Mark R. <cab...@gm...> - 2023-08-24 18:59:07
|
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. |
From: Erich W. <ew....@na...> - 2022-05-20 19:30:07
|
Sorry, hit the button quite prematurely :) Dear AmForthers, thank you so much for your kind words! So far a person behind the email address "in...@un..." has offered to help with AmForth. I have suggested to make an appearance on the list. Martin Nicholas has suggested to forward the original email to comp.lang.forth. I have asked Bernd Paysan (of gforth fame) to forward the original announcement. So the news it might reach a greater group. Brian Navarette has asked, whether the code of my "small" fork is available. Yes it is, see below. One of the things I did, but never announced is this: I converted the subversion repository to git in two variants: In this repository the release tree is spread out like in the original subversion repository: > https://git.sr.ht/~amforth/code-tree And in this repository the releases have been converted to git branches: > https://git.sr.ht/~amforth/code The account 'amforth' on sourcehut.org is a paid account. I'm happy to provide funding for this account for the foreseeable future and pass it on later. Carsten Strotmann has reserved the domain amforth.net. currently it points to the sourceforge page, if I am not mistaken. > https://www.amforth.net/ So these are things to play with. The web interface for Sourcehut.org works completely without JavaScript, which is why I have chosen them and migrated all my repositories. On top, changes on tickets and code can be coupled to email. So changes can be managed with email workflows. However, I have not understood all the neccessary details. I don't remember just now, whether I configured a new mailing list, probably not. Because I never really tested the workflow. But these are all puzzle pieces to play with. I admit that I have hesitated with the mailing list move as well. I am a little concerned that this move might break the small community. However, I would be more than happy to be proven wrong. So where is the above mentioned fork of AmForth Version 5.0? You can find it in this repository: > https://git.sr.ht/~ew/hbv3_am50forth The corresponding project featuring the rs485 connected controllers is growing at > https://git.sr.ht/~ew/hausbus-v3 The hardware I use is described there as well > https://git.sr.ht/~ew/TheStack The second test is running happily and blinking its LED. 544000 seconds uptime without a hitch, so it's about halfway of what I want to see (10^6 seconds or 12 days). I have started to document this journey, and it should turn into English text along the way. Conclusions: - Though I have stepped down, I am still the one with the keys, the janitor, so to speak. - I don't think I am going to drop off the planet soon. Or at least this risk is not much greater than it was before. What can you do? - I would suggest that 3 people receive the credentials for sourceforge and sourcehut, just to reduce the bus factor. I suggest Carsten Strotmann, Tristan Williams and Martin Nicholas, but that is just me. Speak out, please. - I still have a half baken document, how to make a release. So I should just send this as is, or add it to the repositories. - everyone can make up their mind, if they prefer to move to git and sourceforge. - whoever has more insight to the puzzle pieces at sourcehut can try to play with a email based workflow. I strongly suggest to create a public bug ticket instance, I percieved this as a significant lack in the past. I would like to read your thoughts on the list. I have no idea, how many there are reading. The number of subscribers is probably not a good estimate. So, speak up, make yourself heard. Thanks! Cheers, Erich Erich Wälde <ew....@na...> writes: > Dear AmForthers, > > I am herewith stepping down from the maintainer role of AmForth. For details, > read on. If anyone is interested to take over, get in touch with me. > > > In 2020 I received the logins of amforth.sourceforge.net, basically because I > was lucky enough to have met Matthias personally a few times. At that time I > had a lot of ideas on how to proceed. And while I managed to create an > official release, there are a few obstacles in this path. > > First and foremost I am facing a health issue. It is subtle, but it > seriously limits, what I can do. I still have to make several difficult > decisions regarding my daily life. I have started to decrease the number of > things on my list by cancelling items. I have to accept the fact, that I'm not > in a position any more to advance the AmForth project in a meaningful way. > > Secondly, AmForth has become complex over time. Matthias added support for > three more target platforms (msp430, arm, riscv32). Allthough access to these > is easily achievable, I use only avr. And I use it less these days. > > Thirdly, AmForths tools are depending heavily on python code, a language I > consider myself illiterate in. I have written a few small perl scripts around > AmForth to serve my needs. I heavily depend on those and on a Makefile. > > Add the fact, that in 2020 I spent countless hours to port my data acquisition > stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To > this day I still have no clue, why the thing hangs itself after some time, > sometimes hours, sometimes several days. In other words: unusable. > > > Step back: what would I have done, if I didn't know Matthias, and the project > would just have become silent? Simplify. Simplify heavily. > > Very recently I have made a fork of AmForth release 5.0. That version is > before support for msp430 was officially added (5.5). That version happens to > compile with avra rather than wine/avrasm2.exe. Along the way I found, that > avra has seen new releases, which add support for my beloved atmega644p and > lots of fixes, which is nice! This removes the dependancy from wine and allows > for smaller systems for development. > > So I have picked up my data acquisition project again with the fork mentioned > above. Any Interrupt Service Routines are written in assembly to avoid the > thing that I uncovered in 2017, namely a race condition 1 bit wide and 1 > instruction cycle long. I pick missing bits and pieces from later releases. I > would like to add a few features regarding sensors with different needs. A > first experiment has run more than 10^6s (12d) without any failure. So I am > moderately optimistic to continue along this simplified path. > > > Thanks to all, who have answered the list, contributed code, ideas, > documentation in one form or other. It has been an interesting experience. > And should you still care to listen: if you have one or a few more important > plans, do not delay them, you might be unable to pursue them later. > > Happy hacking, and use the Forth! > > Cheers > Erich -- May the Forth be with you ... |
From: Erich W. <ew....@na...> - 2022-05-20 19:25:20
|
Erich Wälde <ew....@na...> writes: > [[PGP Signed Part:Undecided]] > > Dear AmForthers, > > I am herewith stepping down from the maintainer role of AmForth. For details, > read on. If anyone is interested to take over, get in touch with me. > > > In 2020 I received the logins of amforth.sourceforge.net, basically because I > was lucky enough to have met Matthias personally a few times. At that time I > had a lot of ideas on how to proceed. And while I managed to create an > official release, there are a few obstacles in this path. > > First and foremost I am facing a health issue. It is subtle, but it > seriously limits, what I can do. I still have to make several difficult > decisions regarding my daily life. I have started to decrease the number of > things on my list by cancelling items. I have to accept the fact, that I'm not > in a position any more to advance the AmForth project in a meaningful way. > > Secondly, AmForth has become complex over time. Matthias added support for > three more target platforms (msp430, arm, riscv32). Allthough access to these > is easily achievable, I use only avr. And I use it less these days. > > Thirdly, AmForths tools are depending heavily on python code, a language I > consider myself illiterate in. I have written a few small perl scripts around > AmForth to serve my needs. I heavily depend on those and on a Makefile. > > Add the fact, that in 2020 I spent countless hours to port my data acquisition > stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To > this day I still have no clue, why the thing hangs itself after some time, > sometimes hours, sometimes several days. In other words: unusable. > > > Step back: what would I have done, if I didn't know Matthias, and the project > would just have become silent? Simplify. Simplify heavily. > > Very recently I have made a fork of AmForth release 5.0. That version is > before support for msp430 was officially added (5.5). That version happens to > compile with avra rather than wine/avrasm2.exe. Along the way I found, that > avra has seen new releases, which add support for my beloved atmega644p and > lots of fixes, which is nice! This removes the dependancy from wine and allows > for smaller systems for development. > > So I have picked up my data acquisition project again with the fork mentioned > above. Any Interrupt Service Routines are written in assembly to avoid the > thing that I uncovered in 2017, namely a race condition 1 bit wide and 1 > instruction cycle long. I pick missing bits and pieces from later releases. I > would like to add a few features regarding sensors with different needs. A > first experiment has run more than 10^6s (12d) without any failure. So I am > moderately optimistic to continue along this simplified path. > > > Thanks to all, who have answered the list, contributed code, ideas, > documentation in one form or other. It has been an interesting experience. > And should you still care to listen: if you have one or a few more important > plans, do not delay them, you might be unable to pursue them later. > > Happy hacking, and use the Forth! > > Cheers > Erich -- May the Forth be with you ... |
From: Brian K N. <bkn...@gm...> - 2022-05-16 12:05:14
|
Is the fork of amforth available anywhere? brian-in-ohio On 5/16/22, Martin Nicholas via Amforth-devel <amf...@li...> wrote: > Erich, > > Thanks for all your work. > > You may wish to advertise the vacancy on the USENET comp.lang.forth. A > G account will do the job. > > On Fri, 06 May 2022 09:17:23 +0200 > Erich Wälde <ew....@na...> wrote: > >> Dear AmForthers, >> >> I am herewith stepping down from the maintainer role of AmForth. For >> details, read on. If anyone is interested to take over, get in touch >> with me. >> >> >> In 2020 I received the logins of amforth.sourceforge.net, basically >> because I was lucky enough to have met Matthias personally a few >> times. At that time I had a lot of ideas on how to proceed. And while >> I managed to create an official release, there are a few obstacles in >> this path. >> >> First and foremost I am facing a health issue. It is subtle, but it >> seriously limits, what I can do. I still have to make several >> difficult decisions regarding my daily life. I have started to >> decrease the number of things on my list by cancelling items. I have >> to accept the fact, that I'm not in a position any more to advance >> the AmForth project in a meaningful way. >> >> Secondly, AmForth has become complex over time. Matthias added >> support for three more target platforms (msp430, arm, riscv32). >> Allthough access to these is easily achievable, I use only avr. And I >> use it less these days. >> >> Thirdly, AmForths tools are depending heavily on python code, a >> language I consider myself illiterate in. I have written a few small >> perl scripts around AmForth to serve my needs. I heavily depend on >> those and on a Makefile. >> >> Add the fact, that in 2020 I spent countless hours to port my data >> acquisition stuff at home from amforth 4.6 to 6.9 and it just did not >> become stable. To this day I still have no clue, why the thing hangs >> itself after some time, sometimes hours, sometimes several days. In >> other words: unusable. >> >> >> Step back: what would I have done, if I didn't know Matthias, and the >> project would just have become silent? Simplify. Simplify heavily. >> >> Very recently I have made a fork of AmForth release 5.0. That version >> is before support for msp430 was officially added (5.5). That version >> happens to compile with avra rather than wine/avrasm2.exe. Along the >> way I found, that avra has seen new releases, which add support for >> my beloved atmega644p and lots of fixes, which is nice! This removes >> the dependancy from wine and allows for smaller systems for >> development. >> >> So I have picked up my data acquisition project again with the fork >> mentioned above. Any Interrupt Service Routines are written in >> assembly to avoid the thing that I uncovered in 2017, namely a race >> condition 1 bit wide and 1 instruction cycle long. I pick missing >> bits and pieces from later releases. I would like to add a few >> features regarding sensors with different needs. A first experiment >> has run more than 10^6s (12d) without any failure. So I am moderately >> optimistic to continue along this simplified path. >> >> >> Thanks to all, who have answered the list, contributed code, ideas, >> documentation in one form or other. It has been an interesting >> experience. And should you still care to listen: if you have one or a >> few more important plans, do not delay them, you might be unable to >> pursue them later. >> >> Happy hacking, and use the Forth! >> >> Cheers >> Erich >> > > > > -- > Regards, > > Martin Nicholas. > > E-mail: mg...@mg.... > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |
From: Martin N. <amf...@mg...> - 2022-05-16 08:04:12
|
Erich, Thanks for all your work. You may wish to advertise the vacancy on the USENET comp.lang.forth. A G account will do the job. On Fri, 06 May 2022 09:17:23 +0200 Erich Wälde <ew....@na...> wrote: > Dear AmForthers, > > I am herewith stepping down from the maintainer role of AmForth. For > details, read on. If anyone is interested to take over, get in touch > with me. > > > In 2020 I received the logins of amforth.sourceforge.net, basically > because I was lucky enough to have met Matthias personally a few > times. At that time I had a lot of ideas on how to proceed. And while > I managed to create an official release, there are a few obstacles in > this path. > > First and foremost I am facing a health issue. It is subtle, but it > seriously limits, what I can do. I still have to make several > difficult decisions regarding my daily life. I have started to > decrease the number of things on my list by cancelling items. I have > to accept the fact, that I'm not in a position any more to advance > the AmForth project in a meaningful way. > > Secondly, AmForth has become complex over time. Matthias added > support for three more target platforms (msp430, arm, riscv32). > Allthough access to these is easily achievable, I use only avr. And I > use it less these days. > > Thirdly, AmForths tools are depending heavily on python code, a > language I consider myself illiterate in. I have written a few small > perl scripts around AmForth to serve my needs. I heavily depend on > those and on a Makefile. > > Add the fact, that in 2020 I spent countless hours to port my data > acquisition stuff at home from amforth 4.6 to 6.9 and it just did not > become stable. To this day I still have no clue, why the thing hangs > itself after some time, sometimes hours, sometimes several days. In > other words: unusable. > > > Step back: what would I have done, if I didn't know Matthias, and the > project would just have become silent? Simplify. Simplify heavily. > > Very recently I have made a fork of AmForth release 5.0. That version > is before support for msp430 was officially added (5.5). That version > happens to compile with avra rather than wine/avrasm2.exe. Along the > way I found, that avra has seen new releases, which add support for > my beloved atmega644p and lots of fixes, which is nice! This removes > the dependancy from wine and allows for smaller systems for > development. > > So I have picked up my data acquisition project again with the fork > mentioned above. Any Interrupt Service Routines are written in > assembly to avoid the thing that I uncovered in 2017, namely a race > condition 1 bit wide and 1 instruction cycle long. I pick missing > bits and pieces from later releases. I would like to add a few > features regarding sensors with different needs. A first experiment > has run more than 10^6s (12d) without any failure. So I am moderately > optimistic to continue along this simplified path. > > > Thanks to all, who have answered the list, contributed code, ideas, > documentation in one form or other. It has been an interesting > experience. And should you still care to listen: if you have one or a > few more important plans, do not delay them, you might be unable to > pursue them later. > > Happy hacking, and use the Forth! > > Cheers > Erich > -- Regards, Martin Nicholas. E-mail: mg...@mg.... |
From: George H. <jac...@gm...> - 2022-05-07 11:02:43
|
Thanks for your efforts. On Fri, May 6, 2022, 3:37 PM Erich Wälde <ew....@na...> wrote: > > Dear AmForthers, > > I am herewith stepping down from the maintainer role of AmForth. For > details, > read on. If anyone is interested to take over, get in touch with me. > > > In 2020 I received the logins of amforth.sourceforge.net, basically > because I > was lucky enough to have met Matthias personally a few times. At that time > I > had a lot of ideas on how to proceed. And while I managed to create an > official release, there are a few obstacles in this path. > > First and foremost I am facing a health issue. It is subtle, but it > seriously limits, what I can do. I still have to make several difficult > decisions regarding my daily life. I have started to decrease the number of > things on my list by cancelling items. I have to accept the fact, that I'm > not > in a position any more to advance the AmForth project in a meaningful way. > > Secondly, AmForth has become complex over time. Matthias added support for > three more target platforms (msp430, arm, riscv32). Allthough access to > these > is easily achievable, I use only avr. And I use it less these days. > > Thirdly, AmForths tools are depending heavily on python code, a language I > consider myself illiterate in. I have written a few small perl scripts > around > AmForth to serve my needs. I heavily depend on those and on a Makefile. > > Add the fact, that in 2020 I spent countless hours to port my data > acquisition > stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To > this day I still have no clue, why the thing hangs itself after some time, > sometimes hours, sometimes several days. In other words: unusable. > > > Step back: what would I have done, if I didn't know Matthias, and the > project > would just have become silent? Simplify. Simplify heavily. > > Very recently I have made a fork of AmForth release 5.0. That version is > before support for msp430 was officially added (5.5). That version happens > to > compile with avra rather than wine/avrasm2.exe. Along the way I found, that > avra has seen new releases, which add support for my beloved atmega644p and > lots of fixes, which is nice! This removes the dependancy from wine and > allows > for smaller systems for development. > > So I have picked up my data acquisition project again with the fork > mentioned > above. Any Interrupt Service Routines are written in assembly to avoid the > thing that I uncovered in 2017, namely a race condition 1 bit wide and 1 > instruction cycle long. I pick missing bits and pieces from later > releases. I > would like to add a few features regarding sensors with different needs. A > first experiment has run more than 10^6s (12d) without any failure. So I am > moderately optimistic to continue along this simplified path. > > > Thanks to all, who have answered the list, contributed code, ideas, > documentation in one form or other. It has been an interesting experience. > And should you still care to listen: if you have one or a few more > important > plans, do not delay them, you might be unable to pursue them later. > > Happy hacking, and use the Forth! > > 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...> - 2022-05-06 07:36:47
|
Dear AmForthers, I am herewith stepping down from the maintainer role of AmForth. For details, read on. If anyone is interested to take over, get in touch with me. In 2020 I received the logins of amforth.sourceforge.net, basically because I was lucky enough to have met Matthias personally a few times. At that time I had a lot of ideas on how to proceed. And while I managed to create an official release, there are a few obstacles in this path. First and foremost I am facing a health issue. It is subtle, but it seriously limits, what I can do. I still have to make several difficult decisions regarding my daily life. I have started to decrease the number of things on my list by cancelling items. I have to accept the fact, that I'm not in a position any more to advance the AmForth project in a meaningful way. Secondly, AmForth has become complex over time. Matthias added support for three more target platforms (msp430, arm, riscv32). Allthough access to these is easily achievable, I use only avr. And I use it less these days. Thirdly, AmForths tools are depending heavily on python code, a language I consider myself illiterate in. I have written a few small perl scripts around AmForth to serve my needs. I heavily depend on those and on a Makefile. Add the fact, that in 2020 I spent countless hours to port my data acquisition stuff at home from amforth 4.6 to 6.9 and it just did not become stable. To this day I still have no clue, why the thing hangs itself after some time, sometimes hours, sometimes several days. In other words: unusable. Step back: what would I have done, if I didn't know Matthias, and the project would just have become silent? Simplify. Simplify heavily. Very recently I have made a fork of AmForth release 5.0. That version is before support for msp430 was officially added (5.5). That version happens to compile with avra rather than wine/avrasm2.exe. Along the way I found, that avra has seen new releases, which add support for my beloved atmega644p and lots of fixes, which is nice! This removes the dependancy from wine and allows for smaller systems for development. So I have picked up my data acquisition project again with the fork mentioned above. Any Interrupt Service Routines are written in assembly to avoid the thing that I uncovered in 2017, namely a race condition 1 bit wide and 1 instruction cycle long. I pick missing bits and pieces from later releases. I would like to add a few features regarding sensors with different needs. A first experiment has run more than 10^6s (12d) without any failure. So I am moderately optimistic to continue along this simplified path. Thanks to all, who have answered the list, contributed code, ideas, documentation in one form or other. It has been an interesting experience. And should you still care to listen: if you have one or a few more important plans, do not delay them, you might be unable to pursue them later. Happy hacking, and use the Forth! Cheers Erich -- May the Forth be with you ... |
From: George H. <jac...@gm...> - 2022-04-17 11:16:28
|
The big advantage with the Arduino Mega is lots of 8 bit ports available for parrallel i/o. The Arduino Uno pretty much forces all i/o to be serialized one way or another. On Sun, Apr 17, 2022 at 3:33 PM Martin Nicholas via Amforth-devel < amf...@li...> wrote: > On Sun, 17 Apr 2022 07:47:15 +0100 > Tristan Williams <ho...@tj...> wrote: > > > Hi Christian, > > > > Glad it worked. > > > > > How much of 256KB flash is effectively usable with AmForth on the > > > 2560? ? > > > > 64k only (which is heaps) - W and IP are 16-bits only. The upper 64k is > still available, a little bit is used for the flashing code. I use > some of this space for user messages. > > > Good question. I don't know. The file avr8/words/store-i_big.asm may > > give some clues. > > > > > Will this work as well on a Chinese ATmega2560ProMini (with FTDI > > > USB chip for terminal input) ? > > > > Again, I don't know. However, if the board has an ATmega2560 mcu > > running at 16 MHz then there is good chance. I think only by flashing > > the board and testing it will you have a better idea. > > > > The clones work fine. Out of the box you might have to blow the fuses > first - before flashing the memory. > > -- > Regards, > > Martin Nicholas. > > E-mail: rep...@mg... (Address will be valid throughout 2022). > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > Amf...@li... > https://lists.sourceforge.net/lists/listinfo/amforth-devel > |