slab | Recent Entries

I guess it's the big day again (five-year anniversary (observed) of having the Trans Revelation, four-year anniversary of starting hormone therapy (which for purposes of these blog titles I'm considering as the epoch), and now two-year anniversary of living in Minnesota) so ( I suppose it's time to write some stuff again. )

In my last post I mentioned:

a lot of this was pre-<stdint.h> so the integer typedefs were u8/u16/u32 and i8/i16/i32. u64 and i64 were classes in some cases, which is probably a cursed-c++ post all of its own

( ... so here's that post. )

Every now and then I will read a paper or see a talk about error handling in C++, and often they will take one of two forms:

Use exceptions! Always use exceptions.
Never use exceptions! Return error codes instead. (If it's something sufficiently new, it might bring up std::expected.

I've yet to see anyone show up with an implementation of the C++ error propagation mechanism that was pervasive at my old workplace, so I will impart upon you the (possibly-cursed) knowledge of...

status chaining

( okay, what )

(I originally posted this over on cohost, but cohost will be shutting down so I'm reposting it here.)

One of the advantages of moving to Minnesota: Summer Games Done Quick happens locally! ( Which means I went, naturally. )

So for the past couple years on July 1st (the anniversary of me starting hormone therapy) I've been writing up a sort of year-in-review; for 2022 and 2023 I wrote them up on Dreamwidth but I'm not actually certain anyone actually looks at Dreamwidth these days, so I originally posted this over on cohost and oops cohost is shutting down, so I guess it's back to Dreamwidth.

( And so, year three. )

(I originally posted this over on cohost, but cohost will be shutting down so I'm reposting it here.)

While writing this comment I had a story from circa 2015 that didn't really fit in the comment so I figured I should instead branch it out into A Post because I don't really do enough of those here.

So, MSVC has a /kernel flag that it gained at some point (I want to say MSVC 12.0 or so, but Microsoft doesn't have the documentation online for anything earlier than MSVC 2015 anymore). This flag tells the compiler that you're building something to run in the Windows kernel. For C++, this also turns off exceptions and RTTI, so you're getting a subset of C++, but even a subset of C++ can be pretty useful.

There is also another thing that that flag does which is a bit more subtle.
( Read more... )

Today is the two-year anniversary of me starting hormone replacement therapy, and approximately the third year since having had the Trans Revelation.

Today is also the first day of living in Minnesota.

( ... Minnesota? )

(I originally posted this over on cohost, but cohost will be shutting down so I'm reposting it here.)

I recently picked myself up a https://www.terra-master.com/global/products/homesoho-nas/f2-221.html to replace my old NAS and I figured I'd write up my notes on what I did for that. It's based a bit on information from Joel Duncan's TrueNAS on TerraMaster F2-221 article but, uh, less TrueNAS and more Debian I guess.

Rationale

I had a couple goals here:

Physically smaller-- My existing NAS is six drives in a gigantic 4U case, because slab of 2008 thought that the thing to optimize for was "plenty of room to stick a bunch of drives in" but slab of 2022 wanted something that would not be a pain to relocate across state lines (a goal for 2023).
Increase of capacity-- the old NAS had 2x600GB drives in RAID1 and 4x2TB drives in RAID1, which is pretty trivial to exceed capacity-wise with a single drive these days.
Improved power usage-- the old NAS wasn't terribly power-efficient (Athlon 4850e with 6 HDDs idles at about 200W), whereas the new one seems to idle at about 10W, so that ought to be slightly friendlier on my utility bill.

Installation

Joel's article covers the basics (and has pictures), but just to note them here:

The F2-221 has 2GiB of memory soldered on, but has a DDR3L SODIMM slot. I wasn't able to find the same memory module, but the TED3L8G1600C11 is compatible and brings the total system memory up to 10GiB.
There is an internal USB port for the boot volume. It comes populated with a 120MB USB flash drive; I replaced this with a 64GB Sandisk Cruzer Fit.

At that point, you've got yourself a tiny little x64 box; installing Debian _almost_ goes like you'd expect, except I needed to use an installer image containing firmware for sake of the Realtek NICs. :(

(This being a piece of x64 hardware was a requirement for me-- Terramaster does have some ARM64 units in their lineup, but past experience is that generic support for Linux distros on ARM is still non-ideal and I wanted something that didn't feel like my dayjob.)

Disk layout

I installed Debian onto the 64GB USB flash, with the requisite vfat EFI system partition and then a single large ext4 partition for the main filesystem.

In the two drive bays, I installed a pair of Seagate IronWolf 12TB drives, and set them up as a btrfs raid1, on which I created two subvolumes, home (home directories) and share (a big subvolume for shared media to be shared out over SMB). My /etc/fstab looks like so:

# / was on /dev/sdd2 during installation
UUID=f8c56311-488e-442d-920c-a021929dc8d3 /               ext4    errors=remount-ro,lazytime,noatime,commit=120 0       1
# /boot/efi was on /dev/sdd1 during installation
UUID=EF2C-FE9E  /boot/efi       vfat    umask=0077      0       1
tmpfs   /tmp    tmpfs   defaults        0 0
UUID=bf4e94fa-1a8f-42bc-aff8-630c1ad18891       /home           btrfs   defaults,noatime,compress=zstd,commit=120,subvol=home           0       2
UUID=bf4e94fa-1a8f-42bc-aff8-630c1ad18891       /srv/share      btrfs   defaults,noatime,compress=zstd,commit=120,subvol=share,bsdgroups        0       2

I did up the commit time to reduce impact of writes (especially on that USB flash!), and I use the bsdgroups option to help keep any content that users add to /srv/share in the share usergroup.

I'm not sure what other subvolumes to have, but I might think up more someday.

Network setup

The first Ethernet port is serviced by a PCIe-attached RTL8125. Despite the F2-221 specifications saying that it's a 1GbE port, this seems to be 2.5GbE-capable? I do not have any other 2.5GbE network equipment to test this though.

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05)

The second Ethernet port, curiously, is internally USB-attached and is an RTL8153:

Bus 002 Device 002: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter

Unfortunately in systemd's fine estimation, this means that we have a enp2s0 and a enx6cbfb502543c and that lack of consistency annoyed me, so I set up link files to rename them to eno1 and eno2, which is what they should be named as on-board ports.

# File: /etc/systemd/network/10-eno1.link
# The first network port is PCIe-attached, but is not indicated as
# an onboard port in the BIOS.

[Match]
Property=ID_VENDOR_ID=0x10ec ID_MODEL_ID=0x8125 ID_BUS=pci

[Link]
Description=Onboard Port 1
Name=eno1

# File: /etc/systemd/network/10-eno2.link
# There is a permanently-affixed but USB-attached NIC for the second port.

[Match]
Property=ID_VENDOR_ID=0bda ID_MODEL_ID=8153 ID_BUS=usb

[Link]
Description=Onboard Port 2
Name=eno2

Extra Samba configuration for sake of MacOS

I have, amongst the hardware in my house, a Mac Mini that is still serving as a HTPC. Did you know that MacOS in 2022 _still_ displays non-Mac machines (which it deduces to be Windows) as CRT monitors with a Win9x-era BSOD? Despite CRTs falling out of fashion in the mid-2000s as well as the last operating system with that style of bluescreen going completely out of support in 2006?

Come on, Apple. It's not funny anymore, it's just petty. And it's made even more ridiculous by this icon being used for Linux machines too! Sigh.

Anyway. We can fix that by advertising a couple services over mDNS with Avahi:

<!-- File: /etc/avahi/services/devinfo.service -->
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=Xserve1,1</txt-record>
  </service>
</service-group>

<!-- File: /etc/avahi/services/smb.service -->
<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_smb._tcp</type>
    <port>445</port>
  </service>
</service-group>

Unfortunately we can't come up with our own custom icons here (the icons are specified for each model code on the MacOS side, in /System/Library/CoreServices/CoreTypes.bundle/Contents/Info.plist) but Xserve1,1 is an okay fit. But hey, now we show up as not-a-CRT monitor!

LEDs

Terramaster supposedly has an LED driver for Intel J33-based platforms which is pretty gross (just pokes PCI configuration space to find the GPIO controller, then creates its own device files instead of using /sys/class/leds), and while there have been some slight modifications by others (such as this one that is DKMS-enabled) none of them really do anything to alleviate any of the grossness. However, as far as I can tell... on my F2-221 the HDD LEDs are not actually connected via these GPIOs-- neither of these drivers affect the visual state of the LEDs, nor does exporting the GPIOs to userspace via /sys/class/gpio/export (I believe GPIO23 through GPIO32 would be 457 through 466) and twiddling them that way.

The LEDs do turn on or off based on the presence or absence of a drive in a bay, so they're hooked up somewhere in hardware I think? This unfortunately probably means that I cannot make them turn red on drive failure or any other interesting condition.

(Terramaster even making a driver for GPIO-connected LEDs in the first place also boggles me-- those can be specified in ACPI!)

Today is the one-year anniversary of me starting hormone replacement therapy.

This feels like an occasion that deserves a milestone roundup post to cover the last two years. I wrote more words than what would fit in a Twitter thread, so let's bring out the ol' blog format for this one.

( How'd we get here? )

If you're wanting to softmod an original xbox, the procedure involves using a small USB flash drive to function as a memory unit in order to get a carefully-crafted save file into the system.

I didn't have a USB flash drive small enough to work, but I do have some BeagleBone Blacks around.

I was able to make a BeagleBone Black act convincingly like a 512MB flash drive with the following process:

Grab a firmware image and put it on an SD card. I used "AM3358 Debian 10.3 2020-04-06 4GB SD IoT", which was the current version at the time of this writing.

In /etc/defaut/bb-boot:
- set USB_NETWORK_DISABLED=yes

In /opt/scripts/boot/am335x_evm.sh:
- change usb_ms_ro=1 to 0
- comment out or remove the following lines for the serial gadget function in run_libcomposite:
  - #mkdir -p functions/acm.usb0
  - #ln -s functions/acm.usb0 configs/c.1

By default we load cape overlays, but we don't have any capes, so to improve boot time, in /boot/uEnv.txt:
- change enable_uboot_overlays=1 to 0
- change enable_uboot_cape_universal=1 to enable_uboot_cape_universal=0

Set up the image file with:
- rm /var/local/bb_usb_mass_storage.img
- dd if=/dev/zero of=/var/local/bb_usb_mass_storage.img bs=1024 count=524288
- mkfs.vfat /var/local/bb_usb_mass_storage.img

You'll probably want to have a external FTDI cable, as this process disables the serial and network interfaces over USB. However, with this setup, I was able to have the Xbox recognize the flash drive as a memory unit and reformat it. ("The memory unit you inserted isn't working correctly. It has been erased.")

One of the things I do these days is video game streaming on Twitch, and I generally try to do so with actual consoles.

Trying to get the output of a game console into a monitor is one of the major problems with trying to stream a game console. LCD monitors with CVBS (composite or S-Video ports are a bit difficult to come by these days, and even worse I'm using an ordinary desktop LCD (Dell E228WFP) with only VGA and DVI inputs. I set myself a couple rules:

No CRTs. They're big, they're heavy, I don't have a good place to put one, and thus they create a complication I'd rather try to avoid.
No SCART. SCART has been relegated to being "the retrogaming enthusiast's video connector" and therefore anything that deals with SCART is priced accordingly, especially living in a region where SCART was not prevalent when it was in regular use. HD15 (e.g. VGA) connectors are wholly adequate for transmitting RGB analog video.

An additional challenge is that game consoles, especially from the 16-bit era and earlier, use non-standard video mode timings collectively termed "240p"-- essentially, instead of transmitting an "even" and an "odd" field like in normal interlaced NTSC, the device sends only one field type. While CRTs of the day had no problem with this, modern HDTV equipment tends to choke.

The thing most people recommend is the Open Source Scan Converter; however, the only producer is Video Game Perfection. At the time I started looking at this, they were based in the UK and their £135 cost (plus shipping) came out to about $200; they've since moved to Ireland and their now €135 cost plus shipping knocks it down to about $175. (I have at times wondered how much capital I'd need

I felt that was a bit steeper than what I was willing to spend on this hobby, so I went looking around for cheaper options. One thing that did catch my eye was the Extron DVS 304, which boasts a wide variety of inputs and outputs:

Input 1: CVBS (via BNC)
Input 2: Composite/S-Video/YPbPr (via BNC)
Input 3: S-Video mini-DIN
Input 4: 15-pin HD supporting RGBHV, RGBS, YPbPr, S-Video, and Composite
Output: RGBHV, RGBS, RGsB, or YPbPr

The Extron DVS 304 series is dual-output. All have output via BNC connectors, and the Extron DVS 304 has a 15-pin HD connector while the Extron DVS 304 DVI replaces the HD15 connector with a DVI-I connector.

So it's got a lot of points in its favor:

Basically every input useful for a retro game console (if you I'm willing to eschew SCART for HD15 connectors) while letting me take my time in upgrading cables from CVBS/S-Video up to RGB
RS232 control for automation (which will pair quite nicely with my Extron MPS 112CS RGBHV/S-Video/CVBS switch) instead of needing a dumb IR blaster
Half-rack form factor for convenient mounting
Dual outputs to go both to an LCD and to a capture card and not needing a VGA splitter

This was "professional"-level gear, but as more and more professional installations are moving to HDMI, models like this can be found from eBay pretty cheaply-- and after finding a video where someone was able to successfully use a DVS 304 with a Genesis, I pulled the trigger on an Extron DVS 304 DVI with shipping for about $35.

Unfortunately, I've since learned a couple things: specifically, while one would think that the "DVI" model just augments the RGB output of VGA with a DVI transmitter for digital and leaves the input frontend alone, it turns out that the "DVI" model appears to be substantially different from the non-DVI model.

To wit: I'm unable to get any usable picture out of 240p signals. The usual failure mode for video hardware is that it processes 240p as 480i, usually leading to effects like "combing" or flashing objects not properly being rendered (see some of HD Retrovision's examples). The Extron DVS 304 DVI does something completely different.

I've shared some earlier videos around Discord in the past, but now that I've finally picked up a better capture card, here's a comprehensive video of me trying out the DVS 304 DVI with three game consoles:

Sega Genesis (with 32X) connected via CVBS
Super Nintendo connected with S-Video
Nintendo Wii connected with YPbPr

This video uses the 240p Test Suite on all three of these consoles. In addition, I also use Sonic the Hedgehog 2 on both the Genesis and the Wii (Virtual Console). Sonic the Hedgehog 2 uses the Genesis's "interlaced mode" (480i) to implement the split-screen two-player mode, so it's a useful test case with a "real" game.

Note too, I haven't tried to dial in any color settings or the like-- this is all just the first pass of "is the result something playable". Also, this is with the latest version of the firmware (thanks to dentnz on the OpenVGS Discord for helping me obtain it).

Most of the literature that's out there reviewing upscalers and video processors (for example, RetroRGB, or Fudoh's list) concerns itself with the characteristics of processing RGB (as this is usually the "native" and highest-quality video output from a console)-- I was surprised that the DVS 304 DVI behaves so poorly with CVBS and S-Video signals.

Another curiosity I've found is that there is a difference between Virtual Console games launched via the Wii System Menu vs. an EmuNAND-capable loader (such as USB Loader GX) when the Wii is in 480p mode. From the Wii System Menu, Virtual Console games will automatically output in either 480i or 480p (I'm not sure which is happening). However, from USB Loader GX, I appear to get the same result as if my Wii were set to be in 480i mode. I've tried setting "Force NTSC480p" as well as other video-patching options but nothing seems to do the trick-- I assume that this is due to use of a custom IOS slot to support games on EmuNAND (instead of the slot it's "supposed" to use), but I don't know enough about the Wii ecosystem to know for certain.

At any rate: If you're looking for a cheap alternative to the OSSC, I'd recommend staying away from the Extron DVS 304 DVI. The non-DVI model is reported to be better-behaved-- if I can find one at around the $35 price-point I'd be willing to give it a shot. Until then, I'm mostly only using this as an overkill VGA splitter, with a ViewSonic NextVision N4 to handle CVBS/S-Video to VGA conversion.

I recently purchased a Marvell ESPRESSObin. The support is... currently a bit rough.

The wiki has two articles on how to install Ubuntu:

Unfortunately, they're kind of a pain to follow, they have you do a bit more work than necessary, and they don't actually give you a useful Ubuntu image.

Here are my notes. I used a USB SD card reader, an 8GB SD card, and a Debian virtual machine on Windows. You'll also need to grab the following linked to from the EspressoBin site:

Creating your Ubuntu SD card

My SD card came up as /dev/sde. Substitute the correct device name as appropriate. You will also need to be root for these steps (either prefix each command with 'sudo' or just do 'sudo -s' to get a shell.)

Use 'cfdisk' and create a smallish (100M?) FAT32 partition, then allocate the rest to be Linux.
mkfs.vfat /dev/sde1
mkfs.ext4 /dev/sde2
mkdir -p /mnt/sde1 /mnt/sde2 /mnt/iso
mount /dev/sde1 /mnt/sde1
mount /dev/sde2 /mnt/sde2
mount -o loop ubuntu-16.04.2-server-arm64.iso /mnt/iso
unsquashfs -f -d /mnt/sde2 /mnt/iso/install/filesystem.squashfs
You should apply the fixups that the wiki recommends:
- edit /mnt/sde2/etc/passwd and remove the 'x' in in 'root:x:0:0:root:/root:/bin/bash' so root can log in.
- edit /mnt/sde2/etc/securetty and add 'ttyMV0'
unzip kernel.zip
mv kernel/armada-3720-community.dtb /mnt/sde1
mv kernel/Image /mnt/sde1
umount /dev/sde1
umount /dev/sde2

Boot from removable storage - Ubuntu

Insert your SD card. You are now done.

The wiki directions want you to create a single ext4 filesystem for your entire SD card, and then muck around with creating a 'bootmmc' command in u-boot and then modifying 'bootcmd'. However, the default 'bootcmd' sequence loads the kernel and device tree off the first FAT partition, then boots using /dev/mmcblk0p2 (the second partition) as a rootfs.

At this point, you should be able to use the serial connection (over micro-USB) to log in as root. You should probably set a password now.

But wait, I keep getting kernel panics about eighty seconds after boot!

Thanks to

annathyst for figuring this out.

The kernel image that EspressoBin provides currently has some problems with the ondemand governor. You'll want to kill the "ondemand" script:

sudo systemctl disable ondemand
sudo pkill ondemand

Note: After you do this, your device won't do frequency scaling anymore. It will get kind of toasty! I had some small heatsinks handy, and I highly recommend putting one onto the Armada 3720 processor. You can also downclock the CPU with:

echo 250000 > /sys/bus/cpu/devices/cpu0/cpufreq/scaling_max_speed

Next up is going to be building a kernel build environment to try and update the kernel...

RIP my LiveJournal account, 23 May 2000 - 9 Apr 2017. Maybe I should start putting stuff here.

Profile

slab

July 2025

S	M	T	W	T	F	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Syndicate

Page Summary

transition, year four
fake integer types
i can still hear you saying we would never break the chain
sgdq 2024
transition, year three
the tale of the upgraded compiler and the corrupted memory
transition, year two
Debian on a Terramaster F2-221
transition, year one
HOWTO make a BeagleBone Black be a flash drive for Xbox modding
The Extron DVS 304 DVI does not work very well with game consoles
Installing Ubuntu on an ESPRESSObin
(no subject)

Style Credit

Style: Dreamer for Dusty Foot by timeasmymeasure

Expand Cut Tags

No cut tags

Page generated Aug. 12th, 2025 12:49 am

slabnormal

Recent Entries

transition, year four

fake integer types

i can still hear you saying we would never break the chain

status chaining

sgdq 2024

transition, year three

the tale of the upgraded compiler and the corrupted memory

transition, year two

Debian on a Terramaster F2-221

Rationale

Installation

Disk layout

Network setup

Extra Samba configuration for sake of MacOS

LEDs

transition, year one

HOWTO make a BeagleBone Black be a flash drive for Xbox modding

The Extron DVS 304 DVI does not work very well with game consoles

Installing Ubuntu on an ESPRESSObin

(no subject)