Re: [Amforth] avr8
Hello Brian, thanks for your message! > ... to the arm based systems where the 'real' work can be > done. Well observed imho. I read a book on PIC microcontrollers many years back, where the authors made a case that if need be, counted loops (in asm, no matter which way through the if statements the code executes, it will always take exactly the same time) are your tool to make the 8 bitter - sing a song - dim a 50/60 Hz lamp - do one more job i forgot by now - all at the same time and organize these three jobs well. Eye opening and jaw droping at the same time. It has made a lasting impression on me. > So I ask that you don't eliminate the ability > to build from source, even if it means using wine and the atmel > (micochip) assembeler. Rest assured. First of all *I* want to build from source any time, because I still play with stuff written in assembly. And I don't want this project to die, just because I happen to use it myself! Who would have thought :-) And most importantly: this is GPL software. The source ist the fundamental representation of the whole project. It always must be possible to build from source. I'm just a whee bit uneasy that this fine project depends on non-free components for this very step. And I had good discussions with Matthias about this. There is just no /easy/ way out, I'm afraid. But: lurking folks on the list resorted to writing emails! Even sending patches! Definitely progress around here. Thank you! Cheers, Erich -- May the Forth be with you ... ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] avr8
Hello Brian, My suggestion was just that the prebuilt AVR hex files in the distribution should include more assembler words as standard. Being able to build from source means being able to do things that might otherwise prove impossible. Not something I would want to change. Best wishes, Tristan On 06Jul20 10:08, Brian wrote: > Sending this again > > Hello, > > I'm an avr8 user and love amforth. This is the best system for an eight bit > micro that lets you have interactive use of the chip. Things like circuit > python and ulisp are cool but so resource intensive or tied to the arduino > ecosystem that they become fun toy environments (on the 8 bit platforms) > meant to move you on to the arm based systems where the 'real' work can be > done. So I ask that you don't eliminate the ability to build from source, > even if it means using wine and the atmel (micochip) assembeler. These tools > allowed me to build and run the current amforth on the avrbutterfly. I think > this is a great project. I would love to help, especially in the > documentation. I'll keep my eyes open to how to submit patches. Thanks for > everything. > > brian-in-ohio > > On 7/1/20 2:17 AM, Tristan Williams wrote: > Hello, > > > Who of you is using which target controller? > I use AVR atmega328p, atmega1284p, atmega2560 > > > Can we get rid of the Atmel/Microchip Avrasm Assembler? > Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine > that would be a lot of work and wine does run it very well. > > Having "fuller" hex files in the distribution that have assembly words > like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would > delay the need to build AmForth. AVR flash and ram are not the limited > resource they once were. It might be worth updating the documentation > to say which hex files are available. > > > Would it be feasible to drop msp430, arm, risc-v in order to simplify > > the whole thing? yes/no? > I think that depends on the collective response to the first question. > > > amforth-shell.py and python3 > amforth-shell.py is a great tool for AmForth. I have modified it to > run under python3 and it works well for me. I will put up a patch but > it really needs testing in a python os/environment other than mine. > > > ticket system or mailing list ? > I would prefer a mailing list. > > Thank you Erich for AmForth Weekend #1 - I look forward to #2 > > Best wishes, > Tristan > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] avr8
Sending this again Hello, I'm an avr8 user and love amforth. This is the best system for an eight bit micro that lets you have interactive use of the chip. Things like circuit python and ulisp are cool but so resource intensive or tied to the arduino ecosystem that they become fun toy environments (on the 8 bit platforms) meant to move you on to the arm based systems where the 'real' work can be done. So I ask that you don't eliminate the ability to build from source, even if it means using wine and the atmel (micochip) assembeler. These tools allowed me to build and run the current amforth on the avrbutterfly. I think this is a great project. I would love to help, especially in the documentation. I'll keep my eyes open to how to submit patches. Thanks for everything. brian-in-ohio On 7/1/20 2:17 AM, Tristan Williams wrote: Hello, Who of you is using which target controller? I use AVR atmega328p, atmega1284p, atmega2560 Can we get rid of the Atmel/Microchip Avrasm Assembler? Unless AmForth/avr8 can be ported to gnu assembly, no. I would imagine that would be a lot of work and wine does run it very well. Having "fuller" hex files in the distribution that have assembly words like bm-clear, bm-set, sleep, spirw, wdr, store-wdc already, would delay the need to build AmForth. AVR flash and ram are not the limited resource they once were. It might be worth updating the documentation to say which hex files are available. Would it be feasible to drop msp430, arm, risc-v in order to simplify the whole thing? yes/no? I think that depends on the collective response to the first question. amforth-shell.py and python3 amforth-shell.py is a great tool for AmForth. I have modified it to run under python3 and it works well for me. I will put up a patch but it really needs testing in a python os/environment other than mine. ticket system or mailing list ? I would prefer a mailing list. Thank you Erich for AmForth Weekend #1 - I look forward to #2 Best wishes, Tristan ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
Re: [Amforth] amforth-shell.py and python3
Super. I just patched my local repo. All I had to do was to add the python3-serial package (debian buster) and change the defaults for the serial port and it fired right up. I'll try it next time I'm passing files around to see how things go here. Thank you, Mark On Mon, Jul 6, 2020 at 12:53 PM Tristan Williams wrote: > Hello, > > I have modified amforth-shell.py to run under python3 and put up a > patch here > > https://tjnw.co.uk/new-shell/doc/ > > as the patch seemed a little too large for a mailing list. > > Best wishes, > Tristan > > > > > ___ > Amforth-devel mailing list for http://amforth.sf.net/ > Amforth-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/amforth-devel > ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
[Amforth] amforth-shell.py and python3
Hello, I have modified amforth-shell.py to run under python3 and put up a patch here https://tjnw.co.uk/new-shell/doc/ as the patch seemed a little too large for a mailing list. Best wishes, Tristan ___ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
