• What if I replaced Google Photos? (1/x)

    Years and years ago, as I started using operating systems besides Mac OS X full time, I decided to let go of iPhoto and start doing my photo management elsewhere. I ended up on Google Photos for a few big reasons. One, the launch photo editing was pretty amazing. Two, since the primary interface was web-based, it was easy to use pretty much anywhere. Three, since most of my photos were coming from my phone by that time, having it auto-upload from my phone was pretty amazing.

    Some time has passed, and I’m starting to get that itch again. I still use Android as my primary mobile OS, but I’m less trusting of Google both from a privacy standpoint and a feature standpoint. They absolutely have the ability to mine through my data, even if I am paying for the storage. They also have a terrible track record of removing features and functionality that they feel doesn’t get a lot of traction.

    So, I have a home file server, I have outside cloud backup, maybe the landscape is better now for multi-device photo management than it once was. I’m going to explore.

    What do I want?

    There are some hard points that I like about Google Photos that I’d like out of any solution, and then there’s other functionality that I’d really like to have but wouldn’t stop me from migrating. I’m open to both open source and proprietary solutions, provided the proprietary solution doesn’t limit me to the consuming platform.

    Must have

    • Photos should sync to the destination without me performing the action manually
    • Photos could be viewed, added, or removed from a web interface
    • Albums could be created, viewed, or removed — and photos could be moved in and out from a web interface
    • I should be able to download images locally from that interface
    • Basic categorization should exist automatically…
    • … and in particular, automatic facial recognition should exist and be navigable

    Nice to have

    • Open source
    • Does not require a separate cloud service
    • A server side agent that works on FreeBSD
    • A native application for Android and/or iOS for faster, fluent navigation
    • Google Photos is pretty good at determining other objects, words, and locations from photos, and I’d like to see something similar. For instance, searching for “green”, or searching for “car”
    • Location categorization for determining where photos were taken
    • Video organization along with photo organization
    • Automatic file organization, similar to iPhoto, to make it easier to export, back up, and avoid collision
    • Duplicate detection, in case two photo sources get mixed up
    • Public sharing of photos or albums, to allow those with a certain link to view certain photos without giving away everything

    Where to from here

    At the time of this post, without veering off to other solutions, these are the ones I’m going to be looking at, in alphabetical order:

    • Adobe Lightroom (proprietary, requires subscription)
    • LibrePhotos (open source)
    • Mylio (proprietary, requires subscription, potentially allows for self hosting images)
    • Photonix (open source)
    • PhotoPrism (open source)
    • Piwigo (open source)

    Auto syncing from my phone

    While some of the solutions I’ll be looking at have some capacity for auto sync from my phone, I wanted to at least have a solution to get photos from my phone to my file server without having to mess around with it.

    Enter Syncthing

    Syncthing provides bidirectional or unidirectional sync between folders on two different devices. In some cases, this could be a documents folder on your laptop and your desktop, or maybe important files between work and home. They have agents for Windows, Linux, macOS, the various BSDs, and even Solaris. Even better, they have a first party client for Android. A third party is currently working on an iOS client that will likely cost some money to use.

    I was able to set up my file server and my Pixel 4 very easily, and was able to point the Pixel at the QR code from the file server’s web interface to link up the two devices. By default, the Android client is set up to send pictures one way from the camera folder to another device, so it was a matter of flipping the switch to enable it, and authorizing the connection from the file server and setting the destination folder. All of the NAT traversal was automatic, and within a few minutes, all of the photos from my phone were safely on my file server.

    That seems like a good starting point to me, I’ll worry about a Google Photos export once I find a decent solution.

    More to come.

  • The Ongoing Saga of this Commodore B128 (3/x)

    In the last post, I ended up desoldering some components that I thought could be a problem, only to find that they appear to be just fine. I moved on to second guess my assumptions due to my experience level, specifically wondering about whether these address and data lines are correct. I then sent off all of my socketed chips to another member of the Commodore CBM-II community to see what he thinks.

    Oh, ho, ho.

    My new Commodore friend popped my 6509 CPU, 6526A CIA, PLA, and 3 ROMs into one of his test boards to verify functionality. My ROMs and PLA successfully ran for an hour of diagnostics. My CIA checked out okay (but looked quite different than the CIAs he had). My 6509… was toast. In two different machines, it hung up before it could even hit diagnostics. I don’t know for sure if what he saw was similar to what I see on my board, but it certainly was not computing, and that looked a lot like what I was running into.

    Camera image of the Commodore B128 displaying diagnostic results

    Now, nothing else using the 6509 was released by Commodore, so finding these chips in the wild is rare to impossible. Luckily, back in December, I ordered a Nu6509 from RETRO Innovations, and with any luck, that will arrive soon. The Nu6509 allows one to use a 6502, 65C02, or 65C816S CPU, and adds the memory banking logic of the 6509 to provide a fully compatible CPU for these machines. I ordered it as a “just in case”, and now it looks like we have a winner.

    That said, I’m fully aware that this could be one element of potentially multiple failures in this board, so I am not getting my hopes up.

    In the meantime, I am awestruck by the work of Michal Pleban creating a replacement 8088 card for the CBM-II. Commodore originally created an 8088 board to allow CBM-II owners to use MS-DOS 1.25, however, since none of the I/O ports matched up with the IBM PC, it was DOS-compatible, but not PC-compatible, so of limited usefulness. Michal took the original card design, and created a quasi-virtualization layer to proxy those requests to Commodore hardware. Furthermore, he managed to get FreeDOS running on it from an SD card, making it a fairly usable XT-style machine that can work in high profile and low profile CBM-IIs. Now he has a schematic available, and is building boards to sell this fall. If I get this machine working, that may end up being my next step — unless I can convince him to send me a card. 🙂

    Next update when I receive my parts and my Nu6509.

  • The Ongoing Saga of this Commodore B128 (2/x)

    In the last post, I introduced my US-market Commodore B128 that wasn’t feeling like being a computer. A lot of the diagnostics looked okay, and I was just about to start desoldering components out of a combination of hope and despair.

    Some Soldering Required

    Each desoldered component was replaced with a same-size socket, and continuity tested from the pin receiver to the bottom of the board.

    Step one was desoldering the 74LS275 at U12. I wasn’t sure if there was an internal short that was bringing down D1 at pin 12, and I couldn’t test it in circuit effectively. Once out, I put it in my TL866-II to test, and it tested good. For fun, I replaced it with another 74LS275, with the same results. Drat.

    Second was the RAM connected to D1, at U65 and U73. That is, theoretically, the only other thing on D1. I don’t have a DRAM tester, but I do have some 3764s which should be 1:1 compatible. Popped those in, no appreciable change. Drat.

    Third was the 74S138 at U40, to figure out if there’s an issue with chip select, since what I was seeing in the oscilloscope didn’t really match what I thought the truth table said. It also tested good in the TL866-II. I tried a replacement SN74AS138N1 but that didn’t change any of the chip selects, so maybe I’m reading that truth table wrong.

    Hands in the Air

    It was this point that I started to wonder if I was going to desolder every TTL chip on this board. Due to my lack of experience, I don’t know what these address and data lines are supposed to look like on an oscilloscope, but something about them bother me. It shouldn’t be power ripple, but I just have this nagging feeling that something is affecting the data bus on this board, and that’s why things are getting weird. Furthermore, there’s a huge difference in how the bus looks when the BASIC ROMs are installed versus when they are empty. While I’ve already successfully read them in my EPROM programmer, something is bugging me.

    With that, I’m taking up the offer of another member of the B128 community. He’s going to burn me a new 82S100 PLA, and while doing that, he’s taking all of my socketed chips and testing them in a working B128 board. I still have a feeling everything’s going to check okay, but at least it’ll eliminate those chips, particularly the 6509. Next entry will be after those chips are tested and back in the board.

    1. It’s incredibly difficult finding a 74S138 nearby, though fairly available as used stock on eBay. I went the instant gratification route after reading up on legacy vs modern versions of these TTL chips. The S is a faster max propagation delay (8ns), high power component. The LS was a low power, but somewhat slower (21ns) variant. The AS has a typical delay of 9ns, whereas the ALS is 12ns. Figured the AS was the closest match to the component.
  • The Ongoing Saga of this Commodore B128 (1/x)

    This is my Commodore B128, serial C002720. The B128 is the low-profile US version of the Commodore CBM-II, a machine designed to replace the PET/CBM series, released around the same time as the Commodore 64. Other pages, linked below, do a great job covering the history of this machine.

    When I received it, it looked great but did not work. Upon applying power, the LED lights, but the connected screen over composite is garbled, looking almost like it lost sync. On a 1084S, presents almost looking like characters. On a LCD over composite, just looks like flickering.

    No sounds are made when power is applied. Pressing CONTROL-G on the keyboard does not produce a beep. As a side project, connected the keyboard via USB to another machine, and verified that the keyboard works splendidly. Connecting a Commodore 4040 drive to the IEEE-488 bus will light up when the B128 is booted, but that could just be power applied to the bus. Attempting to type commands does not result in any activity from the drive.

    After a little bit of starting, I decided to remove the variable of potential ripple or power shorts by recapping the OEM power supply. There are plenty of forum posts of DOA power supplies, might as well get one win in.


    First up, the resource list. None of this diagnosis would be possible without the following pages, created with obvious love and care by the community of people who continue to appreciate Commodore and/or the CBM-II machines.


    Time for some diagnosis with absolutely no knowledge of how anything this works, armed with schematics and images from I’m making this post to keep myself accountable.

    • Power rails
      • No short to ground
      • Clean 4.99v at power LED
      • Clean 4.96v-5.02v on major ICs across the board
    • Addressing, timing, reset
      • CPU clock is clean
      • Dot clock is clean
      • RESET line starts low, then moves high, and the address lines start to make some noise, so it seems like the 6509 might be ok
      • Address lines have continuity throughout
      • Address lines out of 6509 at U9 look like decent square waves showing proper TTL. Each look okay on the oscilloscope, but A13-A15 on the logic analyzer look stuck high after a short amount of time — maybe after the RAM test?
        • Some research here suggests my kernal ROM isn’t in a good place
    • Traced video lines from plug, through TTLs back to the 68B45P at U7
      • Continuity is good across each path
      • Video signal looks something approaching normal
      • In most, but not all, cases, there is no hsync signal out of the 6845
      • In some cases, there is an hsync pulse, with no relevant change in output
      • It seems that the 6845 isn’t going to initialize on its own, the CPU needs to initialize the 6845, which also sets sync
    • ROMs
      • Signals out of kernal ROM at U61 look fine, from a TTL perspective
      • For a fleeting moment, having the BASIC HI ROM at U60 inserted would cause a very noisy looking data bus, leading to a wild goose chase that I couldn’t reproduce later
      • Forums seem to indicate having a kernal without basic lo or hi would boot into a monitor, but no change when leaving those out
      • Building a 2364 to 2764 adapter and testing in a TL866-II show that each socketed ROM content matches the binaries available online
      • Buying a 2764 to 2364 adapter, burning a ROM to a 27C64, and inserting does not change anything for any of kernal, basic lo, or basic hi. I did not try all three at the same time, but I have no reason to believe that it warrants further checking
      • Chip select coming from a 74S138N at U40 looks high on kernal (U40p7), basic hi (U40p10), and basic lo (U40p11), and that also seems super suspect. Chip select comes out of a 74S138 at U40, which is soldered. Could be bad? Can’t test until desoldered, but maybe this is a RAM issue
    • RAM
      • Initial checks of the data in/out lines (which are bridged) show that U65 and U73 kinda look shorted to ground on the oscilloscope, certainly a lower frequency on the logic probe
      • For a brief moment, every single data line looked weird, but that could be the 275 doing its job, or the 275 sucks
      • Tracing back to a 74LS275 at U12 shows the same grounded line. The opposite side of the 275 looks normal, so either the 74LS275 has a short, or something else on D1 has a short
        • D1 comes from U12p12
        • Passes through U65, U73, and the other bank of RAM if populated
        • Passes through P9p4
      • No obvious issues on the top or bottom of P9
      • Maybe a RAM IC is dead?

    I’m at the point now where it’s time to desolder parts. I’m likely starting with the 74LS275, and if that ends up good, moving on to the two RAM chips, and then looping back around to the 74S138.

    I also have a standing offer to test the rest of my socketed chips in a working B128, and if this desoldering doesn’t go well, that’s my next step.

  • Sharing your WSL2 environment with Linux

    It seems like I’m in a constant state of switching between Windows 10 and Linux on my personal laptop, so I keep both environments available in a dual boot. I’ve really enjoyed using WSL2 on my Windows 10 side, so much so that I have a bunch of projects that are in active use within that environment.

    WSL2 uses a lightweight virtual machine to boot a Linux kernel, and each WSL Linux distribution keeps a complete ext4 Linux filesystem as a virtual hard disk image for faster — and native — file access on your Windows 10 host. Luckily, it’s pretty easy to mount this filesystem if you’re booted on the Linux side.

    I’m using Windows 10 2004 and Pop_OS! 20.04, but this process will work with any Linux distribution that is set up to mount NTFS partitions read/write using ntfs-3g and can install the guestmount utility via libguestfs.

    To do this, the Windows 10 disk will need to be mounted within your Linux environment. On my Linux installation, I mount my Windows 10 volume using ntfs-3g under /mnt/c.

    You will need to find your root virtual disk, which is located in the application package directory of the WSL Linux distribution being used. In Windows, this follows the pattern “C:\Users\username\AppData\Local\Packages\distribution\LocalState\ext4.vhdx”, where C is your drive letter, username is your Windows username, and distribution is the generated name of the distribution used. If one is using Ubuntu, the generated name is “CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc“. I’m going to use this path in the example below.

    The other tool we’ll need is guestmount. This can be installed on Debian/Ubuntu/derivatives by installing the libguestfs-tools package using APT.

    sudo apt install libguestfs-tools

    Now, let’s mount the partition. The mount points in the image do not like being mounted as a normal user, and I’m happy to hear suggestions on how to get around this. We’re using the allow_other flag to let other users have access to the filesystem, and mounting it under /mnt/wsl. You can alter the username, distribution, and mount point to match your system.

    sudo mkdir -p /mnt/wsl
    sudo guestmount -o allow_other \
      --add /mnt/c/Users/username/AppData/Local/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/ext4.vhdx \
      -i /mnt/wsl

    Your WSL2 distribution is now available under /mnt/wsl. I haven’t found any odd side effects, except that Visual Studio Code reminds you to install the Remote – WSL extension, as WSL is available on your system. Go figure. 🙂

    Remember to use guestunmount when complete, before the Windows filesystem is unmounted. Too many force unmounts will eventually cause problems with the WSL2 environment, and there isn’t a lot of self-healing available.