search

scotws / TaliForth2

A Subroutine Threaded Code (STC) ANS-like Forth for the 65c02
Other
86 stars 23 forks source link

Strange RTS behaviour #272

Open svhum opened 2 years ago

svhum commented 2 years ago

First, I want to say that this is a really great project!

I am encountering a strange issue using the assembler on actual 65C02 hardware. I'm using a simple SBC I built that has the memory map recommended in the TaliForth documentation, with the ROM at $8000 and kernel at $E000. I use a modified wozmon as the monitor (that uses a UART for I/O instead of Apple hardware) in the remaining kernel memory space, and a UART at $F000. So far, TaliForth seems to run as expected except when using the assembler.

The issue I'm having is using the RTS word in the assembler. In py65mon, the following works as expected:

here .s <1> 2048  ok
rts .s <1> 2048  ok
execute .s <0>  ok

However, for some reason on the SBC, RTS consumes what is on the stack:

here .s <1> 2048  ok
rts .s <0>  ok

This will obviously prevent a subsequent execute word from running.

I am wondering if this has something to do with how TaliForth is run from the monitor somehow (i.e. E000 R), but can't pinpoint why this would be.

SamCoVT commented 2 years ago

Hi @svhum, I've taken over maintenance of TaliForth2 (just a few days ago) and I've copied your issue over to: "https://github.com/SamCoVT/TaliForth2/issues/5" Also, you'll likely want to change your upstream over to my repository to get bugfixes: https://github.com/SamCoVT/TaliForth2 If you are using the Ophis assembler, you will want the master-ophis branch and if you are using 64tass, you will want the master-64tass branch. The latter is the default branch in my repository and is where new development will take place, but I backport any bug fixes to the ophis branch as well.

I don't have permissions to close this ticket (so it may stay open for a while), but I will help you over at my repository and hopefully we can get this issue resolved.