13:19:41 From Paul Hardy : I recommend reading Starting Forth, downloadable for free here (thanks to Leon): https://1scyem2bunjw1ghzsf1cjwwn-wpengine.netdna-ssl.com/wp-content/uploads/2018/01/Starting-FORTH.pdf 13:20:01 From Paul Hardy : If you want to learn Forth and have no computer experience. 13:21:09 From Paul Hardy : Hmm…Leon, looks like the link is broken. :-( 13:21:35 From Brad Nelson : For folks on the Zoom, I assume the room audio is ok? 13:21:48 From Paul Hardy : It’s perfect--thanks. 13:24:07 From Kevin Appert, Program Chair : Speaking of books, the incompetent program chair forgot to schedule Juergen Pintaske's talk about the 20 Forth books on Amazon. 13:29:48 From Don Golding : let him talk at 4pm? 13:30:25 From Kevin Appert, Program Chair : I don't see him, don't think he's here. 13:31:33 From Kevin Appert, Program Chair : it's 10:30 PM in Berlin, not sure where he is. 13:31:45 From Don Golding : OK 13:44:16 From Erik Olson : How many gates is magic register going to consume? It gets close to a barrel shifter, but if you settle for a serial shifter, you just need some 4:1 multiplexers on the adder to shift L/R 13:45:09 From frederick desimpel : yes 13:45:14 From Erik Olson : I'm studying the S181 and S481 ALUs and microcode that existed around them in the 1970s. 13:45:23 From frederick desimpel : Now just the slide 13:48:15 From Stephen Cagle : I'm looking at the Forth books on Amazon (as recommended) and I am not seeing one fiction Forth book! Not a perfect book, but https://www.goodreads.com/book/show/631233.Wizard_s_Bane is a power fantasy about mixing Forth and magic in a fantasy world. Worth a read and a chuckle. 13:49:34 From Erik Olson : Here's one, then follow the Juergen Pintaske link. https://www.amazon.com/Programming-Problem-Oriented-Language-internals/dp/1983362565 13:55:41 From Kevin Appert, Program Chair : Stephen Cagle doesn't show a microphone, can't mute him 13:56:38 From Kevin Appert, Program Chair : Travis is the only one unmuted now 13:57:21 From Stefan Mauerhofer : Reacted to "Travis is the only o..." with 👍 14:16:40 From Liang PC : My slides can be downloaded from https://github.com/omnixtar/omnixtar.github.io/tree/main/docs/FORTH-Decentralised 14:17:00 From Erik Olson : Floating point: decimal input and decimal output are tricky. 1/10 and 1e-8 are repeating fractions. Is your decimal output routine considering rounding at the last digit? For example, 5.7 will print as 5.699999 (If I recall). When input, both lead to the same binary pattern. So on output, you may decide to round the last 3 bits which are 111. 14:17:06 From frederick desimpel : 👍 14:18:04 From Travis Bemann : @Erik Olson I am rounding from the last digit, but in many cases math is inexact so rounding from the last digit doesn't work 14:19:26 From Erik Olson : OK. Talking about input/output decimal is easy compared to arithmetic error terms! 14:20:16 From Travis Bemann : BTW, my slides are at https://tabemann.github.io/zeptoforth-1.9.0.odp 14:20:29 From frederick desimpel : Btc, not bitcoin 14:23:53 From Erik Olson : "What every computer scientist should know about floating-point arithmetic" https://dl.acm.org/doi/10.1145/103162.103163 14:24:10 From Travis Bemann : there is a reason I implemented fixed-point first 14:24:45 From Travis Bemann : even though the first platform on which zeptoforth ran, the STM32L476, supports floating point 14:27:33 From Travis Bemann : and implementing string conversions, even in my quick and dirty fashion, was one major PITA 14:27:58 From Travis Bemann : for floating point that is 14:28:55 From Travis Bemann : BTC is not Turing-complete, right, IIRC 14:28:58 From Travis Bemann : on purpose 14:33:44 From Erik Olson : I'm working out a gate-level ALU based on Radix-100. This is more human-centered. And seems not many more gates than a binary ALU. (Carry Look-Ahead is modified.) 14:34:30 From Travis Bemann : implementing floating-point/decimal conversion taught me to hate decimal numbers 14:34:51 From Erik Olson : I belong to an ancient sect that still uses fig-Forth and Radix-100 floating point. 14:34:56 From Travis Bemann : there is a fundamental impedance mismatch between binary and 10, because 10 is not a power of two 14:35:30 From Kevin Appert, Program Chair : Blocks or files, Erik? 14:36:05 From Erik Olson : Heh! It was blocks, disk sectors. Or a file of blocks. I 14:36:09 From Travis Bemann : I chose not to choose with zeptoforth - it supports both blocks and files (but you can't have both in local flash at the same time, because it uses blocks to store files) 14:36:25 From Kevin Appert, Program Chair : floating point is the work of the devil... that's why those old coprocessors ran so hot 14:37:11 From Travis Bemann : floating point's main raison d'être is when you really, really need dynamic range and don't care about precision 14:37:14 From Kevin Appert, Program Chair : remember the Patriot missile system bug? Somebody tried to do time in floating point. 14:37:36 From Erik Olson : But taking Chuck's remark that blocks are virtual memory, my OS uses block numbers to refer to the range of all physical memory. In user space, block numbers go thru a lookup table that says where they are. 14:39:00 From Travis Bemann : you can implement filesystems on top of blocks 14:39:13 From Travis Bemann : blocks are a fundamentally lower-level concept 14:39:58 From Travis Bemann : I leveraged this because I had already implemented wear leveling with blocks, and instead of reimplementing it for implementing FAT32 in local QSPI flash, I just chose to use blocks as my backend for it 14:42:53 From Erik Olson : Right now, my block is 4K of Flash EEPROM (the page size.) The firmware has Forth source code in blocks. User space can rewrite them. And 4K is also the MMU page size... blocks can be mapped from one Process to another, zero-copy, especially user space to kernel, which governs the flash (in protected address space). 14:44:03 From Erik Olson : I assume that when I use an SD card, the firmware is doing wear-leveling for me. Another few blocks are FRAM, 8K as of now. This stores a Forth boot script. 14:44:11 From Don Golding : Reacted to "I belong to an ancie..." with ❤️ 14:48:23 From Travis Bemann : I'm using 1K blocks, so for FAT32 I had to split the blocks in half (because for FAT32 I'm using 512-byte sectors) 14:50:09 From Travis Bemann : on the RP2040 and RP2350 I split QSPI flash into one part for the flash dictionary and one part for blocks 14:50:10 From Erik Olson : Oh, you said you implemented wear leveling for QSPI flash. I will have to do a test-to-destruction of my Flash EEPROM to see when it wears out. These are the 128Kx8 SST39F010 chips (or larger). 14:50:46 From Travis Bemann : wear leveling is critical if you're implementing FAT32 14:50:58 From Travis Bemann : FAT32 is *not* flash-friendly by default 14:51:36 From Travis Bemann : which is the reason for filesystems like littlefs 14:51:39 From Travis Bemann : but 14:51:46 From Travis Bemann : the standard for SDHC cards is FAT32 14:51:50 From Erik Olson : So far I'm only reading FAT32 from SD. No plans to use FAT32 on Flash EEPROM. It's really for firmware. 14:52:03 From Travis Bemann : and I implemented FAT32 for SDHC first 14:53:01 From Travis Bemann : so rather than implement multiple filesystems I just decided to use FAT32 across the board 14:53:12 From Travis Bemann : even though TBH FAT32 is an awful filesystem 14:53:35 From Travis Bemann : e.g. it doesn't separate the concepts of directory entries and inodes 14:56:23 From Erik Olson : FAT32 is just one of many "logical layers" in my DSRs (device service routine libraries.) Flash is one "media" layer (blocks or AUs) with a FAT32 "filesystem" layer above it. From that, one large file on it can be a "media" layer to another "filesystem" (think floppy disk image.) 14:57:31 From Travis Bemann : zeptoforth doesn't really have a concept of a fundamental filesystem abstraction subsuming everything, unlike, say, UNIX 14:58:00 From Erik Olson : Another "filesystem" layer is called FIAD, files in a directory. It represents the individual FAT32 files to another logical filesystem, doing some translation (such as storing file attributes in the first 128 bytes) 14:58:07 From Kevin Appert, Program Chair : Welcome to our next speaker, Hi George! Ready to go? 3 or 4 more minutes. 14:58:27 From George-Phillip Orais : Hi, yes I am 14:58:39 From George-Phillip Orais : a bit nervous because first time here 14:59:54 From Travis Bemann : FAT32 filesystems in zeptoforth are built on top of an abstraction called "block devices" 14:59:58 From Don Golding : George, you will do fine. 15:00:28 From Travis Bemann : I could very well create a block device that is on top of a file in a FAT32 filesystem, but I have never bothered 15:01:02 From Travis Bemann : the three current types of block devices are SDHC cards, block storage in QSPI flash, and PSRAM 15:01:15 From Don Golding : Travis, give us a talk on how to implement file system on top of blocks. 15:02:02 From Travis Bemann : @Don Golding unfortunately, most of the SVFIG meetings are smack-dab in the middle of my daughter's karate 15:02:21 From Travis Bemann : it only worked out today because, being Forth Day, there were talks later in the day as well 15:02:34 From Don Golding : bummer! 15:02:55 From Kevin Appert, Program Chair : you can always do a video and we'll heckle you behind your back 15:03:02 From Travis Bemann : lol 15:04:22 From Erik Olson : I also have thought a lot about how to do databases on Flash. You want to minimize block-erase, but changing 1s to 0s is free. 15:05:03 From Travis Bemann : @Erik Olson I used 1s to 0s to implement bookkeeping behind the scenes for block storage 15:05:42 From Don Golding : Erik, want to give a talk on our monthly meetings? 15:08:32 From Erik Olson : I would like to, but have difficulty getting organized 15:15:29 From Erik Olson : One idea I'm pondering: in a Btree node, where keys are appended, seldom sorted (rewrite), how to represent the smallest and largest key in a node? My idea is a "bounding box"--you can always lower the number bound (negated) when a key is appended to that node. And maybe when blocks are cached in RAM, they are scanned linearly. 15:16:35 From Erik Olson : And of course, a node has two bitmaps--one that is marked for records used, another for records scratched. 15:17:31 From Paul Hardy : Old HP calculator brochures used to have examples of how much more efficient RPN was compared to infix. 15:18:42 From Travis Bemann : to me I implement blocks as an opaque abstraction, where the filesystem layer doesn't know anything about how blocks themselves work (except that each 1K block is split into two 512 layers, which I abstract away in a layer in between the two) 15:19:30 From Travis Bemann : *two 512 sectors 15:25:50 From Erik Olson : I'm not to the point of optimizing yet, but it hurts to think that EEPROM has 4K blocks, FAT32 has 512 byte blocks, my main filesystem has 256-byte buffers of packed records, and when backed by FAT32 the backing file has a 128-byte header. So the quantum is really 128 bytes. I get wasteful erase-writes, or I defer writes until buffers are flushed. For coherence, I can put the temporary buffers in FRAM (non-volatile) 15:26:27 From M Edward Borasky (@znmeb) : As an old man yelling at clouds I am loving this! 15:30:25 From Travis Bemann : one thing I do is cache sectors in RAM and only write them to flash/SDHC when they are evicted due to needing another sector which is not currently cached and which there is not room for in the 8-sector cache, except when FLUSH is explicitly called, which writes all sectors in RAM that are dirty to flash/SDHC 15:31:35 From M Edward Borasky (@znmeb) : ILLIAC I was asynchronous!! 15:31:49 From M Edward Borasky (@znmeb) : Don't ask me how I know. 15:32:12 From Travis Bemann : many earlier systems were asynchronous 15:32:42 From Erik Olson : Question - how do we get started with GreenArrays hardware? Boards? 15:35:44 From frederick desimpel : I could use a billion of them 15:36:43 From Paul Hardy : Like the Spud Server: https://totl.net/Spud/ 15:39:23 From Erik Olson : $495 is a big bite. 15:41:28 From Don Golding : https://www.greenarraychips.com/ 15:52:55 From Travis Bemann : have you considered creating an Emacs major-mode or the equivalent for vim for this?