PabloC

Hello, In October 2020 I began to program an application as a terminal-serial console, with different features that I have missed and that I have not found in terminal programs. I have corrected and expanded some functions of the application, and it seems to me that it can be comfortable to work. This week I have prepared everything to publish it under the "GNU General Public License version 3.0". Today I have published it for your free access. I have called the program TermFF, and these are the...

I repeat the second of the 'post', to give the text of the terminal a monospace format. The 'see' of forth is complex of programing since this forth is direct-threading or rather subroutine-threaded code, with in-line expansion. In this way a call to a forth word can be compiled as a 'call', a 'goto', or correspond to a serie of inline cpu instructions. As for the low-level disassembler, I found it important to give the option to interpret the ram bank in use, and present the symbolic name of the...

The debug is based on the trigger of the Timer5 that interrupts the execution, and is installed through the method provided by "[i ... i] ;i" to start executing forth from the interrupt. The interrupt code 'dbgirq' changes the return address of the interrupt to the forth-word 'dbgstep' which processes the 'menu' and debug screen outputs, to finally push on the return-stack the original return address, and after resetting the timer emulate the return of the interrupt. For speed reasons, the word 'dbgirq'...

To implement the debugger, the approach has been to start from the original FF, without modifying anything of the source, in such a way that compiling the forth code from forth it can be operative. This does not take advantage of the debugging capabilities of the cpu. In a later version it would be interesting to use the debugging capabilities, but this would imply including code for this purpose in the source file of the forth. This implementation is made for 18FxxK22 and obviously has dependencies....

The 'see' of forth is complex of programing since this forth is direct-threading or rather subroutine-threaded code, with in-line expansion. In this way a call to a forth word can be compiled as a 'call', a 'goto', or correspond to a serie of inline cpu instructions. As for the low-level disassembler, I found it important to give the option to interpret the ram bank in use, and present the symbolic name of the SFR, as well as the name of the routine (forth-word) called for each call or each goto....

Hello I have long wanted to start studying and testing FlashForth. I prepared a board with a PIC18F26K22 and flash it with a FF-5 to it, but it stayed pending, and finally at the end of last March I finally started his study. First of all, my thanks and acknowledgment to Mikael Nordman for such a great job. Once I studied how it works, I thought about implementing an application written in flash-forth. I missed a high level and low level disassembler, to check how the code looks, as well as a forth...