amforth-devel — Development discussion and user support

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hello,

Again thanks for the response.
Yes I know that the boot loader is removed.
Stil I am try now for about 14 days to get a running AMforth.

These are my settings.

I need the B5 otherwise I get errors. Running XP under Parallels on my IMAC Lion.
Try also different computers, no good result!

avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U efuse:w:0x05:m -U hfuse:w:0xd9:m -U lfuse:w:0xFF:m
avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U flash:w:amforth.hex:i 
avrdude  -B 5 -q -c usbtiny  -P usb -p m328p -e -U eeprom:w:amforth.eep:i

and these settings I used for unlocking in the past

avrdude  -q -c usbtiny -b -P usb -p m328p -e -U lock:w:0x3f:m

As programmer I use the USBTinyISP, under windows XP.

I am now on the end, the last try is that someone is checking my flashed arm forth. I send it to the US.

Someone experience with burning under XP?

Cheers,

Jan

Hellevoetsluis-NL


Op 6 mei 2012, om 21:00 heeft Erich Waelde het volgende geschreven:

> Hello,
> 
> On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>> 
>> If I understand correctly the best is to buy some bare 328p chips,
>> and flash them without tatching the lock bits.
> 
> If fuses and "lock bits" refer to the same thing, then
> no: "bare chips" and arduino boards are different things.
> I personally use the following settings on arduino "duemilanove" 
> and "uno" boards
> 
> MCU=atmega328p
> # set the fuses according to your MCU
> LFUSE=0xFF
> HFUSE=0xD9
> # some MCU have this one, see write-fuses target below
> EFUSE=0x05
> 
> The bare chips will run on the internal RC oszillator at 1 (or 
> 8?) MHz, they will ignore the attached crystal, unless you 
> correct the fuse bits.
> 
> 
> There is a "readme.txt" file in the directory appl/arduino with 
> more information on arduinos.
> 
> And just to make sure: you are aware, that flashing amforth to 
> an arduino board does remove the arduino bootloader, are you?
> 
> 
> Cheers,
> Erich
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
avrdude  -q -c usbtiny -b -P usb -p m328p -e -U lock:w:0x3f:m

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hello,

On 05/06/2012 08:12 PM, Jan Kromhout wrote:
>
> If I understand correctly the best is to buy some bare 328p chips,
> and flash them without tatching the lock bits.

If fuses and "lock bits" refer to the same thing, then
no: "bare chips" and arduino boards are different things.
I personally use the following settings on arduino "duemilanove" 
and "uno" boards

MCU=atmega328p
# set the fuses according to your MCU
LFUSE=0xFF
HFUSE=0xD9
# some MCU have this one, see write-fuses target below
EFUSE=0x05

The bare chips will run on the internal RC oszillator at 1 (or 
8?) MHz, they will ignore the attached crystal, unless you 
correct the fuse bits.


There is a "readme.txt" file in the directory appl/arduino with 
more information on arduinos.

And just to make sure: you are aware, that flashing amforth to 
an arduino board does remove the arduino bootloader, are you?


Cheers,
Erich

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hi Matthias,

Thanks for the quick response.

If I understand correctly the best is to buy some bare 328p chips, and flash them without tatching the lock bits

This is perhaps the issue that my Amfort is not won't to run.

Cheers,

Jan

Op 6 mei 2012, om 19:16 heeft Matthias Trute het volgende geschreven:

> Hi Jan,
> 
>> When I take 2 new 328p with boot on it ( buy it recently from
>> original supplier) then when I read the lock byte the should be the
>> same? If my working version has an other number, because I did some
>> stupid things, I always can set it back to the origional value with
>> avrdude?
> 
> I've never changed any lock bits, just keep them as they are (all
> 1). When reading the lock bits (difficult enough), it may be
> possible that the unused bits in a byte may come up as 0 oder
> 1, thus changing the byte value. If you really want to check
> the lock bits, deal with the bits  themselves. For any details,
> consult the (long) datasheet(s).
> 
> Arduino has pre-programmed the controllers, maybe they have
> changed the lock bits too. You may have to ask the ardiuno
> people, why (but I doubt that they did it).
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi Jan,

> When I take 2 new 328p with boot on it ( buy it recently from
> original supplier) then when I read the lock byte the should be the
> same? If my working version has an other number, because I did some
> stupid things, I always can set it back to the origional value with
> avrdude?

I've never changed any lock bits, just keep them as they are (all
1). When reading the lock bits (difficult enough), it may be
possible that the unused bits in a byte may come up as 0 oder
1, thus changing the byte value. If you really want to check
the lock bits, deal with the bits  themselves. For any details,
consult the (long) datasheet(s).

Arduino has pre-programmed the controllers, maybe they have
changed the lock bits too. You may have to ask the ardiuno
people, why (but I doubt that they did it).

Matthias

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Jan K. <kro...@ho...>]

Hi

When I take 2 new 328p with boot on it ( buy it recently from original supplier) then when I read the lock byte the should be the same?
If my working version has an other number, because I did some stupid things, I always can set it back to the origional value with avrdude?

Jan kromhout
Sacharovlaan 3
3223HM Hellevoetsluis-NL

Op 6 mei 2012 om 16:20 heeft Matthias Trute <mt...@we...> het volgende geschreven:

> Hi,
> 
>> Hi, after a year I'm trying to run the latest version on atmega32
>> (11.0592Meg xtal). Compiling and flashing is ok, I get working
>> system with one exception - I cannot add a new word - ie 
>>> : foo 123 . ;
>> ok
>>> words
>> and it hangs here
> 
> Cannot reproduce:
> 
>> : foo 123 . ;
>   ok
>> words
>  foo pick nip ...
>> foo
> 
>  123  ok
> 
>> 
> 
>> Otherwise it works fine (even the floating point calcs work
>> properly). It seems it does not write internaly to flash or eeprom
>> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
>> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
>> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
>> high fuse (and many others..). What am I missing here?
> 
> Try high fuse set to 0xd9 (Atmega32). This sets the boot flash section
> to the default. high fuse 0xdf leads to a too small boot section
> size, and effectivly disables flash write operations (a !e should
> work however).
> 
> Lock fuses leave as they are set from the factory. Always. Never ever
> change them.
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[pito <pi...@vo...>]

Matthias,
thanks - yes - the bootloader space is used by amforth .. do not ask
me how much time I've spent tackling this, finally I thought my both
chips are dead... :) ... the D9 did the trick..
> foo
123  ok
Thanks,
Pito

----- PŮVODNÍ ZPRÁVA -----
Od: "Matthias Trute" <mt...@we...>
Komu: "Everything around amforth"
<amf...@li...>
Předmět: Re: [Amforth] Issues with a word compile - flash or eeprom
Datum: 6.5.2012 - 16:20:37

> Hi,
> 
> > Hi, after a year I'm trying to run the latest
> > version on atmega32
> > > (11.0592Meg xtal). Compiling and flashing is ok,
> > I get working
> > > system with one exception - I cannot add a new
> > word - ie 
> > >> : foo 123 . ;
> > ok
> >> words
> > and it hangs here
> 
> Cannot reproduce:
> 
> > : foo 123 . ;
> ok
> > words
> foo pick nip ...
> > foo
> 
> 123  ok
> 
> >
> 
> > Otherwise it works fine (even the floating point
> > calcs work
> > > properly). It seems it does not write internaly
> > to flash or eeprom
> > > properly. The lock fuses are 0x3f (write
> > enable). Baudrate, char and
> > > line delay, waiting on "ok" is set properly. BOD
> > disabled. Tried 2
> > > chips at 3.3V and 5V. Chips erased, programmed
> > with FF low and DF
> > > high fuse (and many others..). What am I missing
> > here?
> > 
> Try high fuse set to 0xd9 (Atmega32). This sets
> the boot flash section
> to the default. high fuse 0xdf leads to a too
> small boot section
> size, and effectivly disables flash write
> operations (a !e should
> work however).
> 
> Lock fuses leave as they are set from the factory.
> Always. Never ever
> change them.
> 
> Matthias
> 
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> Exclusive live event will cover all the ways
> today's security and 
> threat landscape has changed and how IT managers
> can respond. Discussions 
> will include endpoint security, mobile security
> and the latest in malware 
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for
> http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

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

Hi,

> Hi, after a year I'm trying to run the latest version on atmega32
> (11.0592Meg xtal). Compiling and flashing is ok, I get working
> system with one exception - I cannot add a new word - ie 
>> : foo 123 . ;
> ok
>> words
> and it hangs here

Cannot reproduce:

 > : foo 123 . ;
   ok
 > words
  foo pick nip ...
 > foo

  123  ok

 >

> Otherwise it works fine (even the floating point calcs work
> properly). It seems it does not write internaly to flash or eeprom
> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
> high fuse (and many others..). What am I missing here?

Try high fuse set to 0xd9 (Atmega32). This sets the boot flash section
to the default. high fuse 0xdf leads to a too small boot section
size, and effectivly disables flash write operations (a !e should
work however).

Lock fuses leave as they are set from the factory. Always. Never ever
change them.

Matthias

Re: [Amforth] Issues with a word compile - flash or eeprom write issues

[Charles S. <sum...@gm...>]

I had a similar problem with the uno until I saw I had left the flash
locked after I out on the forth image.
On May 6, 2012 7:51 AM, "pito" <pi...@vo...> wrote:

> Hi, after a year I'm trying to run the latest version on atmega32
> (11.0592Meg xtal). Compiling and flashing is ok, I get working
> system with one exception - I cannot add a new word - ie
> > : foo 123 . ;
> ok
> > words
> and it hangs here, so I have to reflash eeprom, then I can see words
> again (without foo). Moreover, I tried my old v4.4 images (which
> worked fine) with the same issue - I cannot compile a new word.
> Otherwise it works fine (even the floating point calcs work
> properly). It seems it does not write internaly to flash or eeprom
> properly. The lock fuses are 0x3f (write enable). Baudrate, char and
> line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
> chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
> high fuse (and many others..). What am I missing here?
> Pito
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] Issues with a word compile - flash or eeprom write issues

[pito <pi...@vo...>]

Hi, after a year I'm trying to run the latest version on atmega32
(11.0592Meg xtal). Compiling and flashing is ok, I get working
system with one exception - I cannot add a new word - ie 
> : foo 123 . ;
ok
> words
and it hangs here, so I have to reflash eeprom, then I can see words
again (without foo). Moreover, I tried my old v4.4 images (which
worked fine) with the same issue - I cannot compile a new word.
Otherwise it works fine (even the floating point calcs work
properly). It seems it does not write internaly to flash or eeprom
properly. The lock fuses are 0x3f (write enable). Baudrate, char and
line delay, waiting on "ok" is set properly. BOD disabled. Tried 2
chips at 3.3V and 5V. Chips erased, programmed with FF low and DF
high fuse (and many others..). What am I missing here?
Pito

Re: [Amforth] ATmega128 undocumented changes verified in 4.8

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

Hi,

> Questions: The file “core/devices/atmega128/device.asm” says-
> "generated do not edit" Can these changes be added to the regular
> code base?

The MCUSR stuff should be possible. I'll have to rewrite the
tool that generates these files anyway.

> 
> “core/drivers/usart_0.asm” - Can the changes to be added to the code
> base without messing things up for other processors?

Send patch ;) (but I doubt it is worth the trouble, just make a copy of
the device/atmega128 tree in your application directory and edit there.
The files and directories in the application area are checked first
during assembler runs)

> 
> Or is the ATmega128(x) too obscure to merit attention?

obscure no, but old and out-dated. Even Atmel seems to have learnt
some lessons..

Matthias

Re: [Amforth] Lock and Unlock fuse AMForth Arduno UNO

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

Hi Jan,

> Is it needed to unlock before flashing and later lock?

Never lock the flash, it is more a precaution to prevent
from un-authorized reads with a debugger etc.

> 
> If yes what are the codes for lock and unlock for the arduino UNO?

You will have to check the datasheet for your particular controller
(Atmega328p IIRC). You can find it at www.atmel.com

Regarding your other questions: No idea what could possibly go
wrong. To my knowledge the Ardiunos now use kind of a software
USART/USB converter which leads at least with linux
to different device names (ttyUSB -> ttyACM). But I cannot check
it myself.

Matthias

[Amforth] ATmega128 undocumented changes verified in 4.8

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

Hi David 

Just found your response and time, so I tried it on amforth 4.8

Works great!

I had to use AVR Simulator 2 to get ATmega128 (instead of 128A and 128P on AVR simulator1)

Some of the instructions in the 4.2 User guide are out of sync with 4.8; but since the software was known to be good I was able to sort it out. 

Programed it with Kanda AVRISP over parallel port on an old STK300, if anyone is curious.

Questions:
The file “core/devices/atmega128/device.asm” says- "generated do not edit"
Can these changes be added to the regular code base?

“core/drivers/usart_0.asm” - Can the changes to be added to the code base without messing things up for other processors? 

Or is the ATmega128(x) too obscure to merit attention? 

Comment:
"core/words/store-i_nrww.asm" the underscores are already present; 

Very helpful, completely solved a long standing problem.

Thanks!

>>>>>>>>>>>

Hi D Williams -

I managed to get Amforth running on a Mega128. There are three 
undocumented file changes you need to make:

“core/devices/atmega128/device.asm”: add these lines (I put them after 
'ifndef EEPME' etc…)
.ifndef MCUSR
.equ MCUSR = MCUCSR
.endif

For some reason the Mega128 doesn't have the MCUSR register, but the 
MCUCSR does the same job (and a bit more...). Adding these lines ensures 
the code will compile with the Mega128 as well as the others supported.

“core/words/istore_nrww.asm” (or "core/words/store-i_nrww.asm")
edit line 114 from
in temp1, SPMCSR to
in_ temp1, SPMCSR ,
and line 122 from
out SPMCSR,temp0 to
out_ SPMCSR,temp0

The 'in' and 'out' commands only work for a limited range of addresses. 
Fortunately the macros 'in_' and 'out_' do the same job for all addresses.

Finally,

“core/drivers/usart_0.asm”: change lines 1 to 6 to:
.equ BAUDRATE_LOW = UBRR0L + $20
.equ BAUDRATE_HIGH = UBRR0H
.equ USART_C = UCSR0C
.equ USART_B = UCSR0B + $20
.equ USART_A = UCSR0A + $20
.equ USART_DATA = UDR0 + $20

These changes are caused by the Mega128 trying to cram a quart into a 
pint bottle. Some addresses are double booked, and this offset is needed 
to fix things.

With these modifications to the code I was able to get the system up and 
running in the AVR Studio (version 4) simulator - and even talk to it 
using 'Hapsim', which permits you to make a virtual serial connection to 
the emulated code.

Hope that's helpful -

David Jeffrey

[Amforth] Lock and Unlock fuse AMForth Arduno UNO

[Jan K. <kro...@ho...>]

Hi,

Is it needed to unlock before flashing and later lock?

If yes what are the codes for lock and unlock for the arduino UNO?

Thanks for any help

Cheers,

Jan Kromhout

Re: [Amforth] VT100 terminal IMAC

[Jan K. <kro...@ho...>]

Hello Ulli,

Thanks for your information. Some of them in the list are new for me.
Yes you are right, I should have mentioned my needs.

I need a VT100 or equal emulator for communication between my arduino and this "terminal"

I want to place text on fixed positions on the screen, and also have the possibility to delete some text or as an example the text from a certain position
to the end of the line.

I think wit VT100 emulation this will working perfect.

Cheers,

Jan Kromhout
Hellevoetsluis-NL

Op 3 mei 2012, om 09:24 heeft Ulrich Hoffmann het volgende geschreven:

> Hi Jan,
> 	there are several options with Mac OS X and terminal support.
> 
> First, you might try command line programms like good old kermit [1] (that's what I use) or screen [2]
> or as mentioned before minicom [3]
> 
> And then here are some GUI programs for OS X. 
> Classical is ZTERM [4], but then you can also choose among different Cocoa based apps:
> Cornflake [5], CoolTerm [6] or goSerial [7].
> All have more or less the same features. Have a look at them an choose yourself. You might
> want to let us know, what suits your needs best.
> 
> Regards,
> 		Ulli
> 
> Links:
> 
> [1] http://www.kermitproject.org/ck90.html
> [2] http://etherealmind.com/serial-console-on-osx/
> [3] http://turin.nss.udel.edu/programming/
> [4] http://homepage.mac.com/dalverson/zterm/
> [5] http://tomgerhardt.com/Cornflake/
> [6] http://freeware.the-meiers.org/
> [7] http://www.furrysoft.de/?page=goserial
> 
> 
> 
> Am 02.05.2012 um 22:21 schrieb Jan Kromhout:
> 
>> Hello,
>> 
>> I am searching for a free ware VT100 terminal emulater for the IMAC.
>> 
>> Can you give me me some sugestions?
>> 
>> Cheers
>> 
>> Jan kromhout
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] VT100 terminal IMAC

[Carsten S. <ca...@st...>]

I use ZOC if I want a GUI tool:
http://www.emtec.com/zoc/

Else I use emacs or screen:
<http://strotmann.de/roller/cas/entry/terminal_emulatoren_für_forth_systeme>

-- Carsten

> 
> Am 02.05.2012 um 22:21 schrieb Jan Kromhout:
> 
>> Hello,
>>
>> I am searching for a free ware VT100 terminal emulater for the IMAC.
>>
>> Can you give me me some sugestions?
>>
>> Cheers
>>
>> Jan kromhout
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] VT100 terminal IMAC

[Ulrich H. <uh...@xl...>]

Hi Jan,
	there are several options with Mac OS X and terminal support.

First, you might try command line programms like good old kermit [1] (that's what I use) or screen [2]
or as mentioned before minicom [3]

And then here are some GUI programs for OS X. 
Classical is ZTERM [4], but then you can also choose among different Cocoa based apps:
Cornflake [5], CoolTerm [6] or goSerial [7].
All have more or less the same features. Have a look at them an choose yourself. You might
want to let us know, what suits your needs best.

Regards,
		Ulli

Links:

[1] http://www.kermitproject.org/ck90.html
[2] http://etherealmind.com/serial-console-on-osx/
[3] http://turin.nss.udel.edu/programming/
[4] http://homepage.mac.com/dalverson/zterm/
[5] http://tomgerhardt.com/Cornflake/
[6] http://freeware.the-meiers.org/
[7] http://www.furrysoft.de/?page=goserial



Am 02.05.2012 um 22:21 schrieb Jan Kromhout:

> Hello,
> 
> I am searching for a free ware VT100 terminal emulater for the IMAC.
> 
> Can you give me me some sugestions?
> 
> Cheers
> 
> Jan kromhout
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] VT100 terminal IMAC

[Andrew H. <and...@4a...>]

Hi,

Open up a terminal.

Now you have a number of choices :)

loak at man screen.

Something like screen /dev/cu.usbserial 9600. adjust the port name and baud rate to suit.

My personal favourite is kermit though you ma have to build this your self.

HTH
Andrew



On 2 May 2012, at 21:21, Jan Kromhout wrote:

> Hello,
> 
> I am searching for a free ware VT100 terminal emulater for the IMAC.
> 
> Can you give me me some sugestions?
> 
> Cheers
> 
> Jan kromhout
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

Re: [Amforth] VT100 terminal IMAC

[Charles S. <sum...@gm...>]

I'm not a mac guy, but this might do the trick:

http://hints.macworld.com/article.php?story=20041026113304907

I use minicom to talk to amForth from my linux box and it works great.
-chassum

On Wed, May 2, 2012 at 3:21 PM, Jan Kromhout <kro...@ho...> wrote:

> Hello,
>
> I am searching for a free ware VT100 terminal emulater for the IMAC.
>
> Can you give me me some sugestions?
>
> Cheers
>
> Jan kromhout
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>



-- 
-chuck
* This sig intentionally left blank *

[Amforth] VT100 terminal IMAC

[Jan K. <kro...@ho...>]

Hello,

I am searching for a free ware VT100 terminal emulater for the IMAC.

Can you give me me some sugestions?

Cheers

Jan kromhout

[Amforth] AMForth 4.8, not running on arduno uno rev3

[Jan K. <kro...@ho...>]

Hello all,

I have compiled the latest version of Amforth 4.8.
After flashing with the USBtinyISP under windows XP my arduino is not booting up.
After reset the LED is not blinking. (also not when on the usb)

The source used is from a member, who send me his complete directory, so no errors where in it.
(thanks Chuck!!)

Fuse also conform documentation Arduino.

Get the latest FTDI driver for Windows, also for my IMAC running Lion 10.7

I have tried a lot of terminal programs for Windows also for the IMAC with no results.

Has anyone get the same problems?

Thanks!

Cheers,

Jan Kromhout
Hellevoetsluis-nl

Re: [Amforth] Amforth on Cortex-M3?

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

Hi,

> Can amforth run on cortex-M3?

>From the FAQ (http://amforth.sourceforge.net/faq.html)

Does amforth run on hardware xy?
amforth is targeted to Atmel AVR Atmega controllers. It does not and
never will run on Attiny controllers or on completely different
architectures like PIC or 8051 etc. Work is currently under way to fully
support Atmels ATXMega's.


> 
> Has anyone done this?

There are other forth's for ARM's e.g. gforth

HTH
Matthias

Re: [Amforth] Amforth on Cortex-M3?

[Charles S. <sum...@gm...>]

You might look at Frank Sargeant's forth for the  ARM - Riscy Pygness

http://pygmy.utoh.org/riscy/

-cheers
-chassum


On Tue, May 1, 2012 at 1:25 PM, Prof Braino <pro...@gm...> wrote:

> Hi all
>
> Can amforth run on cortex-M3?
>
> Has anyone done this?
>
> Thanks!
>
> --
> Sincerely,
>
> Prof.Braino
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>



-- 
-chuck
* This sig intentionally left blank *

[Amforth] Amforth on Cortex-M3?

[Prof B. <pro...@gm...>]

Hi all

Can amforth run on cortex-M3?

Has anyone done this?

Thanks!

-- 
Sincerely,

Prof.Braino

Re: [Amforth] Release 4.8 now available

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

On 03/26/2012 09:01 PM, Matthias Trute wrote:
> Many thanks to Erich (again) for finding and
> telling me about each and every trap he fell
> into.
:-)

Schönen Abend,
Erich

[Amforth] Release 4.8 now available

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

Hi,

I've just tagged the 4.8 release of amforth.
Most noteworthy changes are support for EVALUATE
(and perhaps macros) and the new debugger tools
(see recipes section on the webpage).

Some people like a unified memory access, so
I added some *very* basic support for it. If
you set the compile time option WANT_UNIFIED
to 1 (the default is 0). If I do not get any
feedback beyond "c@ does not work" or alike
I'll probably drop it later ;)

ATXmegas are a nightmare, only the AVR studio
seems to be able to correctly flash them, avrdude
has huge problems. Same for the USB-atmega's.

Many thanks to Erich (again) for finding and
telling me about each and every trap he fell
into.

Matthias