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 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.
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)
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)
Also missing from that blog post but important:
As usual, Oxide raised the salary when we took more money, so some of that profit is going back to us workers. (Not all of it, obviously, Oxide is a VC-funded corporation, but some of it.)
Since the salary's on the website, you could have noticed this for yourself, so I figure there's no harm in pointing it out.
I feel like Bryan's blog post buries the lede a little bit here with its choice of headline -- yeah Oxide took more money, but, the important thing is why:
We've been quietly profitable since the start of the year and have been receiving more orders than we can fill.
In this current economy of "give me more money so I can light it on fire" and companies filing to IPO proud to spend $3 to make $1, it's nice to be able to tell investors "if you give us some more money, we will make it a larger number in the near future."
Anyway, please subscribe to my Substack to get more breaking news on protocols from 1977. 😉
I'm not sure which of you needs to hear this, but:
lrzsz-sx has at some point started defaulting to YMODEM. You have to add -X to get actual OG XMODEM.
Yeah, no idea. But that's why your firmware transfer is failing.