amforth-devel — Development discussion and user support

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

[Christian B. <cas...@ca...>]

Am Mittwoch 12 März 2008 20:43:16 schrieb Erich Waelde:
> Hi,
>
> not sure whether this helps: You did look at the application
> in amforth/appl/tv, did you?

No, but that sounds interresting. What is it and where do I find it? I don't 
have an appl directory.

I found the bug now, insteadt of writing
.set heap=heap+XSize*YSize+...
I wrote
.set heap=XSize+YSize+...

I am now almoust done, BTW. The only thing missing is shift on the keyboard.

> Good luck,
> Erich


Thank you
  Christian Berger

Re: [Amforth-devel] Adding own code to amforth: reserving heap space

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

Hi,

not sure whether this helps: You did look at the application 
in amforth/appl/tv, did you?

Good luck,
Erich

Christian Berger wrote:
> Servus, (=bavarian for hello and goodbye)
> 
> I am trying to add video-terminal code to amforth, and currently it only kinda 
> works.
> 
> I can enter text and it gets displayed, but whenever I press the enter key it 
> mostly crashes.
> 
> I suspect that my software and amforth use the same memory areas.
> 
> I am currently using a code like this to allocate space on the heap:
> 
> .dseg
> .org heap
> keyboard_buffer: .byte 1
> keyboard_shift: .byte 1
> .set heap = heap + 2
> .cseg
> 
> I am not sure if this is correct, but if it is I will also check if I'm not 
> messing with registers in a way I shouldn't.
> 
> Servus
>   Casandro
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> 

[Amforth-devel] Adding own code to amforth: reserving heap space

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

I am trying to add video-terminal code to amforth, and currently it only kinda 
works.

I can enter text and it gets displayed, but whenever I press the enter key it 
mostly crashes.

I suspect that my software and amforth use the same memory areas.

I am currently using a code like this to allocate space on the heap:

.dseg
.org heap
keyboard_buffer: .byte 1
keyboard_shift: .byte 1
.set heap = heap + 2
.cseg

I am not sure if this is correct, but if it is I will also check if I'm not 
messing with registers in a way I shouldn't.

Servus
  Casandro

Re: [Amforth-devel] Changing the word used for output and input

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

Christian Berger wrote:
> Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute:
>> Hi,
>>
>>> Now my big question is, how do I redirect the output of the forth system
>>> to the emit_tv word?
>> just do
>>
>> ' your-emit is emit
> 
> Thanks, that works fine, but how can I change that permanently?

similiar: amforth defines a deferred word named turnkey which is
executed whever the controller starts up. The default turnkey is
defined in the application/words/turnkey.asm file and sets up the
serial line, turns the interrupts on and prints the version number.

You turnkey action may look like

--------------
: my-turnkey ( now your code goes here ) ;

' my-turnkey is turnkey
---------------

And the default turnkey action is changed to yours. Be aware that
the default turnkey action is not saved, you may need to re-flash
the eeprom (turnkey is a EEPROM based DEFER word).

>> The IS/DEFER is based upon a forth200x standard see
>>
>> http://www.forth200x.org/deferred.html for the
>> details.
> 
> Unfortunately I know far to little about Forth to understand that.

Its a elegant way to do vectored execution. Traditional forth
would express it like the first amforth versions: A variable named
'<something> and a word named <something> that reads the content of
the variable '<something> and executes the XT stored there.

------ old

variable 'something
: something 'something @ execute ;
' a-word 'someting !
something

------- new

RDEFER something
' a-word IS something
something
---------

afterwards something will execute a-word when called. The RDEFER is
used to express that the XT vector is stored in RAM. Other possibilities
are EDEFER (for EEPROM) and UDEFER (for the user area). An IDEFER would
use a flash cell. The IS is always the same, for all deferred words.

Note that the DEFER/IS words are almost lowercase and need to
be loaded from the file lib/defer.fs since the core system contains the
runtime words only ;=)

Bye
Matthias

Re: [Amforth-devel] Changing the word used for output and input

[Christian B. <cas...@ca...>]

Am Freitag 07 März 2008 17:22:08 schrieb Matthias Trute:
> Hi,
>
> > Now my big question is, how do I redirect the output of the forth system
> > to the emit_tv word?
>
> just do
>
> ' your-emit is emit

Thanks, that works fine, but how can I change that permanently? In the next 
step of my project I will loose the serial line, but gain a keyboard, so I'd 
like to change input and output to those new devices.

> The IS/DEFER is based upon a forth200x standard see
>
> http://www.forth200x.org/deferred.html for the
> details.

Unfortunately I know far to little about Forth to understand that.

> Bye
> Matthias

Servus
  Casandro

Re: [Amforth-devel] Changing the word used for output and input

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

Hi,

> Now my big question is, how do I redirect the output of the forth system to 
> the emit_tv word?

just do

' your-emit is emit

at the prompt or inside a colon definition

: 2tv ['] your-emit is emit ;

The IS/DEFER is based upon a forth200x standard see

http://www.forth200x.org/deferred.html for the
details.

Bye
Matthias

[Amforth-devel] Changing the word used for output and input

[Christian B. <cas...@ca...>]

Servus, (=bavarian for hello and goodbye)

I want to make a forth-based home computer. And I already got so far as to 
write accompanying video routines for it.

So I can currently enter something like emit_tv and a character will appear on 
the monitor. The hardware actually just consists of 2 resistors. :) If you 
are interested I can upload pictures of the current system somewhere.

Now my big question is, how do I redirect the output of the forth system to 
the emit_tv word?

Servus
  Casandro

Re: [Amforth-devel] Version 2.6: case ... endcase broken?

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

Hello,

Matthias Trute wrote:
> Hi Erich,
> 
> better late than never
> 
> Erich Waelde wrote:
> 
>> In release 2.6 "case" "encase" "of" "endof" were moved into
>> lib/case.frt
> 
>> Any ideas? 
> 
> I took the code from the usenet and did not test it. mea culpa.
> Another forth-project named flashforth has a different implementation
> for it, maybe you can test theirs?
> 

After downloading "flashforth" (for PIC controllers, GPL v3) 
from flashforth.sourceforge.net, I stole "case.fth" from 
their code base. With a minimum of changes (change "for ... 
next" to "?do ... loop") it did work for my tests. In 
particular, case did work, and the argument is cleaned up 
properly. I found this implementation easily readable. Kudos 
to Mikael Nordman and the flashforth folks.

Please find below the files I used.


Cheers,
Erich

-------------------------------------------------------------------
flash_case.fs
-------------------------------------------------------------------
\ 
*********************************************************************
\    Case for FlashForth 
           *
\    Filename:      case.fth 
           *
\    Date:          15.1.2008 
           *
\    FF Version:    3.2 
           *
\    Copyright:     Mikael Nordman 
           *
\    Author:        Mikael Nordman 
           *
\ 
*********************************************************************
\    FlashForth is licensed acording to the GNU General 
Public License*
\ 
*********************************************************************
\ A case implementation posted by Jenny Brien on c.l.f.
\ Modified to use for..next instead of do..loop

\ Modified for use in amforth, changed for..next back
\ to do..loop; Erich Waelde

\ -case
\ marker -case
\ hex ram

variable #of
: case  (  x -- x #of )
   #of @  0 #of !  \ allow nesting
; immediate


: of  ( -- orig)
     postpone over  postpone = ( copy and test case value)
     postpone if    ( add orig to control flow stack )
     postpone drop  ( discards case value if = )
; immediate

: endof ( orig1  -- orig2 )
    postpone else 1 #of +!
; immediate

: endcase  ( #of  orig1..orign  -- )
     postpone drop  ( discard case value )
     #of @ 0 do
       postpone then
     loop
     #of !
; immediate

-------------------------------------------------------------------
test_case.fs

\ 2008-02-02 Erich Waelde


#include lib/ans94/postpone.frt
#include flash_case.fs

: checkout ( n -- )
   case
     0 of ." none" endof
     1 of ." once" endof
     2 of ." twice" endof
     ." unknown"
   endcase
;

-------------------------------------------------------------------

Re: [Amforth-devel] Version 2.6: case ... endcase broken?

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

Hi Erich,

better late than never

Erich Waelde wrote:

> In release 2.6 "case" "encase" "of" "endof" were moved into
> lib/case.frt

> 
> Any ideas? 

I took the code from the usenet and did not test it. mea culpa.
Another forth-project named flashforth has a different implementation
for it, maybe you can test theirs?

Matthias

Re: [Amforth-devel] Atmega8 UART issues

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

Klaus Zerbe wrote:
> Hi,
> i probably got into the same problems like Matt Eastburn.
> 
> I also used AVStudio 4.13 to compile & link and burned the HEX and EEP 
> files with AVR Prog 1.4 into an Atmega8L with an external Xtal with 
> 36864 Mhz.
> 
> I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses 
> alone.

I found the following website useful when it comes to fuses:

http://palmavr.sourceforge.net/cgi-bin/fc.cgi

> Like for Matt the resulting controller did not communicate via USART. 
> Reducing the baudrate didn't help. So I added some Assembler code for 
> trace output and that worked. I could follow the inner interpreter and 
> found this running all the time, but seemed not reaching the 
> "applturnkey" ever.

Strange. Did you find out in which  word the inner interpreter kept
so busy? I've observed this behavior only when I forgot to upload
the eeprom bytes.

> Finally I stopped this and used an ATmega168 instead. After correcting a 
> Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that 
> compiled and linked fine and after burning that output amforth started 
> without a problem.

It's not exactly a typo but a different name for the same address in
different tools. And I prefer the linux based ones ;=)

> So maybe something is wrong in "atmega8.asm" when using the Atmega8L ?

This and/or the fuses.

> @Matt: If possible, try also another controller since Atmega8 ist a 
> little bit small for amforth anyway. There are only 17% memory free for 
> your applications. Atmega168 is pincompatible but has 16kb instead 8kb 
> FlashROM and a built-in far-distance JMP-instruction too ;)

at a very deep internal level, amforth uses the far-call instruction
even on systems which do not officially support the mnemomic. All
my atmega8 run fine with it and have no trouble with it, but maybe
not all are such tolerant. Can you please send me a picture of your
atmega directly? (the mailling list does not accept attachements)
together with your application definition file.

Matthias

[Amforth-devel] Atmega8 UART issues

[Klaus Z. <kl...@ze...>]

Hi,
i probably got into the same problems like Matt Eastburn.

I also used AVStudio 4.13 to compile & link and burned the HEX and EEP 
files with AVR Prog 1.4 into an Atmega8L with an external Xtal with 
36864 Mhz.

I fused for Highsped external Xtal and 2.7V BOD, leaving all other fuses 
alone.
@Matt: click on the "Advanced settings button" in AVR prog to access the 
fuses.

Like for Matt the resulting controller did not communicate via USART. 
Reducing the baudrate didn't help. So I added some Assembler code for 
trace output and that worked. I could follow the inner interpreter and 
found this running all the time, but seemed not reaching the 
"applturnkey" ever.

Finally I stopped this and used an ATmega168 instead. After correcting a 
Typo in "atmega168.asm" (The label ADCCaddr was written as ADCaddr) that 
compiled and linked fine and after burning that output amforth started 
without a problem.

So maybe something is wrong in "atmega8.asm" when using the Atmega8L ?

@developers: Keep up your great work!
I've not used Forth since 1986 on Z80 and 8088- systems but remember how 
much fun that was.
Now its even greater being able to explore those cool microcontrollers 
in direct interaction !

@Matt: If possible, try also another controller since Atmega8 ist a 
little bit small for amforth anyway. There are only 17% memory free for 
your applications. Atmega168 is pincompatible but has 16kb instead 8kb 
FlashROM and a built-in far-distance JMP-instruction too ;)

Kind regards

Klaus Zerbe

Re: [Amforth-devel] Atmega8 uart issues.

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

Hi Matt,


Matt Eastburn wrote:
> 
> I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud.
> 
> As mentioned in my first post i get the exact same hardware to work when
> compiling C to it.

To summarize:
1. you can transfer a program to the controller. I suppose, you
use the same tools/programmer for
a. the compiled C Programm and
b. the "compiled" amforth system.

Can you reread the program from the compiler and compare
that to the original file?

2. The amforth system depends on a small second file
(*.eep.hex). This file is only 12 byte, but it must be
transfered into the controllers eeprom. It stores a few
important things for internal use of the amforth system.
Just to make sure, you did transfer that as well, right? If
you did not, the amforth system cannot start.

3. fuse bits. The fact, that you can successfully transfer
and run a compiled C program, seems to suggest, that it is
not a problem with the fuse bits. I do not use AVR Studio,
but I expect that there is some "menu", which says something
like "set fuses" or "set fuses/locks". Then I expect a panel
with a list of "bits" to select, with strange names like
BODLEVEL, BODEN (brown out detection enabled), CKSEL0..3 to
select the exact clock source.

In theory, a brandnew controller runs on its internal RC
oscillator at something like 125 kHz, but again, the fact
that your C program works, seems to suggest that the fuses
are set ok.

> I do unplug the programmer - but it does not help.
> 
> Now as for the fuse bits - this is where i could be going wrong. because I
> dont really know how or what to set them to.
> 
> I just use AVR Studio to compile the asm files then program the chip. but
> dont know what to set the fuse bits to - or where i can set them.
see above.


4. Again, let me recommend to test lower baud rates.


Good luck,
Erich

Re: [Amforth-devel] Atmega8 uart issues.

[Matt E. <mat...@me...>]

Hi Erich,

thanks for your help.

I will give you some more info on the setup I have.

I am using a atmega8L (at 5volts). 8MHz Crystal. 9600baud.

As mentioned in my first post i get the exact same hardware to work when
compiling C to it.

I do unplug the programmer - but it does not help.

Now as for the fuse bits - this is where i could be going wrong. because I
dont really know how or what to set them to.

I just use AVR Studio to compile the asm files then program the chip. but
dont know what to set the fuse bits to - or where i can set them.


Matt Eastburn

Re: [Amforth-devel] Atmega8 uart issues.

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

Hello,
and "welcome" :-)

Matt Eastburn wrote:

> I have just set up a basic project to see if I can get something out  
> of the serial port.
> 
> At this stage can't get it to do anything on the serial port.

This could unfortunately be any number of things ... so 
without more details (exact controller, crystal or internal 
oscillator, at what speed ...) this is hard to "debug".

My suggestions:

1. go to very low speeds on the serial port, maybe 1200 
baud, just to see, if bits go across the line. Use an LED 
with a resistor as a "probe". Just to make sure there are 
pulses on the cable connections.

2. I had similar problems with an atmega32. They were fixed 
by using a "baud rate crystal" (11.0592 MHz) and better fuse 
settings (I had to dig deep in the datasheet: hfuse=0x89, 
lfuse=0xee). This setting now works reliably with 115200 baud.

3. To make things a little more "obscure", the programmer I 
used initially, did not release the /Reset line properly. So 
unplugging the damn thing made much of a difference :-)


Good luck!
Erich


Good luck!

[Amforth-devel] Atmega8 uart issues.

[Matt E. <mat...@me...>]

Hi guys,

Just found amforth and am pretty excited by it.

I have just set up a basic project to see if I can get something out  
of the serial port.

At this stage can't get it to do anything on the serial port.

Is there something I am doing wrong. Avr assembler compiles fine. Then  
programs to the chip fine.

I know the hardware works because I can get C to talk on the serial  
port.

Please help me out if you can.


Matt Eastburn

[Amforth-devel] Version 2.6: case ... endcase broken?

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

Hello,

In release 2.6 "case" "encase" "of" "endof" were moved into
lib/case.frt

I loaded a small amforth (no case) on an atmega32.

using the following file
-----------------------------------------
#include lib/ans94/postpone.frt
#include lib/case.frt

: checkout ( n -- )
   case
     0 of ." none" endof
     1 of ." once" endof
     2 of ." twice" endof
     ." unknown"
   endcase
;
-----------------------------------------
for upload with amforth-upload.py produces a reset or hang
(!) of the controller after "endcase".

Any ideas? The above example used to work with Version 2.5
and included case.asm endcase.asm of.asm endof.asm files,
except for a leftover argument.

Cheers,
Erich

--- the gory details --------------------
$ amforth-upload.py -t /dev/ttyUSB0 zz.fs
: postpone
  ok    bl word find dup 0<
  ok    if
  ok drop compile compile , exit
  ok    then
  ok    if
  ok , exit
  ok    then
  ok    drop
  ok    [ base @ decimal ] -13 [ base ! ] throw
  ok; immediate
  ok
> 0 constant case
  ok
> : of
  ok    1+
  ok    >r
  ok    postpone over postpone =
  ok    postpone if
  ok    postpone drop
  ok    r> ;
  ok
>  immediate
  ok
> : endof
  ok    >r
  ok    postpone else
  ok    r> ;
  ok
>  immediate
  ok
> : endcase
  ok    postpone drop
  ok    0 ?do
  ok      postpone then
  ok    loop ;
  ok
>  immediate
  ok
> : checkout
  ok  case
  ok    0 of ." none" endof
  ok    1 of ." once" endof
  ok    2 of ." twice" endof
  ok    ." unknown"
  ok  endcase
amforth 2.6 ATmega32
>
  ok
> ;
amforth 2.6 ATmega32
> Traceback (most recent call last):
   File "/home/ew/bin/amforth-upload.py", line 232, in ?
     main(sys.argv[1:])
   File "/home/ew/bin/amforth-upload.py", line 228, in main
     write_file_flow(in_file,tty_dev)
   File "/home/ew/bin/amforth-upload.py", line 169, in
write_file_flow
     write_line_flow(line,dest)
   File "/home/ew/bin/amforth-upload.py", line 121, in
write_line_flow
     i = dest.read(1)
KeyboardInterrupt
$

Re: [Amforth-devel] case/endcase does not drop its Argument: bug or feature?

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

Hi Erich,

> [case ... endcase]

So richtig habe ich in meinem alten Code nicht mehr
durchgeblickt, da habe ich mich zu einer Radikalkur
entschlossen. Die Definitionen f=FCr case und Co sind
erst mal rausgeflogen und in eine Forth Sourcelib
gewandert. F=FCr den Kernsystem braucht man die eh
nicht und das Debuggen ist im Forth Quelltext einfacher.

Wenn man dann einen befriedigenden Stand hat, kann man
ja =FCber die Wiedereinf=FChrung nachdenken.

Der Einfachheit halber habe ich das Eaker CASE aus dem
Usenet herausgekramt, ohne es allerdings n=E4her zu testen.
Selbige Implementation wurde allerdings von Ullrich Hoffman
seinerzeit als nicht problemfrei charakterisiert, warum
genau lie=DF er aber offen...

> [serial-io und buffer]

Da konnte ich noch nicht nachschauen, aber die restlichen
=C4nderungen am Kernsystem haben mich bewogen, trotzdem
ein neues Release zu machen.

Gru=DF
Matthias

Re: [Amforth-devel] case/endcase does not drop its Argument: bug or feature?

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

Hallo Matthias,

> you have a very subtle method to describe bugs ;=)
Natürlich hab ich das :-)))

Schließlich bin ich ja *nicht* der Forth Crack, auch wenn 
ich der kurzen Zeit schon das eine oder andere verstanden 
habe :-)

[case ... endcase]
ich hab in endcase.asm nachgesehen. Da steht auch ein ".dw 
XT_DROP" drin. Aber ich habe nicht gesehen, ob das wirklich 
erreicht wird, oder ob's da noch ein zweites drop braucht 
... da es ja einen wörkerraund gibt, ist das kein Problem.

[serial-io und buffer]
ja, ich kann weiterhin mit dem Kontroller reden, auch wenn 
diese verstümmelten strings kommen. In welcher Ecke befindet 
sich denn das mit dem buffer? Vielleicht kann ich ja doch 
mithelfen.

Mir gefällt amforth ganz gut. Den Prompt würde ich anders 
machen, so wie bei gforth: " ok\n" hinten an die Zeile und 
dann eine neue Zeile anfangen. Aber das ist ja wohl 
Geschmacksache.

Am meisten fehlen mir die '$' (hex), '&' oder '#' (decimal), 
'%' (binary) Vorsetzel für die Zahleneingabe. Albert Nijhof 
hatte ja einen Artikel geschrieben zu dem Thema. Vielleicht 
sollte ich das mal versuchen. Ich hab allerdings keine 
Ahnung, ob "die reine Lehre" state-aware Worte erlaubt oder 
nicht. Aber egal, Hauptsach 's funktioniert, oddrrr?

Ich bin von dem r8c Kontroller inzwischen weg, weil mir der 
Programmspeicher nun doch zu klein war. Auf dem atmega32 hab 
ich jetzt den i2c-Bus, multitasker, die timeup-Uhr und die 
DCF Uhr am laufen. Und dann ist da noch massig Platz übrig. 
Also meiner Wetterstation in Forth steht nicht viel im Weg 
--- außer der stets zu knappen Zeit, versteht sich.

Vielen Dank für amforth!

Und einen schönen Abend,
Erich

PS. Fährst Du (Fahren Sie, wie immer gewünscht) zur Forth 
Tagung? Ich ringe noch mit mir, aber das wär vielleicht ein 
echter Grund.

Re: [Amforth-devel] case/endcase does not drop its Argument: bug or feature?

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Erich,

you have a very subtle method to describe bugs ;=)

> I found that "case ... endcase"(1) leaves its argument on 
> the stack and I must explicitly drop it after "endcase". 
> This behaviour is different from gforth, so I was wondering 
> whether it is intented or not.

I once intended to use case and friends in the core routines
to ease handling of the throw codes. Soon I changed my
mind and the case/endcase group of words is left mostly in
a development state without beeing properly tested.

> Comments?

They should work like any other case, hopefully next week
I'll find the time to fix it. It can be as little as adding
a drop to endcase but I'll check it first (or anybody
out there sends me a patch 8=) )

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHkyfb9bEHdGEMFjMRAoTzAJ9KmNlPUhOY+X8juuso0up3v102UQCdGzUV
KOudl61t77DifRGD5HfIg1k=
=qENO
-----END PGP SIGNATURE-----

[Amforth-devel] case/endcase does not drop its Argument: bug or feature?

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

Hello,

I found that "case ... endcase"(1) leaves its argument on 
the stack and I must explicitly drop it after "endcase". 
This behaviour is different from gforth, so I was wondering 
whether it is intented or not.

Comments?

Erich

(1) yes, sure, I have to add "case", "endcase", "of", and 
"endof" to my application dictionary in dict_appl.inc.

Re: [Amforth-devel] string output problem while using lib/multitask.frt

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Erich,

> and it does exactly, what it should. However, calling the
> contents of message "manually", fails to show on the terminal:
> 
>    > ." c2_null_from_prompt"
>     ok
> 
> Note that the string did not show up. Is this a bug or a
> feature? This looks like a feature to me.

Quoting ANS94
- -----------------
6.1.0190 ."
dot-quote CORE

        Interpretation: Interpretation semantics for this word are
undefined.

        Compilation: ( "ccc<quote>" -- )

Parse ccc delimited by " (double-quote). Append the run-time semantics
given below to the current definition.

        Run-time: ( -- )

- ------------------

I agree that most systems support an interpretation semantic similar to
the run-time of the compiled word, but I decied against. Mostly to have
a system that runs on 8 KB flash...

> Now I start the tasker. I expect the count in c0 to increase,
> and occasionally the message to show up.
> 
>    > c0 @ u.
>     50964 ok
>    > multi
>     ok
>    > c0 @ u.
>     53896 ok
> 
> The counter does increase indeed, however, the message does show
> up only partially.
> 
>    > >
>    > c2_
> -------^ stops here! no " ok", no newline, no "> "

Does the system still accept any commands (simply hit <ret>)?

> It looks like the string is not handled correctly, since calling
> message manually does work:
> 
>    > message
> 
>    c2_null_msg ok
> 
> Is this a bug or a feature? Looks like a bug to me anyway.

Me too. But not in the multitasker. The serial O code (output
part) was inteded to use a queue, but it turns out, that the
code only looks like using a queue, but in fact does not use it
at all. I'll fix it, but only ASAP ....

Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHhTYi9bEHdGEMFjMRAtoeAJ9ZtSh3E5mfed1IYoJ7og4Pzp4t9QCfbYaI
Kp+VDcJA+++4nrzpE9/Qehw=
=DagZ
-----END PGP SIGNATURE-----

[Amforth-devel] string output problem while using lib/multitask.frt

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

Hello amforth'ers,

I'm trying to get the multitasker coming with amforth doing
something useful, but I have hit a problem.

I create one task in addition to "the input handling". It
increments a counter, and occasionally a message should be
written to the (serial) terminal. I dont care if it would
interfere with my typing. Consider this code:

   #include ../../lib/multitask.frt

   decimal
   : message
     cr ." c2_null_msg"
   ;

   variable c0  0 c0 !
   : task0 ( tid -- )
     activate
     begin
       1 c0 +!
       c0 @ 8 /
       0= if message then
       pause
     again
   ;

   onlytask

   20 20 task      ( -- tid0 )
   dup task-sleep  ( -- tid0 )
   dup alsotask    ( -- tid0 )
   task0           ( -- )


I upload the program

   user@box$ amforth-upload.py -t /dev/ttyS1 taskdemo.frt

and connect to the controller (<ret> is the return key):

   user@box$ minicom -o atmega
   ...
   <ret>
   ok
   > tlist<ret>
    96  running  rp0= 2143 TOR= 43784  sp0= 2063 TOS= 96
sp= 2057
    297  running  rp0= 361 TOR= 14597  sp0= 341 TOS= 357
sp= 339
   Multitasker is not running ok

I can call message:

   > message

   c2_null_msg ok

and it does exactly, what it should. However, calling the
contents of message "manually", fails to show on the terminal:

   > ." c2_null_from_prompt"
    ok

Note that the string did not show up. Is this a bug or a
feature? This looks like a feature to me.

Now I start the tasker. I expect the count in c0 to increase,
and occasionally the message to show up.

   > c0 @ u.
    50964 ok
   > multi
    ok
   > c0 @ u.
    53896 ok

The counter does increase indeed, however, the message does show
up only partially.

   > >
   > c2_
-------^ stops here! no " ok", no newline, no "> "

It looks like the string is not handled correctly, since calling
message manually does work:

   > message

   c2_null_msg ok

Is this a bug or a feature? Looks like a bug to me anyway. Am I
doing something wrong? Is IO on the serial terminal somehow
colliding with the tasker? Interestingly, the output from tlist
is processed ok. Also interestingly, leaving "activate" and
"pause" out of "task0" and running it "in the foreground" (no
tasks involved), does work as well. Any insight would be
appreciated.

FWIW: I'm running this on a atmega32 with a 11.05920 MHz crystal
clock.


Cheers,
Erich W.

[Amforth-devel] New release 2.5

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just prepared a new release of amforth and it's library.

The core system got mostly bugfixes and contains two
documentations: Karl's User Guide and a more technical
description. The last one is far from beeing complete but
should illustrate some design decisions.

The library got a cooperative multitasker and a
new memory dump utility. Users can now load the code to
create own deferred words too.

The applications did not change much, but got the version
number 2.5 as well.

Have fun with it
Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHWEto9bEHdGEMFjMRArK3AKCSYsKhX8B9XvODE0LO/kWP2sSr9ACg8KmA
yrJ2WsXcxXKFE7F0mhWUS9U=
=enOx
-----END PGP SIGNATURE-----

[Amforth-devel] enhanced amforth uploadtool

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

in the last few days I've extended the upload tool from
pix. He has written a nice python script to ease (and
speed up) the sending of forth source code to amforth without
running into trouble due to lost characters etc.

You can find the script in the subversion repository (re-connect
the link if broken), the next release of amforth will contain
it as well (if I do not forget to include it)

http://amforth.svn.sourceforge.net/viewvc/amforth/tools/amforth-upload.py?view=markup

It has two enhancements which are related: first it
scans the uploaded text for a command named #include.
When it detects this command, it will take the
next word as a filename and send it's content insted of the
two words. That looks like the following excerpt:

- -----8<--------8<--------8<-

...
#include ans94/marker.frt
#include bitnames.frt

marker _hello_
: hello_world ." Hello World " ;
hello_world
- ---------8<---------8<--------8<

As you may notice, subdirectories can be used. But no
spaces in the (file)names. The syntax is modelled after
the C preprocessor (and not something forth-ish) since
the code cannot be used without that preprocessing, it
is not really forth.

The other enhancement is the introduction of an environment
variable AMFORTH_LIB. This variable works like PATH. It
contains a double-colon separated list of directories the
upload tool looks for the files if it does not find them in the
current working directory. This list is iterated sequentially
from left to right until the first file is found. If not
file is found, the tool aborts with an error message and
the controller may need some cleanup.

in bash it looks like

export AMFORTH_LIB=~/projects/amforth/trunk/devices:~/lib/amforth

Note: the . (current working directory) is always preprended to
this list.

Note2: amforth-upload.py has help screen, call it with -h and enjoy

Please test it and feel free to comment.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHTUU99bEHdGEMFjMRAvHsAJ0X6cVvI6rP/xEE79W4Njkxw9ny6wCePwEB
MCVB1ioPuA8xGRWY9+RIWkw=
=VxhR
-----END PGP SIGNATURE-----

[Amforth-devel] New release - 1st anniversary of amforth

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all!

To celebrate the 1st anniversary of amforth I just prepared a new
release :=))

The details what's changed are as always on the homepage, long term
users may notice that the usart settings have changed considerably:
The EEPROM contains no longer the baudrate but the calculated register
values. Future releases may put the usart-b and -c register values
into EEPROM as well, let me know what you think about it. The code
for the applications is left untouched..

Let's party,
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHDSNc9bEHdGEMFjMRAqVSAJ9K5qqsPdlTeaSn7n2HG8X+x9bnQQCgyOkJ
wwSKd5eNjlh/lnSJk/zTEug=
=dr/I
-----END PGP SIGNATURE-----