2026-06-25 02:03:54 <cleobuline  > forthBot:  1 128 << .
2026-06-25 02:03:54 <forthBot    > 340282366920938463463374607431768211456
2026-06-25 02:05:20 <cleobuline  > forthBot:  1 128 <<   1 - ?PRIME
2026-06-25 02:05:20 <forthBot    > Error: Unknown word: ?PRIME
2026-06-25 02:05:34 <cleobuline  > forthBot:  1 128 <<   1 - PRIME?
2026-06-25 02:06:38 <cleobuline  > forthBot:  .
2026-06-25 02:06:39 <forthBot    > 0
2026-06-25 02:06:52 <cleobuline  > forthBot:  1 127 <<   1 - PRIME? .
2026-06-25 02:06:52 <forthBot    > 1
2026-06-25 03:47:02 <Stalevar    > tabemann, edit also said stack underflow when exiting if run without block parameter
2026-06-25 04:00:40 <Stalevar    > zed unable to parse: zed
2026-06-25 04:00:41 <Stalevar    > zeptoed unable to parse: zeptoed
2026-06-25 04:02:52 <freebnc     > *growls like a fiesty lion* :D
2026-06-25 04:06:52 <forthBot    > Environment for cleobuline inactive, freeing...
2026-06-25 04:11:53 <Stalevar    > 
ACTION scans freebnc 

2026-06-25 04:29:39 <Stalevar    > Ah, it's in extra files
2026-06-25 04:30:04 <Stalevar    > So I have to format fatfs and then copy neopixels and zeptoed there
2026-06-25 04:39:23 <Stalevar    > with the lower 2 MiB being used for the zeptoforth kernel and flash dictionary and the upper 14 MiB being used for block/FAT32 storage
2026-06-25 04:40:11 <Stalevar    > Meaning you can edit blocks between the end of zeptoforth kernel and start of fat32 without conflict, because you are unlikely to write a dictionary exceeding 2M limit.
2026-06-25 04:47:56 <Stalevar    > Note that the general unsuitability of FAT32 for in-on board flash is tempered by the fact that block storage provided by zeptoforth has built-in wear leveling.
2026-06-25 04:48:17 <Stalevar    > I think NOR would work fine without wear leveling, though it's probably nice to have
2026-06-25 05:35:52 <freebnc     > 
ACTION *wiggles happily*

2026-06-25 05:51:11 <Stalevar    > freebnc, you know that you are probably supposed to set up your nick instead of using freebnc?
2026-06-25 05:51:49 <Stalevar    >  You can issue /nick New_Name command into any chat window to change your name
2026-06-25 09:48:43 <xentrac     > Stalevar: NOR doesn't have longer wearout life than NAND
2026-06-25 09:49:14 <xentrac     > it's still Flash, not FeRAM or something
2026-06-25 10:10:01 <freebnc     > 
ACTION burps

2026-06-25 10:26:14 <Stalevar    > xentrac, afair, NOR lifetime = 10x SLC NAND = 100x MLC NAND = 1000x TLC NAND = 10000x QLC NAND
2026-06-25 10:27:05 <xentrac     > I've seen SLC NAND rated for 100k erases and NOR rated for 1k erases
2026-06-25 10:27:35 <xentrac     > and yeah I've seen QLC rated for 10 erases
2026-06-25 10:27:59 <xentrac     > so I think the NOR lifetime maybe depends more on the fab process than on the NOR/NAND choice
2026-06-25 10:31:16 <Stalevar    > dunno. Still NOR is generally better
2026-06-25 10:32:22 <Stalevar    > I wish I could get a NOR USB flash drive. Even without wear leveling and with FAT it can work fine to test things like KolibriOS or SectorForth or such and be almost ethernal
2026-06-25 10:32:34 <Stalevar    > 16M is plenty for small files
2026-06-25 10:33:35 <Stalevar    > being that small means it could be as cheap as cheapest chinese NAND flash drives (usually 16G)
2026-06-25 10:40:03 <xentrac     > I don't think it's accurate to say that NOR is generally better
2026-06-25 10:40:47 <xentrac     > it's extremely slow to write to and extremely expensive per bit
2026-06-25 10:41:50 <Stalevar    > xentrac, if by `better` we only mean longevity it is
2026-06-25 10:42:08 <Stalevar    > also slow to write? 16M is biggest NOR on market, still less than a second to overwrite
2026-06-25 10:42:09 <xentrac     > well, as I said, I've seen NOR whose longevity is literally 1% of commonplace NAND
2026-06-25 10:42:32 <xentrac     > if we mean number of erase cycles
2026-06-25 10:43:02 <Stalevar    > What about regular SPI Winbond 16M in TSOP 8 or 16 package?
2026-06-25 10:43:39 <Stalevar    > or SMD package like I have on my Tenstar RP2350 USB
2026-06-25 10:44:10 <Stalevar    > same thing but pads instead of legs
2026-06-25 10:44:31 <xentrac     > you'll have to look up the datasheet for the chip
2026-06-25 10:44:32 <xentrac     > or test it
2026-06-25 10:44:47 <xentrac     > also, although this isn't inherent to the NOR architecture, it generally doesn't enjoy any ECC.  NAND, on the other hand, has such high bit error rates that ECC is always necessary
2026-06-25 10:45:05 <Stalevar    > Also zeptoforth and my receiver script interact in weird way, making terminal input wedge
2026-06-25 10:45:36 <Stalevar    > So you recommend SLC NAND flash for super longevity?
2026-06-25 10:46:14 <Stalevar    > xentrac, but why BIOS chips, router firmware and such are generally on SPI NOR or even parallel NOR EEPROM?
2026-06-25 10:46:52 <veltas      > Execute in pace
2026-06-25 10:46:55 <veltas      > place
2026-06-25 10:47:14 <veltas      > That's a big reason, some of it is just conventional
2026-06-25 10:47:29 <Stalevar    > Also while good old BIOS never overwrites NOR unless you update it manually, while UEFI and especially UEFI with ME overwrites it constantly and it still works for years
2026-06-25 10:47:56 <veltas      > Define 'constantly'
2026-06-25 10:48:02 <veltas      > And also depends on the chip as xentrac said
2026-06-25 10:48:08 <Stalevar    > Like at least one write per reboot?
2026-06-25 10:48:21 <Stalevar    > UEFI and ME tend to overwrite itself
2026-06-25 10:48:22 <veltas      > With wear levelling and a 99% static image that doesn't assume a lot about the NOR
2026-06-25 10:48:43 <Stalevar    > I don't think UEFI / ME have much of wear leveling
2026-06-25 10:48:49 <veltas      > There's no shortcut, really you need to understand how both technologies are used and what the specs are for the chip in question
2026-06-25 10:49:21 <veltas      > The bit being erased/programmed may be wear-levelled
2026-06-25 10:49:27 <veltas      > I don't know what you're talking about though honestly
2026-06-25 10:49:47 <Stalevar    > Regular UEFI has nvram which is overwritten on every OS install, (still more than regular old BIOS), while UEFI+ME can overwrite the chip when you don't do anything as far as I know
2026-06-25 10:50:29 <Stalevar    > veltas, regular x86 PC newer than 2014 or so
2026-06-25 10:51:28 <veltas      > UEFI vars are updated regularly maybe but I don't know how they're laid out
2026-06-25 10:51:38 <veltas      > I doubt there's zero consideration in that for NOR life
2026-06-25 10:51:42 <veltas      > Could be wrong
2026-06-25 10:51:45 <Stalevar    > Its main firmware chip hosts UEFI, ME region and nvram, which is UEFI var storage. The latter is edited by UEFI settings and efibootmgr, and ME region belongs to Intel ME which runs proprietary MINIX fork which does who knows what and overwrites its region often enough, probably on every boot
2026-06-25 10:51:56 <veltas      > But the NOR used for PCs might be more expensive than you would need for other applications
2026-06-25 10:52:18 <veltas      > So again despite what others are doing you need to actually know the chips / prices to make the best choice for your own project
2026-06-25 10:52:20 <xentrac     > Stalevar: SLC NAND generally still doesn't have super longevity.  100k erases can be reached in a few minutes without wear leveling
2026-06-25 10:52:38 <xentrac     > and the retention spec is typically only 10 or 20 years
2026-06-25 10:52:45 <veltas      > A big concern I'd have is retention, like how long does programmed data last, and at different temps
2026-06-25 10:53:01 <xentrac     > yeah
2026-06-25 10:53:03 <veltas      > Typically flash retention is piss poor above even moderate temps, like a warm room
2026-06-25 10:53:24 <Stalevar    > And regular HDD are being phased out
2026-06-25 10:53:45 <xentrac     > they still sell tape drives
2026-06-25 10:54:19 <veltas      > HDDs have a niche
2026-06-25 10:54:31 <xentrac     > it keeps shrinking tho
2026-06-25 10:54:35 <xentrac     > same as tape drives
2026-06-25 10:54:40 <veltas      > True
2026-06-25 10:55:12 <veltas      > Eventually everything will be stored in amazon cloud
2026-06-25 10:55:26 <xentrac     > amazon butt
2026-06-25 10:55:28 <veltas      > And the only storage will be what they are purchasing
2026-06-25 10:55:48 <xentrac     > https://github.com/panicsteve/cloud-to-butt
2026-06-25 10:55:51 <veltas      > Just a terrible direction things are going in, I think tech is really foolish
2026-06-25 10:56:15 <xentrac     > it's time you knew.  the cloud?  is actually your parents
2026-06-25 10:56:26 <veltas      > Alas I'm not the malevolent dictator of tech so I can't direct it
2026-06-25 10:57:01 <veltas      > I do know people that know him though so maybe....
2026-06-25 10:57:17 <veltas      > Assuming Space-X doesn't break up on reentry
2026-06-25 10:57:51 <xentrac     > I'm excited by the things *I* can do with tech but terrified by the things others can
2026-06-25 10:58:16 <veltas      > You're right to fear what I will do with tech, I also fear
2026-06-25 10:58:39 <veltas      > Have I told you that I crashed the MISRA website once for months by accident
2026-06-25 11:05:17 <xentrac     > I was more thinking about what the Islamic Revolutionary Guard Corps and Anduril will do
2026-06-25 11:10:17 <veltas      > What about Palantir?
2026-06-25 11:11:03 <veltas      > "Anduril" is a much better name for a company than "Palantir"
2026-06-25 11:13:01 <xentrac     > Palantir too, but I was just thinking about organizations that directly murder people rather than organizations that just recommend which people to murder
2026-06-25 11:37:03 <Stalevar    > $ hexdump -C zeptoforth.flash_dump.bin | cut -d ' ' -f 3-19 | xxd -p -r | wc -c
2026-06-25 11:37:03 <Stalevar    > 4079908
2026-06-25 11:37:18 <Stalevar    > That's alot. About 4M out of 16 are used by zeptoforth
2026-06-25 11:37:48 <Stalevar    > I have dumped entire 16M flash through terminal via forth dump command
2026-06-25 11:37:55 <veltas      > Why not wc -c name.bin ?
2026-06-25 11:38:13 <veltas      > Am I missing something about what this command is doing
2026-06-25 11:38:17 <Stalevar    > veltas, because it is 16777216
2026-06-25 11:38:23 <veltas      > Ah
2026-06-25 11:39:16 <Stalevar    > hexdump compresses repeated regions into *  so converting to hex and back is a quick way to count useful bytes ( as opposed to ff ff ff
2026-06-25 11:39:51 <xentrac     > I usually use gzip for that ;-)
2026-06-25 11:40:16 <xentrac     > of course containing random noise doesn't imply bytes are useful...
2026-06-25 11:40:31 <veltas      > gzip would be significantly smaller though
2026-06-25 11:41:02 <veltas      > What Stalevar did makes sense, I just didn't get it from the pipe
2026-06-25 11:43:14 <Stalevar    > $ hexdump -vC zeptoforth.flash_dump.bin |  cut -d ' ' -f 3-19 | tr -s ' \n' '\n' | sort | uniq -c | sort -n
2026-06-25 11:43:58 <Stalevar    > Least common bytes:  5644 5b; 5654 c6; 5666 d3; 5681 25; 5686 5d
2026-06-25 11:44:54 <Stalevar    > Most common bytes:   40670 10; 43803 01; 48444 20; 51550 04; 6458933 ff; 7323839 00
2026-06-25 11:47:12 <Stalevar    > $ gzip -c zeptoforth.flash_dump.bin | wc -c
2026-06-25 11:47:12 <Stalevar    > 2237212
2026-06-25 11:48:59 <Stalevar    > zstd gives similar figure
2026-06-25 11:50:33 <Stalevar    > $ expr 16777216 - 6458933 - 7323839
2026-06-25 11:50:33 <Stalevar    > 2994444
2026-06-25 12:20:03 <iv4nshm4k0v > From where I stand, it's mostly division of labor yet again.  A century or two ago, you've been expected to grow your own food; now we have Big Money doing that for you (in places where IRC is relatively cheap, at the least.)  A decade or two ago, you've been expected to keep your own data; now we have Big Money doing that for you.
2026-06-25 12:20:03 <iv4nshm4k0v > And it kinda-sorta works as it is.  Sure, you may keep an archive of photos of your grandkids on tapes, or DVD+Rs, and it will easily last thirty years at the minimum, but, well, will /you/ last just as long?  And with all the Youtube videos and Netflix shows out there, do you even have much time to look at those photos in the first place?
2026-06-25 12:20:43 <veltas      > It's not division of labour when like one company is managing most computing.  That's the direction we're headed
2026-06-25 12:21:14 <veltas      > Luckily I do think the market will fix this, and companies/investors who don't understand this will suffer
2026-06-25 12:21:22 <veltas      > But they'll also probably make a ton of money in meantime
2026-06-25 12:22:22 <veltas      > Unless state intervenes ... "you don't need to do computing locally, what are you a criminal" etc
2026-06-25 12:40:43 <iv4nshm4k0v > "The Capitalists praise competition while they create monopoly; [...]" - The New Jerusalem, by G. K. Chesterton.  http://en.wikisource.org/wiki/?curid=39865 .  I'm not sure why "division of labor" cannot exist within a monopoly.
2026-06-25 12:40:43 <iv4nshm4k0v > As to "local computing" - well, don't age verification laws effectively outlaw customized operating systems already?
2026-06-25 12:42:50 <veltas      > Division of labour can exist in a monopoly, I didn't say it couldn't
2026-06-25 12:43:06 <Stalevar    > 0 tib 15 + ! : plc hold ." Hello world!" ;  ok
2026-06-25 12:43:06 <Stalevar    > tib dup 22 + 0 swap ! hold plc cr Hello world!
2026-06-25 12:43:10 <veltas      > The age verification stuff is definitely related
2026-06-25 12:43:44 <Stalevar    > Nobody commented on this example yesterday (or I missed it because I had 6 minute disconnect), I wonder what you think
2026-06-25 12:47:19 <veltas      > HOLD is for pictured numeric output string i.e. formatted numbers
2026-06-25 12:47:34 <veltas      > TIB is the terminal input buffer, i.e. where it stores the stuff you type in terminal
2026-06-25 12:47:44 <veltas      > So they're not related
2026-06-25 12:48:42 <veltas      > Also HOLD takes a character to store in your formatted string, you are passing TIB to HOLD, so will just put some random char (quite possibly NUL) in the string
2026-06-25 12:48:54 <veltas      > via  PLC
2026-06-25 12:49:04 <Stalevar    > veltas, you didn't get it
2026-06-25 12:49:14 <Stalevar    > plc hold / hold plc do absolutely nothing
2026-06-25 12:49:35 <veltas      > Okay what is the point of the code then?
2026-06-25 12:49:36 <Stalevar    > you can replace them with plc_hold and hold_plc
2026-06-25 12:50:08 <Stalevar    > veltas, read the code again?
2026-06-25 12:50:43 <veltas      > No thanks I'm busy anyway
2026-06-25 12:50:55 <iv4nshm4k0v > 
ACTION listens to http://he3.magnatune.com/all/03-Open%20the%20Source-Paolo%20Pavan 

2026-06-25 12:50:57 <Stalevar    > Alright, I just thought it was a cool trick
2026-06-25 12:51:43 <Stalevar    > I create a word with 8 zero bytes as name and then call it and it is executed
2026-06-25 12:52:39 <veltas      > Okay I see that now
2026-06-25 12:53:08 <veltas      > Something like this was done typically to break out of interpreting words on a line of input
2026-06-25 12:53:31 <veltas      > They'd put a null byte at the end of the TIB and that was linked to a word that does QUIT
2026-06-25 12:53:31 <iv4nshm4k0v > My point is that in the world of today, the division of labor is such that, like, 1% of companies do 99% of computing.  Not altogether unprecedented, IMO; think of the decades-long AT&T monopoly, for example.  My gut feeling is that some other sectors of the world economy (say, growing food) have similar splits.
2026-06-25 12:54:05 <veltas      > 1% isn't a problem, 1 is a problem -- especially if it's enforced
2026-06-25 12:54:29 <veltas      > That's the division of labour vs monopoly
2026-06-25 16:08:10 <tabemann    > Stalevar, yeah, always check the number of arguments of a word before calling it!
2026-06-25 16:11:39 <Stalevar    > tabemann, can you comment why it has so many zero bytes? I have found some minor quirks in zeptoforth. Not real bugs but I can explain if you want
2026-06-25 16:12:11 <tabemann    > why what has so many zero bytes?
2026-06-25 16:12:14 <Stalevar    > Like if you feel like that's nitpicking and its annoying I guess it's not worth it, but if you are interested I can tell
2026-06-25 16:12:33 <Stalevar    > tabemann, did you read entire chat log?
2026-06-25 16:12:47 <Stalevar    > I can give you relevant part to PM if you want
2026-06-25 16:12:55 <Stalevar    > as I said it's not terribly important
2026-06-25 16:13:22 <tabemann    > btw, mixing EDIT and FAT32 is *not* going to work properly in the general case
2026-06-25 16:13:47 <tabemann    > unless the FAT32 is on other media such as an SD card or PSRAM
2026-06-25 16:14:35 <tabemann    > just message me the relevant part
2026-06-25 19:50:08 <sqvery      > Just my take - AI is ok when things keep working - but what about when things go wrong?
2026-06-25 22:36:14 <xentrac     > tabemann: or you could just try calling it and see if you get a stack underflow