What was your solution? I’m curious about it, because the only problems I’ve had with zeptoed hanging was when I tried it on the RP2040 with the graphical terminal emulator.
soulution was to not use zeptoed, and consentrate on modify and use the block editor with 32 buffer-with instead of 64. gives 32 lines instead of 16. but works perfectly. Only nag is that I have to fill the blocks with char 32 (space) othervise the editor hangs the picocalc (haven’t figured out that yet)
One alternate solution is to use the 5x8 font and strip out the borders and line numbers of the block editor, because with the 5x8 font the display is exactly 64 characters wide.
the 5x8 font is straining my eyes… And the screen easily show 32 lines @ 6x8 or 7x8. I have to be mindful to not split words, makes issues, but othervise it have been working great. Only nag I’ve had with it is that I have to initialize the blocks with 1024 char 32… which is not a big issue, for now
I’m still wondering about what is happening with zeptoed for you. Have you been mixing the use of blocks with the filesystem in block storage? utils/build_picocalc.fs sets things up for having a FAT32 filesystem in block storage. If you manually edit blocks with edit at the same time it will corrupt the FAT32 filesystem in block storage – and there could be a bug in the FAT32 layer where it does not properly handle all kinds of possible filesystem corruption cleanly. It may even fail on boot if it does not properly recognize a FAT32 filesystem, because extra/common/setup_blocks_fat32.fs configures the system to initialize a fat32::<fat32-fs> instance using block storage on boot.
hmm, not really sure… but, every time I tried installing zeptoed was with a fresh install… first with a text term 2 or 3 times, nuked first. then I tried with graphic. gave up and changed focus. But I will try again to figure out what happens. Someone might benefit, I am just messing around until my rp2350 board arrives… btw, am using zeptofort-1.14.0, downloaded monday 14/07. I will make a new download and try again, just to eliminate corruption in download.
And will also install on a second pico to exclude that there is some fault in the one I have in my picocalc…
Hmm… One thing I should note is that block storage in on-board flash is not erased when installing zeptoed, but you said that you did a flash nuke, which should clean out any issues with it. However, if you touched block storage between installations of zeptoforth, they would not be cleared by subsequent installations of zeptoforth without another flash nuke.
I don’t think your RP2040 is bad, BTW, I think there must just be something subtler going on here that we are missing, and I am interested in finding out what this is, just in case there is some bug in zeptoed or utils/build_picocalc.sh I am not aware of, or some point missing in USING_THE_PICOCALC.md that I should clarify.
I guess I just have to nuke it before a fresh install.
I know I nuked it a couple of times, but there were no science in it. And I did not make a log of what I did… Hmm, guess I should start doing that when I try out stuff. 
Last time I installed, I did not nuke it, but did not try to install zeptoed either… just a restore-state and installed the “basic” picocalc stuff to get it up again.
I have also not gotten around to upgrade the picocalc bios to 1.2, but I do not think that should make any difference here.
looking at the build_picocalc.sh, zeptoed is set to install (if not rp2040) before setup_blocks_fat32.fs and picocalc_fat32.fs. Could that be an issue?
will do a nuke, and try a utils/build_picocalc.sh with text term, without the screenshot (since I really do not need it) and try a install of zeptoed.
The order of installation of zeptoed and of extra/common/setup_blocks_fat32.fs etc. should not be an issue at all, because FAT32 support is baked into full builds of zeptoforth, and extra/common/setup_blocks_fat32.fs and like essentially enables it for FAT32 in block storage and initializes a FAT32 filesystem in block storage if it does not recognize a valid MBR being present (yes, when using FAT32 in block storage it does create an MBR).
The main thing to remember is that if extra/common/setup_blocks_fat32.fs has been loaded ever since the last flash nuke you should not be manually editing blocks, as that will corrupt the FAT32 filesystem in on-board flash, and otherwise unless something horribly goes wrong and your block storage is corrupted you do not need to flash nuke between zeptoforth installs unless you want to manually edit blocks, or you are using an RP2350 board with 16 MiB of on-board flash and you want to go between a rp2350 to an rp2350_16mib build for some reason (or you otherwise manually edit the size of the on-board flash).
As I don’t manually use blocks myself these days I practically never have to flash nuke my boards (aside from before and after a time I tried out MicroPython, and after a time that a bug resulted in block storage itself getting horribly corrupted such that zeptoforth would not boot even after re-flashing it).
Try #1:
- Batteries removed since powering from Pico micro-usb
- nuked flash
- installed zeptoforth_kernel-1.14.0.uf2 from release tar.gz downloaded 14/7-25
- Cable connected to picocalc usb-c
- comment out lines in utils/build_picocalc.sh regarding screenshot
- run utils/build_picocalc.sh rp2040 /dev/ttyUSB0 7x8 text, resulted in a working system
- ran install of zeptoed_all as described in USING THE PICOCALC.md resulted in:
TX: method handle-editor-forward ( editor -- )
error method handle-editor-forward ( editor -- )
Error file extra/common/zeptoed_all.fs line 23: could not upload file
>>> #include extra/common/zeptoed.fs
- “method handle-editor-forward ( editor – )” is line # 1003 of zeptoed
- picocalc hanging, no response on serial or on device
- turn off device, turn on device. No response from device.
- remove usb-c cable, reinsert. still no response. Batteries still out
I do not remember where it stopped on earlier tries, since I did not log anything. But I remember the same abrupt stop while installing Zeptoed, and that I had to install a new uf2 to get up running again. Same happened when I had the screenshot util uncommented in build_picocalc.sh
Will try uncomment screenshot util and see what happens.
I haven’t played much with fat32 filesystems at all, and my programming skills are mostly from Commodore 64 basic, and a little C later years.
Most of what I do nowadays is copying others to get the result I want…
edit:
try #2:
- nuke flash
- install kernel 1.14 uf2
- uncomment screenshot util in build_picocalc.sh
- run build_picocalc rp2040 /dev/ttyUSB0 7x8 text runs fine until
picocalc_screenshot_text.fswhere it it stops at line # 393 witherror offset 0> if out of range literal
Okay, I should note that if you do not have a good reason to do otherwise, use the rp2040_big platform rather than the rp2040 platform because the former provides a larger flash dictionary space. Yes, this means less block storage space being available, but as the PicoCalc has support for SD cards this should not be a problem because the SD card provides vastly more space.
I should also note that when using utils/build_picocalc.sh with the rp2040_big (or rp2350 or rp2350_16mib) platforms it will automatically install zeptoed for you, so you don’t need to install it yourself.
With the rp2040 platform, there likely is not enough flash dictionary space available for everything including zeptoed, which is why I didn’t make the rp2040 platform automatically install zeptoed. This is probably the source of your problem, as running out of flash dictionary space will render zeptoforth unusable.
There most likely is a bug in picocalc_screenshot_text.fs (and likely also picocalc_screenshot.fs) on the RP2040 (which I honestly never tried installing it on) that is preventing it from compiling. I will try to fix that today.
Edit:
Your detailed listing of what you exactly did and what exactly happened was very helpful, as I had thought that zeptoed was crashing when you attempted to run it, but what was actually happening is that it was exhausting the flash dictionary when you attempted to install it. You should use the rp2040_big rather than rp2040 platform here, and it will automatically install zeptoed for you. As for the screenshot tool, I’m working on fixing that right now.
I have modified extra/rp_common/picocalc_screenshot.fs and extra/rp_common/picocalc_screenshot_text.fs so they compile on the RP2040 and tested the modified versions successfully on the Pimoroni Pico Plus 2 W in my PicoCalc. These have been committed and pushed to master and devel in the zeptoforth repository.
What I would recommend is, unless you have used edit since your last post, not bothering with a flash nuke and simply pulling the latest master, installing bin/1.14.0/rp2040_big/zeptoforth-kernel-1.14.0.uf from the 1.14.0 release on your PicoCalc, then executing in your pulled master branch without modifying any scripts or source files:
utils/build_picocalc.sh rp2040_big /dev/ttyUSB0 7x8 text
Let me know how that goes, and if you have any more problems.
I just ran a from scratch install with a flash nuke first, then kernel
edited out screenshot, since I dunno if I need it ( i did this before your last post… Can do it again if you want to confirm working…)
Ran build_picocalc.sh rp2040_big /dev/ttyUSB0 7x8 text and it seem to work.
now I can type s" TEST.FS" zed and it works. save and then open again also work…
then follow up question… how do I list files on filesystem? when I issue list-dir, I get a
*** HARDWARE EXCEPTION. RETURNING TO PROMPT ***, is this “normal”?
edit:
figured out myself…
filesystem-addr s" /" list-dir
your documentation is both good and bad, tabemann… No offence
I think you assume user is inside your head, and understand the same as you…
(Note: all the words below are in the fat32-tools module.)
list-dir has the signature ( path-addr path-bytes – ) with the specific use case that if path-bytes is 0, e.g. one specifies s" " list-dir, it lists current directory. If you neglect the arguments it pulls garbage values off the stack, and when it attempts to access them typically a hardware exception results (and it is recommended that you reboot after that occurs, as it will put your system in an undefined state). Remember that Forth does not automatically have a way of specifying variable numbers of arguments unless you specifically have a word that takes a count on the stack.
Note that the filesystem is not an argument to list-dir itself. list-dir always uses the current filesystem. Rather, blocks-fs: selects the FAT32 filesystem in the on-board flash as the current filesystem and sd-fs: selects the FAT32 filesystem on the first partition of the SD card as the current filesystem. When this happens, if the current filesystem changes, the current directory is also changed to /. Note that blocks-fs@ and sd-fs@ simply push the specified filesystem onto the stack and do not affect the current filesystem or current directory.
from fat32-tools.md:
list-dir
( path-addr path-u – )
List a directory at the specified path. Display the file creation date, modification date, and size.
to me it looks like two arguments needed in the docs… hence my remark. I guess I did not read it right. But then again, how could I know how to read it… I am used to files in *unix. Last time I was actively programming, I was using a commodore 64, in basic…
The documentation for zeptoforth is good(!) no problem. I just lack the right context to read it right. hence my comment that your doc is both good and bad. I feel that the asumption is that the reader should understand what is meant, which I do not…
Okay, a bit of context. In Forth there are typically two ways strings are represented on the stack: address/length pairs, where the length is always above the address on the stack, and addresses of counted strings, where the first byte of the string is its length and it is followed by the bytes in the string (think ye olde style Pascal strings).
zeptoforth typically only uses counted strings internally in the internal format of the dictionary and, as a bit of premature optimization, in the names of tasks and in string maps. Other than that it normally uses just address/length pairs, as they are more flexible and are bounded only by the addressing space of the processor.
Strings specified with s" push an address/length pair on the stack, so s" /" pushes an address containing the character / and the length 1. Note that if an empty string, i.e. s" ", is provided it may push the address 0 and the address should be ignored.
When you execute s" /" list-dir it passes this address/length pair to list-dir, which then lists the root directory. I should have mentioned that list-dir always uses the current filesystem and if an empty string is provided it uses the current directory; that is my fault.
no problem, and now I know. some context is needed to really understand, and some documentation suck when context is assumed or missing. Good documentation is, in my eyes, the most important part of any project. (unless you are the only one using it…)
I put together a particle hack for zeptoforth on the PicoCalc, which can be found here. It involves multicolored particles that move around the screen of the PicoCalc and bounce off its edges.
A screenshot is below:
Note that this requires an RP2350 because it uses hardware single-precision floating-point numerics
I think there might be an issue in the text terminal…
seems the bottom line of the font is never printed, at least in 7x8 font.
I haven’t tried 5x8 and 6x8. But I guess it will be the same, since height is the same.
A ,(comma) looks like .(period), a ;(semicolon) looks like a :(colon) and so forth…
Any “simple” way of fixing this?
I did not have that issue when using the graphical terminal, will reinstall with the graphical term just to make sure.
on a sidenote,
I also have a pico clone with 16Mb flash with zeptoforth installed. How do I utilize that space if possible? not that I need it atm, but wasted space is wasted space…
And maybe it could be a better candidate to put into the picocalc until my rp2350 board arrives
I will investigate the lowest-line-of-the-font issue with the textual terminal emulator.
About the 16 MiB, recognizing that extra space so it can be utilized by the blocks layer requires a minor source code change, such that in src/rp2040_big/forth/qspi.fs the following:
$200000 constant QUADSPI_Size
becomes
$1000000 constant QUADSPI_Size
Note that this source code change will break compatibility with boards with less than 16 MiB of on-board flash.
Edit:
There was indeed a bug in extra/common/st7365p_text_common.fs and extra/common/st7789v_text_common.fs where the address of the current page in the font was not being updated properly with each column of the text when rendering the last row of each character. I have fixed it, confirmed that my fix works properly, and committed and pushed my changes to master and devel.