2025-10-22 14:53:59 <veltas      > crc: Any other plans for the UEFI port?
2025-10-22 15:28:55 <cleobuline  > NEWS ! I installed photovoltaic panels on my roof
2025-10-22 15:32:03 <ajhidd2     > \3
2025-10-22 15:43:43 <cleobuline  > 4,5 kw
2025-10-22 15:44:23 <cleobuline  > actually producing 2,5 kw
2025-10-22 15:44:28 <cleobuline  > cloudly
2025-10-22 15:56:25 <crc         > veltas: yes, in the short term: adding in stack over/underflow & memory access bounds checks, additional ilo i/o devices for direct reads/writes to physical RAM & system i/o ports, improvements to the graphics support (adding color, faster drawing primitives)
2025-10-22 16:03:29 <crc         > a bit longer term: support for aarch64 systems, saving/loading the konilo image from a disk partition, mouse support, possibly network support
2025-10-22 16:03:53 <crc         > I'm going to have a dedicated machine running this soon
2025-10-22 16:12:39 <KipIngram   > cleobuline: Where are you geographically?
2025-10-22 16:49:42 <cleobuline  > KipIngram:  https://www.google.com/maps/search/?api=1&query=40%20route%20du%20chatelet%20chateaumeillant
2025-10-22 16:50:19 <cleobuline  > installed yesterday
2025-10-22 16:50:36 <cleobuline  > i'm happy of that
2025-10-22 17:07:06 <KipIngram   > Cool.  Not exactly the best solar spot in the world, but I do hope it goes well for you!  I live around latitude 30 degrees, so it's a pretty favorable solar zone, but I have no panels on my home.  A few of my neighbors do.
2025-10-22 17:26:50 <veltas      > crc: awesome, I'm interested in anything that comes out of that
2025-10-22 17:29:32 <veltas      > cleobuline: You're only a 10 hour drive from me
2025-10-22 17:32:56 <veltas      > KipIngram: We can't all live in Cape Verde
2025-10-22 17:47:43 <crc         > veltas: I'll provide updates as the work continues
2025-10-22 18:06:19 <KipIngram   > veltas: True true - we all do the best we can.
2025-10-22 18:06:44 <KipIngram   > Trust me, around August or so I often wish I lived 10-15 degrees further north.  :-|
2025-10-22 18:06:58 <KipIngram   > It gets god awful miserable around here that time of year.
2025-10-22 18:07:14 <KipIngram   > You can almost look out the window and start sweating.
2025-10-22 18:08:33 <KipIngram   > I used to watch that TV show, "Sex and the City."  On an episode or two it would be summer there in New York City, and they all sat around acting like they were about to faint from  heat stroke and envy the people who were able to "go up to the Hudson" for the hot weather.  I'd just shake my head and think "You have no idea what you're even talking about."
2025-10-22 18:10:52 <KipIngram   > Although part of it could be that some folks living up around New York have no air conditioning - you can think of it as optional in that part of the country.  So then when the "hot" weather comes, you can't hide from it, and that could make it psychologically worse, I guess.  Around here AC is simply not optional.
2025-10-22 18:11:29 <KipIngram   > Especially since they don't build homes to take advantage of natural circulation anymore.  They just build a box, often with many windows that won't open, and slap a machine on the ground next to it.
2025-10-22 18:12:37 <KipIngram   > Back between my marriages I lived in Austin and had bought a homesite I intended to build my own place on, and I meant to try to honor those old ways of doing things.  But then I met my current wife and she sort of turned my whole world upside down, and that path never materialized.
2025-10-22 18:13:02 <tp_         > KipIngram, it's the same here in nsw, australia, it's 3am and the lowest the temperature has been since 9am yesterday is 25,2 C  77,4 F
2025-10-22 18:13:05 <KipIngram   > Sold that lot and moved her to Houston.
2025-10-22 18:13:44 <tp_         > our peak was aroung 36C yesterday
2025-10-22 18:16:41 <veltas      > Yeah I don't envy people near equator, I am not built for it
2025-10-22 18:16:48 <veltas      > I need cold weather to function
2025-10-22 18:21:05 <tp_         > me too
2025-10-22 18:21:39 <tp_         > especially as I get older
2025-10-22 18:23:28 <tp_         > well, I've mostly finished my years long project that provides the same kind of hardware knowledge to Forth for embedded that C gets from header files
2025-10-22 18:24:36 <tp_         > Im just rewriting the example project for it (digital thermometer) but everything else is finished now ince the doc, with flowcharts
2025-10-22 18:25:49 <veltas      > Interested to read your doc when it's published
2025-10-22 18:26:02 <tp_         > here is a sample of the syntax "COMP_CSR_COMP1EN  enable!  \ Comparator 1 enable"
2025-10-22 18:26:29 <tp_         > veltas that should be in a couple of days
2025-10-22 18:27:14 <tp_         > it doesnt modify the base Forth in any way (mecrisp-stellaris) or alter the project source in any way
2025-10-22 18:28:03 <tp_         > and it uses 100% compliant CMSIS-SVD syntax
2025-10-22 18:29:06 <veltas      > Is it pre-processing the Forth before it's transmitted?
2025-10-22 18:29:24 <tp_         > veltas, exactly right!
2025-10-22 18:30:52 <veltas      > The purist in me isn't too keen on all the tools used and the fact it sort of messes with the core interpreter/compiler concept; but also I can't really suggest a better alternative, this solves a real problem effectively
2025-10-22 18:31:30 <veltas      > I'll read about it when it's published, it's definitely an important tool for the Mecrisp ecosystem
2025-10-22 18:32:03 <tp_         > "COMP_CSR_COMP2EN enable!  \ Select COMP2" becomes "$4001001C  16  enable!" before upload to the mcu
2025-10-22 18:34:03 <tp_         > yeah, Mecrisp-Stellaris or any Forth with no knowledge of the hardware is usless with any cortex-m cpu
2025-10-22 18:34:47 <veltas      > How easy is it to hook into the 'unrecognised symbol' routine in Mecrisp?
2025-10-22 18:35:24 <tp_         > Im only a electronics tech and dont understand your question
2025-10-22 18:35:34 <tp_         > Im not a real programmer
2025-10-22 18:36:16 <tp_         > I understand Mecrisp-Stellaris well enough but Im not a Forth implimenter
2025-10-22 18:36:29 <veltas      > What I mean is in Mecrisp's interpreter if it doesn't find a word in the dictionary, it will attempt to read it as a number, and then otherwise give up and print an error, riht?
2025-10-22 18:36:38 <tp_         > yes
2025-10-22 18:37:25 <tp_         > it would be impossible to add to Mecrisp-Stellaris itself as the image as is is 20KB in size and the mcu only has 64KB storage
2025-10-22 18:37:41 <veltas      > I'm wondering if you can add your own code after failing to find it in the dictionary, that talks to the host (if connected) to search the CMSIS
2025-10-22 18:37:58 <tp_         > hmm, good question
2025-10-22 18:38:35 <tp_         > that would need modification of the terminal and some special control characters I guess ?
2025-10-22 18:38:44 <veltas      > This would run slower because of the back-and-forth, but could prevent issues caused by pre-processing
2025-10-22 18:39:00 <veltas      > If it is assumed the terminal is the only two-way connection then yeah
2025-10-22 18:39:11 <veltas      > Which I'm guessing is the normal situation?
2025-10-22 18:39:43 <tp_         > yes, and it's not a 'normal terminal' eother
2025-10-22 18:40:15 <tp_         > this terminal talks to the mcu via SWD over the debug interface
2025-10-22 18:40:45 <tp_         > and that provides a 512 chr ring buffer in sync with the PC
2025-10-22 18:41:52 <tp_         > the bottom line being I can do 512 char prints and not affect running programs at all, unlike what happens with a usart 'terminal'
2025-10-22 18:42:18 <veltas      > Very nice
2025-10-22 18:42:30 <tp_         > the SWD terminal runs at 1 - 20 MHz
2025-10-22 18:43:35 <tp_         > so it provides problem free debugging with up to 512 chr 'printfs'
2025-10-22 18:44:59 <tp_         > lol, Im still trying to measure how long it actually takes to do a full 512 char print, but the 1ms Systick is no good as it always measures '0' so I have to write a accurate microsecond timer
2025-10-22 18:45:23 <veltas      > Could you do 1000 512 char prints and measure that?
2025-10-22 18:46:11 <tp_         > good idea! I hadnt considered that
2025-10-22 18:47:11 <tp_         > I focussed only on the 512 char elapsed time
2025-10-22 18:47:53 <tp_         > thanks! now I can try both and compare them to confirm the timer accuracy
2025-10-22 18:48:27 <veltas      > I use something like that to check timers, clocks etc at work with low precision stopwatches etc
2025-10-22 18:49:14 <tp_         > it's embarrasingly obvious now that you have suggested it
2025-10-22 18:49:27 <veltas      > :P
2025-10-22 18:49:33 <tp_         > I have a singular one-track mind
2025-10-22 18:49:36 <KipIngram   > tp_: If you're on Linux there is a system call that gives microseconds as a pair of 64-bit results.  I forget it it's actually a 128-bit microseconds quantity or seconds / microseconds.  I think the latter.
2025-10-22 18:49:55 <tp_         > KipIngram, yeah I'm on nixos
2025-10-22 18:50:08 <KipIngram   > I've got code for it (nasm) if you're interested.
2025-10-22 18:51:03 <tp_         > as the mcu has a xtal controlled clock I'd normally get it to do the time measurements
2025-10-22 18:52:09 <tp_         > KipIngram, so thanks but I'll use the mcu for that part
2025-10-22 18:53:40 <tp_         > the only think that has prevented me from doing that with a microsecond timer is finishing my 'furs' project as I've been putting 100% of my time into it
2025-10-22 18:54:01 <tp_         > (furs = Forth Upload Replacement System)
2025-10-22 18:55:06 <tp_         > oh and the awesome SWD terminal was designed by "crest_" who I see is on this channel atm
2025-10-22 18:55:20 <crest_      > tp_: ?
2025-10-22 18:55:29 <crest_      > (haven't read the backlog in a while)
2025-10-22 18:55:36 <tp_         > hi crest!
2025-10-22 18:56:35 <tp_         > swd2 is still working great, I use it with the python readline wrapper designed by 'wolfmanjm' thesedays
2025-10-22 18:57:00 <tp_         > so now I have Mecrisp-Stellaris with command history etc
2025-10-22 18:57:29 <crest_      > yeah i've nevver gotten around to implement my smart console for forth fully
2025-10-22 18:57:44 <crest_      > i wanted to have a client that autostarts it server similar to tmux
2025-10-22 18:58:00 <crest_      > (or screen for the gnu users)
2025-10-22 18:58:26 <tp_         > crest_, well the python wrapper works fine, so I have all I need
2025-10-22 18:58:29 <crest_      > that opens a single 8bit clean connection to the forth system via whatever method is specified
2025-10-22 18:59:01 <crest_      > with the idea that the server also provides semi-hosting like access to the host pc
2025-10-22 18:59:25 <crest_      > so that things like including files would work by having the forth system download the file from the host computer
2025-10-22 18:59:49 <tp_         > crest_, my next project is a SWD connected mcu info screen, (after FURS is finished and released in the next few days)
2025-10-22 19:00:39 <crest_      > as in an info screen for your host computer e.g. an e-ink or oled display for cpu temp, ram usage, network traffic?
2025-10-22 19:00:40 <tp_         > crest_, oddly uploading files has never been a issue since you wrote swdcom
2025-10-22 19:01:09 <crest_      > but i want(ed) smarted file uploading, stopping precisely on errors etc.
2025-10-22 19:01:34 <crest_      > also i wanted to support other connection types e.g. can bus, spi, nrf24l01+, etc.
2025-10-22 19:01:36 <tp_         > no, more for design, dynamic register and bitfield values displayed
2025-10-22 19:02:17 <crest_      > yeah the other thing i wanted was a swdcom / segger rtt server that works while gdb is attached
2025-10-22 19:02:32 <tp_         > Mecrisp-Stellaris does stop on errors tho :) it's not exact but that has never mattered to me as it's always obvious
2025-10-22 19:02:49 <crest_      > but the openocd segger rtt implementation sucks (slow, incomplete, buggy)
2025-10-22 19:03:11 <tp_         > is that your implementation ?
2025-10-22 19:03:18 <crest_      > no
2025-10-22 19:03:29 <crest_      > i never implemented the full rtt protocol
2025-10-22 19:03:35 <crest_      > swdcom does its own thing
2025-10-22 19:03:46 <tp_         > Im not supised as your designs work perfectly!
2025-10-22 19:04:17 <tp_         > I'm suprised that the openocd implementation is so bad
2025-10-22 19:04:19 <crest_      > e.g. i use reserved register that mecrisp stellaris doesn't use to auto-detect the buffer address instead of scanning the whole memory map (that you have to know^^) to guestimate where buffers are
2025-10-22 19:04:34 <tp_         > yeah R11 or 12 ?
2025-10-22 19:04:39 <crest_      > segger rtt is both a lot more complex (it supports multiple terminals)
2025-10-22 19:04:44 <crest_      > iirc R11
2025-10-22 19:05:05 <crest_      > because R12 has special meaning in the C ABI for far calls etc.
2025-10-22 19:05:05 <tp_         > ahh, thats what i'd need to implement my mcu info screen
2025-10-22 19:05:19 <crest_      > multiple streams?
2025-10-22 19:05:26 <tp_         > I think so
2025-10-22 19:05:37 <crest_      > how many and do they need to be interactive?
2025-10-22 19:05:38 <tp_         > one for swdcom, one for the mcu info
2025-10-22 19:05:51 <tp_         > no, they would be seperate
2025-10-22 19:06:01 <crest_      > that's not really what i asked
2025-10-22 19:06:39 <crest_      > what i meant is could you interleave the streams
2025-10-22 19:06:52 <tp_         > my concept was that Id have a config for the bitfields I wanted to see, and that would update on a 1 second interval on a second screen as I worked on the code
2025-10-22 19:06:59 <tp_         > ahh
2025-10-22 19:07:23 <crest_      > you could implement new mecrisp forth console hooks on top of the swd2 terminal.s hooks
2025-10-22 19:07:25 <tp_         > you shouldnt confuse me with a proper programmer :)
2025-10-22 19:07:50 <crest_      > e.g. using ascii control chars like shift in/shift out to multiplex between two streams
2025-10-22 19:08:21 <tp_         > thats handy to know
2025-10-22 19:08:39 <tp_         > and would probably be fine]
2025-10-22 19:09:20 <tp_         > I never need instant terminal access and as long as uploading still works properly ...
2025-10-22 19:11:37 <crest_      > have you already decided on a chip to use?
2025-10-22 19:11:52 <crest_      > will it be a cortex m3 or m4?
2025-10-22 19:12:04 <tp_         > I always use M0
2025-10-22 19:12:12 <crest_      > not even m0+?
2025-10-22 19:12:19 <tp_         > I have a huge stock of stm32f051
2025-10-22 19:12:49 <crest_      > still "stuck" on your old stock i see
2025-10-22 19:13:18 <crest_      > does it implement the pendsv and syscall exceptions?
2025-10-22 19:13:19 <tp_         > no, Id love to use the m0+ namely the STM32G030 and I do have 10 of those in 64KB flash
2025-10-22 19:13:41 <tp_         > no, the F051 is pretty retarded in that area
2025-10-22 19:13:54 <tp_         > it's even obsolete now
2025-10-22 19:14:13 <tp_         > but it's still insanely useful
2025-10-22 19:14:42 <crest_      > so you want a console and send draw commands without disrupting the console
2025-10-22 19:14:46 <crest_      > correct?
2025-10-22 19:15:27 <tp_         > the only thing I need is not to intefere with uploads (oncve started)
2025-10-22 19:15:44 <crest_      > okay here is an idea
2025-10-22 19:15:50 <crc         > updates done today: better hardware detection & reporting; bugs in input handling were fixed; auto select of default blocks partition based on label; support more than 10 disks/partitions (up to 36); clean restart of the Konilo image on stack overflow, underflow, memory boundary issues, and division by zero; added NOP instruction skipping in the ilo vm to aid in performance
2025-10-22 19:15:53 <tp_         > the console access doesnt have to be instant as I rarely use it
2025-10-22 19:16:07 <crest_      > implement the draw commands in your key hook.
2025-10-22 19:16:45 <crest_      > if you read an ASCII shift-in byte you dispatch the bytes to your draw command buffer
2025-10-22 19:17:26 <crest_      > if you see an ASCII shift-out byte you execute the draw command buffer
2025-10-22 19:18:07 <crest_      > or the other way around^^
2025-10-22 19:18:21 <tp_         > crest_, I assumed i'd need jtag/swd to access the bitfields via debug interface, same as gdb ?
2025-10-22 19:18:39 <crest_      > you could to the same kind of trick with the output
2025-10-22 19:19:13 <crest_      > and modify the console wrapping pyhton script to do what you want
2025-10-22 19:19:34 <crest_      > beware if your update rate is too high swd2 will eat a lot of host cpu cycles
2025-10-22 19:19:52 <tp_         > ahh yes, I recall
2025-10-22 19:20:00 <crest_      > because i aggressively poll the swd ring buffers via the debug probe for a few ms after something changed
2025-10-22 19:20:08 <tp_         > I do have plenty of host cpu to spare tho
2025-10-22 19:20:53 <crest_      > swd2 is just (barely) good enough to be a really fast interactive console to the forth system
2025-10-22 19:21:17 <tp_         > as in 20MHz ?
2025-10-22 19:21:42 <crest_      > with an st-link v3 it tries 24MHz swd clock
2025-10-22 19:22:00 <crest_      > and falls back to the max. an stlink v2 can do
2025-10-22 19:22:02 <tp_         > oops I meant V3 for 20Mhz
2025-10-22 19:22:24 <crest_      > iirc the v3 can clock the swd interface with 24MHz (not "just" 20MHz)
2025-10-22 19:22:24 <tp_         > I see
2025-10-22 19:22:33 <tp_         > ha
2025-10-22 19:22:43 <crest_      > the older stlink v2 (and their plentyful clones) can do up to 4MHz
2025-10-22 19:23:00 <crest_      > but they'll stretch the clock when they have to do any protocol processing
2025-10-22 19:23:13 <crest_      > because they're mostly stm32f103 (clones)
2025-10-22 19:23:18 <tp_         > thats been plenty fast enough for me so far. I havent even used the V3 units yet
2025-10-22 19:23:35 <crest_      > i did because one of my disco boards has a builtin v3
2025-10-22 19:23:57 <tp_         > the H7xx ?
2025-10-22 19:23:57 <crest_      > it's crazy how fast an stm32h7xx runs with a 24MHz console
2025-10-22 19:24:09 <tp_         > yeah, it would be
2025-10-22 19:24:31 <crest_      > you don't even see any flickering text when running words with plenty of your svd2forth words loaded
2025-10-22 19:24:44 <crest_      > it just jumps to the last screen page
2025-10-22 19:25:09 <tp_         > it's even mind bending how fast swd2 is printing a 512 char 'printf' to the terminal
2025-10-22 19:25:24 <crest_      > that's just ~1Mb/s
2025-10-22 19:25:56 <crest_      > i wanted to implement other console hooks e.g. i2c, can bus, spi, etc.
2025-10-22 19:26:04 <tp_         > yeah, but the screen upload is over before the screen finishes displaying I think
2025-10-22 19:26:06 <crest_      > but so far i've mostly used swdcom and serial
2025-10-22 19:26:45 <tp_         > yes, but serial over the swd debug
2025-10-22 19:26:59 <crest_      > for compilation speed it helps that swdcom has a ring buffer between the debug probe and the console input hooks (key?, key)
2025-10-22 19:27:20 <crest_      > so swd2 can upload bytes into the ring buffer while the forth system compiles
2025-10-22 19:27:23 <tp_         > the second you start using a std peripheral wont that slow everything down ?
2025-10-22 19:27:39 <crest_      > depending on the peripheral it can be even faster
2025-10-22 19:27:57 <crest_      > i've pushed the stm32f103 high speed uart all the way to 4.5Mbaud
2025-10-22 19:28:11 <tp_         > oh yeah, Ive just recalled how fast USB is on the 103!
2025-10-22 19:28:30 <crest_      > i didn't write the f103 usb driver
2025-10-22 19:28:43 <tp_         > it's actually seems as fast as swd2
2025-10-22 19:28:58 <crest_      > with the right serial driver (double buffered DMA, line idle interrupt, etc.) the serial port can be as fast or faster than usb full speed in real life
2025-10-22 19:29:09 <tp_         > I know. that driver has been worked on by a few people
2025-10-22 19:29:41 <crest_      > i hacked together a fancy stm32f1xx serial driver that uses the DMA engine to keep the UART fed
2025-10-22 19:29:50 <tp_         > that driver was initally written by mitch bradley for the OLPC project iirc
2025-10-22 19:29:54 <crest_      > because STM32 UARTs aren't meant to be used interrupt driven
2025-10-22 19:30:19 <crest_      > all but the low-speed ones that can wake up the chips from sleep lack FIFOs
2025-10-22 19:30:46 <crest_      > you only have a single frame (aka byte) uart receive/transmit buffer
2025-10-22 19:31:04 <tp_         > I wouldnet be constrained by the F103, that thing while still fast is pretty old
2025-10-22 19:31:11 <crest_      > so either you have to poll them like crazy or accept stupid interrupt rates to use them without DMA at higher baud rates
2025-10-22 19:31:28 <tp_         > why develop for the F103 ?
2025-10-22 19:31:37 <crest_      > because at the time i didn't know better
2025-10-22 19:31:49 <crest_      > i wanted a cheap chip i kinda knew that has can bus
2025-10-22 19:32:11 <crest_      > but the can bus and usb share the same dual ported sram bank as buffer on the f103
2025-10-22 19:32:20 <crest_      > so you can't use them at the same time
2025-10-22 19:32:42 <tp_         > oh, or is it allSTM32 uarts ?
2025-10-22 19:32:43 <crest_      > also i wanted to protect the host system from voltage spikes on the can bus
2025-10-22 19:32:43 <tp_         > the only advantage I can see to the F103 is all the clones coming out of china, such as the APM32F103, available and cheap
2025-10-22 19:33:01 <crest_      > so the idea was to get a good enough opto coupler for the uart rx/tx lines
2025-10-22 19:33:14 <tp_         > but the STM32G030 is in 40nm node and pretty cheap now
2025-10-22 19:33:32 <tp_         > ahh, I see
2025-10-22 19:33:38 <crest_      > because that's a lot easier to isolate than usb or swd which happen to be half duplex (data goes both directions on the same pin)
2025-10-22 19:34:04 <crest_      > sure you can buy fancy usb protection devices
2025-10-22 19:34:06 <tp_         > and 40nm nodes arent as 'analog friendly' as 90nm
2025-10-22 19:34:22 <crest_      > and there are debuggers that claim to have protected pins
2025-10-22 19:34:47 <crest_      > but a random ~10MHz opto coupler from the parts bin is so much cheaper and easier
2025-10-22 19:34:48 <tp_         > yeah a real issue on CAN bus I guess
2025-10-22 19:35:13 <crest_      > especially when you it as a bus for a hackerspace
2025-10-22 19:35:29 <crest_      > and let other idiots build their own devices to hook to the bus
2025-10-22 19:35:30 <tp_         > you used CAN for controil inside a building, right, not automotive ?
2025-10-22 19:35:53 <tp_         > hackerspace, yes I recall now
2025-10-22 19:36:00 <crest_      > frigde door status, lights, etc.
2025-10-22 19:36:06 <tp_         > no wonder you needed all that protection
2025-10-22 19:36:20 <crest_      > and the host pc was the primary file server
2025-10-22 19:36:31 <tp_         > it's only a matter of time before someone put mains onto that bus
2025-10-22 19:37:05 <tp_         > Ive blown up 8 seperate PC's with mains on the ethernet, wasnt a good look
2025-10-22 19:37:09 <crest_      > i didn't want some idiot frying the file server just because they couldn't be assed to unplug something before they short things with multimeter probes
2025-10-22 19:37:21 <tp_         > it's even easier than that
2025-10-22 19:37:38 <crest_      > you should've learned better the 7th time :-P
2025-10-22 19:38:01 <tp_         > all it takes is making a mains extension lead and accidentally reversing the active and earth
2025-10-22 19:38:17 <tp_         > I did them all at once
2025-10-22 19:38:26 <crest_      > i assumed as much :-P
2025-10-22 19:38:27 <tp_         > every pc in the building
2025-10-22 19:39:02 <crest_      > just wanted to mess with you
2025-10-22 19:39:03 <tp_         > it was a coax network at the time, (1994 ish)
2025-10-22 19:39:51 <tp_         > dont torment us old people, we have had enough already ;)
2025-10-22 19:40:29 <tp_         > the screams from the users was kinda interesting tho
2025-10-22 19:40:53 <crest_      > i may be younger, but i still grew up with thin net and apple talk over phone lines before that
2025-10-22 19:41:17 <tp_         > many said that it was like a 'angle grinder' at the back of their pc's as the coax connectors all melted
2025-10-22 19:41:18 <crest_      > i've never used thick net in anger
2025-10-22 19:41:50 <tp_         > was just RG502 or something like that
2025-10-22 19:42:28 <tp_         > Ive installed university backbones on coax that was so large I had to drill a hole in it for the 'vampire connector'
2025-10-22 19:42:55 <tp_         > ethernet has indeed come a very long way
2025-10-22 20:24:06 <cleobuline  > forthBot:  LOAD ini.fth
2025-10-22 20:24:06 <forthBot    > File ini.fth with MOON  loaded
2025-10-22 20:24:15 <cleobuline  > forthBot:  MOON
2025-10-22 20:24:15 <forthBot    > Phase de la lune pour Wed October 22 2025
2025-10-22 20:24:15 <forthBot    > 🌒 Croissant montant Une jeune lune, un nouveau depart a Paris ! Illumination 1%
2025-10-22 20:32:00 <lmt         > 🥐
2025-10-22 21:04:45 <tp_         > veltas, I asked a AI to compare my FURS efficiency to using the default 'base address + offset" method and it agreed that FURS  is better for small embedded mcu's "Bottom line:
2025-10-22 21:04:46 <tp_         > For the STM32F051 (64 kB flash) FURS **always** saves flash unless your application literally configures **every** register and bit-field in the entire peripheral set. Even then the break-even is ~14800 accesses, which is far beyond typical usage. Therefore FURS absolute-address mode is strongly recommended for this part."'s
2025-10-22 22:24:15 <forthBot    > Environment for cleobuline inactive, freeing...
2025-10-22 22:44:37 <cleobuline  > brave forthBot ...