Ryan Finnie

Monoprice Maker Select Plus 3D printer mods

Monoprice Maker Select Plus 3d printer

About a month ago I bought a 3D printer, the Monoprice Maker Select Plus. This is a rebrand of the Wanhao Duplicator i3 Plus, and is also rebranded by several other manufacturers, including Aldi supermarkets in Australia. Yes, really.

3D printers run a wide range, from “build the frame yourself and buy a hundred off-the-shelf parts”, to kits which include all the parts but require full assembly, to “spend a few grand, plug it in and turn it on”.

I picked the Monoprice model because it’s nearly fully assembled, requiring about 15 minutes of assembly to attach the two main components together, and it is well reviewed as producing decent prints out of the box. This is an important consideration for a first 3D printer, and I was very lucky to have my first few prints go perfectly, so I had an idea what the process should look like, to compare when things are going wrong.

And they will go wrong. No 3D printer will be completely foolproof, and all require various levels of troubleshooting. For all that I’ve learned in the last month, I feel confident that if I buy another printer, a kit would be easy and a completely-from-scratch build would be possible. (From what I’ve seen, 3D printers are like cats: people who have more than zero usually have more than one. Some even have their houses overrun by them.)

The second important factor in choosing the Monoprice is there is a lot of potential for customization, with a large community of Wanhao i3 owners. And oh boy, have I modded it in the last month. Strictly speaking, none of what I’ve done below is necessary, but this is a hobby, and all of it was fun.

  • Printed a filament guide arm just below the spool holder. This was actually my first “mod” and was done with the sample black filament which came with the printer (and I used much of it).
  • Added a Z brace, which helps avoid movement of the vertical frame and theoretically reduces the chance of ghosting on prints. It also allows you to minutely adjust the torsion flex of the frame as a whole. This is one of the most impressive cost-to-looks ratio mods, and consisted of a 1 meter threaded rod ($3) split in two, about $3 worth of nuts and bolts, and a large amount of printed parts. The corners also double as a larger base to attach rubber or cork feet.
  • Printed a lenth extension to the spool holder arm. The spool holder which comes with the printer isn’t wide enough to fit most common spools, which I think is one of the few outright flaws of the i3 Plus (albeit a small and easily corrected flaw).
  • Printed an LCD extension panel, which tilts the viewing angle up slightly, and allows access to the LCD’s internal diagnostic MicroSD card (see below).
  • Replaced the printer’s firmware with ADVi3++. The original firmware was decently capable, but was based on an older version of Marlin. ADVi3++ is based on the latest version, has extra features such as guides for filament length adjustment, and quality of life improvements such as temperature readings on the main menu. This involved upgrading the firmware on the internal main board itself via USB, as well as upgrading the LCD’s firmware via a MicroSD slot on the side of the LCD. (Yes, the LCD has its own microcontroller.)
    • Update (2019-06-16): I am no longer recommending ADVi3++ as, while the source code is still open source, the author is now charging for the firmware binaries as well as much of the documentation, including how to compile the source. The author is within his rights to do this, but I disagree with it.
  • Replaced the cold block fan (which prevents the molten filament in the hot end from flowing back up and jamming) with a direct replacement. The original one started making a loud noise after a few weeks of use, and is a known problem. Thankfully direct replacements are a few dollars on Amazon.
  • Replaced the 40mm part cooling fan with a 50mm blower fan. There are many more efficient part cooler mods such as the DiiiCooler or the CiiiCooler which evenly distribute the air around the nozzle, but have tradeoffs such as visibility and clearance issues. I’ve found simply printing an adapter shroud for the front slot works fine for my needs.
  • Replaced the original 4-point corner bed leveling system with a 3-point bed level (two on the left corners, one on the middle of the right side). This allows for more accurate adjustment, since technically it’s impossible to adjust a flat plane using four points (you end up warping it into a 3-dimensional object).
  • Added BLTouch bed leveling. This consists of a probe mounted as close to the nozzle as possible. The probe can sense with a high level of precision when it touches the surface, and reports this data at various parts of the bed to the firmware, which can correct for different heights on the bed’s plane. (It’s still also a good idea to start with a decent attempt at manual leveling.)
  • Replaced the BuildTak-like surface with a glass print surface, with a large (but incredibly thin) thermal pad between the heated plate and the glass.
  • Added four binder clips to the edges to prevent the glass from separating from the plate. Not the most exciting mod, but it’s worth pointing out since you need to account for them when doing low-height print head travels. I’ve got some thinner clips ordered, but they haven’t arrived yet.
  • Replaced the thin Y carriage with an all-aluminum replacement, allowing for a more stable Y axis.
  • Did some of my own firmware mods based on ADVi3++. In particular, the BLTouch sensor’s hardware development is moving fast and the version I received (v3) wasn’t compatible with the support in ADVi3++ (v2), so I backported v3 support from the Marlin development branch.
  • Set up a Raspberry Pi with OctoPrint, a USB printer manager. You could just transfer GCODE to an SD card and print it directly from the printer, but OctoPrint gives you more convenience and flexibility. After I slice an object, I can tell Cura to send the GCODE directly to OctoPrint which starts the print. And I’ve got a webcam pointed at the print bed, which OctoPrint shows and lets me monitor the print when I’m away from it, and it also captures a per-layer timelapse of the print.
  • The printer’s main board is a variation of a reference Arduino platform, and an annoying side effect is it can be powered from the USB port. I don’t want this, since the USB host is a Raspberry Pi which has its own limited power to deal with, and also means that when I turn off the printer via the back power switch, the main board and LCD remain on (but have no control over the motors, heaters, etc). I solved this by taking a USB cable, stripping off the sheath in the middle and cutting the red wire. This turns it into a “data only” USB cable, so the printer turns off completely when the power switch is turned off. Interestingly, I have yet to find a commercially sold “data only” cable, though obviously the opposite “charging only” is common.

So you want a Stratum 1 NTP server...

(Standard warning: I’d consider myself an informed amateur in this field, so don’t take anything I say as gospel.)

MECCA GPS time receiver

The Global Positioning System is an amazing piece of technology. In very simple terms, GPS is a constellation of moving satellites which simply broadcast when they are, and rely on you to know where they can be in the sky. Picking up one satellite by itself determines your position to within a hemisphere of Earth. Two satellites reduce that down to a radial line. Three pinpoint you to a specific latitude and longitude (2D fix). And four or more let you pinpoint elevation (3D fix).

To do this with any sort of accuracy, the clocks onboard the satellites must be extremely accurate. GPS atomic clocks use cesium (or more recently, rubidium) as an oscillator, and are theoretically accurate to within 14 nanoseconds. So great, you have a free source of high-precision timekeeping! Just hook up a consumer GPS receiver to your computer and you have a Stratum 1 device, right?

There’s a small problem, in that there’s a lot of uncertainty in getting from the receiver to your computer. The receiver may say “the current time is 01:23:45.000 UTC”, but there’s a (relatively) massive amount of time between “the” and “UTC”. When was it 01:23:45.000 UTC?

The solution is PPS, or 1PPS. It’s simply a high precision pulse, once per second, at the same time (or as close as can be) every second. Usually the PPS pulse is at the top of the second, and then the receiver has the rest of the second to send its data to the computer.

Many modern GPS receiver chipsets support PPS, but almost no consumer devices support exporting it. Take apart nearly 100% of the “mouse” style u-blox USB receivers, and you will often see a PPS solder pad, but nothing to attach to it. The embedded USB TTL chipset just doesn’t support it.

USB GPS PPS receiver (breadboard)But you can build your own. The FT232R USB chipset has support for emulating all RS-232-style serial control signals, including Data Carrier Detect. DCD’s classic meaning in serial communication is basically “I’m ready to begin sending you something”, so the logic maps well to the PPS concept. This post by Larry Cochrane explains how to pair a $15 GPS receiver module with a $10 FT232R-based USB TTL adapter to get a USB GPS receiver with PPS support. This was the first design I built.

This is fine for a home NTP receiver, but there is a problem. USB is laggy, in the realm of local high-precision timekeeping. (Still better than you could do from an Internet NTP source.) Worse still, it’s unpredictably laggy, i.e. jitter. USB 1 and 2 are packet-based, and it’s not guaranteed packets will arrive over the bus in the exact same amount of time. The average latency from the receiver to the software may be 200 microseconds, but the jitter may be ± 300 microseconds.

If we want to get serious, we need to go old school. RS-232 serial is interrupt-based. An electrical signal comes in, the CPU pauses whatever it’s doing to read it. (In a tiny amount of time; the amount of time lost processing the interrupt is insignificant for modern computers.) And amazingly, the beast of a home server I built late last year — a Ryzen 7 2700X with 64GB memory and 9 hard drives — still has a motherboard with an RS-232 header on it.

Let’s take a moment to discuss RS-232 and TTL. TTL is the language of nearly all modern serial components (such as the GPIO pins on your Raspberry Pi). A one is 3.3V (high), a zero is 0V (low). Fine for high-ish-speed, physically short runs of a few inches. But RS-232 is what home computers used to use for serial communication to devices such as modems. With RS-232, high is anywhere between 3V and 25V, and low is -3V to -25V. Signals between -3V and 3V are discarded as garbage. This was useful for reliable longer-length cable runs.

So we can’t just solder our GPS receiver (TTL) to a DB9 port and plug it into a computer. We need something to actively translate between TTL and RS-232 voltages. There are plenty of TTL to RS-232 DB9 adapters on Amazon and eBay. The problem is they’re almost all based on the MAX232 chipset or similar, which only supports two drivers (transmit from the TTL device to the PC) and two receivers (receive from the PC to the TTL device). 75% of these adapters will implement TX and RX only, and the other 25% will also support CTS and RTS, but no DCD.

The MAX3238 chipset supports five drivers and three receivers, and is designed specifically for full RS-232 translation. As far as I’ve been able to find, there is exactly one manufacturer currently making breakout boards based on the MAX3238: the Pololu 23201a for about $10.

So now, let me present to you MECCA: Measuring Expensive Cesium Clocks in the Air.

MECCA GPS time receiver (open case)

The RS-232 board is the Pololu 23201a. The USB board is a random cheap micro USB header to supply 5V to the GPS receiver, which is an Adafruit Ultimate GPS Breakout. The Adafruit receiver is quite expensive, about $40, but I chose it because it has an automatic external antenna header, something I didn’t find on any of the $15 eBay modules. But if you’re in a relatively open area, the $15 modules with their built-in antennas should be fine.

The receiver has a 3.3V regulator which drives the TTL logic, but also powers the RS-232 board. It’s a pretty simple schematic; the hardest part was soldering the various VCC bridges (needed to keep DSR, CTS and RI high) on the breadboard connecting the RS-232 and USB boards to fit in the project box. (I left the GPS receiver modular since it’s the most expensive component of the setup.)

MECCA 1.0 schematic

One thing to note if you go for the $15 bare module: The “enable” pin must also be tied to VCC to enable it. On the Adafruit module, “enable” is pulled high by default and can be tied to ground to disable it.

If you wanted to go more versatile, you could build something which supports USB or RS-232:

MECCA 2.0 schematic

FT232R-based USB converters support “PWREN”, which is high when the converter has power, but goes low when the converter actually has USB communication with a host. This can switch a P-channel MOSFET to VCC on the RS-232 converter, so it’s only active when there’s simple USB power. The only reason I didn’t build this is because fitting it all in a small project box would be tight (and I didn’t happen to have a suitable MOSFET at the time).

Now that you have a PPS-capable receiver, you’ll need gpsd which will interface with ntpd. This gpsd page goes into excruciating detail about the theory and the operation, so I won’t go into the details here. My final ntpd configuration is the standard ntp.org pool config (ntpd works best with other peers to act as sanity checks), plus the following:

# GPS Serial data reference (NTP0)
server 127.127.28.0 minpoll 0 maxpoll 0 noselect
fudge 127.127.28.0 time1 0.521643 refid GPS

# GPS PPS reference (NTP1)
server 127.127.28.1 minpoll 0 maxpoll 0 prefer
fudge 127.127.28.1 refid PPS

I wouldn’t worry too much about fine-tuning the GPS reference. My offset (“time1”) is 521.643ms, but the jitter can be up to 60ms, so I’ve explicitly told ntpd to track it but not to consider it (“noselect”). Even if I didn’t explicitly specify “noselect”, it would eventually work out that the jitter is garbage and ignore it (with an “x” in “ntpq -p”). The kernel PPS feed is the high-precision component, and has an average jitter of about 7 microseconds.

Weighted file cleanup

I’ve got four security cameras streaming to my home server, and save the most recent 3 TiB of raw recordings locally. I won’t go too much into the details (because they’re out to get me, of course), but cam2 and cam4 are the main ones, and I would like to save them locally the longest. However, cam4’s file sizes are larger than cam2’s. cam1 is in an unimportant area so I don’t want to save as much, and cam3 is only used on demand, so it has an even lower priority.

I struggled with a system for deleting old recordings, but recently came up with what I believe is a decent system. I assign file globs into per-camera collections, and then assign a weight to each collection. cam2 and cam4 each get a weight of 1.0, cam1 gets 0.2 and cam3 gets 0.1.

It then goes through what can be multiple rounds, determining if each collection is over or under its weighted share of the total target. If a collection is under target, it is eliminated from the round, but importantly its usage is removed from the considered total target for the next round. Rounds continue until all collections in the round are over target.

cam1: 3809 files, 364.82 GiB, 0.20 weight
cam2: 8226 files, 809.57 GiB, 1.00 weight
cam3: 529 files, 83.86 GiB, 0.10 weight
cam4: 7514 files, 1817.40 GiB, 1.00 weight
Grand total: 3075.66 GiB used, 3072.00 GiB target, 3.66 GiB above target
Round 1: cam1: 364.82 GiB used, 267.13 GiB target, 8.70% round weight of 3072.00 GiB, 97.69 GiB above target
Round 1: cam2: 809.57 GiB used, 1335.65 GiB target, 43.48% round weight of 3072.00 GiB, -526.08 GiB above target (disqualifying)
Round 1: cam3: 83.86 GiB used, 133.57 GiB target, 4.35% round weight of 3072.00 GiB, -49.70 GiB above target (disqualifying)
Round 1: cam4: 1817.40 GiB used, 1335.65 GiB target, 43.48% round weight of 3072.00 GiB, 481.75 GiB above target
Round 2: cam1: 364.82 GiB used, 363.09 GiB target, 16.67% round weight of 2178.57 GiB, 1.73 GiB above target
Round 2: cam4: 1817.40 GiB used, 1815.47 GiB target, 83.33% round weight of 2178.57 GiB, 1.93 GiB above target
cam1: Freeing 1.73 GiB
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (175.85 MiB)
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (102.45 MiB)
Deleting /media/camera/streams/cam1/cam1_XXX.mp4 (103.56 MiB)
[...]
cam4: Freeing 1.93 GiB
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (844.88 MiB)
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (839.17 MiB)
Deleting /media/camera/streams/cam4/cam4_XXX.mp4 (797.06 MiB)

In this example, in round 1, both cam1 and cam4 are over their weighted share of the total 3072 GiB target. cam2 and cam3 are under so they are removed, and the total target of the next round’s considered collections is reduced to 2178.57 GiB. In round 2, cam1 and cam4 are re-evaluated according to this target, using their own weights compared to each other (not all collections). It’s actually possible a collection can be over target in one round but under the next, triggering a round 3 (cam1 used to do this until a few days ago). With the final weights determined, files from each collection are deleted until they come in under their collection target.

Right now, the initial round is massively skewed since the this system is new, with cam4 largely above target and cam2 is largely below target. But over time, this will even out to their respective weights. The nice part of this system is it’s not wasteful if a collection is below target; as I mentioned, cam3 is only used on-demand and will likely always be below its target of 133.57 GiB. But because of that, it’ll always go on to a new round which will utilize the extra space, and the global target will always be 3072 GiB utilization.

The full Python code is available here. I’m pretty sure I’ve got all the corner cases worked out, but obviously please use caution if you use this. (I’ve commented out the line used to actually do the delete.)

CMYK printer line test sheet

CMYK printer line test screenshot This week I bought a new color laser printer, a Brother HL-3170CDW. It’s replacing my old laser printer (Brother HL-2270DW) and inkjet (Canon MX922), the latter I got sick of being, well, an inkjet printer.

I use to have a weekly test print sent to the Canon, to prevent the nozzles from seizing and to notice when the ink cartridges were empty. This was a cropped test print I found online, and mostly did the job. But with the new printer, I decided to design my own test page. It’s not comprehensive; there are better tests out there for when you suspect something is wrong, for example it doesn’t test gradients. The one I designed is specifically for a weekly test, and will point out ink/toner problems while not using much ink/toner.

For each tested color (cyan, magenta, yellow, black, magenta/yellow, cyan/yellow and cyan/magenta), it shows a series of 15mm lines at 2.0, 1.0, 0.75, 0.5 and 0.25 points. The lines are shown horizontal, vertical and at 45 degree angles. Each tested color’s total surface area is 285.84mm² (which would be about a 16.9mm square, so roughly equal to one of the colors’ individual squares). All ancillary text is grey to make the pure tested black stand out.

Download:

I have my Ubuntu laptop run the following every Sunday morning:

lpr -P brotherc /path/to/CMYK_Line_Test_US_Letter.pdf

(Replace “brotherc” with your printer identifier.)

Building a RetroPie game console

RetroPie system with monitor and controllers Early in 2017, I did a three part series, “Re-Buying My Childhood”, where I tracked down and re-purchased the various Nintendo consoles and games I owned as a kid. It was a fun process, but since then, all the consoles (except the Game Boy Color) and games have sat in a box.

See, the problem with collecting a set of 30+ year old hardware is at the end of the day, you’re left with 30+ year old hardware. The NES and SNES don’t even work with my living room’s 65” 4K LCD TV. (My working theory is the TV expects a proper 480i composite signal, while Nintendo consoles of the time would output a slightly standard-breaking 240p which is to be interpreted as 480i.)

Even if they did work, I don’t really have room in my living room’s entertainment center. And I don’t have a “man cave” where I can set up a proper CRT TV to play them on. And let’s face it, I (and the world) have gotten lazy over the last 30 years or so. Get up from the couch and physically switch out a bulky cartridge to play a single game?

So this year, I decided to build an emulation box for the living room. As an aside, I like to take things apart, figure out how they work, break them, re-implement them, make them do new things, etc. This plays into the story of my last emulation box: years ago, I built an i3 system into a small Shuttle case. I installed Ubuntu, got emulation software working, and wrote my own custom front-end launcher system.

I ended up rarely using it. The problem was there was always something wrong or quirky with it. It wouldn’t be on when I wanted to play and would require a full boot and log-in cycle (digging out a USB keyboard to attach). The wired USB control pad wouldn’t be attached and might be in a drawer somewhere. The front-end software I wrote might not work right.

No, if I wanted to do a new emulation box, I would need to suppress my desire to tinker with every internal aspect of the box and build something which is self-contained and just works. A simple RetroPie setup. Well, that was the theory, anyway. Ironically, this post has been delayed by months because I’ve been continually switching out and modifying things, but the important difference is that at any point during the last few months, the system has always been in a “just works” state. I could pick up the controller and be within 30 seconds of gameplay.

The hardware

I didn’t want to build a mini x86 system, and RetroPie is primarily targeted at the Raspberry Pi. When I first built the system, it was a Raspberry Pi 3, but shortly after, the 3 B+ (slightly better CPU and Wifi) was released and I switched to that. Either would be fine, but while technically RetroPie is supported all the way down to the original Raspberry Pi models, I wouldn’t recommend anything older than a 3 due to the emulation’s CPU demands.

Good power is an absolute requirement. When I originally built the system, I used the first random micro-USB cable I found lying around, plugged into a shared USB power supply. But when playing games, I would get slowdowns combined with a yellow lightning bolt in the corner of the screen. This meant the Raspberry Pi was not able to get a continual clean 5v supply, and was throttling itself as a result. I replaced the USB cable with a better quality one, and while it helped a bit, the slowdowns were still present. I finally swapped it out for a dedicated 2.5A micro-USB power supply from CanaKit, and the problems went away completely. In fact, if you’re starting from scratch, I’d recommend buying a complete kit from CanaKit which includes a Raspberry Pi, good power supply, case and a few other accessories.

A decent heatsink is also needed. The standard square ones found everywhere will minimally do the job, but I recommend a full-coverage heatsink as large as possible. I’ve currently got a very nice heatsink from Kintaro which covers almost the entire board. The problem is, as of this writing, the model I have (for the 3 B+) doesn’t appear to be for sale, just the 2 / 3 B model.

A fan may also be nice to have, but I’ve found if the heatsink is good enough, it’s not strictly needed.

Kintaro Super Kuma, Retroflag SUPERPi, SNES Classic Mini (EU version), original SNES

From left: Kintaro Super Kuma (RPi), Retroflag SUPERPi (RPi), SNES Classic Mini (EU version), original SNES

The case

Technically, any case will do – or even no case; just chuck the board next to the TV. But let’s be honest, I wanted something nice and retro-looking for the living room. I got the Kintaro Super Kuma, an SNES lookalike Raspberry Pi case. This thing was tiny (and therefore adorable), taking up little more than the footprint of the Raspberry Pi itself and about half the size of even the SNES Classic Edition, while still looking like an authentic SNES. There were a few small cosmetic issues, such as the top buttons were decorative only and the plastic colors were a bit lighter than authentic, but I was fine with that until something better came along…

… Which it did, a few months later with the release of the Retroflag SUPERPi case. The SUPERPi is larger than the Kintaro case, is dimensionally identical to the SNES Classic Edition, and the colors are spot on. There’s also a Super Famicom-styled case if you prefer that instead, but I find the SNES styling to be great.

The power and reset buttons are functional, attaching to GPIO pins on the Raspberry Pi. Even the eject button is functional, popping up the cartridge slot to reveal a small space which can be used to store MicroSD cards. Finally, the front controller port area features two USB ports for attaching wired controllers, while leaving the other two Raspberry Pi USB ports accessible on the side of the case. The case even comes with an SNES-style USB controller, which is great quality as far as SNES controller clones go.

I wanted to retain the excellent Kintaro full-spread heatsink, but there were some compatibility issues with its size which required a bit of light surgery. Ultimately I removed the cartridge slot storage and forced close the slot cover, making the eject button nonfunctional, but I’m fine with that as a trade-off for a better heatsink.

The controller

I actually wrote an entire post just on controllers; please take a look if you want all the details. But in general, you can use nearly any controller with RetroPie, wired or wireless, if you have enough time and/or money for the more esoteric combinations. But nearly any wired USB controller should work out of the box with RetroPie.

My current favorite is the 8Bitdo SN30 Pro, a Bluetooth controller which feels nearly identical to the original SNES controller, but has the addition of dual analog sticks and extra trigger buttons. It’s a little uncomfortable for longer play sessions (as was the original SNES controller), so I am looking forward to the SN30 Pro+ later in 2018, which is functionally identical to the SN30 Pro but has ergonomic wing grips.

The software

This is the part I’ve fiddled the least with, intentionally. I just want it to work reasonably well. I downloaded RetroPie, wrote it to a MicroSD card, and ran it. The only reason confusion came from the initial startup: it booted up to a RetroPie configuration menu, and that was it. I sort of expected a list of emulators, or some sample open source games, or similar. Turns out the emulated systems will automatically appear once you upload ROMs to it, something easily done with scp.

Obviously I’m not going to get into the legal or moral aspects of ROMs, but I will say I’ve got ROMs of the cartridges I’ve purchased, as detailed in a previous post. I even headed to a local retro game shop one weekend (yes, we have a local retro game shop), picked up a few PS1 games and ripped them.

(Is it a problem that I’ve ripped CDs for a system I’ve never owned? Technically yes, since the PS1 emulator requires a BIOS ripped from original hardware. But hey, Sony sued Lik-Sang out of existence, so screw them. Yes, I’m still bitter.)

Overall, emulator performance and compatibility is excellent with nearly any system of PS1 era or older, with one exception. NES, SNES, Game Boy and PS1 games all seem to work great. The one major exception is the Nintendo 64. In general, don’t bother on the Raspberry Pi, or use a modern desktop PC if N64 emulation is desired. RetroPie has an entire page of half-baked tips and tricks to get acceptable N64 speed on a case-by-case basis, but even its own docs discourage you from trying. The Raspberry Pi just isn’t powerful enough for the N64’s quirky architecture.

In general, I’ve mostly left the RetroPie software itself alone, but there are a few tweaks I’ve made. I’ve forced the resolution to 1280x720 (on my massive 4K TV) and enabled integer scaling for better performance, with the idea that the emulator should spend as little effort as possible on actually outputting the graphs, and let the TV handle the rest. I also needed to install handler software for the case’s power/reset GPIO buttons, even though I don’t ever turn off the system itself.

The blockiness of the graphics on a 65” TV are noticeable, so I spent a day playing with various graphics shaders, but eventually settled on the simple built-in bilinear filter. It softens things but doesn’t do anything else. People will argue endlessly about scanlines, but my rose-tinted glasses don’t remember scanlines being part of the authentic CRT experience growing up, so they don’t look “right” to me.

Overall, I think I’ve accomplished my goal. A simple retro system which is fun and easy to pick up and play.

« All posts