Changing B/BUFF

[powersoft_51]

Hello,

I have a running FigForth on my esp32 and teensy 4.1 with a 6502 emulator.
I have also connect a sd card to the forth and this is working fine.
Use the old values as SSIZE = 128 bytes and NBUF = 8.

Now I won't to change the system to SSIZE = 1024 and NBUF to 2 ore more.
Have done some changes but the system is crashing when I start the editor
and do 5 CLEAR.

Where should I make the necessary change to get it working.

Thanks for your help.
Jan

[SamCoVT]

I don't have a solution for you, but I can verify that I also attempted to change the size of the buffers in Fig (at that time, I believe I was trying to change to 512 byte buffers to match the sector size on a compact flash card), and I also got crashes. I looked through some of the words, and the ones I inspected were using the variables and should have worked. I suspected there was a word or two in there that had a hardcoded value to match the default layout, but I did not find it at that time (and didn't really know enough at that time to do a good job finding the issue).

Do note that there is an extra 16-bit value in front of each buffer with the block number (lower 15 bits) and whether the buffer has been updated (highest bit), and then an extra 16-bit value behind each buffer that has a zero in it. That zero needs to be there, as it's how Fig knows it has reached the end of a buffer when doing something like LOAD. You'll need to run EMPTY-BUFFERS before you do anything with buffers, as that's the routine that puts those zeroes there.

Dr Ting's "System Guide to figForth" is a good reference for this in Chapter 10 (Virtual Memory): https://www.forth.org/OffeteStore/1010_ ... gForth.pdf

I believe enso got Fig working with 1024 byte buffers, so hopefully he will chime in. Having 1 buffer = 1 block = 1 screen makes things so much easier, so it's worth the effort to get it going.

[enso1]

I tried that but was not sure if it was working correctly. I found the whole way of buffering ridiculously convoluted, and would have much preferred explicitly dealing with buffers. And all those bytes-per-buffer, blocks-per-screen, sheets-per-roll variables...

I did have a hardware issue, so I will eventually try again, especially now that I have block storage working on Tali.

[okwatts]

I am no forth or assembler expert but I was able to get FIG-forth going on a few of Plasmo's boards as well as Grant Searle's MultiComp which because they use CF or SD cards for storage have 512 byte sectors. My SSIZE=512 and NBUF=2 but I started with a FIG version from Chris Baird from the SYMbiosys project (had some edits for U/MOD and additions for the line editor). My implementation used the mass storage for what would translate to Track $C0 for forth to use for it's screens. I have puttered away at this periodically and have been happy with the result. It's been awhile since I did this so while I can include code it would be quite board specific.

[Dietrich]

Any combination of SSIZE (128,256,512, 1024) and NBUF (8,4,2,1) that gives SSIZE * NBUF =1024 should work in FIG FORTH. I have SSIZE 256 and NBUF 4 on my system.

Dietrich