Bug: Loading block to buffer from CF leaves buffer number on stack

Software
1

Hello and happy Friday!

It seems that when you load a buffer with a block from the CF card, the buffer number is left on the stack. I can’t figure out where this is happening and so I cannot submit a proposed fix. Sorry!

To reproduce:

  1. With a CF card installed, do 1 list. Then do 0 o. This will prompt you to enter text for line 0 on block 1. Enter 1 2 3 4.
  2. Type flush to save the block.
  3. Repeat the process with block 2, except with text 5 6 7 8.
  4. Type xx to make sure that the stack is cleared.
  5. Type 1 2 thru to load and execute blocks 1 and 2.
  6. Check the stack with .s
  7. On my machine the result is: 20953 1 2 3 4 20953 5 6 7 8This is the buffer address followed by the contents of the block. I imagine the buffer address will vary on different machines.
  8. The expected stack result is: 1 2 3 4 5 6 7 8.

You can verify the expected result by running the same test using Tali Forth in py65mon, using 4 block-ramdrive-init and editor-wordlist >order to initialize the block ramdrive system before performing the above tests. You can also run the block-ramdrive-init version on the Planck machine and it will work the same way.

If it would be better for me to submit this on the Gitlab site, I’m glad to do so.

Best wishes, Ben

2

Hi Ben, thank you for the bug report.
Yes it would be lovely if you could create an issue on Gitlab. I won’t be able to look at it for the time being, and having an issue open there will make sure I don’t lose track of the bug.

3

I do remember having issues with the block words not setting the stack correctly though, but I thought this was fixed. As far as I remember the issue was with the forth code, and not with the assembly code.

4

Sounds good. I’ve created an issue in Gitlab. I’ll keep trying to find the issue. Thanks!