I am running figForth on a 6502 emulator, running on an ESP32, M5Stack-Core2 with screen and sd-card. (Arduino IDE)
The system runs well, even a simple file system with 128 sectors works.
But when I expand the files system to 512 bytes / sector and 2 buffers per screen,
On the SD card are 256*2 blocks as 256*2 files of 512 byte.
The code shows the R/W routine.
RAM is the memory of the 6502 simulation (0x0000-0xFFFF)


I can read and write the data. Stored well. But when I load a file, the first block is loaded and the system hangs.
Does anyone have experience with 512 bytes / sector, when a word is loaded that this is also be compiled!

Or can figForth only be operated with 128 bytes / sector?

Maybe someone can help me out with this.

Cheers,

Jan

I don't think the problem is with the RW code if the routine can load a block. What is the command you are using to load a screen?

If you are doing LOAD "screen#", Forth will try to compile the screen buffer. Make sure both blocks of 512-bytes are loaded before Forth tries to compile or it may hit random bytes on the second half of the buffer and freeze that way.

You can also do just a block load with the BLOCK command to make sure blocks are being loaded correctly from the sd card. Then do a manual dump of the buffer, if that is an option, and check what was loaded.

It's been ages, but I seem to recall it was necessary to EMPTY-BUFFERS before LOADing anything.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks for the reply. But the strange thing is when I using 128 b/sec and 8 buffers I have a perfect working system, based on the routine as in my first post. Do I change to 512 b/sec and 2 buffers the system is crashing at load, one buffer will loaded and thats it.

When I load a random screen in the first situation ( screen is empty ) ok is prompted.
In situation 2 the system hangs. The files load are prepared as files of n bytes ($20)

Anny sugestions to check?

Cheers,

Jan

What does your base Operating System handle for sector size? Most operating systems only handle one size of buffer. Therefore if your OS is handling 128 bytes per sector, then keep it at that and just load 8 sectors to get the screen.

Fig Forth has a Bytes/Block and Blocks/Buffer being a Buffer is the same size as a screen (1024 bytes). In this instance, the Bytes per Block is the standard size that your OS uses. On my Apple Computer I have two different OSes. DOS 3.3 handles a 256 byte sector, and the sector is designated as the block size of this OS. This means the Bytes/Block is 256 and the Blocks/Buffer is 4 to get the buffer size of 1024 bytes.

On the same computer, Prodos handles a 512-byte block. So, Bytes/Block is 512 and Blocks/Buffer is 2 to get the buffer size of 1024 bytes.

Therefore, if your OS only handles 128 byte sectors, then keep it at that. Make Bytes/Block equal to 128 and Blocks/Buffer equal to 8, which gives the buffer size of 1024 bytes. The goal is to get a 1024-byte screen buffer, but depending on how your Drive and buffer commands handle the byte numbers, it may not allow for other configurations.

But, so as to not get confused, or confuse the Forth your are using, use the numbers that your OS uses.

Thanks for this. After this I have change my R/W routine. Do not acces buffers or sector byte write to a file.



I simulate a sector as a file. On the sd card are for 100 sreens 800 files! I have no operating system on the ESP32 but communicate via SPI commands (Arduino IDE) to the sd card.
Have tested writing to files of 128,512 and even 1024 bytes/file. And the only working is 128 bytes/sector. And move these data direct to the adsress given by the R/W.
This is for the moment my status.

cheers

Jan