amforth-devel — Development discussion and user support

Re: [Amforth-devel] Enough for today

[Christian K. <ck...@pe...>]

Hi Andy,

I just upgraded to trunk and the duemilanove target fails to upload
because the address range is too big:

[exec] avrdude: ERROR: address 0x8010 out of range at line 300 of duemilanove.hex

This happens with revision 883.

I also experienced hangs when I try to define colon words, once I
reset the controller it seems hosed, i.e. numbers arent put on the
stack but crash the atmega (or make it loop indefinitely)

What's your workflow when developing forth for these embedded
devices?

HTH,

Christian

Re: [Amforth-devel] devices path

[<an...@ki...>]

Mathias

Please find attached a copy of the updated diecimila.asm and device.asm 
(atmega 168 now fixed) files.

Also the latest copy of the readme.txt file which has the fuse settings 
in for each board that I have successfully tested.

With these files it assembles with no errors or warnings and programs 
into my test diecimila board fine. appears to work fine.

To date now I have working loaded images built form the svn-876 sources 
plus tweaks (mostly trivial realy) for the folloowing Arduino Boards.

Mega
Diecimila
Duemilanova

I am just looking onto buying and/or mocking up a 644p based Sanguino 
for testing. Again I have an image built with no errors and warnigns but 
have not tested it yet.

Cheers

Andy Kirby (aka47)

Re: [Amforth-devel] devices path

[<an...@ki...>]

Mathias

Please find attached a copy of the updated readme.txt and 
duemilanove.asm files.

The asm file has a tweaked device path and an odd spurious comment 
tidyed up. The readme.txt details the fuse settings I used to program my 
test board with hex files built from svn-876 and the attached asm file.

It assembled with no errors or warnings and the programmed arduino 
appeared to work fine.

Cheers

Andy Kirby (aka47)

Re: [Amforth-devel] devices path

[Matthias T. <mt...@we...>]

Andy,

> Just pulled down up to svn 876 and started to work through the arduino defs.

trunk is dangerous ;=)


> Have I missed something is there a magic macro somewhere that picks up 
> what the device is and sorts this out or do I need to tweak this for the 
> others too ??

I'm currently redesigning the source files (again) and did not update
the docs yet. If in doubt, please stay with the 3.9 release. The next 
(4.0) will have an updated docu. Basically you need to add the proper
device/<type> directory as well. But again: It's still work-in-progress
and unfinished.

> 
> Mathias by copy:
> 
> Please find attached a copy of the tweaked mega.asm just in case this 
> was something that needed fixing rather than my understanding. I removed 
> a little bit of superfluous comment too.

I cleaned up a lot of such lines recently, not all is already in 
the subversion...

Matthias

[Amforth-devel] devices path

[<an...@ki...>]

Guys

Just pulled down up to svn 876 and started to work through the arduino defs.

Something that is probably me but I had to tweak the mega.asm file 
changing the path for device.asm so that studio would find it.

Have I missed something is there a magic macro somewhere that picks up 
what the device is and sorts this out or do I need to tweak this for the 
others too ??

Mathias by copy:

Please find attached a copy of the tweaked mega.asm just in case this 
was something that needed fixing rather than my understanding. I removed 
a little bit of superfluous comment too.

Cheers

Andy Kirby (aka47)

[Amforth-devel] [Solved] Possible problem in words/greater.asm

[Erich W. <ew....@na...>]

Just for the records:

this was a classic "layer 8" problem:

: > ~end ; \ cancel rs485 echo loops  <-- bad idea!

:-/
Erich

On 06/02/2010 11:34 AM, Erich Waelde wrote:
> Hello,
>
> I was wondering, why my simple code would stall the controller.
> Turns out that '<' and'>' behave differently, or more
> precisely, '>' (words/greater.asm) seems broken. This is in
> releases/3.8, but md5sum suggests, this file is unchanged in
>
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.3/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.4/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.5/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.6/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.7/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.8/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.9/core/words/greater.asm
> e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/trunk/core/words/greater.asm
>
> However, this could be a sideeffect from some other change ...
>
>
>   >  ver
> amforth 3.8 ATmega32 ok
>   >  : f1  1 >  if ." gt" else ." not gt" then cr ;
>    ok
>   >  : f2  1 <  if ." lt" else ." not lt" then cr ;
>    ok
>   >  4 f2
> not lt
>    ok
>   >  4 f1
> ��獊�����<-- controller stalls here
>
>
> Cheers,
> Erich
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

[Amforth-devel] avra

[Ian J. <ij...@sa...>]

Just FYI,

There seems to be some activity around AVRA again and an upcoming 1.3 release.

"Thanks to Tobias Weber I'm now the project admin and integrating the patches from the mailing list and some new targets. It is already in the git repository but have to make a release. This release will also support Apple Mac OS X snow leopard Universal :-)

2010-05-11 19:50:44 UTC by jerryjacobs"

In addition there are some tools in the mailing list archives I missed to add additional part descriptors to device.c to the Assembler.  I ended up manually patching some version of AVRA (1.2.x) to support the ATMEGA169 that seemed to work although I'm not entirely sure I did it correctly.  The tcl tool works against the xml part description files.  I have not tried yet.

http://sourceforge.net/mailarchive/message.php?msg_id=44B8B018.5000604%40suprafluid.de

Sadly wine didn't (doesn't) work on my version of 64 bit FreeBSD so I ended up using Avra for amforth which seems OK.  I thought others might have the same issue.

IJ

Re: [Amforth-devel] Forthduino

[<an...@ki...>]

Just caught up with the renames/ moves etc.

This is looking good, thanks mathias. Found the Duemilanova starter 
files too.

I will get those other files out some time soon honest guys, just been 
up to my eyeballs.

Cheers

Andy Kirby

On 30/05/10 19:55, an...@ki... wrote:
> Guys
>
> Dumb question time.
>
> Why is the template for the forthduino in the /applications section
> rather than in /trunk/appl with the other development boards like the
> butterfly ??
>
> The forthduino template is'nt actually an application it is a
> development board to build an application on.
>
> In all reality anywhere is good and I am happy to go with the flow, it
> just seems a little counter intuitive.
>
> Thoughts
>
> Cheers
>
> Andy Kirby
>
>
>

Re: [Amforth-devel] Protected Amforth

[Andy K. <an...@ki...>]

Ok what would you rather name them ???
I am not too hung up on names.

I agree that the prpject needs to protect itself from fuss.


-- 
Like a rolling stone
----- Original message -----
> Hi Andy,
> 
> > Did someone get the 168 to actualy work or do I need to put some time
> > into this again ??
> 
> All systems mentioned in the core/devices directory should work
> without trouble.
> 
> > I will rename the forthduino asm file to be mega and add in definitions
> > for Duemilanove, Deicimilla and Sanguino. A bit like the Polin
> > boards/definitions. That should pretty much be the full set of major
> > Arduino boards then. I can't see the point of doing any more than
> > those.
> 
> I agree with you that the arduino boards are (now) much better suited as
> a starting point than the pollins. But the pollin's are cheaper (at least
> for me ;=) ). And they can be used for a any controller that is still
> available
> in the PDIP format (no SMD) That makes porting amforth much easier.
> 
> forthduino may serve as the toplevel name for various implementations
> since they are no longer real arduino's. But: IANAL I do not want to get
> any legal trouble
> 
> 
> 
> Matthias
> 
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.   See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Forthduino

[Andy K. <an...@ki...>]

At the moment yes. When isr comms and the debug led code is added in though they will have differed a little.

Has anyone had much of a play with zigbee yet ???

-- 
Like a rolling stone
----- Original message -----
> > Guys
> > 
> > Dumb question time.
> > 
> > Why is the template for the forthduino in the /applications section
> > rather than in /trunk/appl with the other development boards like the
> > butterfly ??
> 
> The application section contains all of the hardware that I cannot test
> myself.
> 
> > In all reality anywhere is good and I am happy to go with the flow, it
> > just seems a little counter intuitive.
> 
> In the meantime I've got my own arduino mega so I may move
> the code to the "right" place at trunk/appl/arduino
> 
> The various types of arduinos may be part of the game, they are
> mostly duplicates of the eval-pollin/ tree but with different build
> names.
> 
> 
> Matthias
> 
> 
> 
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate 
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
> lucky parental unit.   See the prize list and enter to win: 
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] Protected Amforth

[Matthias T. <mt...@we...>]

Hi Andy,

> Did someone get the 168 to actualy work or do I need to put some time
> into this again ??

All systems mentioned in the core/devices directory should work
without trouble.

> I will rename the forthduino asm file to be mega and add in definitions
> for Duemilanove, Deicimilla and Sanguino. A bit like the Polin
> boards/definitions. That should pretty much be the full set of major
> Arduino boards then. I can't see the point of doing any more than those.

I agree with you that the arduino boards are (now) much better suited as a
starting point than the pollins. But the pollin's are cheaper (at least
for me ;=) ). And they can be used for a any controller that is still
available
in the PDIP format (no SMD) That makes porting amforth much easier.

forthduino may serve as the toplevel name for various implementations since
they are no longer real arduino's. But: IANAL I do not want to get any legal
trouble



Matthias

Re: [Amforth-devel] Forthduino

[Matthias T. <mt...@we...>]

> Guys
>
> Dumb question time.
>
> Why is the template for the forthduino in the /applications section
> rather than in /trunk/appl with the other development boards like the
> butterfly ??

The application section contains all of the hardware that I cannot test
myself.

> In all reality anywhere is good and I am happy to go with the flow, it
> just seems a little counter intuitive.

In the meantime I've got my own arduino mega so I may move
the code to the "right" place at trunk/appl/arduino

The various types of arduinos may be part of the game, they are
mostly duplicates of the eval-pollin/ tree but with different build
names.


Matthias

Re: [Amforth-devel] files for atmega644

[<an...@ki...>]

Erich

Thanks for that, I can read the forth on Lubos site but struggle with 
the eastern european. Checkoslovakian ??

With the 485 I have always been a little concerned about the overhead of 
microcontrolers following a data stream of which only a fraction is 
addressed for the controler.

Reading through the Atmegas usarts there is an additional 9 bit mode 
that allows the usart to ignore traffic that is'nt addressed for the 
microcontroler in question. Good for reducing unnecesary interupts etc.

I think this could be useful.

Cheers

Andy Kirby



On 31/05/10 13:00, Erich Waelde wrote:
> On 05/31/2010 10:04 AM, Andy Kirby wrote:
>> Hmmmmmm
>>
>> rs485 interesting thats on my list of things to do one day.
>> A lightweight 485lan using the multidrop features of the atmel uart.
>
>
> The rs485 part was shamelessly stolen from Lubos:
> http://www.forth.cz
>
> I'm using this for my stuff with modest success ...
>
> Cheers,
> Erich
>

Re: [Amforth-devel] Possible problem in words/greater.asm

[Kalus M. <mic...@on...>]

Hm...:

» diele
  ok
» ver
amforth 3.6 ATmega168.forthISRoff ok
» 1 4 <
  ok
» 1 4 >
  ok
» .s
0 1195 0
1 1197 65535
  ok
» : f1  1 > if ." gt" else ." not gt" then cr ;
  ok
» : f2  1 < if ." lt" else ." not lt" then cr ;
  ok
» 4 f1
gt
  ok
» 4 f2
not lt
  ok
» 1 f1
not gt
  ok
» 1 f2
not lt
  ok
» 0 f1
not gt
  ok
» 0 f2
lt
  ok
»

Michael

[Amforth-devel] Possible problem in words/greater.asm

[Erich W. <ew....@na...>]

Hello,

I was wondering, why my simple code would stall the controller.
Turns out that '<' and '>' behave differently, or more
precisely, '>' (words/greater.asm) seems broken. This is in
releases/3.8, but md5sum suggests, this file is unchanged in

e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.3/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.4/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.5/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.6/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.7/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.8/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/releases/3.9/core/words/greater.asm
e7c30a91806871702d10a0fe4a2f8b28  Forth/amforth/trunk/core/words/greater.asm

However, this could be a sideeffect from some other change ...


 > ver
amforth 3.8 ATmega32 ok
 > : f1  1 > if ." gt" else ." not gt" then cr ;
  ok
 > : f2  1 < if ." lt" else ." not lt" then cr ;
  ok
 > 4 f2
not lt
  ok
 > 4 f1
��獊�����   <-- controller stalls here


Cheers,
Erich

Re: [Amforth-devel] Amforth 3.9 errors with ATmega128

[Andy K. <an...@ki...>]

Best advice is double check that the serial comms isr stuff rx and tx is commented out and the polled serial stuff is un commented.

After that crack open the data sheet for your device and double check the uart mnemonics for correct uart and that the a b c regisgters are being initialised to something sensible. Ie

8 bits no stop interupts disabled. Make sure mode of uart reg c is definitely async. My original template was set synchronous.

If that does,nt work i think you will probably need to mail out your device and build files so we can see what is in them.

Sorry for my email workstation is belly up and this is from my phone.

Cheers

andy kirby 

-- 
Like a rolling stone
----- Original message -----
> Hi Guys
> 
> I tried version 3.9 for my ATmega128.     I got it to compile without
> errors, but it does not display a prompt. 
> 
> Did you run across issues with the extended I/O ports? 
> 
> m128.inc:
> ; Definitions marked "MEMORY MAPPED"are extended I/O ports
> ; and cannot be used with IN/OUT instructions
> .equ    SPMCSR    = 0x68    ; MEMORY MAPPED
> 
>       change IN to LDS                   - istore_nrww.asm(109)
>       change OUT to STS                 - istore_nrww.asm(116)
> 
> I saw that Andy had to sort out issues with interupts and asynchronous,
> did these make into the core portion of the package or is that only
> apply to the ardurino?     
> 
> My results are attached if you would be so kind as to take a look.     
> 
> Thanks!
> 
> D
> 
> 
>               
<Attachment>     amforth39-ATmega128errors.txt

Re: [Amforth-devel] Amforth 3.9 errors with ATmega128

[Andy K. <an...@ki...>]

Best advice is double check that the serial comms isr stuff rx and tx is commented out and the polled serial stuff is un commented.

After that crack open the data sheet for your device and double check the uart mnemonics for correct uart and that the a b c regisgters are being initialised to something sensible. Ie

8 bits no stop interupts disabled. Make sure mode of uart reg c is definitely async. My original template was set synchronous.

If that does,nt work i think you will probably need to mail out your device and build files so we can see what is in them.

Sorry for my email workstation is belly up and this is from my phone.

Cheers

andy kirby 

-- 
Like a rolling stone
----- Original message -----
> Hi Guys
> 
> I tried version 3.9 for my ATmega128.    I got it to compile without
> errors, but it does not display a prompt. 
> 
> Did you run across issues with the extended I/O ports? 
> 
> m128.inc:
> ; Definitions marked "MEMORY MAPPED"are extended I/O ports
> ; and cannot be used with IN/OUT instructions
> .equ    SPMCSR    = 0x68    ; MEMORY MAPPED
> 
>      change IN to LDS                  - istore_nrww.asm(109)
>      change OUT to STS                - istore_nrww.asm(116)
> 
> I saw that Andy had to sort out issues with interupts and asynchronous,
> did these make into the core portion of the package or is that only
> apply to the ardurino?    
> 
> My results are attached if you would be so kind as to take a look.    
> 
> Thanks!
> 
> D
> 
> 
>              
<Attachment>    amforth39-ATmega128errors.txt

Re: [Amforth-devel] files for atmega644

[Erich W. <ew....@na...>]

On 05/31/2010 10:04 AM, Andy Kirby wrote:
> Hmmmmmm
>
> rs485 interesting thats on my list of things to do one day.
> A lightweight 485lan using the multidrop features of the atmel uart.


The rs485 part was shamelessly stolen from Lubos:
http://www.forth.cz

I'm using this for my stuff with modest success ...

Cheers,
Erich

Re: [Amforth-devel] files for atmega644

[Andy K. <an...@ki...>]

Hmmmmmm

rs485 interesting thats on my list of things to do one day. A lightweight 485lan using the multidrop features of the atmel uart.

Thanks i'll have a rummage through the files and recycle as a start point.

Cheers

andy kirby

-- 
Like a rolling stone
----- Original message -----
> Andy,
> 
> I found an old (amforth 3.5) folder for the atmega644, used with
> the Atmel Assembler2
> 
> > I have 168's and 644's left over from reprap work and 16mhz crystals,
> > so can bread board those.
> 
> 
> So please find attached another tar files with stuff to recycle.
> ./36_rs485_ws4_644/Makefile
> ./36_rs485_ws4_644/dict_appl.inc
> ./36_rs485_ws4_644/dict_appl_core.inc
> ./36_rs485_ws4_644/main.asm
> ./36_rs485_ws4_644/devices/atmega644.asm
> ./36_rs485_ws4_644/devices/atmega644.frt
> ./36_rs485_ws4_644/devices/m644def.inc
> ./36_rs485_ws4_644/main.fs
> ./36_rs485_ws4_644/main.fs.unfold
> 
> No promises, on how good this is though ...
> 
> Cheers,
> Erich

[Amforth-devel] files for atmega644

[Erich W. <ew....@na...>]

Andy,

I found an old (amforth 3.5) folder for the atmega644, used with
the Atmel Assembler2

>  I have 168's and 644's left over from reprap work and 16mhz crystals, so can bread board those.


So please find attached another tar files with stuff to recycle.
./36_rs485_ws4_644/Makefile
./36_rs485_ws4_644/dict_appl.inc
./36_rs485_ws4_644/dict_appl_core.inc
./36_rs485_ws4_644/main.asm
./36_rs485_ws4_644/devices/atmega644.asm
./36_rs485_ws4_644/devices/atmega644.frt
./36_rs485_ws4_644/devices/m644def.inc
./36_rs485_ws4_644/main.fs
./36_rs485_ws4_644/main.fs.unfold

No promises, on how good this is though ...

Cheers,
Erich

Re: [Amforth-devel] Protected Amforth

[Erich W. <ew....@na...>]

Hi Andy

> Did someone get the 168 to actualy work or do I need to put some time
> into this again ??

I have a "rumpus" (http://www.lochraster.org/rumpus/) featuring an atmega168.

I do have a working configuration using amforth 3.7 and using the "avra" Assembler.
Please find attached a tar file with the more relevant files
./40_rumpus/Makefile
./40_rumpus/dict_appl.inc
./40_rumpus/dict_appl_core.inc
./40_rumpus/main.asm
./40_rumpus/devices/atmega168.asm
./40_rumpus/devices/atmega168.frt
./40_rumpus/devices/m168def.inc
./40_rumpus/main.fs

Feel free to recycle, or ask for missing parts.


Cheers,
Erich

Re: [Amforth-devel] Protected Amforth

[Kalus M. <mic...@on...>]

Hi Andy.


Am 30.05.2010 um 21:04 schrieb an...@ki...:
..
> Did someone get the 168 to actualy work or do I need to put some time
> into this again ??

I use amforth 3.6 on a board called "triacmega2" (4x Triacs 220V,  
4xADC) to control solar heat colecting at home. The board is used in  
an industrial scale as well. amforth ran right away, no probs. Well,  
almost: You have to have the right m168def.inc and for AVRA there at  
hand.
I still use AVRA Version 1.2.0 Build 30 (15. October 2006) which can  
not handle the #<commands> in the m168def.inc file like #ifndef  
#endif and #pragma so I had to comment them out. My m168def.inc  
version is from 2005 too, still working on PowerBook G4, macOSX.

The other adjusment was caused by the application: polling key and  
emit, excluding amforths high level interupt handling, changing emit  
to halfduplex.

Michael

Re: [Amforth-devel] Protected Amforth

[<an...@ki...>]

Mathias

I have just been doing a comparison of a hand full of Atmegas and their 
boot loader/protected flash sizes. Principaly aimed at forthduino as 
they are mostly the types used for the most common of the arduino boards 
plus the sanguino (greatly favored by the maker-bot community within the 
reprap project)

1280, 168, 328, 644

The largest common size really is 1K.

So I guess this ends up being as you suggest, bootloader/bios territory, 
plus as many of the primitives as can be got into the 1k.

Did someone get the 168 to actualy work or do I need to put some time 
into this again ??

Just ordering up a duemilanove (328) for testing. I have 168's and 644's 
left over from reprap work and 16mhz crystals, so can bread board those.

I will rename the forthduino asm file to be mega and add in definitions 
for Duemilanove, Deicimilla and Sanguino. A bit like the Polin 
boards/definitions. That should pretty much be the full set of major 
Arduino boards then. I can't see the point of doing any more than those.

Cheers

Andy Kirby





On 26/05/10 18:50, Matthias Trute wrote:
> Am 26.05.2010 17:48, schrieb an...@ki...:
>> Guys
>>
>> Been doing some thinking on bits of the conversations going off recently
>> about protecting the Amforth Core from accidental overwrite. (Useful in
>> some cases, particularly teaching scenarios and new starters). Thought I
>> should throw them into the ring for discussion.
>>
>> Creating protection is as I understand it a three step process.
>>
>> 1. Rearrange the core words (or at least everything needed to compile
>> and load the rest. etc into the boot-loader area as if it were a large
>> boot-loader.
>>
>> 2. Tweak the interrupts and reset vectors (maybe the reset ISR too) and
>> code to deal with the new location and prepare for a boot-loader start
>> (That is actually the Amforth core system).
>
> My ideas go into the same direction. the amforth system in the
> bootloader section can be seen either as the "real" system or as a
> BIOS like utility that only checks the setup and than hand over
> the execution to the "real" code, which may be another amforth
> system or something completly different.
>
>> This pseudo boot loader does
>> in fact boot but doesn't pass off execution to anything unless turnkey
>> is setup to do so. Turnkey or a rewritable template turnkey would have
>> to live in the normal flash area so it could be rewritten if necessary.
>
> turnkey is a deferred word, and as such it is easy to give it
> new code to execute.
>
>> 3. Set the boot vector option in the fuses to make it boot from the top
>> of flash (boot loader boot) rather than the bottom (Usual or non boot
>> loader boot).
>
> thats a technical need.
>
>>
>> Activating protection is a case of setting the appropriate fuses etc to
>> lock down the boot-loader/upper flash area.
>
> The undestroyable amforth does not need to be protected with fuses (at
> least not per se). It is from the fact that the bootload area cannot be
> overwritten with anything that runs on the same controller. Just like a
> bootloader cannot overwrite itself. Using some fuses may be an add-on,
> but I doubt that it is that useful.
>
>> Notes/thoughts.
>>
>>
>> C. Issues I can see with this is that not all devices have as big a boot
>> loader area. (Don't quote me on this, I could be wrong and would have to
>> go through all the data sheets to be sure)
>
> thats right. Only the bigger controller types have the 8K+ bootloader
> section. On smaller systems, sorry. No way.
>
>>
>> D. It may be worth considering creating a word like "FactoryReset" or
>> something that lives in the core/Boot-loader section and after
>> confirmation wipes/purges/re-initializes the non core/Boot-loader
>> section. Restoring the board/chip to a clean state. (Good for classroom
>> scenarios and new starters)
>
> you are right, thats absolutly neccessairy. It need to reset the
> essential EEPROM cells as well.
>
>> E. Making the ability to clone the current state of the device ie a
>> "clone" word, part of the protected core/boot-loader would be optimal.
>
> I dont see the clone word in the bootloader section. Cloning a
> malfunctioning system image is useless. The cloning may clone
> the bootloader section only, the remaining flash may be transferred
> separatly. And putting the clone word into the normal flash area gives
> much more code space to make it a comfortable tool.
>
>> There are arguments for not doing this and making it optional.
>> Personally I favor the idea that it becomes an intrinsic part of all
>> Amforth implementations. (Today forthduino, tomorrow the world, "Go
>> forth and multiply" is a mangled biblical quote that springs to mind)
>
> It may be part of the distribution but never ever part of the
> default configuration.
>
>>
>> F. Given all of the above we could be struggling in 8k of boot-loader
>> unless something or other could me done with the current core set to
>> make space.
>
> There is still room for optimization, no doubt. But 8K is not that
> little space.
>
> Matthias
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth-devel] Forthduino

[<an...@ki...>]

Guys

Dumb question time.

Why is the template for the forthduino in the /applications section 
rather than in /trunk/appl with the other development boards like the 
butterfly ??

The forthduino template is'nt actually an application it is a 
development board to build an application on.

In all reality anywhere is good and I am happy to go with the flow, it 
just seems a little counter intuitive.

Thoughts

Cheers

Andy Kirby

[Amforth-devel] Amforth 3.9 errors with ATmega128

[D W. <dou...@ya...>]

Hi Guys

I tried version 3.9 for my ATmega128.  I got it to compile without errors, but it does not display a prompt. 

Did you run across issues with the extended I/O ports? 

m128.inc:
; Definitions marked "MEMORY MAPPED"are extended I/O ports
; and cannot be used with IN/OUT instructions
.equ	SPMCSR	= 0x68	; MEMORY MAPPED

  change IN to LDS         - istore_nrww.asm(109)
  change OUT to STS        - istore_nrww.asm(116)

I saw that Andy had to sort out issues with interupts and asynchronous, did these make into the core portion of the package or is that only apply to the ardurino?  

My results are attached if you would be so kind as to take a look.  

Thanks!

D