AMR Forth stack issue?

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

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

Reply to
Darrell Adams
Loading thread data ...

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

Stephen

-- Stephen Pelc, snipped-for-privacy@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:
formatting link
- free VFX Forth downloads
Reply to
Stephen Pelc

... snip ...

I suspect the input mechanism forms the value in A, then pushes it. The , 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.

--
 
 
 
 
                        cbfalconer at maineline dot net
Reply to
CBFalconer

I tried entering

1 2 + .

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.

Reply to
Darrell Adams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.