2026-02-13 00:04:09 <veltas      > Massive
2026-02-13 00:18:55 <KipIngram   > Yeah, that's a  heck of a lot of blocks if that's what I decide to do with it.
2026-02-13 00:19:15 <KipIngram   > I'll start out, though, by just squirting source at it over the UART.
2026-02-13 00:21:43 <KipIngram   > It is clear that this load_ram thing has to work, because the bootloader on this thing is in un-alterable ROM - it can't be updated.  And it's of fairly basic functionality.  So what they do is for all these esptool commands is send over a "stub" (they call it) which runs in RAM and extends the bootloader functionality.
2026-02-13 00:21:55 <KipIngram   > So - they're doing it, as an official part of how the tool works.
2026-02-13 00:22:19 <KipIngram   > And I suppose when the flash the whole flash they do that from RAM.
2026-02-13 01:21:27 <tpbsd       > veltas, when did I start Forth ? approx april 2014, but I managed to ignore Forth totally from 1978 when I designed and built a 1 foot square pcb for a Rockwell 65F11, with gpios, rtc, banked eprom, heaps of ram for a underwater UAV project for a contractor for the Australian DOD
2026-02-13 01:22:52 <tpbsd       > I actually worked with three Forth programmers on that project, but I was so busy on my hardware that had no idea what they were doing. Plus being DOD related, it was all compartmentalised, so no one talked about their work
2026-02-13 01:25:31 <tpbsd       > veltas, oops it was more like 1986, so I missed  28 years of doing Forth!
2026-02-13 01:25:50 <tpbsd       > veltas, talk about a late started!
2026-02-13 01:25:55 <tpbsd       > veltas, talk about a late starter!
2026-02-13 01:27:44 <tpbsd       > amby, this is how I access my STM32xx GPIO's "RCC_AHBENR_IOPAEN enable! \ enable GPIOA
2026-02-13 01:27:44 <tpbsd       > RCC_AHBENR_IOPCEN enable! \ enable GPIOC"
2026-02-13 01:28:40 <tpbsd       > amby, I use 100% compliant CMSIS-SVD syntax
2026-02-13 01:36:09 <amby        > when ive done gpio on avrs in assembly ive either just poked the registers or used the avr's set/clear io bit instructions
2026-02-13 01:37:09 <tpbsd       > amby, thats what Im doing here, configuring register (bit)fields
2026-02-13 01:38:24 <tpbsd       > amby, I have a system that takes CMSIS-SVD names and replaced them with absolute addresses only on upload to the Mecrisp-Stellaris Forth
2026-02-13 01:39:01 <tpbsd       > amby, the programmer gets CMSIS for humans, the mcu gets absolute addresses, no constants are needed
2026-02-13 01:40:09 <amby        > CMSIS-SVD?
2026-02-13 01:41:51 <tpbsd       > here is what the gpio init code looks like properly formatted https://bpa.st/6TEA
2026-02-13 01:43:18 <tpbsd       > CMSIS   https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#arm-cortex-m-microcontrollers
2026-02-13 09:15:46 <KipIngram   > Nice.  I read up on the GPIO in the ESP32 last night.  A fair number of details, but straightforward.  There are a bunch of RAM-mapped registers associated with it.  All the output enables in one, the input enables in another, register for pull-up settings, pull-down settings.  Then a bunch more to attach various peripheral I/Os to them, etc.
2026-02-13 09:16:02 <KipIngram   > So it really just looks like a list of memory pokes.
2026-02-13 09:16:22 <tpbsd       > sounds like the STM32 setup
2026-02-13 09:16:30 <KipIngram   > For inputs there's a de-glitch/filtering facility you can engage.
2026-02-13 09:17:06 <KipIngram   > Oh, and  you can set output current drive to any of several values, from 5 mA to 40 mA.
2026-02-13 09:17:23 <KipIngram   > Yeah, I guess it's one of those things that has a fairly standard pattern associated with it.
2026-02-13 09:17:48 <tpbsd       > 40mA, thats about double the default of STM32
2026-02-13 09:18:39 <tpbsd       > STM32 GPIO's are 20mA max each, but a max of 80 mA per chip
2026-02-13 09:19:07 <KipIngram   > 20mA is also the default here.
2026-02-13 09:19:17 <tpbsd       > so plan to use external transistors or buffers etc if you need more
2026-02-13 09:19:29 <KipIngram   > I don't know what the chip max is in my case yet.
2026-02-13 09:19:46 <KipIngram   > But I'm mostly only interested in one output for this next test.
2026-02-13 09:20:02 <tpbsd       > bound to be similar to the default for CMOS  mcu's
2026-02-13 09:20:28 <tpbsd       > 20 mA is heaps for a LED at 3.3v with a 100R resistor
2026-02-13 09:22:05 <tpbsd       > and if youre buying leds' get the 'high intensity' ones as theure blinding at 5mA, tho narrow beam
2026-02-13 09:28:58 <KipIngram   > Yeah, makes sense.  They're all ultimately playing the same game, more or less.
2026-02-13 09:29:36 <tpbsd       > yeah, theyre all kind of similar these days in terms of peripherals
2026-02-13 09:29:47 <KipIngram   > There are so so many of these registers for various configuration aspects.  Every chapter of this tech reference ends with a list of all of them associated with that function.
2026-02-13 09:30:09 <KipIngram   > So - all perfectly straightforward, but a mess of individual steps.
2026-02-13 09:30:26 <tpbsd       > I only work with the really low end Cortex-M mcus, ie 64KB flash, 8 KB ram
2026-02-13 09:30:51 <KipIngram   > It's how things go, I guess.  I read somewhere some years back that internally Windows and Linux were converging in a lot of ways.  Very different "wrappers" on top, but similar guts.
2026-02-13 09:30:53 <tpbsd       > thats plenty for the stuff I do with Forth
2026-02-13 09:31:45 <tpbsd       > and the differences are  shrinking as Linux thrives and Windows loses popularity I believe
2026-02-13 09:31:46 <KipIngram   > This ESP32 is around my favorite sweet spot.  Cheap enough to be used for knock-off things, but enough resources to actually HOST a Forth system without having to be tethered to anything.
2026-02-13 09:32:59 <tpbsd       > a tether (connected during development only) can enable awesome features I have found
2026-02-13 09:33:22 <KipIngram   > Oh, one neat feature here I noticed was that the mapping of functions to the GPIO pins is different between normal operation and the sleep modes.
2026-02-13 09:33:29 <tpbsd       > Mecrisp-Across is the poster child there, it's truely remarcable imho
2026-02-13 09:33:46 <KipIngram   > So you can set it up so that pins can be used to wake the thing up, and then flip back to your main desired function once it's awake.  I thought that was a nice touch.
2026-02-13 09:34:02 <tpbsd       > ah yeah, sleep modes can be a real brain burner
2026-02-13 09:34:04 <KipIngram   > Yes, for sure.  I've not used it, but it's clearly a perfect idea.
2026-02-13 09:34:28 <KipIngram   > Feels exactly like what a tethered Forth should be - works in a way that lets you almost forget you're tethered.
2026-02-13 09:34:59 <tpbsd       > almost perfect, the difference between emulation and standalone speed is a inconvenience with Mecrisp-Across
2026-02-13 09:35:04 <KipIngram   > This one has three sleep modes - they're called "deep," "light," and "modem."
2026-02-13 09:35:18 <tpbsd       > thats also fairly typical
2026-02-13 09:35:31 <tpbsd       > but of course the devil is in the details
2026-02-13 09:36:10 <KipIngram   > One of my work gigs involved wireless (5 GHz radio linked) data collection units for land based seismic work.
2026-02-13 09:36:15 <tpbsd       > for instance, how do the different sleepmodes affect the response of the UART ?
2026-02-13 09:36:32 <KipIngram   > You just scattered these units out over your terrain and jammed a geophone into the ground plugged into them.
2026-02-13 09:36:35 <KipIngram   > Battery powered.
2026-02-13 09:36:42 <tpbsd       > very cool
2026-02-13 09:37:03 <tpbsd       > I understand part of the requirements there
2026-02-13 09:37:06 <KipIngram   > And the idea was you could leave them out there for months and wake them up when you were ready.  They'd form up a mesh network that would route the data back to your data collection truck.
2026-02-13 09:37:52 <KipIngram   > The really groovy things there were a) an insanely low noise floor and b) they all phase locked their oscillators over the mesh net and would agree to within a few hundred nanoseconds as to what time it was.
2026-02-13 09:38:05 <KipIngram   > It was like it was one huge distributed circuit, all with a common clock.
2026-02-13 09:38:21 <KipIngram   > That clock management protocol was... fun.
2026-02-13 09:38:58 <KipIngram   > They'd wake up every few minutes just enough to see if they were being "beckoned."
2026-02-13 09:39:48 <KipIngram   > There might be ten or twenty thousand of them spread out over some huge area.  At least that was the idea - the company really never "made."
2026-02-13 09:40:17 <KipIngram   > It had a poisonous political atmosphere that I think killed it in the end, though I left for IBM before that was a foregone conclusion.
2026-02-13 09:40:38 <KipIngram   > Well, left for what became IBM.
2026-02-13 09:40:51 <KipIngram   > It was a tiny company for my first six months.  :-)
2026-02-13 09:41:39 <KipIngram   > I could tell right away that something funky was going on, but it was a month or two before the owner and president outed the impending acquisition to me.
2026-02-13 09:45:45 <tpbsd       > wow
2026-02-13 10:10:46 <veltas      > What brought you to Forth in 2014?
2026-02-13 10:19:35 <tpbsd       > veltas, I stumbled across Mecrisp-Stellaris Forth online
2026-02-13 10:23:10 <veltas      > Remember how or why?  A talk / IRC / etc?
2026-02-13 10:23:14 <veltas      > Just interested how people find things
2026-02-13 10:23:36 <tpbsd       > it's a good question, but I can't recall
2026-02-13 10:23:52 <veltas      > I found Forth because I've hung around a lot of low level coders and it occasionally comes up in conversation, eventually I gave it a shot
2026-02-13 10:24:38 <veltas      > I heard about it a lot from certain people, especially people into Z80 assembly, Zx Spectrum, x86 assembly, and small languages
2026-02-13 10:24:59 <veltas      > At university I had a project to write a "small programming environment" for ZX Spectrum I never ended up actually finishing
2026-02-13 10:25:10 <veltas      > I essentially achieved it when I wrote zenv though
2026-02-13 10:25:51 <veltas      > My initial design was more based on something like Lua or BASIC, but while I was writing the assembly code for it I realised that a second stack would help make the code a lot smaller, and it reminded me of how Forth worked
2026-02-13 10:26:52 <veltas      > The university project was a failure but still helped me get my job and was a lot of fun, I really had no clue what I was doing though
2026-02-13 10:27:50 <veltas      > Code's here if anyone has a sick curiosity https://github.com/Veltas/spectrum-env
2026-02-13 10:28:50 <veltas      > Why does it look like it was written by an LLM though?  Amazing
2026-02-13 10:29:06 <veltas      > It's from 8 years ago which sort of proves it wasn't, yet it does look that way
2026-02-13 10:30:52 <veltas      > I feel like I could refactor that code so hard now, it would barely exist
2026-02-13 10:32:06 <tpbsd       > hahah
2026-02-13 10:45:11 <veltas      > KipIngram: Another good youtube tip if you don't know is the numbers skip to different parts of the video, i.e. 0 skips to start
2026-02-13 10:45:22 <veltas      > I often use 0 but the others are sort of helpful too sometimes
2026-02-13 11:05:55 <iv4nshm4k0v > Back in 2000 or so, I've got a distinct impression that a lot of "professional" coding boils down to taking lots of examples from books and forums and mixing them together until you've got something that seems to work.  Something, I thought, that a machine would probably do better than a human being.  ... Was kinda the reason I choose physics as my major.
2026-02-13 11:10:38 <veltas      > That's a little bit too cynical, and I know from my actual job that's not true
2026-02-13 11:11:13 <veltas      > I've definitely had to work on a number of problems most people would struggle to solve, yet alone an LLM / google / books
2026-02-13 11:15:54 <iv4nshm4k0v > I did my share of (semi-)professional programming since, and I'm well aware that things are different, sometimes.  I'm not aware of any proper studies on the matter, but my impression is still like that: for a lot of problems, people tend to just go and pick some ready-made code from Stackoverflow or perhaps Github.  In luckier cases, one uses libraries rather than just copying code.
2026-02-13 11:17:14 <veltas      > Just in my job role it's not been true, I can't speak for whole industry
2026-02-13 11:17:34 <veltas      > I wouldn't be surprised if it was like that for some people
2026-02-13 11:24:10 <KipIngram   > I think that very much depends on the nature of the task.  In the SSD codebase we had at IBM there sure wasn't much that was just "picked up" from anywhere.  But we were interfacing deep internals of flash chips and so on.
2026-02-13 11:24:27 <KipIngram   > I imagine the more specialized the work is, the less you can just find in the wild.
2026-02-13 11:25:45 <KipIngram   > That said, when IBM bought the place, they ran what they called a "bluewashing" process on the codebase, which was designed to find things like risky open source code references and so on, and there were some things that had to be quickly replaced, mostly for licensing concerns.  They didn't want to get caught in any GPL issues.
2026-02-13 11:26:22 <KipIngram   > Since they regarded SOME of the code as "crown jewels," and couldn't have anyone claiming it had become open source via GPL taint.
2026-02-13 11:29:59 <veltas      > A lot of GPL scaremongering in industry, it's insane
2026-02-13 11:30:19 <veltas      > A whole industry exists specifically for GPL scares, as if other licenses don't exist and aren't just as applicable
2026-02-13 12:09:17 <KipIngram   > I don't know that it was actually limited to GPL - it's just the one I mentioned there.
2026-02-13 13:13:55 <veltas      > Was just saying the other day git does a good job recovering on weird NFS issues and now it's failed mid-rebase
2026-02-13 14:37:10 <veltas      > It's an open question whether the room should stay cool or not when compiling programs, but as Forth programmers I think we generaly agree the room should stay cool
2026-02-13 14:37:30 <veltas      > Many other kinds of programmers disagree and think the room should warm up, and write compilers designed to heat the room
2026-02-13 14:37:48 <veltas      > But they can have their compilers and we'll have ours
2026-02-13 15:03:35 <cleobuline  > forthBot:  LOAD ini.fth
2026-02-13 15:03:36 <forthBot    > File ini.fth with MOON  loaded
2026-02-13 15:03:45 <cleobuline  > forthBot:  1 QUOTE
2026-02-13 15:03:46 <forthBot    > When we are dead we do not know that we are dead. It is for others that it is difficult. When we are jerk it is the same - Jean Claude Vandamme -
2026-02-13 15:17:29 <cleobuline  > forthBot:  2 QUOTE
2026-02-13 15:17:29 <forthBot    > Every second laugh is a little time saved on existence -Raphaël Quenard-
2026-02-13 17:17:29 <forthBot    > Environment for cleobuline inactive, freeing...
2026-02-13 18:53:34 <KipIngram   > Ok - change of plans.  The load_ram path presented difficulties - apparently the file you send over has to conform to a certain format specific to the dev environment, and I can't figure out how to make such files.  Trying to suss that out with ChatGPT led nowhere.  So, I've bailed on that.
2026-02-13 18:53:44 <KipIngram   > I do have something workable in place now, though.
2026-02-13 18:55:14 <KipIngram   > I was able to hijack one of the examples in the console dev envionment to get me a C program flashed onto the thing that will echo back USB serial characters.  And it turns out I can connect to that in one window with picocom, and still cat files at it in another window.  If I  have echo turned on, then when I cat the file from window 2, it gets echoed in window 1.  That's not quite what I'll be
2026-02-13 18:55:16 <KipIngram   > wanting, but it's interesting.
2026-02-13 18:55:45 <KipIngram   > Anyway, I'm going to put a big RAM buffer in that C program, and mark that RAM executable, and rig it up so that I can cat binary machine code files over and they'll land in that buffer.
2026-02-13 18:55:57 <KipIngram   > Then just type "go" or "run" from the picocom connection.
2026-02-13 18:56:25 <KipIngram   > If the code actually finishes and returns, great.  if not, I'll have to do something with esptool that sends a reset and start it all up again.
2026-02-13 18:56:57 <KipIngram   > But anyway, it's a way to get code into RAM and run it without too much hullabaloo, which is all I'm after right now.
2026-02-13 18:58:12 <KipIngram   > And I can use riscv32-esp-elf-* to tools to work with assembly on the host.
2026-02-13 18:58:17 <KipIngram   > And make the binaries.
2026-02-13 19:07:54 <KipIngram   > Anyway, all it does right now is echo - I have to put in all the logic.
2026-02-13 20:27:15 <tpbsd       > ho lads!  my eldest son put me onto a really decent AI, super low cost as it's opensource being Chinese
2026-02-13 20:27:43 <tpbsd       > Ive been testing it and Im really impressed
2026-02-13 20:34:27 <tpbsd       > checkout Z.ai: GLM 5
2026-02-13 20:34:44 <tpbsd       > this one is seriously good!
2026-02-13 20:35:09 <tpbsd       > https://www.youtube.com/shorts/vGKC9LpGnOQ?si=71e-zlAq0qaagBb3
2026-02-13 20:36:07 <tpbsd       > GLM-5 is Z.ai’s flagship open-source foundation model engineered for complex systems design and long-horizon agent workflows. Built for expert developers, it delivers production-grade performance on large-scale programming tasks, rivaling leading closed-source models. With advanced agentic planning, deep backend reasoning, and iterative self-correction, GLM-5 moves beyond code generation to full-system construction and autonomous execution.
2026-02-13 20:37:42 <tpbsd       > also see https://openrouter.ai/z-ai/glm-5?sort=price
2026-02-13 20:38:31 <tpbsd       > the YouTube video is a comedy skit about the rapid release of AI models
2026-02-13 22:25:40 <KipIngram   > Here's the link for the GUI development environment:
2026-02-13 22:25:43 <KipIngram   > https://wiki.seeedstudio.com/xiao_esp32c6_getting_started/
2026-02-13 22:25:53 <KipIngram   > and here's the github repo for the command line setup:
2026-02-13 22:26:02 <KipIngram   > https://github.com/espressif/esp-idf
2026-02-13 22:35:45 <tpbsd       > Espressif ESP32-C6 SoC
2026-02-13 22:35:46 <tpbsd       > two 32-bit RISC-V processors, with the high-performance one running up to 160 MHz, and the low-power one clocking up to 20 MHz  ?? thats 3 cpus ?
2026-02-13 22:36:08 <KipIngram   > No, just two.
2026-02-13 22:36:20 <KipIngram   > One up to 160 MHz, the other up to 20 MHz.
2026-02-13 22:37:08 <veltas      > No other non-RISC-V CPU?
2026-02-13 22:37:26 <veltas      > I've seen that before they'll shove an ARM Cortex M0 or something in there for good measure
2026-02-13 22:38:46 <tpbsd       > veltas, are you sure ? it's ESP we are talking about, arent they Xtensa oriented ?
2026-02-13 22:39:29 <tpbsd       > veltas, I agree tho with some other types of mcu's
2026-02-13 22:40:12 <veltas      > I'm not sure just saying I've seen, not saying ESP
2026-02-13 22:40:33 <veltas      > Sorry I'm neck-deep in a NetBSD install right now
2026-02-13 22:40:41 <tpbsd       > veltas, aha
2026-02-13 22:41:26 <KipIngram   > No, no others.
2026-02-13 22:42:03 <KipIngram   > Yes, that MAX32655 that I looked at a while back had that - an ARM Cortex M4 for main use and a RISCV mostly for Bluetooth timing.
2026-02-13 22:43:05 <KipIngram   > On this one that slow processor is mostly for low power, and I think think it can do some things in some of the sleep states.
2026-02-13 22:44:43 <tpbsd       > KipIngram, my AI agrees:
2026-02-13 22:44:46 <tpbsd       > The ESP32-C6 features two 32-bit RISC-V processors: a high-performance core and a low-power coprocessor.
2026-02-13 22:44:47 <tpbsd       > MAIN POINTS:
2026-02-13 22:44:47 <tpbsd       > 1. The microcontroller integrates two distinct 32-bit RISC-V processor cores.
2026-02-13 22:44:47 <tpbsd       > 4. One secondary low-power coprocessor manages tasks during sleep modes.
2026-02-13 22:44:49 <tpbsd       > 5. A low-power RISC-V (RV32EMAC) core serves as the coprocessor.
2026-02-13 22:44:51 <tpbsd       > 6. That secondary core runs at a maximum speed of 20 MHz.
2026-02-13 22:44:53 <tpbsd       > 7. Both processors utilize the open-source RISC-V instruction set architecture.
2026-02-13 22:44:55 <tpbsd       > 8. This design optimizes for a balance of performance and efficiency.
2026-02-13 22:44:57 <tpbsd       > 9. Heavy computation and wireless protocols are handled by the main core.
2026-02-13 22:44:59 <tpbsd       > 10. Low-power states utilize the coprocessor for GPIO and sensor activities.