> I suspect the input mechanism forms the value in A, then pushes
> it.  The <ret>, if there is no input value forming, pops the stack
> top.  The action of an operator will be different - it will pop the
> two top values, operate on them, and push the result.

I tried entering

1 2 + <ret>.

At the terminal, it shows a 3.  When I check the hardware stack, it still
puts 0 on the hardware stack and 3 in the accumulator (R2 is zero).

It appears that when a number is sent to the target, the hardware stack is
being changed in this way: (the data stack inits at 00 and grows downward
from FF)

SP DEC   R2->@SP	\ R2 contains old data
SP DEC    A->@SP	\ A ...
lo-byte-from-terminal->A
hi-byte-from-terminal->R2

It should be something like this:

lo-byte-from-terminal->A
hi-byte-from-terminal->R2
SP DEC   R2->@SP
DP DEC    A->@SP

The old version did not cache the top of the stack and it set the SP to
the next available address after pushing the last byte onto the
stack. 

The current version sets the SP to the last byte put on the stack.
The order of high and low bytes has also swapped.

Anyway, I am not sure what to do at this point other than to keep digging.
At least I am learning some forth.

Darrell Adams wrote:
> 
> This questions concerns the use of AMR Forth v7 under Linux.  This
> is my first post on this newsgroup.
> 
... snip ...
> 
> If I type, e.g.,
> 
> 1 2 3 4 <ret>
> 
> and look at the stack on the target (by sending values to P1), the
> stack pointer seems to be working fine.  However, the hardware
> stack looks like
> 
> 0
> 1
> 2
> 3
> 
> with 4 stored in R2:A.

I suspect the input mechanism forms the value in A, then pushes
it.  The <ret>, if there is no input value forming, pops the stack
top.  The action of an operator will be different - it will pop the
two top values, operate on them, and push the result.

This is my guess - I have no direct knowledge of your system.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

On Mon, 04 Jun 2007 12:09:11 -0500, Darrell Adams
<dar651230@gmail.com> wrote:

>This questions concerns the use of AMR Forth v7 under Linux.  This is my
>first post on this newsgroup.  

It's not a Forth I know about, so try comp.lang.forth as well.

Stephen


-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

This questions concerns the use of AMR Forth v7 under Linux.  This is my
first post on this newsgroup.  

I have been using my own 80C52 (DS80C320) based board with the old DOS
software and am trying to transition to a Linux environment using the
newer version 7 software.  I have been studying GForth and thought it
would be fairly simple to get rolling.

I had some trouble getting the target to respond until I edited config.fs.
 Here I was able to configure the file to match my crystal frequency of
22.118400 MHz. I can download code and run it for the most part.

However, I am having problems with the stack, as seen from the host not
matching up with the stack, as seen from the target.  I am assuming this
is because there is a mismatch between the way the host manipulates the
stack and the way the code in the kernel manipulates the stack.  This is
my vague understanding so far.

If I type, e.g.,

1 2 3 4 <ret>

and look at the stack on the target (by sending values to P1), the stack
pointer seems to be working fine.  However, the hardware stack looks like

0
1
2
3

with 4 stored in R2:A.

I have the old kernel version burned into my rom using tk.bat.  If
appropriate, how do I make a new kernel to run with v7 software?  Is this
the source of the problem?

Thanks,
Darrell