So I don't carry a smartphone with me for a mixture of reasons. Privacy obviously, I don't think at this point that needs spelling out. Environmental concerns are high up for me, though. Having to buy a new device every few years is not environmentally friendly. When I went looking for an alternative I looked at (and tried) a lot of things, but landed on a weird option.

The ClockworkPi uConsole looks cool. I get told it looks "cyberpunk" a lot. Thats... nice, but not the point. It is all metal, made of modular boards and has published schematics. It is powered by 2 18650 batteries and even has space in the case for an expansion board you can buy or build yourself. Durability, modularity, expandability. It is a really nice device.

This post isn't about the uConsole itself, but about an addon I built for and the challenges getting that addon working reliably. While ClockworkPi ships an internal 4G modem for the uConsole, and while I was able to get my hands on one, I wound up not using it. The T-Mobile 4G sunset is coming up next year. I don't like doing projects that only last a year or so, and getting the 4G modem working reliably would be a project. Also, I needed the 2nd USB port on the expansion connector exposed so I could connect my camera to it.

My solution was to get a 5G USB modem and use that velcro'd to the back of the case. To do this, though, I wanted a USB port that I could turn on and off in software. I don't need the modem anywhere I have wifi. The first version of this board was a bunch of parts hot glued to the blank 4G card that ships with the uConsole. It worked... not well, but it proved out that the idea was feasible if I could get past one error message.

[21351.442444] usb usb1-port1: disabled by hub (EMI?), re-enabling...

I would get runs of 10s of this message and afterword the USB hub on the uConsole motherboard would be unstable. Some connected devices like the keyboard would recover after a timeout, others (like the camera or my lapdock) would not work again until a power cycle. Clearly something had happened to make the hub unstable. Finding out what that was, and fixing it, took me down a months long rabbit hole that I will now describe.

The first and most obvious problem was construction. The prototype was a mess of wires, break out boards and hot glue. After the first tests I got to work designing a proper PCB. It needed to be thin to fit into the uConole's expansion connector, so I use OSH Park's 0.8mm 2oz process. That worked out great, the boards fit perfectly. I kept the design simple, 90 ohm diff paris for the external USB connector and camera and a TPS61023 breakout board to provide power to the external USB. I added this because it will fall back to pass through mode if the input is 5v, but boost if there is a dip. I had thought that a dip on the supply going to the modem might account for the errors, so I wanted to make sure that wasn't the case.

The first board was better, I got fewer errors, but they did not go away. When they happened I would still loose the camera, so the instability was still there. I tried different USB-C cables connected to the modem but that wasn't it. Then I made a fateful discovery, if I connected the modem to the uConsole's USB-A port I still got the error. This ruled out my board, but not the modem or the uConsole. If I connected the modem to another computer, though, I couldn't repoduce the error there. That pointed to the uConsole.

I spent a lot of time looking at the schematic. A lot of time. The problem wasn't obvious at all, but I did find it. The USB hub on the uConsle is a GL850G. This chip has it's own LDO for generating it 3.3v power rail from an existing 5v rail. This is useful if it is being used an external hub, but for some reason it is being powered that way on the uConsole even though the PMIC generates a 3.3v rail. Worse, the 5v rail doesn't have any dedicated capacitor feeding that LDO. Any small dip on the rail will push the LDO out of regulation. At first I experimented with added an 220uF cap to the 5v rail right at the hub. This improved the situation a lot, I got fewer errors and they didn't always result in the hub becoming unstable. I thought I solved it, until eventually the camera disappeared.

I knew I was on to something though, so I removed that mod and lifted pin 23 on the hub (the 5V input) and powered the hub from the 3.3v rail generated by the PMIC by connecting the supply side of C505 and C143 together. Thats actually a really small run of magnet wire on top of the board. Again the situation improved. I went all through SakruaCon with a working modem, but not a working camera. It would still drop out.

Solving layered problems starts with figuring out that the problem is in fact layered. Its easy to see the results and think the lack of progress is due to not going far enough when instead the real problem is somewhere else entirely. To be sure, the USB hub power was a problem and I encourage all uConsole owners facing USB stability issues to make that mod. It was not, however, the only problem.

I didn't include an ESD diode pack on the initial design of my board. This was an oversight due to rushing too much, but when I started on a redesign I added one. ESD could definatly cause the USB hub to go unstable, and since this thing lives it's life in my purse or pocket its going to encounter static. I got this new board in and to my surprise things got worse. It would work fine and then I would get a raft of that same error. I was watching dmesg the other evening and found the other culprit, if I flexed the connector on this new board just a little it would produce errors.

This may not have been a problem on the first PCB. These USB-C connectors are hard to solder down with just an iron and hot air. I got another USB-C cable that didn't stick out from the case and have been testing with that for the last 3 days without issue. No error messages, no drop outs, camera has worked the whole time.

This wasn't one problem, it was multiple problems that all generated the same error message. Ironically, EMI wasn't even one of the problems even though the kernel message hints at it. Working these kinds of problems its easy to be led astray or get tunnel vision on one aspect of the problem an miss other factors that might be leading to the fault. We have to step back and look at the whole system periodically to regain the context the fault happens in.

While we were at SakuraCon this year I saw some animated gif badges and backpacks. Its a simple idea, you load animations on to them and they play while hooked onto your backpack. I asked about them and found out that they don't use a microsd card, instead you have to use an app to upload pictures to them and they only hold a handfull of images. Not having one of those I decided the best option was to make my own badge that loaded images from a microsd card.

I went looking for parts initially with the intention of building the whole thing myself. However, I quickly came across this Waveshare ESP32 AMOLED display. It has everything I wanted to build myself onboard and even more. Waveshare dev boards dont ship with batteries, but they did list the size of battery that would fit in the case so I picked some of those up as well.

On the software front I went looking for a library to decode GIFs on esp32 and stumbled across this project that does almost everything I wanted and targets the waveshare hardware. Great minds think alike I guess. There are some featues I want to add when I get time, but for now it covers the main points. It plays gifs from a microsd card, has playlist support, and can play one gif after the other.

With those two down there was one last hurdle. The gifs need to be unoptimized and rotated for use on the device (I'm using it in a wide orientation). The ESP32 doesn't have enough RAM to handle unoptimized gifs. I can run the commands easily enough to do that conversion, but my family is non-techinical. They needed a simpler interface to do that (I made one for my husband and son). So I whipped up this interface in a couple of hours that can take a video file or gif and apply the correct conversions so that it will play correctly on the badge. I called it GifMaker.

This was a fun little project that was helped along by the work of others. It was really neat to see other people working on the same thing I was. I'm overall really happy with the badge, it gets a little over two hours run time on a charge. I might add shuffle mode, and maybe wifi image upload. We'll see how my free time shakes out.

Running htop:

I couldn't keep that computer. We had to move various times and I had to pair down my hoard of machines (garage sales in the late 80s and 90s were great) down to just the most essential. I've looked now and then for Altos 580s and ADDS Viewpoint terminals on the various auction sites, but never had much luck. The Altos is unobtainum, and the ADDS terminals go for a lot. Until I saw one for a price I could pay on Goodwill's auction site. I managed to snag it and I will say they did a great job shipping it. The protection for the CRT was quite good. It gave me a cursor when I powered it up, but I couldn't get it to respond to serial data or to transmit.

Logging into the ICM's vintage system menu:

The PCB inside was covered in bodge wires. I'm not actually sure whats going on with it. It seems stuck on 110 baud. Thats lower than my USB to RS232 converters will go, but at 300 baud you could at least see something happening. I started gearing up to debug the board when a set of 4 PCBs for the Viewpoint 3a landed on ebay. I snatched them up quick. Lo and behold the first one I tried worked. I could receive, but not transmit. Turns out this keyboard is a Keytronics with the dreaded foam and foil keypads. I got a set of replacements from TexElec. These are not fun to replace, but the replacement pads are great quality. This fixed the keyboard and now I was able to transmit and receive just fine.

I'm in

My ultimate goal is to build a homebrew Z80 CP/M computer to run with this when I take it to events. A replica of my original computing environment. Maybe one day I'll find another Altos 580, but they are frankly huge and I wouldn't have anywhere to put one right now. I might even try to finish that first project, an ASCII version of SMB. Maybe just the first level. This terminal has enough control codes to support curses well enough. Vim and htop run fine. Time will tell.

This website in lynx:

It was time for the upgrade. Intraspace is a nice cozy venue, but we were clearly maxing it out with the number of exhibits and visitors.

This year all photos were taken on a Sony FDMavica MVC-FD75. All images stored to and retrieved from 3.5" floppy disk. The setup this year was similar to last, with the addidion of the PowerBook 2300c I restored.

The Atari needed a quick patch, Ive had trouble with the mini-din connector for the RGB+S video, the wires will touch and I'll loose a color channel. I need to make a PCB for that, but time is the enemy.

I also had a little trouble with wifi on the 2300c. The wifi selector DA kept locking up the system. I found if I disabled extensions at startup it was more stable but it crashed once even then. I feel the call of MPW, maybe I'll put this bug on my list of projects. Still, I did get it on the network.

The Ultra 2 performed flawlessly and had several people logged in to it over the network at once while I was watching The Matrix on it.

I also got career advice about becoming a DOS programmer which I promptly ignored and went back to C on classic MacOS.

And someone brought a LISP machine. Space cadet keyboard and all.

Unfortunately it suffered a disk problem and wasn't running for long, so I didn't get to play with it. Hopefully it will be back for VCF PNW.

I'm really excited to see this event grow. I had a ton of fun explaining my computers to visitors and talking with others about their machines. Its great to see how many people care about keeping these machines running and not just dead objects in a museum. I think the modern web has a lot to relearn from the past web and I'm glad we're keeping that alive.

My machines at the table shared with SRCS:

FurryTel:

Project Ivy:

X Terminals hosted by a VAX:

Compu-Global-Hyper-Mega-Net:

VintageLink:

The SDF logo print hanging over my workbench:

Even though I'm a dyed-in-the-wool Linux user, I have a history with Sun machines. I picked up a Sparc 20 back in college and even made a friend because of it. I had various bits of Sun kit for a long time and ran Linux on most of them. Life happened, I dont have any of that kit anymore. My first real industry job was as a Solaris system administrator. I had one of the newer Sparcs for a desktop (A 30 at first, I think, and then at 45 at the end) and had one of those SunPCI cards for it. It was clear, even at the time, that Sun was on its way out. PC architecture servers were eating up the market share of those old dedicated UNIX machines.

Since the old Sparc workstations (the 1 through 20) were called pizza boxes due to their shape, I've affectionately named this machine DeepDish. Its a double height case in the same style as those so it seemed fitting. Its also a bit of a Hitchhikers Guide reference. I bought all new caps for the PSU and replaced them, but still couldnt get the supply to start up. One of the caps leaked badly, and in a dense part of the board. Some component legs showed signs of corrosion, and that can creep up and into the plastic package of the component and eat it from the inside. I feel I can fix it with more time, but the ICF is coming up and I have a long ways to go on this machine so I got a replacement PSU on ebay.

The new PSU works and with that sorted I turned to cleanup. It was amazingly dusty. After a good clean and a reseat of all cards I got a green power light on the motherboard and diagnostic output from the serial port. It reports both CPUs working and all RAM available, so thats a good sign. I picked up a Creator3D card since this machine sports the Creator3D badge on the front. Thats where I'm currently at, since I dont have the right kind of 13W3 adapter for it. Note to others getting into Sun hardware, the UPA video cards use the SGI style DDC pinout on their 13W3 ports, not the Sun standard. Who knows why. I got one of those configurable 13W3 to VGA adapters with the dip switches to try and get around the problem, I'll post updates once thats in.

Life happens and I had to get rid of that machine in a move in the 90s. A few years ago, though, I came across one with a 1050 drive for a reasonable price at a retro gaming convention and grabbed it. Since then I've turned it into the maximally upgraded example of an 800XL. Rapidus 65816 upgrade with 16mb of SDRAM, Ultimate 1mb upgrade card, VBXL video upgrade, FujiNet and SIDE3 (kinda wish I had gone with SIDE2 or an AVG cart, but it works).

That wasnt enough though. I had a very powerful 8/16 bit machine now, but it sat o my bench unused most of the time. It annoyed me and so I decided I would find some way to put the machine to daily use. As a keyboard. Now, put the pitchforks down, I would never harm my beloved 800XL by gutting it. Instead I came up with a weird plan.

The 800XL has a FastBasic program running on it that captures keystrokes out of the Pokey registers, adds the state of the right hand buttons and control/shift, and sends that as two bytes to my PC. On the PC is a python script that takes the bytes in, uses a cofiguration file to decode them into PC keycodes and injects them into the Linux uinput stack as keypresses. This is all enabled by the FujiNet, which lets me open a TCP socket to my PC over wifi. Currently the protocol itself has no encryption, but it is wrapped in the WPA2 encryption of the wifi connection.

This setup is great, honestly, and I've been using it for months. There are a few catches, though. Firstly, the Pokey only shows one keypress (and two modifiers) at a time. No rollover. This makes the software unuseable for gaming. Sorry die hard FPS players. Secondly, if you run a keyboard-heavy setup, you might find the lack of modifiers limiting. I use sway for a compositor and I've taken to using the right hand buttons as additional modifiers. Third, some things dont seem to play nicely with uinput. Particularly old games emulated in wine seem to have some kind of issue processing keystrokes this way. Sorry Warhammer 40K: Dawn of War fans (myself included).

I've mentioned this setup to a few people in the local retrocomputing community and have gotten some interest, so I'll be publishing the code in the next day or two (when I figure out where to host it) for others to use.

Doing this has definitely changed how I approach computing. Starting out I had a laptop, a couple of older monitors and several ARM Linux boards acting as servers for various locally hosted services. Now I use three Android devices as my computers, and the servers have been reduced down to one and all of the locally hosted services are gone with the exception of Home Assistant.

A big eye opener was when I spun up a locally hosted Pleroma instance and tried to run it from solar power. One cloudy day was all it took for my 1.2 KWH of battery to be almost completely empty. While I understand the push on the privacy side to move to self hosted web applications, I feel like its not practical from an energy perspective. Beyond that there are discussions about security and abelism that aren't happening as much as they need to.

I've moved to as much of a "mesh" infrastructure as I can as an alternative. My git repositories are hosted on a folder that gets synced to my devices using syncthing, negating the need for a service like Gitea to be running. I likewise use DecSync to sync my contacts and calendars to other devices. While fine in those applications I know from experience that messaging/microblogging isn't really feasible in a mesh architecture. Even if we had reliable and well established protocols to handle the data, we would still have to find some way to deal with the energy requirements of each node processing all of that data.

Looking back its been interesting to see how I've adapted to use as little energy as possible in ways I wouldn't have considered before. I feel like practical experience is an overlooked way of solving engineering problems. It will be interesting to see how I need to adapt when I move to a less sunny climate.

It only took about 10 pages to win me over. First off, the cover does not do the art justice. Where I went in expecting a predictable and cookie cutter style, I found the characters to be well defined and possessing a wide range of expression. The vampiric tropes aren't present for the most part, no bursting into flames in the sun, no garlic issues, and not supernatural. They don't even like being called vampires. Aria, the vampire love interest, isn't dark or brooding. She is revealed to be in the range of a hundred or more years old and seemed to have some kind of relationship with the protagonist, Ichika's, grandmother.

What really won me over was the depiction of Ichika's interest in Aria. A lot of otherwise good Yuri manga can't seem to grapple with wanting to portray a lesbian relationship positively while also acknowledging that this isn't currently seen as normal by a lot of people. Some just don't ever depict any kind of pushback whatsoever which leads to a story that seems too much a fantasy. Some spend the whole story overcoming that pushback to then come to a screeching halt before any actual relationship develops. Vampeerz does not do this, Ichika recognizes that there will be pushback but decides her new love for Aria is too strong and she just leans in to it.

Another unexpected highlight is Sakuya, Aria's mother. Anyone who knows me will know that I love characters that are unabashedly open about their desires, and Sakuya is just that. She winds up as the school nurse, and in a hilarious scene that has Ichika and Aria going to the nurse Aria has to stop Ichika from seeing into the room because her mother has her legs spread, feet on the desk, drunk and looking at her laptop. I'm positive the implication was that she got caught masturbating and I genuinely laughed out loud.

I want more, the story is just getting started by the end of the second volume and I feel like its set up a great cast and premise. Depressingly I noted that the second volume was published in December of 2022 so I'm hoping this series doesn't just fade away.