Y'know... I love the warm, undersaturated appearance of photos on my Pebble Time 2. It's such a cheerfully shit display, it reminds me of the display on my color Sony Clie circa 2000, when we were just impressed that it was color at all.
I feel like we could use more displays with an aesthetic other than "150% of sRGB" or whatever.
...this is totally what my parents sounded like when they said vinyl sounded better isn't it 💀
Tempted to move my storage server over to NetBSD for funsies, but it looks like it doesn't support ZFS encryption? Currently I'm running ZFS-over-LUKS and I'd sure love to move to standard OpenZFS-style encryption.
The words related to bootstrapping using a target system (in this case, an emulator) have historically been in <angle> <brackets> but... angle brackets are so fricking unreliable to type on the PicoCalc that I just might change that!
This is how you wind up with C-style names isn't it
The machine is still running on the Icoboard tethered to the PicoCalc with dupont wires, because I haven't finished my FPGA replacement brain.
It's emulating itself in software because of my Turducken approach that I mentioned recently (see the docs in the repo). There's actually a second core in the FPGA that I could use instead; doing it this way cuts the time to something like 10 seconds, last I measured.
I asserted yesterday that the Forth sources I was viewing on the PicoCalc were the system sources, and you "could" recompile them and reboot.
Well, here's what it looks like to do so!
Enjoy this riveting 90 second video of a 40 MHz CFM CPU emulating itself in software, recompiling the operating system. Also, me typing on the world's worst keyboard. (Seriously. The PicoCalc's keyboard is a torture device.)
RE: https://hachyderm.io/@rain/117446083340236126
This is why, when people say things like "omg the LLM can generate an embedded kernel for me!!!" I can't help but think
"Yeah, it was trained on _at least_ three of mine, plus immeasurable training load on my webserver serving the docs."
By claiming ownership of the result, or even just claiming to have managed the machine while it spit it out, you're basically just stripping all attribution for the actual work that went into its inputs. You might as well just clone my repo, remove the license, and remove my name. So no, I am not impressed.
Anyway, Anthropic just ripped off a bunch of Rain's work with no attribution, as they do.
Wrote a simple source browser for CFM on PicoCalc! Now you can easily scroll through the system sources. Both directions, fast, thanks to some careful use of the LCD controller.
That's the actual source of the running system, btw. You could change it, recompile, and reboot, without a bigger computer.
I'm color coding screens by index to make it easier to see the boundaries.
Also, kicad on a 10" display is Not Great but workable.
So there's this thing I've been wanting, and can't find for purchase, so I guess I've gotta make it.
The Pi Pico has become a de-facto standard for "microcontroller you plug into something." But what if you want to make the CPU yourself?
There are plenty of boards that have an RP2xxx chip _and_ an FPGA, but they generally have a different pinout. I haven't been able to find one that's _just_ an FPGA and has the right pinout.
So, here's 5k LUTs, 128 kiB of SRAM, and several meg of flash. I'm hoping to put this in my PicoCalc so that it runs my CPUs natively.
It seems deeply ironic that my attempts to load the SF Permacomputing mailing list archive fail, because the proof-of-work requirement pegs the CPU on my low-end laptop for at least a minute before I just close the tab to conserve battery.
Oh well.
Well hello! Almost didn't see you there.
(It's like 5cm across, on a window mullion on the outside of my shed)
Awwww yeeeeah smooth scrolling
(The ILI9xxx parts can be programmed to display with an offset in vram, poke that carefully from a loop and you get this! This was a single line of code change because Forth.)
Alright, I figured out some of the reasons why my display repaints are faster than others'. (Not everyone's -- there are some very fast demos on YouTube, source unavailable.)
A meme appears to have spread that the ILI9488 doesn't support 16-bit color mode in 4-wire SPI mode, only 24-bit. So these applications are sending 50% more bits than I am.
The meme seems to stem from an error in a diagram in the datasheet, but the datasheet _text_ says it's supported, and it's what I've always used.
I wonder if I should send some PRs to people.
This board's running CFM1 at 40MHz, and repainting the display text is significantly faster than most of the demos running on the 150 MHz RP2xxx board that came with it. (I read over the code people are using, and it misses a lot of optimization opportunities.)
Theoretical minimum time required to repaint the full display: 81 ms.
My mostly-unoptimized prototype routine (some of which is being displayed on the screen there) is taking: 85 ms.
Okay, this is decent. I have a habit of doing "high-waisted" capital forms to match high x-height, which gives the face a bit of a Charles Rennie Mackintosh vibe, but I feel like the 8 needs opened more to distinguish it from the 0.
This is a 16 bit color display, so there's no reason the default palette can't be Catppuccin. 😻
(Edit: goddamn I _always_ get Mackintosh's first name wrong by cross-wiring him with John Rennie of cast-iron fame.)
Got some text rendering working from forth on CFM.
I wanted to be able to show a full 64 column traditional Forth screen on the display, but at only 320 pixels wide, that means 5 pixels per character horizontally, which is not a lot. So I've drawn a halfway readable tiny font.
The PicoCalc is an ILI94xx series LCD controller, a chip I know well. With some care you can get vertical text for free.
After several people suggested not using Wayland with Kicad, I've been testing more carefully with Sway. So far I'm quite happy with it.
Setting `focus_on_window_activation smart` fixed KiCad's attempts to change window focus -- the defaults on Sway don't let applications do this to prevent focus-stealing.
Sway places KiCad's windows in reasonable places, instead of KiCad's X behavior which involves placing them off the screen in random locations. (KiCad considers this to be a Wayland bug; I consider this to be a feature. To each their own.)
The only remaining thing I keep hitting is that keyboard modifiers aren't attached to scroll events sent to unfocused windows. This isn't a Wayland limitation, but a Sway issue -- it's explained in https://github.com/swaywm/sway/issues/9233
Platform: Arch (Linux)
Environment: Sway (Wayland)
No I do not have an input manager/method running
Yes I poked around in the settings looking for anything that appeared relevant
This is a fresh install on a new machine without imported settings from any previous install. (So it might be something I turned off in an earlier version?)
Any KiCad 10 users out there who can tell me why pressing a key repeatedly, fast, only recognizes the first press until a delay elapses?
(Edit: I appear to have gotten 10.0.5 which has an input bug! Thanks @remmy )
Like, open schematic, select item, start moving, then press R-R-R to rotate it three times... it rotates only once if you press too quickly. Some kind of type-ahead search in the hotkey mechanism maybe?
The part that really bothers me is that this affects cursor keys, when nudging things around manually. Have to press. them. slowly.
(answers to some of the likely questions in the replies)
In honor of Spooky Season, a PicoCalc horror vignette!
"Oh I see you've got a graphics thing running on your PicoCalc, let me just ... oh ... oh no ... WHERE IS ITS BRAIN‽ YOU MONSTER 😱"
(I thought it would be a nice body for my Forth machine, so I'm prototyping before building a Pico-sized module)