2026-01-29 00:40:58 <KipIngram   > :-)  tpbsd: You really seem to be a "do it yourself" sort of fellow.
2026-01-29 00:41:17 <KipIngram   > I'm still impressed with the "make your own wire" thing.
2026-01-29 00:43:11 <KipIngram   > I'm primarily focused on the core module right now, but I will keep all this in mind.  And I'm gradually, some each day, cleaning out my disaster of a third car garage, which is where my workshop is.  It's currently unusable because of clutter, but it's actually a pretty nice setup when I have it properly open.
2026-01-29 00:43:55 <KipIngram   > I have a nice workbench I made myself - the top is from 2x4's I glued and clamped, and then I used a hand plane on it to smooth it down.
2026-01-29 00:45:44 <KipIngram   > I've got a Moxon vise on one end of the front that I also made myself.
2026-01-29 00:46:03 <KipIngram   > Leather on the gripping surface so I don't mar nice wood.
2026-01-29 00:46:18 <KipIngram   > No dog holes, though I eventually plan to add some.
2026-01-29 00:47:12 <KipIngram   > And about a year ago I surveyed my tool storage situation and found it entirely inadequate.  So I made three largish drawer units and painted them to match the color styling of my purchased floor-standing tool boxes.
2026-01-29 00:48:14 <KipIngram   > Eight drawers each in those that I made.  No metal hardware at all - wooden runners that the drawers run on (the plywood bottoms go in side grooves), and I got some slippery teflon tape to go on the sliding surfaces.  They run in and out really nicely.
2026-01-29 00:48:25 <KipIngram   > I'll post a picture when I get things cleaned up out there.
2026-01-29 00:49:03 <KipIngram   > Down at the other end in the back of the garage there's a 12' long table with folding legs (the cheap kind you see in schools) where I have my soldering station set up and things like that.
2026-01-29 00:49:54 <KipIngram   > Anyway, 24 new quite large and spacious drawers really solved my storage problem.  All of my tools and plenty of draws left for things like fasteners, electronic parts, etc. etc.
2026-01-29 00:50:43 <KipIngram   > Those drawers are a hair under 2' wide and right at 18" deep front to back.  Between 3 and 3.5" deep.
2026-01-29 00:52:46 <KipIngram   > I started out with a floor-standing commercial drawer unit with a stack-on tool chest on top of it, and a second portable toolbox that always just sat whereever it sat.  Now it sits on top of one of the three new drawer units, right beside the commercial units.  My drill press lives on top of the second drawer unit, and the 3D printer my wife's getting me for my birthday will sit atop the third
2026-01-29 00:52:49 <KipIngram   > when it it gets here.
2026-01-29 00:53:15 <KipIngram   > This one:  https://us.store.bambulab.com/products/p2s?id=664977091405410311
2026-01-29 00:54:02 <KipIngram   > One of my daughters did biometical engineering and works in a research lab where they do a lot of 3D printing - she and one of her coworkers advised me in choosing that.
2026-01-29 02:54:36 <tpbsd       > KipIngram, Ive never seen or operated a 3Dprinter, mainly as I have a milling machine so Ive always done subtractive manufacturing
2026-01-29 02:55:04 <tpbsd       > KipIngram, but a creative guy needs a workshop and tools for sure!
2026-01-29 02:55:33 <tpbsd       > and in electronics, LOTs of storage
2026-01-29 03:25:36 <MrMobius    > KipIngram: good idea to make a generic module with holes like a breadboard. What about buying proto board that's just the holes? It's an easy way to get started and can always do the PCB later
2026-01-29 03:28:41 <tpbsd       > MrMobius, I find any kind of holed board a LOT harder than wiring single sided pcb cut to shape
2026-01-29 03:29:10 <tpbsd       > just remove copper with a knife etc, do island type construction
2026-01-29 03:29:55 <tpbsd       > the easiest of all is of course getting a pcb made, if you dont mind waiting
2026-01-29 07:08:13 <KipIngram   > MrMobius: That's basically what I meant.  What I pictured there was a small PCB for the Cortex / Forth module, with pins that drop into one of those generic proto boards covered with plated holes.  Then the project-specific circuitry (which has been simple in the cases I've mentioned so far) would go on the proto board, hand wired, but the Cortex module would basically function like "one more part"
2026-01-29 07:08:16 <KipIngram   > to be wired on.
2026-01-29 07:14:19 <KipIngram   > tpbsd: Surely that copper cutting method doesn't work for very fine-pitch stuff?  For something big enough for that to work, couldn't you just draw your circuit on with an etch resist pen and then etch all the rest of the copper off?
2026-01-29 07:26:26 <tpbsd       > KipIngram, no it would be impossible to use a knife at that pitch. I remove the entire copper area for a chip, and hand wire only the pins I use as in this pic: https://mecrisp-stellaris-folkdoc.sourceforge.io/_images/pcb-round-pins-mcu2.jpg
2026-01-29 07:27:33 <tpbsd       > in that pic all the wires I needed are present, namely 0v,+3v, SWD
2026-01-29 07:28:21 <tpbsd       > it runs the terminal over SWD, same as the programmer to flash a image
2026-01-29 07:28:37 <tpbsd       > so only 4 wires are needed
2026-01-29 07:41:34 <KipIngram   > What if you need a whole slew?  I guess that when you go to a pcb.
2026-01-29 07:42:07 <tpbsd       > KipIngram, absolutely
2026-01-29 07:43:00 <tpbsd       > but my prototypes are small, various pieces of an overall design, all connected together
2026-01-29 07:43:13 <KipIngram   > So, why take the copper off at all?  Sounds like you could flip the chip upside down and glue it down on its back, and solder directly to the pins.
2026-01-29 07:43:28 <tpbsd       > I build my hardware like my Forth code, small pieces working together
2026-01-29 07:43:35 <KipIngram   > Ah, a "Forth like" hardware approach.  Small widgets, put them together.
2026-01-29 07:43:47 <tpbsd       > exactly
2026-01-29 07:44:40 <tpbsd       > dead bug is my prefered method as I mainly use QFN32 packages and they can only be accessed fron umderneath
2026-01-29 07:45:43 <tpbsd       > I have a new design coming up thats radically different, I have a heap of really tiny 16 pin MSp430 in BGA
2026-01-29 07:47:06 <tpbsd       > Im planning to bulk solder fine flexible silver coated wires to the chip solder blobs and then encapsulate the chip and the start of the wires in a small transistor like case
2026-01-29 07:47:40 <tpbsd       > that way I can easily hand solder the chip into any board form factor I like
2026-01-29 07:48:11 <tpbsd       > these chips are about 2mm x 2mm, incredibly small
2026-01-29 07:49:00 <tpbsd       > in fact theyre so small that places like JLCPCB cant etch and construct multi layer pcbs for them
2026-01-29 07:50:17 <KipIngram   > Yeah, stuff has gotten ridiculously small.
2026-01-29 07:50:42 <tpbsd       > yeah, but small and bga are the cheapest of all
2026-01-29 07:50:45 <KipIngram   > We were talking about the gold 74xx book the other day - sometimes I still miss those days.
2026-01-29 07:50:58 <tpbsd       > and these MSP430 are very advanced with 4k of fram
2026-01-29 07:51:28 <tpbsd       > not me, Ive escaped from the past and theyre not taking me back alive!
2026-01-29 07:51:36 <KipIngram   > Yeah, for certain applications that will be a nice little bomb to be able to drop.
2026-01-29 07:52:19 <tpbsd       > Ive already designd the soldering jig for them, I just have to make it now
2026-01-29 07:52:22 <KipIngram   > :-)  Well, I wouldn't REALLY want to go back.  We can do so much more now.  But, I was a young buck and good at what I did, so fond memories.
2026-01-29 07:52:52 <KipIngram   > And I could actually touch a pin with a soldering iron without toching five others around it.
2026-01-29 07:53:34 <KipIngram   > And you could get at everything for troubleshooting - all those DIP pins were just right there.  :-)
2026-01-29 07:54:46 <KipIngram   > Clip your logic analyzer leads on wherever you wanted to.
2026-01-29 07:58:49 <tpbsd       > no thanks! you could (and I did many times) flip a DIP chip as you pulled it with a finger so it embedded itsely up to the hilt, all pins
2026-01-29 07:59:04 <tpbsd       > it's indescribably painful
2026-01-29 07:59:41 <tpbsd       > I can't possibly describe all the ways I love SMT
2026-01-29 08:08:24 <tpbsd       > KipIngram, I recently blogged why I hated that TTL from those days : https://mecrisp-stellaris-folkdoc.sourceforge.io/ttl-7400-series.html
2026-01-29 08:28:46 <KipIngram   > Yeah, that's true - you could inflict pain on yourself with those.  And your fingers, man - lots and lots of nerve endings there.
2026-01-29 10:58:17 <KipIngram   > Surface mount is awfully impressive in all the ways that count most, but I think a fair degree of skill has to be developed when working with it by hand before you get to feel at ease with it.  I'm certainly not all the way there yet.
2026-01-29 10:59:50 <tpbsd       > I spent 12 months as the tech manager for a 100 person SMT assembly factory with all the good gear, die bonder, wire bonder, 3 large P&P machines, ir reflow etc, so Im fully converted now
2026-01-29 11:00:05 <KipIngram   > The best experience I ever had with SMT was while I was consulting back in the early 2000's - I populated the PCB for one project myself - I put the solder paste on with a a squeegee on the solder mask, put the parts on by hand, and then reflowed it in a toaster oven.  Worked great.
2026-01-29 11:00:34 <KipIngram   > But I have no really good SMT soldering skills to speak of.  I want to learn how to do that "drag" thing, but I don't have it down yet.
2026-01-29 11:00:38 <tpbsd       > I know every stage of commercial SMT usage perfectly now, but not BGA
2026-01-29 11:01:25 <tpbsd       > lots of liquid flus is the perfect SMT cure all Ive found
2026-01-29 11:01:29 <tpbsd       > flux
2026-01-29 11:02:07 <tpbsd       > and a deceny binocular microscope workstation
2026-01-29 11:02:09 <KipIngram   > I have quite a lot of background in pick-and-place, including building and programming them.  We used PnP machines for our automated programming systems at BP Microsystems.  We bought them initially, but our primary supplier threatened to go bankrupt, so our owner just decided we'd build our own.  I was running engineering by then, so I was saddled with figuring that out from ground zero.
2026-01-29 11:02:22 <KipIngram   > We had one to demo at the next Nepcon show about six months later.
2026-01-29 11:02:23 <tpbsd       > me too :)
2026-01-29 11:02:44 <tpbsd       > Dynapert and Amistar mainly
2026-01-29 11:02:57 <KipIngram   > I was in a position to cherry pick the parts of the work that seemed interesting to me.  I wrote all of the low-level motion control and the machine vision aspects.
2026-01-29 11:03:07 <tpbsd       > Ive rebuilt them down to and inclusing the rails
2026-01-29 11:03:30 <KipIngram   > Yes, we designed and built them (no "re-") from that level.  :-)
2026-01-29 11:03:51 <tpbsd       > we didnt have any machine vision apart from the die bonding machine
2026-01-29 11:04:19 <tpbsd       > ah, so youre off to a good start
2026-01-29 11:04:36 <KipIngram   > The first one we did was actually before that bankruptcy issue - the owner wanted a "mid-range" automated product (fewer parts per hour).  Later, when the bankrupcy thing came up, we had to build another one for our flagship automated system, which programmed 1200 parts per hour.  The boss wanted to hit 1400, and we did by switching from steppers to servos.
2026-01-29 11:04:59 <KipIngram   > Got it to the show, and one of our big customers actually pulled out a stopwatch to time it.
2026-01-29 11:05:16 <KipIngram   > I stood there calm as a cucumber, because I knew damn well it could do it.
2026-01-29 11:05:41 <tpbsd       > all our machines had servoes, big ones. The Amistar had a rotary head and did 17,000 parts a hour back in 1987
2026-01-29 11:05:48 <KipIngram   > Afterward he just put the watch back in his pocket and looked at me and gave me a nod.
2026-01-29 11:06:08 <KipIngram   > Yeah, the level we worked at certainly wasn't the tippy top of the industry.
2026-01-29 11:06:24 <tpbsd       > I also reconditioned DIP P&P machines
2026-01-29 11:06:38 <KipIngram   > The Quad Systems Quad IVc was the original flagship PnP (the PnP for OUR flagsghip, that is).
2026-01-29 11:07:04 <KipIngram   > More speed would have offered diminishing returns anyway, because after all, the parts had to be programmed too.  There was a sweet spot.
2026-01-29 11:07:15 <tpbsd       > aha
2026-01-29 11:08:11 <KipIngram   > That Quad IVc based system had 12 programming sites spread out on the tabletop, that could run out of phase with one another.  So once the programming time got to a certain point, the PnP could keep them busy pretty much full-time.
2026-01-29 11:08:30 <tpbsd       > I was always amazed how stable a large platter with thousamds of SMT parts only head on with solder paste is. I used to bang the platters against a brick wall, edge on to demonstrate that nothing moved
2026-01-29 11:08:37 <KipIngram   > And we couldn't bend pins - our target there was to have every pin tip within 0.001" of precise when we dropped it into the socket.
2026-01-29 11:08:43 <tpbsd       > held on
2026-01-29 11:09:03 <KipIngram   > That's where the vision came in, because those parts rattle around in their tray and tape pockets, and you can't know exactly how you're holding it without looking to see.
2026-01-29 11:09:26 <tpbsd       > thats pretty accurate, I think ours were to 0.003"
2026-01-29 11:09:57 <KipIngram   > We supported an upward looking camera that was needed for some parts, but for most of them we could use the "laser align" unit mounted to the moving head.  Rotate the part in a sheet of laser beams and analyze the shadow pattern.  You could do that while you were on the way to the socket - no separate trip to a camera required.
2026-01-29 11:10:13 <tpbsd       > all our machines had alignment jaws for the component registration
2026-01-29 11:10:32 <KipIngram   > So start a rough move to the target, do the laser align on the way, and update the target before the motion finished.
2026-01-29 11:10:49 <KipIngram   > I wrote all that code, including the shadow pattern analysis.
2026-01-29 11:10:56 <tpbsd       > thats a lot later tech than I had back then, it was all mechanical in the placement
2026-01-29 11:11:05 <tpbsd       > wow
2026-01-29 11:11:33 <KipIngram   > Turned out later that motion control and machine vision were good skills for a consultant to have, though I never made as much money consulting as I had working a job.
2026-01-29 11:11:52 <KipIngram   > Which is why I went back to working jobs when we wanted to move to a bigger house in a better school district.
2026-01-29 11:12:04 <tpbsd       > KipIngram, do you ever use neovim editor ?
2026-01-29 11:12:59 <KipIngram   > I have it installed and have toyed with it.  It's interesting.  It seems to control the display in a different way that defeats certain control aspects, though.  I haven't forced myself to "default" to it.
2026-01-29 11:13:01 <tpbsd       > I just cant get Forth syntax highlighting working and my all the tests my AI suggest pass
2026-01-29 11:13:10 <KipIngram   > Yeah - exactly.
2026-01-29 11:13:28 <KipIngram   > It just somehow doesn't do that stuff in the way that the highlighting relies on.
2026-01-29 11:14:01 <tpbsd       > Its ok, not my favorite, which is Helix editor (written in rust) and for which I made a Forth LSP
2026-01-29 11:14:06 <KipIngram   > Its way is probably "better" in some describable ways, but it misses some other things.
2026-01-29 11:14:25 <KipIngram   > I'm pretty content with vim and haven't really explored elsewhere.
2026-01-29 11:14:42 <tpbsd       > plus I like Lua personally
2026-01-29 11:14:44 <KipIngram   > I used to be an emacs guy, but I decided that the vim ecosystem was getting a lot more ongoing development.
2026-01-29 11:15:23 <KipIngram   > I think it surprised my coworkers when I just randomly switched - I think the idea that that's a "holy war" of sorts was really baked into their minds.
2026-01-29 11:15:28 <tpbsd       > Helix is incredibly well made and stable, so easy to get a LSP running on it
2026-01-29 11:15:39 <tpbsd       > heh, yeah
2026-01-29 11:16:00 <KipIngram   > If I pull off this project I've described, I'll be writing my own editor as part of that in Forth.
2026-01-29 11:16:25 <KipIngram   > I have pretty extensive plans for how the whole edit / debug stuff should operate.
2026-01-29 11:16:30 <tpbsd       > Ive made a pretty handy pop-up window for neovim, and it works perfectly usig a sqlite database full of SVD data
2026-01-29 11:16:53 <KipIngram   > I have a LOT of "plans," because mostly for the last many years I've just sat around and THOUGHT about this stuff rather than DOING any of it.
2026-01-29 11:17:04 <KipIngram   > I have a lot more time on my hands now, though.
2026-01-29 11:17:17 <tpbsd       > so it's kind of stupid that I cant get Forth syntax highlighting working in nvim!
2026-01-29 11:17:41 <tpbsd       > yeah, retirement is awesome for finishing projects!
2026-01-29 11:18:05 <KipIngram   > I think it's well understood, though.  They just had a different set of priorities, and one of them broke the way that highlighting is typically done.
2026-01-29 11:18:23 <KipIngram   > I don't know if it's "impossible" or not, though.
2026-01-29 11:18:37 <KipIngram   > Hang on a second - let me do a little test.
2026-01-29 11:19:11 <tpbsd       > I have had syntax highlighting working in neovim before, on Linux, but this is FreeBSD and a lot of support apps are missing
2026-01-29 11:19:30 <KipIngram   > Oh, hmmm.  I run a standard Linux.  Fedora.
2026-01-29 11:19:58 <KipIngram   > The way I write Forth I've never found syntax highlighting too critical.
2026-01-29 11:20:13 <tpbsd       > syntax highlighting is working ootb on neovim bit only with about 6 langs, lua, C etc
2026-01-29 11:20:19 <KipIngram   > Forth doesn't HAVE much syntax.
2026-01-29 11:20:33 <KipIngram   > Right - the popular languages.
2026-01-29 11:20:46 <tpbsd       > Im addicted to it, without colors it looks 'flat' and boring to me
2026-01-29 11:21:09 <tpbsd       > just a personal pref
2026-01-29 11:21:29 <KipIngram   > Personal prefs are 100% fine.
2026-01-29 11:21:38 <tpbsd       > yeah, and Forth certainly isnt popolar thesedays
2026-01-29 11:21:51 <KipIngram   > No, which is "their loss."
2026-01-29 11:21:56 <tpbsd       > yeah
2026-01-29 11:22:02 <tpbsd       > Forth is all I use
2026-01-29 11:22:20 <KipIngram   > I consider it the absolute best language for low-level embedded work.
2026-01-29 11:23:08 <KipIngram   > But as I've noted before, the very first programming I ever did - bar none - was my HP-41C calculator I used in college.  So I really drove "stack thinking" into my head right from the jump.
2026-01-29 11:23:31 <KipIngram   > Therefore I probably don't have a valid perspective on how hard it would be to adjust after a lifetime of the alternative.
2026-01-29 11:23:51 <KipIngram   > It just feels 100% natural to me.
2026-01-29 11:25:32 <tpbsd       > RPN is my favorite now, I started Forth in 2014
2026-01-29 11:25:34 <KipIngram   > I think on this new Forth I'm going to incorporate a lot of words that correspond to HP-41 stack actions.  And naming too - call it x<>y instead of swap, RDN and RUP instead of rot and -rot, etc.
2026-01-29 11:25:51 <KipIngram   > Oh wow, you found it late.
2026-01-29 11:26:00 <KipIngram   > I found it in 1982 or so.
2026-01-29 11:26:22 <tpbsd       > I get the feeling that tree-sitter, which is now built-into neovim is stomping over the old syntax highlighter
2026-01-29 11:26:26 <KipIngram   > Initially "it's RPN" (like my calculator) was the big attraction.  Only a few years later did I recognize its "internal beauty."
2026-01-29 11:26:48 <tpbsd       > yeah, I managed to ignore Forth since 1979
2026-01-29 11:27:51 <tpbsd       > thats one of the neovim issues I think, rapid development is leaving issues here and there
2026-01-29 11:27:52 <KipIngram   > The first Forth I wrote was before I really understood how Forth works inside.  It was for a TRS-80 color computer, and written in 6809 assembly.
2026-01-29 11:28:10 <KipIngram   > It worked, but when I did learn what really went on under the hood in Forth I realized how horrible it was.
2026-01-29 11:28:17 <tpbsd       > hahah
2026-01-29 11:28:38 <tpbsd       > as a tech, I'll never write a forth, I just dont have the interest
2026-01-29 11:28:41 <KipIngram   > I was just overhwhelmed at how wonderfully simple it all is.
2026-01-29 11:28:53 <tpbsd       > Im a builder of devices, not software
2026-01-29 11:28:53 <KipIngram   > And that's when the "true love" began.
2026-01-29 11:29:23 <tpbsd       > but some software like FURS I had to build because no one else was doing it
2026-01-29 11:29:25 <KipIngram   > I like to say I do both, though I've never labeled myself a "professional" programmer.  I'm just a hardware guy that learned enough to get (somewhat) dangerous.
2026-01-29 11:29:53 <KipIngram   > For one thing, I've never programmed in a team environment.  One man show things exclusively.
2026-01-29 11:30:00 <tpbsd       > same
2026-01-29 11:30:30 <KipIngram   > So I'm not any sort of version control power user or anything like that.
2026-01-29 11:30:48 <KipIngram   > I'd balk pretty fast at having a coding style imposed on me, I think.
2026-01-29 11:30:55 <tpbsd       > Im a big Fossil DVCS fan myself
2026-01-29 11:31:09 <KipIngram   > When I do do version control I use git.
2026-01-29 11:31:29 <tpbsd       > mainly as it's also a complete design environment, including doc and flowcharts
2026-01-29 11:32:08 <KipIngram   > See, doc hooks is one of the things I want in the environment I plan.  I have always undercommented, or not commented at all, because I always object to the comments "uglying up" my source.
2026-01-29 11:32:31 <KipIngram   > So I want to be able to toggle inline comments on and off, and for more extensive commenting I want to store them somewhere else and have them hyperlinked from the source.
2026-01-29 11:32:56 <tpbsd       > how rediculous getting stumped on syntax highlighting, I guess I have to decide "stay with only Helix" or keep trying to fis this issue on neovim ...
2026-01-29 11:33:01 <KipIngram   > And once I have that, why not go further?  Why not a wiki style set up, that starts at the source, goes to "comments," then to more extensive documentation, and so on, right up to full tech ref type stuff.
2026-01-29 11:33:24 <KipIngram   > I LIKE describing things.  It's just the impact it has on my code appearance that stymies me, and I can fix that if I write it myself.
2026-01-29 11:33:30 <tpbsd       > thats exactly what I have with Fossil
2026-01-29 11:33:35 <KipIngram   > So like I said earlier - lots of plans.
2026-01-29 11:34:05 <KipIngram   > I've got plans for an FPGA-based Forth processor too.
2026-01-29 11:34:16 <tpbsd       > the DCVS is linked into the wiki, I think it is pretty easy to make decent doc that way
2026-01-29 11:34:40 <KipIngram   > I've given a lot of thought to how to arrange things to make effective use of the resources typical FPGAs offer.
2026-01-29 11:35:12 <tpbsd       > there was a new poster on the Mecrisp-Stellaris forum today commenting that hes making a processor on some much fastr FPGA's for Mecrisp-Stellaris to run on
2026-01-29 11:36:18 <KipIngram   > For one thing, I discovered that fetching individual modern RAM is just a total performance killer.  So my thoughts there is that all data motion between main RAM and FPGA block RAM will be in blocks.  Like 4kB or 8kB, to exploit the RAM's burst performance.  The actual Forth operation will all be using block RAM.
2026-01-29 11:36:32 <tpbsd       > we have mecrisp-ice which used a fpga cpu fabric, but the chip is slow and around 5000 LUT's and about $25 USD
2026-01-29 11:36:55 <KipIngram   > I don't know if I'll ever get around to that project.
2026-01-29 11:37:19 <KipIngram   > I have a vision of building my own computer, totally from scratch.  So maybe, but we'll see.
2026-01-29 11:37:28 <tpbsd       > I actually purchased one of the FPGA boards and have Mecrisp-Stellaris on it
2026-01-29 11:37:48 <KipIngram   > I've got an Arty kit.
2026-01-29 11:38:06 <KipIngram   > It has an Artix 7.  Not the biggest one, but decently sized.
2026-01-29 11:38:11 <tpbsd       > but it just doesnt intrest me, theyre too exensive, and MCU's do everything I need
2026-01-29 11:38:41 <KipIngram   > Right - for most projects I'm apt to be interested in, except that one where I have to do my own processor, it's the same for me.
2026-01-29 11:38:59 <KipIngram   > And yes - they've just gotten a little to proud of their FPGAs to suit me.
2026-01-29 11:39:10 <KipIngram   > too
2026-01-29 11:39:41 <tpbsd       > yeah, agreed
2026-01-29 11:40:10 <KipIngram   > Meanwhile, those little micros are just so cheap and powerful.
2026-01-29 11:40:57 <tpbsd       > they sure are, I can do anything with tham
2026-01-29 11:42:02 <KipIngram   > One target I'm interested in for this new system is to deploy it through UEFI and just ditch the "OS" altogether.  Just to say I've done it.
2026-01-29 11:43:37 <KipIngram   > Leave one core in "startup" mode so it can continue to use the UEFI services, and take the rest full native.  That one core would be an "I/O server" so to speak.
2026-01-29 13:10:52 <cleobuline  > Bruce Springsteen a fait une chanson anti Trump
2026-01-29 13:47:45 <crc         > going through UEFI's boot services is pretty easy. It's what I did with ilo-amd64-uefi. I've not looked into whether you can leave just one core with the boot services and note the others though.
2026-01-29 14:20:02 <veltas      > rendar: Is this a Rust-specific issue?
2026-01-29 14:20:10 <veltas      > Like something to do with the borrow checker?
2026-01-29 14:20:31 <veltas      > I'm not sure what you mean by "word dispatcher" and "run-time" etc
2026-01-29 14:38:30 <veltas      > crc, KipIngram: You can't use UEFI services from application cores, apart from a special method to determine the core, and they're really only meant to dispatch small jobs in parallel while UEFI is running.
2026-01-29 14:39:07 <veltas      > After calling EFI_BOOT_SERVICES.ExitBootServices() you shouldn't call any boot services from any core
2026-01-29 14:44:06 <veltas      > I think just speaking incrementally it makes sense to start with the UEFI boot services, until you've implemented the necessary drivers
2026-01-29 14:45:41 <veltas      > And your drivers can be pretty similar to the UEFI functionality anyway, it's not inherently inefficient
2026-01-29 14:47:27 <crc         > I'll eventually work on native drivers, but it's not a high priority; the UEFI boot services work well enough for ilo's needs for now
2026-01-29 14:47:46 <veltas      > I doubt I'd ever touch that stuff unless UEFI firmware kept burning me
2026-01-29 14:48:00 <crc         > I'm more focused on improving things on the MCU side (arm, risc-v, esp32)
2026-01-29 14:48:17 <veltas      > "I/O core" sounds like a bad direction, I've used real-time OS's that work this way though
2026-01-29 14:50:00 <veltas      > I will say that all 'real-time' stuff that's not legally required to be real-time has moved over to e.g. Linux because they realised it was faster *and* more stable for their application.  The 'real-time' mindset is extremely limiting and expensive, it's best reserved for medical/vehicle software
2026-01-29 14:50:25 <veltas      > Except like FreeRTOS et al because they can fit on smaller chips, not because they're real-time
2026-01-29 15:09:49 <KipIngram   > I don't like it much either, veltas, but the problem is that the UEFI system is basically a single-core thing.  I can run all of my cores, but I can only allow one of them to call into the UEFI stuff.
2026-01-29 15:10:46 <KipIngram   > It's just the only way I've thought of so far to manage both goals (multi-core and use UEFI for I/O), but I suppose I might be able to use some sort of a lock on the UEFI.  Don't know if that's better or worse, though.
2026-01-29 15:10:57 <KipIngram   > And in any case it might muck up caches.
2026-01-29 15:11:40 <KipIngram   > UEFI really just wasn't designed to support multiple cores - it's not really for long-term use at all, I think.
2026-01-29 15:11:49 <KipIngram   > Just a bootstrap into a "real" OS.
2026-01-29 15:12:10 <KipIngram   > But I just don't much care for having to write all of the code for all of the I/O hardware.
2026-01-29 15:13:01 <KipIngram   > I am going to have to program the keyboard controller myself, though, because I want to base my system on key make/break events, but UEFI is keystroke oriented.
2026-01-29 15:14:04 <veltas      > The lock has the advantage that you can 'port' that layer to work on a baremetal OS that *can* actually share I/O across cores
2026-01-29 15:14:29 <KipIngram   > That's true, though in a real system I'd lock individual hardware items rather the "all of it."
2026-01-29 15:14:34 <veltas      > I suppose it depends whether multiple processors is more urgent than writing the drivers to you or not
2026-01-29 15:14:40 <KipIngram   > But yeah, I'd at least be in that direction.
2026-01-29 15:15:08 <veltas      > I would guess for most workloads you'd get more performance getting proper drivers rather than multiple cores, unless you're doing really compute-heavy stuff
2026-01-29 15:15:38 <veltas      > The main parallel resource of your computer, in a sense, is all your peripherals
2026-01-29 15:15:38 <KipIngram   > I'm taking ideas from Erlang, and Erlang already has threads access, say, disk by sending a message to a "disk manager thread."
2026-01-29 15:15:52 <veltas      > Because they pretty much all allow running in 'parallel' to the CPU
2026-01-29 15:16:00 <KipIngram   > Well, that depends on the application.  I'm pretty interested in scientific computing.
2026-01-29 15:16:08 <KipIngram   > Where I'd be doing lots of numerical calculations.
2026-01-29 15:16:18 <KipIngram   > And fairly little I/O.
2026-01-29 15:16:58 <veltas      > I wonder what SIMD stuff you can do in UEFI
2026-01-29 15:17:41 <veltas      > Have you considered using an existing small OS to port to your lang/asm?
2026-01-29 15:17:44 <KipIngram   > I would think any of it.
2026-01-29 15:17:52 <KipIngram   > I don't know that for sure, but they're just "instructions."
2026-01-29 15:18:04 <KipIngram   > They're not touching any outside hardware or code within UEFI.
2026-01-29 15:18:32 <KipIngram   > No,  haven't looked into that.
2026-01-29 15:32:37 <veltas      > You need OS support to use SIMD, not sure UEFI spec guarantees anything on x86-32 so you might need to initialise some stuff
2026-01-29 15:33:07 <veltas      > I'm guessing all UEFI will initialise it and save those registers so should be okay
2026-01-29 15:33:17 <veltas      > Based on the calling conventions
2026-01-29 15:37:52 <veltas      > I've seen baremetal code crash before because people used -march=native when building, and it generated some SSE to clean things up, but it was in x87 mode and the monitor co-processor wasn't enabled
2026-01-29 15:41:02 <veltas      > KipIngram: I've never used Erlang, is it worth learning?
2026-01-29 16:05:44 <KipIngram   > I haven't "learned it" well enough to use it either, but it has some really interesting aspects.  Not all of it, for sure - I don't  know if I'd actually like using it in full.  I just want to rob some of its thread support ideas.
2026-01-29 16:06:10 <KipIngram   > It supports extremely large thread counts very efficiently, and I want to explore the notion of breaking problems up that way.
2026-01-29 16:07:02 <KipIngram   > An Erlang "green thread" can consume as little as a few hundred bytes of RAM - it's not out of the question to run a million threads on a system (most of them would become active only rarely, of course, or you'd be spending all your time thread switching).
2026-01-29 16:14:26 <KipIngram   > The full Erlang program leans a little too hard into the functional / immutable data thing to suit me.
2026-01-29 16:15:03 <KipIngram   > Except it really doesn't, internally - they tout those ideas like they're the greatest thing since sliced bread, but they breach them all over the place in the internals of the system.
2026-01-29 16:15:24 <KipIngram   > What they expose to you the programmer enforces them, though, and I don't like being restricted like that.
2026-01-29 16:16:59 <KipIngram   > But I do like the idea of very efficient, lean threads that communicate with each other by message passing (though in my modifications to the ideas there will be a way to do shared data interaction as well, if I want to).
2026-01-29 16:17:34 <iv4nshm4k0v > I wouldn't say I'm /familiar/ with Erlang, but after reading a bit on it, and reading sources of actual Erlang applications, I no longer see anything special in its lightweight threads.  It certainly was an achievement to show that the approach is practical, but once there, it can be implemented elsewhere.
2026-01-29 16:17:34 <iv4nshm4k0v > Tcl events, for one thing, are somewhat close and, though it /seems/ that IO is subtly broken there (I suspect an implementation kink that's not a fundamental flaw), can probably used for a similar programming style.
2026-01-29 16:17:47 <KipIngram   > And I like how resilient the system is - if a thread crashes, some other thread monitoring it will recognize that fact and take appropriate corrective action.
2026-01-29 16:18:11 <KipIngram   > Right - I agree.  I see no reason why you couldn't make that kind of move in almost any system.
2026-01-29 16:18:33 <KipIngram   > My impression is that there's a lot of "philosophical evangelism" going on around the language.
2026-01-29 16:18:59 <KipIngram   > Which isn't me criticizing it - it's had enough successes to clearly be a worthy language.
2026-01-29 16:19:33 <KipIngram   > I just generally don't care for dogmatic approaches to such things.
2026-01-29 16:19:43 <KipIngram   > Just let me do whatever I think is best case by case.
2026-01-29 16:20:17 <iv4nshm4k0v > I actually don't see much talk on the language at all.  I suppose it might have its own dedicated community, but unlike, say, Python, it's not a language I see /mentioned/ often.
2026-01-29 16:20:18 <iv4nshm4k0v > Also, isn't classic Forth "task switching" akin to lightweight threads?
2026-01-29 16:20:30 <KipIngram   > Yes, I had to kind of chase it down.
2026-01-29 16:21:00 <KipIngram   > Forth thread switching CAN be lightweight, yes.
2026-01-29 16:21:17 <KipIngram   > And if you arrange so that threads can have or not have various resources, then they can be very light.
2026-01-29 16:21:36 <KipIngram   > Like, maybe a simple thread doesn't need a dictionary of its own and doesn't need a console interface of its own with a big screen buffer, etc.
2026-01-29 16:21:46 <KipIngram   > And maybe it only needs quite small stacks to do its job.
2026-01-29 16:22:05 <KipIngram   > So you could prune it down to a very small size if you have a way to equip it only with the minimum resources it needs.
2026-01-29 16:22:40 <KipIngram   > The place I've deviated from that nice pretty vision of fast task switching in Forth (just swap stack pointers) is that I use a lot of registers.
2026-01-29 16:23:08 <KipIngram   > On x64 I pretty much use all of them.  So I have to save and restore all of them, and the threads will have to have room for that on top of whatever app data is on the stacks.
2026-01-29 16:24:08 <KipIngram   > And if a thread is running a display, that's not a very lean thread anymore.
2026-01-29 16:25:20 <KipIngram   > Erlang has its own specific data structures for organizing the threads and so on, which I may or may not follow closely.  So I'm not really looking at "copying" much of it - more just at "taking inspiration" from it.