Hi Erich, thank you for getting back to me so quickly. On Tue, 29 Dec 2020 at 22:30, Erich Wälde <ew.fo...@nassur.net> wrote:
> Well, well. This is one of the secrets that I have not yet > uncovered from the files I have. You might not know that the > author of AmForth has left this planet earlier this year. So we > have to make due with some code archeology :) > I saw with surprise and sadness the news of Matthias' passing. I imagine this has caused a great deal of disruption for this project. If I can help in any way I will. AVR128DA48. What a beast. I skimmed the datasheet only briefly > https://www.microchip.com/wwwproducts/en/AVR128DA48 > > If you want to work your way to support this chip, I suggest to > make a twofold approach: > > 1. Have a controller, which is supported by AmForth already, > like the venerable atmega328p. Use this to set up the whole tool > chain and verify, that you can build and upload it, and that the > result is actually working. Unless, of course, you have done > this already. > I have access to an STK600 and several devices in the atmega family. Haven't programmed one with AmForth yet but based on what I've read in the documentation I am not expecting too many problems. > 2. Then try to fill in pieces for the new controller. Start with > the files of a supported controller with the same size flash/ram > /eeprom. > > You have to make sure, that the new controller uses the exakt > same set of assembly instructions --- it probably does not, > because I read the word "hardware multiplier" > > > The AVR128DA48 microcontroller is part of the AVR DA family > > featuring the AVR processor with hardware multiplier - running > > at up to 24 MHz and with 128 KB Flash, 16 KB SRAM and 512 > > bytes of EEPROM in 48-pin packages. > I don't think it's going to be straight forward - https://ww1.microchip.com/downloads/en/Appnotes/Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf There appear to be a number of changes at the C macro and register level from the previous mega generation. I have not dug deep enough into the AmForth code yet but it may require a fair bit of rework. Meanwhile I will have a look whether I can uncover the generator > scripts from some dusty corner ... > > Ok, I think I found them: > > $ ls -l pd2amforth ./pd/* > > -rw-r----- 1 ew ew 122 2015-09-03 18:09 ./pd/__init__.py > > -rw-r----- 1 ew ew 226 2015-09-03 18:09 ./pd/convert_number.py > > -rw-r----- 1 ew ew 2183 2016-10-18 20:40 ./pd/device.py > > -rw-r----- 1 ew ew 1187 2016-10-18 20:40 ./pd/interrupts.py > > -rw-r----- 1 ew ew 200 2015-09-03 18:09 ./pd/make_path.py > > -rw-r----- 1 ew ew 1618 2016-10-18 20:40 ./pd/register.py > > -rw-r----- 1 ew ew 1509 2016-10-18 20:40 ./pd/sleep.py > > -rw-r----- 1 ew ew 1065 2016-10-18 20:40 ./pd/wdt.py > > -rwxr-x--- 1 ew ew 1840 2016-10-18 20:40 pd2amforth* > > > I do not know really, how they work, but I can certainly add > them to the repository ... > Thanks, please let me know when you have had a chance to add the scripts, device.py looks interesting. > Cheers, > Erich > Cheers, Stephen > > -- > May the Forth be with you ... And also with you ;) _______________________________________________ > 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
