Zompist Bboard Again

Well, polyfill.io has been nuked. Apparently a ton of websites use(d) it to provide, well, polyfills, but unbeknownst to most it was hijacked by what seems to be some Chinese company and used to deliver malware earlier this year. When this was originally discovered Cloudflare rewrote references to polyfill.io in hosted free sites to refer to a backed-up good copy of the original site. Now, though, its DNS provider has taken down the whole domain, much to my relief. However, I am now paranoid about what has happened between the time this originally started and now.

Thing is, there are a whole lot of paranoid people on Hacker News and like who are ranting about how it's bad that Cloudflare redirected polyfill.io to to a known-good copy. Do they wish that Cloudflare hadn't done that? Would that be better somehow? Sure, you can have your paranoid ravings about how Cloudflare will change the "truth" and whatnot, but isn't things like this what people use Cloudflare for in the first place?

I have now implemented tools for transferring files to and from boards running zeptoforth over serial or USB CDC connections. The need for this arose from FAT32 filesystems in block storage in on-board Quad SPI flash, which unlike SDHC cards cannot be disconnected from your board and accessed from your computer. (I am using a simple protocol that sends data in 512 byte chunks, the size of a sector in the FAT32 filesystems, with CRC32 checksums to ensure data integrity, and encoded with Base64 so as to be able to be compatible with the zeptoforth console, which by default traps control-C for rebooting and control-T for special "attention" sequences.)

I was considering implementing ZMODEM, but from looking into it it seemed to be overly complicated, and also it requires 8-bit clean data transfer; while there is a way to make the zeptoforth console 8-bit clean, the problem with that is that then there would be no way to forcibly reboot zeptoforth or interrupt the data transfer tools other than to manually reset or power cycle your board (and Raspberry Pi Pico's, for instance, have no built-in reset button, making a physical power cycle the only means possible in that scenario).

zeptoforth 1.6.1 is out. This has important bugfixes to the heap allocator and zeptoed, adds LIST-FILE and LIST-FILE-WINDOW to FAT32-TOOLS for listing files with endline conversion (to avoid stair-stepping that results from dumping files with LF endlines to the console with DUMP-FILE in FAT32-TOOLS), and adds the aforementioned tools for transferring files to and from a host computer via serial or USB CDC.

Have any of you been affected by this Crowdstrike globe-spanning bug thing so far? I've heard about it on the news, but I haven't seen or experienced it directly myself yet. How about you?

zeptoforth 1.8.0-alpha.0 is out. This is an initial alpha release of support for the RP2350 (e.g. the Raspberry Pi Pico 2) and also includes binaries for the RP2040 (e.g. the Raspberry Pi Pico) because the RP2040 codebase was significantly impacted by the changes made for the RP2350 (due to seeking to share code when possible).

Note that there already has been a significant bug identified in this release, specifically that when using REBOOT rather than control-C or the Reboot button of zeptocom.js to reboot when using the USB CDC console the USB CDC console is liable to be wedged so hard that the USB cable must be disconnected and reconnected to un-wedge it.

Also note that there is a known issue in the RP2350 A2 pertaining to input GPIO's when not with internal pull-ups or external pull-up/down resistors, so take care when using input GPIO's which are floating or have internal pull-downs. This is not a bug in zeptoforth per se.

zeptoforth has reached 1.8.0-alpha.2. The USB CDC console lockup-on-reboot issue has been fixed, as has been an issue where the Always-On Timer would be reset to the last time set on reboot.

zeptoforth is at 1.8.0-alpha.4. This release includes bugfixes to pull-up-pin, pull-down-pin, and floating-pin in the pin module on the rp2350 platform, where calling these previously caused hardfaults.

My little notebook has been trying to do a Windows update for quite a while now, and I'm not sure if it will ever finish. Given today's date, perhaps there's some kind of computational ghost haunting it?

zeptoforth 1.9.0-beta.2 is out. It fixes an introduced bug where spawning tasks would cause a crash and updates the multitasker to use a "deadline" scheduler, on top of the additions in 1.9.0-beta.1, which were the addition of optional support for FAT32 filesystems in PSRAM on RP2350 boards with PSRAM, a current directory concept, and an optional utility for copying files between filesystems.

zeptoforth 1.9.0-beta.3 is out. This release is largely a grab bag of small improvements, including support for string constants, improvements to of ... endof blocks to increase their performance (except on the RP2040 and STM32L476, due to these platforms' limitations), the addition of the ability to manually set task deadlines, the tuning of zeptoIP using the deadline scheduler, and the fixing of a bug where if a task were blocked long enough its deadline could "wrap around" causing it to be inappropriately scheduled.