Pinned post

...at least I know who I was when I got up this morning, but I think I must have been changed several times since then...

Pinned post

I design software and hardware systems. I've worked on orbital launch vehicles and satellites. I can talk about "space stuff" all day. I design sub-sea ROV systems for fun.

One day hacking on gateware, the next a byte-code interpreter, the next a PCB, the next a Linux kernel driver, etc. I wrote game engines for a time.

I'm recurrently obsessed with artificial general intelligence (Goertzel-like formulations), artificial life, computational behavior (not ML).

I recently installed Gitea gitea.io/ and was pleasantly surprized. A really nice self-hosted git hub solution.

Encouraging first power up! (pardon the ugly display photo -- phone camera and monitor did not get along -- zx81+38 is hooked up via a $12 composite->hdmi adapter).

#hw #zx81 #zx81plus38 #projects #whee

@swetland @trevorflowers FWIW due to the way freecad constructs hexagons (bunch o constraints), this number of features practically made freecad fall on its face. [a panel with a vent I hat cut a few months ago]

Ok, I now have permission to talk about this project in full and in public. I'm working with Alan Kay to build six replicas* of a Xerox PARC Alto display for use in a museum exhibit**. Visitors will see a real Alto and then walk over to one of the replicas to futz with Smalltalk '78***.
Here's a nice writeup of a different project that rejuvenated an actual Alto.
arstechnica.com/gadgets/2016/0

Got a 12 mile trail run in. Set my watch to keep me in Z2 which meant a lot of walking.

So, you might be asking "Brian, what's with the pile of DIP ICs on your kitchen counter," to which I would say, "well, have you seen this project re-creating a Sinclair ZX81 using discrete chips instead of the ULA? It's pretty cool!"

forums.raspberrypi.com/viewtop
github.com/mahjongg2/ZX81plus3
revspace.nl/images/9/94/ZX81pl

#hw #projects #zx81 #zx81plus38

Cleaning up the lab a bit and came across this old size test for a phone project. Turns out...
Great minds, amirite?

I wonder how many kernel patches are like "this other party fork is impossible to merge but they fixed this one thing for which I am including the patch" ... or is that... uncouth?

Show thread

Turned out there were no locks around the atomic commit so it was only atomic if it page flipping was synchronous. If another commit came in it would clobber the commit obj and/or abandon the completion event. Vendor solution in the unholy fork was to disable async page flipping to a terrible performance hit. But they also actually fixed the bug later. :facepalm:

Show thread

Well, this seems like a race condition. If I turn up drm.debug in sysfs, no memory gets leaked. Heisenbugs [sigh]

Show thread

This seems incredible on mainline though. Current theory is ioctl for page flip seems to perhaps be leaking `struct drm_pending_vblank_event` (bleeding kmalloc-64 slabs). Perhaps a missing send_event* ... maybe based on vblank + async combination.

Show thread

f'realz tho...

# grep drm_atomic_helper_commit /sys/kernel/debug/kmemleak | wc -l

51838

Show thread

Well, I'm at the
# cat /sys/kernel/debug/kmemleak
par of my day.
I guess it's my turn to be "it's a kernel bug!" guy.

Spent two hours or more trying to update a vendor's long running unholy Linux kernel fork before realizing it was quicker and simpler to take mainline and patch in the vendor files from the unholy fork. Why are vendors like this? [sigh]

Show older
m.hzrd.us

private hzrd.us mastodon instance