I believe you are missing LIT to go with your literal $4000. Without it, the $4000 will be treated as the CFA of a word and Forth will try to run it. It looks like FIG puts LIT and then puts the literal right after it (Tali works essentially the same way).

All of your literals will need this treatment. For the byte, there is CLIT.

Also, IF doesn't end up in the target word as ".WORD IF". It's an immediate word that compiles a ZBRAN (0BRANCH in the FIG glossary = BRANCH if top item on stack is ZERO) to $0000 and ELSE or ENDIF goes back and fills in the $0000 with the correct offset).

How do you tell if a word is immediate and will need this special treatment? Look in the assembly at each word and if the very first byte (before the name) has a "C" in the upper nybble it is immediate and you'll need to figure out what it does and put the result in your RSLW. If the upper nybble is an "8" then it's not an immediate word and you can just put it in your RSLW with ".WORD".

I think IF and ENDIF are the only two you have here that are immediate, and you can use labels in the assembly so you can just put "MYLABEL-^" (for where to go if it's FALSE - MYLABEL should go where the ENDIF is now) right after the ZBRAN. The ^ is the "current assembling address" for my assembler - yours may use a different symbol. The literal after ZBRAN is added to the Forth IP to take the branch, so it needs to be an offset (positive or negative) rather than an absolute location. You can look at some of the other assembly code to see it used. Sometimes they did the math in the assembly and sometimes they just hardcoded the offset.

One last note - it looks like you missed the R> just in front of the IF. That will also cause crashes.

So you are on the right track, but there are more little details that need to be taken care of to get your RSLW to be a valid FIG Forth word.

Thanks! I have much to learn

I will keep plugging away at it, thus far I have the following. I need to get this back in the simulator (I moved to another machine temporarily) to see if I can tell what is happening, as a 0 list now prints a few lines, then forth breaks, showing 000 for PC.

I do suspect with our help I am getting close?

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

ZBRAN still has a problem. It is expecting an inline word parameter that is the offset to branch to.


should probably be


You may find it useful to look at the contents of words that have been compiled by FORTH.

Thanks leepivonka !

I tried the change but still get the same result.

I did move back to the simulator but this seems hard to debug.

I don't think an error is happening at another location, because I can start forth and enter the new R/W word manually as described by SamCotv, patch the Buffer and Block as he indicated, and all works fine.

However, on the other hand, though the word is all data preventing me from choosing "run to cursor" with the simulator, I inserted a couple of statements at the top to use for this, a PHA and PLA, but the crash happens and doesn't seem to make it to my cursor.

I'm not sure what to make of that at this point, other than debugging is thus far a failure for me.

With the change I still get the same result, sometimes as much as 6 lines will print, others just 2 or 3, and in any case PC is at 0000.

fig-FORTH 1.0
0 list
SCR # 0
0
1
2
PC AC XR YR SP NV-BDIZC
65C02: 0000 70 94 00 ed 00110000

Thanks!

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

Looking at your source further & referencing the FIG-FORTH listing, I see 2 more problems.


should be


and


should be


As you've pointed out, machine code debugging tools are seriously limited when trying to debug indirect threaded code. Subroutine threaded code is much more what a machine code debugger is expecting.
One option is to add some code into FORTH's DOCOL or NEXT to make a simple ITC breakpoint function.
Another option is to define a do-nothing breakpoint word using machine code. The machine code debugger would have a breakpoint set on the machine code in the breakpoint word. The breakpoint word would then be called in the word under test to get the machine code debugger's attention.
Another option is to use print statements in the word under test.

Inserting machine code PHA and PLA in the middle of a colon definition won't work. Word definitions expect the address of a handler (like DOCOL) & DOCOL expects a list of word addresses to execute, maybe with parameters. Any machine code bytes in here won't be interpreted as machine code.

Thanks to you all I got this to work!

I have far to go, but this gets me off to a great start.

As I mentioned, Taliforth 2 is what I use and will keep using, as it's much more modern like gforth, however ones study of forth I think can be improved through working with, and if nothing else for the nostalgic value of working with Fig.

I want to work on a way to make it easy for folks (If I accomplish it, I would think it proper to run by scotws and SamCoVT of course), but to marry Fig to their disk storage solutions, much like Taliforth2's ability to create ones own assembly then map the reads and writes through the vectors of ' myblockreader BLOCK-READ-VECTOR ! and ' myblockwriter BLOCK-WRITE-VECTOR !

Below is the code for the ram disk presently, there may be issues but it appears to work at first testing:



For a quick test, I entered the bytes for screen #1 to contain the following. I did have to list another screen, 0 in my case, then go back and list screen 1 for this to show, but:

: Hello ." Hello World" ;

HEX
4000 AF0 BLANKS



* Listed screen 0, then screen 1 again*

Listing Screen #1

1 LIST
SCR # 1
0 : Hello ." Hello World" ;
1
...

And

FLUSH OK * Probably not neccessary
1 LOAD OK
HELLO Hello WorldOK

Fellows, thank you all so much. I shall continue to see if I can come up with something nice for others.

Appreciate you all!

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

That's great news, and now you've taken a peek at how FIG works under the hood. That should make it a little easier to modify it further.No need to ask either Scot or myself, as Tali Forth 2 is public domain (as much as is possible in your jurisdiction). It doesn't even have an attribution clause, so you are free to take the source code and use it for whatever you would like. It does have a disclaimer of warranty and/or fitness for purpose (eg. use at your own risk), but that's pretty much it. See COPYING.txt in the main folder of Tali2 for details. FIG actually has more requirements on reuse, as it requires the header at the top be intact when distributed. If you want to distribute your mashup, it will need to have the FIG header at the top, but that's not a big deal here (I think) because you're starting with FIG anyway.

You'll likely need to modify all of the words that work directly with blocks, and I will again mention that FIG has blocks/buffers that are different in size than a whole screen. You might also want to consider making buffers and blocks 1K (eg. same size as a screen) as that makes a lot of things much easier and also makes it possible to get away with a single buffer (this is what Tali2 does).

If you do stick with FIGs buffers, make sure to read Ting's System Guide to FIG Forth, in the "Virtual Memory" chapter, about how they work. In particular, they have a header and "tail", so they actually occupy 4 more bytes in RAM than they hold for data. The tail is just a 0 at the end, but is especially important as it runs a special word that stops interpreting there so you don't overrun the contents of the buffer.

To follow-up on my last post, it looks like you should be calling EMPTY-BUFFERS in FIG before using buffers/blocks; that will zero out the memory used by the buffers, including putting that "NULL" or 0 at the very end of the buffer. The COLD start routine does not appear to initialize the buffer area in RAM. If you are running in a simulator, memory might already start out as zeroes, but on real hardware that's unlikely and EMPTY-BUFFERS will properly initialize everything.

Here is my RAMSISK code in 6502 assembler for comparison:



I use memory from $8000 - $D000 and I block screens 1 and 2 to save memory. Works perfect. I even have words to save and load the screens in the ramdisk from and to disk

Dietrich

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

ietrich - Thanks! I appreciate your sharing!

SamCoVT - Appreciate the pointers about block and buffer handling, of which I will be sure to read up on as suggested. I've already started pouring over several pieces of information.

I typically work directly from my sbc, but for this en-devour I have at this point moved over to py65mon, occasionally also with the Kowalski simulator.

Thus far the ram disk is working well, and I have gotten a script together to quickly "paste in" the Ragsdale editor from the Fig-forth installation manual. This works well and along with your code for .S<> ( Thanks much for that!) makes it enjoyable to tinker with.

I have been searching for, and also considered writing my own dump routine, which as you mentioned would make debugging much easier. Strangely I note that it is mentioned in the installation manual, Release 1 November 1980.... however it's apparently part of another vocabulary, etc. I have scoured the internet for various copies of Fig-Forth for the 6502 but have yet to see code representing the dump routine.

From the manual on page 23:

DUMP addr n --- L0
Print the contents of n memory locations beginning at
addr. Both addresses and contents are shown in the
current numeric base.

I'm having allot of fun diving into this again and I appreciate you all.

PS: Tonight I loaded practically the same Fig-Forth to my SBC, just minor changes for i/o addresses and moved the ORIGIN to account for my hardware area. I have a gal and hardware from $200-$300, thanks to the information shared by Daryl! I then loaded the editor and .S<>, and it all worked great.

The neat thing is, this is the first time I've had Fig-Forth working in a reasonable way, with screens and a ram disk, a point that would be OK for one to work through the Starting Forth tutorials, etc. I do realize it's all in the install guide, however you all helped fill in the gaps and I am thankful.

I think tomorrow I'll store away what I have thus far, and begin the adventure of getting it to use the DAREA and talking to my SD card solution.

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

At this point you might want to check out my full screen editor under https://github.com/Dietrich-L/CPM-65/bl ... GS/VED.txt

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L

Hi Dietrich,

Nice, you've got allot of interesting things to check out on your Github!

I did find and run your editor just earlier, in fact your's was the first editor that I got to work.

While I was trying to implement the one from the 79' manual, I had missed the (line) with the following:

: LINE DUP FFF0 AND 17 ?ERROR SCR @ (line) DROP ;

Not realizing it, I was scratching my head wondering what was wrong, and while doing so went on a search, came across a post of yours here on 6502.org and gave your editor a shot. It worked right away!

Your editor is a work of art. I'm on a homegrown sbc, but I do have vga/keyboard, etc... and if working direct off the sbc it's great.

I'm working over serial at the moment, and thus the ctl- commands interfere with minicom, ctl-Q closed minicom and so on, Ha!

I appreciate your sharing see several things on your Github, Forth and much beyond that strike my interest. I'll dig into much of it.

Thanks !

_________________
Shaking out the dirty bits!

https://github.com/DonaldMoran

Thanks for the compliments. If I can help with anything, let me know.

Dietrich

_________________
My system: Elektor Junior Computer, GitHub https://github.com/Dietrich-L