2026-04-04 13:54:34 iv4nshm4k0v: I think you're right about the incompatibility of screens/blocks with modern mechanisms. That said, they still work on their own as well as they ever did, so I think it's very much dependent on what your own long-term goals are. It's a file-driven world. 2026-04-04 13:54:53 I still plan on having blocks first, files later in my own system. 2026-04-04 13:55:28 Ultimately storage hardware is block-oriented, and I have always thought that the lowest levels of a Forth system should map very precisely onto the base hardware. 2026-04-04 13:55:50 In my mind Forth should support blocks because drives do. 2026-04-04 13:56:07 Then where you "go from there" is up to you. 2026-04-04 13:56:49 I think modern drives are too large to NOT support some sort of file facility. You're just dealing with far too many "blocks" to think about doing everything at that level. 2026-04-04 13:58:57 SOME software in your system has to be cognizant of the individual drive blocks - it's either part of your Forth or part of something you've linked into your Forth or access via an OS. 2026-04-04 13:59:33 It's there whether you consciously deal with it or not. 2026-04-04 14:12:20 KipIngram, so do Model T Fords (still work on their own as well as they ever did) which wasn't very well compared to modern systems :) 2026-04-04 14:14:27 KipIngram, it's my observation that modern Forths are unusable on modern embedded projects, which is a bit ironic as I believe that Forth was first developed to run on systems that controlled telescope motor positioning 2026-04-04 14:16:38 KipIngram, I think that Forth has by and large been taken over by Forth writers who spend their lives writing forths, but never actually using them in the real world to control things like motor positioning systems 2026-04-04 14:17:53 which is fair enough tho, as the people wo do actually use Forth in the real world to control devices like myself, couldn't write a Forth to save our lives ! 2026-04-04 14:18:02 it's a dilemma! 2026-04-04 14:18:31 Forth users V/S Forth Implimentors ! 2026-04-04 14:33:31 Just build a file system on top of Forth blocks, problem solved. 2026-04-04 14:38:04 hello-operator, where do these Forth Blocks live on a Microprocessor with 32KB flash or on a PC ? 2026-04-04 15:20:52 Storage is still block-oriented, but, well, HDDs tend to have 512 B blocks, CDs - 2048 B, and Pygmy Forth - as befitting a Forth implementation - has 1024 B ones. In fact, Pygmy uses DOS INT 21h calls that allow file access at byte granularity, which the DOS kernel then translates into BIOS INT 13h calls that use (IIRC) 512-byte blocks. OTOH, cmForth requests its blocks over a serial line. 2026-04-04 15:20:52 Implementing a "Forth OS" that'd use BIOS calls - or even a "Forth BIOS" that'd access the hardware directly - is a problem I'd find interesting. But it's not the one I have at hand. 2026-04-04 15:30:54 tpbsd: FWIW, "classic, two-interpreter" Forths seem more or less straightforward to implement; see, e. g., the "Moving Forth" series of papers by http://bradrodriguez.com/ . Something that (cross-)compiles into highly-optimized native code - much less so. 2026-04-04 15:42:15 tpbsd: Something like 2026-04-04 15:42:20 https://github.com/howerj/ffs 2026-04-04 15:45:07 The blocks live where they usually live, on a micro in flash, and on a PC as a file backed blocks. But if you build a file system upon blocks then your Forth code should be portable between the two 2026-04-04 15:45:51 My question is rather, when you put your Forth sources on Github, do you use block files, or text files? 2026-04-04 15:48:47 Just use text files, you can use toolsto convert between the two, although when you are editing our text files it helps if you have something to prevent you writing too long lines (>=64 bytes), such as "set colorcolumn=64" in Vim. 2026-04-04 15:50:45 I'd only use blocks on a constrained system, the source I'd keep as text 2026-04-04 16:00:46 The specific problem I want to solve is to have a "half-toy" self-hosting operating system useful for explaining how operating systems work. Being self-hosting, the system must include all tools necessary to modify itself - including text to (from) block conversion software, if, say, the source is text files, but the Forth implementation only supports block files. 2026-04-04 16:00:46 I can't quite decide whether I should target (not-so-constrained, actually) 8088/8086 PCs, or 8-bit AVR MCUs, so I'm going to try to do both. (Anything more complex would probably take unreasonable time to explain, and hence unsuitable for the task at hand.) 2026-04-04 16:28:16 you could use an 8051 if you want lots of RAM 2026-04-04 16:29:02 if a few KB on an AVR isnt enough 2026-04-04 16:42:17 Text to block conversion tools are usually quite small, so it is viable that you could store them on the device 2026-04-04 16:42:26 yeah some of those AVRs have a tiny amount of RAM 2026-04-04 16:45:55 MrMobius: I'm not certain that I'd be hitting that particular constraint, TBH. Other than that: a. I'm familiar with AVRe MCUs (and Simavr software), not so with 8051; b. there're AVRe MCUs that support external RAM; c. AVRe has SPM instruction, allowing the code to write to Flash, while 8051 requires "data" / "program" memory spaces to overlap by wiring it that way on the board; 2026-04-04 16:45:55 d. AVRe MCUs I can buy in a retail store "around the corner"; 8051s I'll have to order. 2026-04-04 16:51:00 I guess I'll have to use built-in flash memory as much as possible, and I kinda doubt I'll be able to implement any FS support on AVR, either. 2026-04-04 16:54:17 good reasons 2026-04-04 17:00:11 AVR-based Arduino boards (particularly ATmega328PA-based ones) seem to still be popular around here. I do not intend to target them exclusively (ATmega128A / ATmega32A seem like easier targets - more SRAM, wider GPIO, etc.), but if I can, I'll try to support them as well. 2026-04-04 17:34:40 re: filesystem on avr, i recommend maybe pulling in fatfs and using an sd card over spi as backing storage 2026-04-04 17:40:57 I've seen it done, but I'm yet unsure I can implement it in Forth - one that runs on AVR itself at that. 2026-04-04 17:42:34 ACTION listens to http://he3.magnatune.com/all/14-Velocity%20vs%20Gravity-L2A2.mp3