The springs in a bag.
18 June 2021
Cherry MX Spring Modification
A few years ago, I did a spring mod of some Cherry MX switches that made it a little harder to press certain keys, but it was an imperfect solution. I don't remember how I got to looking for a single-spring solution, but I found a bunch that had higher forces than the stock 80cN springs I was using, and it was hard to decide what sort of force to go with without testing them. I went with 210 gram force springs and ordered about 3 dozen of them because I didn't need too many and they weren't all that cheap.
While they look quite long, that was a length I wasn't concerned about since it was really more about the compressed length that was one of the limiting factors. It's slightly larger in diameter than the standard springs, but it still fits fine. This spring makes it a bit harder to reassemble the switch, but not difficult or impossible. Once I had the switch on a board, it was a lot harder to press than I thought (or tried before soldering), but it's blatantly obvious when accidentally hitting it. I think the spring moves a bit weird in the switch because the click doesn't always happen when the switch actuates, so I could've used a red or silent red or whatever instead of the blue stem, oh well.
Hackintosh
With some of the programmes I was writing (the world clocks one being the one I remember best), a friend wanted to be able to use it, but he daily drives Mac OS, so there wasn't an easy way to allow him to use it without compiling the programme. And because i3rd was superceded by Pod, I decided to put i3rd to use by making a hackintosh. I used the 120GB 2.5 inch SSD from the double drive pi (I think that was the Raspberry Pi 3?) as the boot drive since I wasn't going to need a huge amount of space and I didn't want to buy anything if I didn't have to.
I found some reddit where someone did a hackintosh with the same DeskMini that I have but with a generation older CPU and went the same route as them since there was the links to the instructions and stuff. It wasn't too bad from what I remember, but I think there were times that I wasn't sure if the installation was being slow or if it froze.
The one thing I couldn't figure out how to fix was getting more VRAM than 5MB, I tried a lot of things and eventually decided to just live with it. I did get whichever stuff tested/compiled and such, though with one of them, the GUI glitches out when running, which is likely due to the lack of VRAM (this was during testing and it didn't get compiled or shared).
I have plans to try a Mac OS VM with VirtualBox (since it might allow me to have 128MB of VRAM), but I keep forgetting about it. It's uncertain when my friend will shift to Apple Silicon, but it'll be when I'll grab a Mac Mini with the same SoC to not have to worry about using a VM or having VRAM issues.
I found some reddit where someone did a hackintosh with the same DeskMini that I have but with a generation older CPU and went the same route as them since there was the links to the instructions and stuff. It wasn't too bad from what I remember, but I think there were times that I wasn't sure if the installation was being slow or if it froze.
The one thing I couldn't figure out how to fix was getting more VRAM than 5MB, I tried a lot of things and eventually decided to just live with it. I did get whichever stuff tested/compiled and such, though with one of them, the GUI glitches out when running, which is likely due to the lack of VRAM (this was during testing and it didn't get compiled or shared).
I have plans to try a Mac OS VM with VirtualBox (since it might allow me to have 128MB of VRAM), but I keep forgetting about it. It's uncertain when my friend will shift to Apple Silicon, but it'll be when I'll grab a Mac Mini with the same SoC to not have to worry about using a VM or having VRAM issues.
Qt5
Sometime after making a GUI programme to help a friend run a trivia game (I guess beginning of last year), I started looking into Qt5 because I was having problems with certain Unicode characters causing Tkinter to either crash or screw with displayed text. Might've been other reasons, but it's so long ago that I don't remember.
I learned it by converting my Tkinter programmes, and it was fairly easy to learn since I already had learned a lot of the logic from Tkinter. I think it might've been a couple weeks before I fell in love with Qt5. Anyway, there was a lot of learning and having to go back to programmes I previously converted to add/fix stuff.
Also I think around this time I also learned classes better, which made things easier to do.
It probably was after a couple or so months that I kinda lost steam to convert all the Tkinter programmes (probably because I hardly ever used the last couple I had to left convert) and just moved onto new projects. One of those projects was having a programme that helps me do stuff in EAGLE CAD in the sense that I can plug values into it and it spits out the value I'm looking for. I do know that EAGLE has ULPs, but that's a C-like language and not Python. Anyway, the reason for this is that it was time consuming to draw the parts of the board layout in Fusion 360 to get a value (sometimes having to do this multiple times), and it really is just all mathematics in the end. Also, I'm sticking with EAGLE 7.7.0 btw because it's annoying to have to login for the free version of EAGLE 8+, especially if I'm needing to just look at something real quick.
Anyway, each calculation I made into its own class and then used the main class to place it in the category it belongs to for display. It took a while to figure out how to arrange all the classes without making the window too large, and I ended up finding QScrollArea that really helped keep the width of the programme minimal. After a couple months of working on it (and still not being done), I decided to just leave it for now, since everything within it works and I have around 4000 lines of code. Yeah, I should probably break the classes into their own modules instead, but I don't really feel like working on it regardless.
I've also done a world clock sort of programme that utilises QDateTime and QTimeZone, which I think are better than Python's built-in date/time/timezone solution? There's also QTimer which allows a function to be ran after the set timer expires (which is used in said world clock programme to update the time display every second instead of using a while loop and
It was earlier this year when Qt6 was released, and I decided to poke with it a bit since I probably should move to it, but ran into issues on one of the programmes I converted as a test. There were some name changes (QRegExp → QRegularExpression) or ways to access certain items (QMessageBox.Ok → QMessageBox.StandardButtons.Ok), and when I got everything fixed up, it worked... except for the theme. I use a weird mixture of qt5ct and Kvantum, and just couldn't figure out how to stylise/theme Qt6 to match.
And speaking of name changes, when I was trying to load the Qt6 version of the programme, I ran into more errors because of more name changes (QMessageBox.StandardButtons.Ok → QMessageBox.StandardButton.Ok and Qt.Alignment.AlignCenter → Qt.AlignmentFlag.AlignCenter) (frustration noises here). Anyway I dunno when Qt5 will be end of life, but it probably won't be for at least a few years, and hopefully whenever the time comes, Qt6 will have the maturity that Qt5 currently has.
I learned it by converting my Tkinter programmes, and it was fairly easy to learn since I already had learned a lot of the logic from Tkinter. I think it might've been a couple weeks before I fell in love with Qt5. Anyway, there was a lot of learning and having to go back to programmes I previously converted to add/fix stuff.
Also I think around this time I also learned classes better, which made things easier to do.
It probably was after a couple or so months that I kinda lost steam to convert all the Tkinter programmes (probably because I hardly ever used the last couple I had to left convert) and just moved onto new projects. One of those projects was having a programme that helps me do stuff in EAGLE CAD in the sense that I can plug values into it and it spits out the value I'm looking for. I do know that EAGLE has ULPs, but that's a C-like language and not Python. Anyway, the reason for this is that it was time consuming to draw the parts of the board layout in Fusion 360 to get a value (sometimes having to do this multiple times), and it really is just all mathematics in the end. Also, I'm sticking with EAGLE 7.7.0 btw because it's annoying to have to login for the free version of EAGLE 8+, especially if I'm needing to just look at something real quick.
Anyway, each calculation I made into its own class and then used the main class to place it in the category it belongs to for display. It took a while to figure out how to arrange all the classes without making the window too large, and I ended up finding QScrollArea that really helped keep the width of the programme minimal. After a couple months of working on it (and still not being done), I decided to just leave it for now, since everything within it works and I have around 4000 lines of code. Yeah, I should probably break the classes into their own modules instead, but I don't really feel like working on it regardless.
What it currently looks like.
The precision selection, Ω button, and µ button was added later (the buttons put the corresponding symbols on the clipboard). (Also Qt5 allows for clipboard reading/writing, which is really nice.)
The precision selection, Ω button, and µ button was added later (the buttons put the corresponding symbols on the clipboard). (Also Qt5 allows for clipboard reading/writing, which is really nice.)
I've also done a world clock sort of programme that utilises QDateTime and QTimeZone, which I think are better than Python's built-in date/time/timezone solution? There's also QTimer which allows a function to be ran after the set timer expires (which is used in said world clock programme to update the time display every second instead of using a while loop and
time.sleep(), also you can stop a QTimer with code but not time.sleep()). At this point, I forgot what Tkinter provided that Qt5 doesn't, but I've long adapted to it with a lot of the other things Qt5 provides. It also has its own multi-threading framework, which I think is also easier to use than Python's, especially if I've been using it here and there for things that can really leverage multiple threads.It was earlier this year when Qt6 was released, and I decided to poke with it a bit since I probably should move to it, but ran into issues on one of the programmes I converted as a test. There were some name changes (QRegExp → QRegularExpression) or ways to access certain items (QMessageBox.Ok → QMessageBox.StandardButtons.Ok), and when I got everything fixed up, it worked... except for the theme. I use a weird mixture of qt5ct and Kvantum, and just couldn't figure out how to stylise/theme Qt6 to match.
Qt5 with the style/theme I have set, Qt6 default style/theme (I'm assuming).
And speaking of name changes, when I was trying to load the Qt6 version of the programme, I ran into more errors because of more name changes (QMessageBox.StandardButtons.Ok → QMessageBox.StandardButton.Ok and Qt.Alignment.AlignCenter → Qt.AlignmentFlag.AlignCenter) (frustration noises here). Anyway I dunno when Qt5 will be end of life, but it probably won't be for at least a few years, and hopefully whenever the time comes, Qt6 will have the maturity that Qt5 currently has.
17 June 2021
Raspberry Pi Clock
I had the idea for a while, but didn't really do too much with it until I had the Raspberry Pi 0 W boards from the Bluetooth SNES controller to SNES converter. One thing I didn't mention in that post was that I was planning to use some probe pins (aka "pogo pins") to connect the board to the GPIO pins, which carried over here. Reason for it is that it frees up space for trace routing, makes it easier to swap the boards as needed, and increases compactness.
Anyway, I think I originally started with using counters to run the seven-segment displays, which would require a pulse every so often over one pin, but would require a few more to set the display faster. I did get a breadboard, a seven-segment display or two, and a couple of the counters to test it out and it did work, but it was really fast since I was using jumper cables. Besides that, this version never really got anywhere else.
I think after the controller converter, I was going to maybe use the SN7407 for driving each segment, but probably didn't have enough GPIO pins? I forgot how I learned about the 74HC595 (probably looking sometehing up?), but after understanding how to use it, it was something better to use, since I only needed three GPIO pins. Before I forget, there seems to be a 74HC595 that has SPI communication, but I'm pretty sure I'm not talking about that one because it doesn't seem to be chainable?
One of my requirements for the clock was to have a button to turn the display on at minimum brightness while the button is held and to have a switch that would turn the display on at full brightness (well, within reason), and from getting a better idea of transistors from a previous project, I used a NPN transistor to connect the ground lines of the displays to ground. The only thing that was unclear was what resistor values I would need for the button and the switch, so I designed a prototype board that was derived from the final board for making it easy to test various resistances.
I also had read how to add an RTC (DS3231) to the Raspberry Pi, and I added it because I had the space and it'd make the clock less reliant on the internet for the correct time. With space still leftover, I also decided to add a temperature sensor (DS18B20, and yes, the DS3231 has its own sensor, but I wanted to leave it alone) using an FFC connector, and a flat flex board that the sensor would be carefully soldered to. It was a little tough to design the flat flex board because I hadn't designed the case at all (though I had ideas of how I wanted it to be), so I had originally desiged it with a right-angle bend, which would end up costing a lot because of the unused space to make a rectangle. Eventually I had a "duh" moment where I could just make a straight board and have it go around the back of the Raspberry Pi to where I wanted the sensor to be (outside of the case and isolated from the inside of the case).
There were also two more switches to be able to flip the display (if the display was upsidedown) and to display the temperature instead or the time. I also had a couple headers for the RTC's backup battery connection and a 5-volt input connection (I was going to use a DC jack so that it's more robust, compactish, and so I can have the cable run along the length of the clock).
I really didn't do anything with it for a while, and then I decided to dig into CircuitPython more, which led me to other solutions. I had made a very basic prototype board to be able to tweak the brightness with the intended transistor, a variable resistor (in the standard voltage divider circuit format), and the button I was intending to use. Powering it from 5 volts made it kinda tough to adjust, but it was doable.
I don't remember if it was this or the controller converter board where I measured the GPIO holes (only a couple) with a pin gauge and found them to be scarily close to the maximum of the probe pin diameter (based on the datasheet), but it wasn't until after I had ordered some pins for something else that I was able to test the pins to the GPIO holes. Suffice to say, they fit right into the hole, so I had to scrap the idea and look for something else. I did find a fairly low-profile header and mating socket, since I was trying to keep the distance between the top of the boards around 6mm (which is the distance I calculated for the controller converter board). Of course, this meant that I had less dead space for resistors and capacitors on the board, so they had to get moved.
Since I was using the SOIC package for the 74HC595, I didn't have a lot of space to move the resistors and caps to while trying to keep the board area underneath the display clear in case I do solder the displays directly to the board instead of using the planned sockets. I went with a smaller but wider package and it gave me plenty of room to stick the caps for each of them between them. For the resistors, I used a bussed resistor for all the inputs that needed to be pulled up to save space, and it allowed me to move the resistor for the temperature sensor underneath the board near the FFC connector (which is on top).
While playing with the Adafruit dev board I had (Trinket M0), I decided to toy around with using its onboard DAC and modded the prototype to be able to control the transistor's base from the DAC (the variable resistor is isolated from the base via the button), and it made it so much easier to control the brightness. I found a DAC (MCP4725) that has a CircuitPython library that I'd be able to use, so I added it to the board and re-routed the button and the switch to the GPIO pins instead. I also tweaked the code after saving a copy.
I found a temperature sensor (MCP9808) that has a CircuitPython library, and even though I don't like its package, I decided to use it while scrapping the case (I had modelled the case when I had the first iteration of the board finished). Doing so freed up some space, and I decided to just use a right-angle connector USB cable to the Raspberry Pi's micro USB port, which meant removing the flip functionality since it won't really sit well on the cable. With this, I dropped the switch count from three to one, and the switch displays the time or temperature and has the display at full brightness with either position. I also just used some vias for the backup battery instead of an actual connector since it'd be a little more compact and I didn't feel like running a long trace to where I have space for the connector to the RTC. I went back to discrete resistors because I only had three things to pull up and had the space for them. I also made another copy of the code and changed it accordingly.
I was also working on an internet-connected microcontroller clock around this time, and for it I had a different GPIO expander that connected via I²C (MCP23017) which I was going to use for another revision of this board, but I ended up dropping this project in favour of the microcontroller version. I was also going to add an accelerometer from that project to this one as well. The microcontroller version ended up being a little easier to work with in the code, but I think the main thing is that the board size is smaller than the one for this project, even if the total parts cost would end up being about the same.
Oh, I learned how to tent vias at or under a certain size sometime around the second revision, which made it easier to not have to worry about putting vias too close to stuff being soldered. And I also didn't think about the permanent dot point segments that I was using for a makeshift colon, so I had a note to fix that within the code (which I might've done, I don't remember) in the second and/or third revision board layout(s).
Anyway, I think I originally started with using counters to run the seven-segment displays, which would require a pulse every so often over one pin, but would require a few more to set the display faster. I did get a breadboard, a seven-segment display or two, and a couple of the counters to test it out and it did work, but it was really fast since I was using jumper cables. Besides that, this version never really got anywhere else.
I think after the controller converter, I was going to maybe use the SN7407 for driving each segment, but probably didn't have enough GPIO pins? I forgot how I learned about the 74HC595 (probably looking sometehing up?), but after understanding how to use it, it was something better to use, since I only needed three GPIO pins. Before I forget, there seems to be a 74HC595 that has SPI communication, but I'm pretty sure I'm not talking about that one because it doesn't seem to be chainable?
One of my requirements for the clock was to have a button to turn the display on at minimum brightness while the button is held and to have a switch that would turn the display on at full brightness (well, within reason), and from getting a better idea of transistors from a previous project, I used a NPN transistor to connect the ground lines of the displays to ground. The only thing that was unclear was what resistor values I would need for the button and the switch, so I designed a prototype board that was derived from the final board for making it easy to test various resistances.
I also had read how to add an RTC (DS3231) to the Raspberry Pi, and I added it because I had the space and it'd make the clock less reliant on the internet for the correct time. With space still leftover, I also decided to add a temperature sensor (DS18B20, and yes, the DS3231 has its own sensor, but I wanted to leave it alone) using an FFC connector, and a flat flex board that the sensor would be carefully soldered to. It was a little tough to design the flat flex board because I hadn't designed the case at all (though I had ideas of how I wanted it to be), so I had originally desiged it with a right-angle bend, which would end up costing a lot because of the unused space to make a rectangle. Eventually I had a "duh" moment where I could just make a straight board and have it go around the back of the Raspberry Pi to where I wanted the sensor to be (outside of the case and isolated from the inside of the case).
There were also two more switches to be able to flip the display (if the display was upsidedown) and to display the temperature instead or the time. I also had a couple headers for the RTC's backup battery connection and a 5-volt input connection (I was going to use a DC jack so that it's more robust, compactish, and so I can have the cable run along the length of the clock).
I really didn't do anything with it for a while, and then I decided to dig into CircuitPython more, which led me to other solutions. I had made a very basic prototype board to be able to tweak the brightness with the intended transistor, a variable resistor (in the standard voltage divider circuit format), and the button I was intending to use. Powering it from 5 volts made it kinda tough to adjust, but it was doable.
I don't remember if it was this or the controller converter board where I measured the GPIO holes (only a couple) with a pin gauge and found them to be scarily close to the maximum of the probe pin diameter (based on the datasheet), but it wasn't until after I had ordered some pins for something else that I was able to test the pins to the GPIO holes. Suffice to say, they fit right into the hole, so I had to scrap the idea and look for something else. I did find a fairly low-profile header and mating socket, since I was trying to keep the distance between the top of the boards around 6mm (which is the distance I calculated for the controller converter board). Of course, this meant that I had less dead space for resistors and capacitors on the board, so they had to get moved.
Since I was using the SOIC package for the 74HC595, I didn't have a lot of space to move the resistors and caps to while trying to keep the board area underneath the display clear in case I do solder the displays directly to the board instead of using the planned sockets. I went with a smaller but wider package and it gave me plenty of room to stick the caps for each of them between them. For the resistors, I used a bussed resistor for all the inputs that needed to be pulled up to save space, and it allowed me to move the resistor for the temperature sensor underneath the board near the FFC connector (which is on top).
While playing with the Adafruit dev board I had (Trinket M0), I decided to toy around with using its onboard DAC and modded the prototype to be able to control the transistor's base from the DAC (the variable resistor is isolated from the base via the button), and it made it so much easier to control the brightness. I found a DAC (MCP4725) that has a CircuitPython library that I'd be able to use, so I added it to the board and re-routed the button and the switch to the GPIO pins instead. I also tweaked the code after saving a copy.
I found a temperature sensor (MCP9808) that has a CircuitPython library, and even though I don't like its package, I decided to use it while scrapping the case (I had modelled the case when I had the first iteration of the board finished). Doing so freed up some space, and I decided to just use a right-angle connector USB cable to the Raspberry Pi's micro USB port, which meant removing the flip functionality since it won't really sit well on the cable. With this, I dropped the switch count from three to one, and the switch displays the time or temperature and has the display at full brightness with either position. I also just used some vias for the backup battery instead of an actual connector since it'd be a little more compact and I didn't feel like running a long trace to where I have space for the connector to the RTC. I went back to discrete resistors because I only had three things to pull up and had the space for them. I also made another copy of the code and changed it accordingly.
I was also working on an internet-connected microcontroller clock around this time, and for it I had a different GPIO expander that connected via I²C (MCP23017) which I was going to use for another revision of this board, but I ended up dropping this project in favour of the microcontroller version. I was also going to add an accelerometer from that project to this one as well. The microcontroller version ended up being a little easier to work with in the code, but I think the main thing is that the board size is smaller than the one for this project, even if the total parts cost would end up being about the same.
Oh, I learned how to tent vias at or under a certain size sometime around the second revision, which made it easier to not have to worry about putting vias too close to stuff being soldered. And I also didn't think about the permanent dot point segments that I was using for a makeshift colon, so I had a note to fix that within the code (which I might've done, I don't remember) in the second and/or third revision board layout(s).
16 June 2021
Bluetooth SNES Controller to SNES Converter via Raspberry Pi
A long time ago my (half) brother let me use his SNES for numerous years, but some years ago he took it back, and I was left with the games. I eventually saw a review video that Linus Tech Tips did on the Super NT, and after some months, I bought one to be able to play my SNES games again whenever I wanted to. I also bought an 8Bitdo Bluetooth SNES controller with receiver for the SNES, since I kinda wanted the buttons to have the Super Famicom colour scheme, and also because the wired controller I have is a Mad Catz High Performance controller (see below the break) that had a broken directional pad (think of it as a very cheap version of the directional pad on the XBox 360 controller). (Pretty much I was left with a short stick that still allowed use of the directional pad, but it wasn't something to use for anything serious... Also it didn't have any sort of "centre nub" that prevented all four directions being pressed at the same time.)
Anyway, Nintendo released their SNES emulator for Switch Online subscribers (I'm calling it a SNES emulator because that's pretty much what it is and it'll be easier to make the distinction), and I was able to use the 8Bitdo controller fine except for the screenshot or home buttons (which were needed for the emulator menus), but I ended up just using the Joy Cons instead. I forgot when Nintendo launched their Bluetooth SNES controller (again, making distinctions), but I bought a set of four (the max per account) so that I'd have two for the emulator and two for the Super NT. I also bought another 8Bitdo Bluetooth controller receiver for the SNES, which kinda sat after I made sure it worked with the 8Bitdo controller.
When I finally got Nintendo's Bluetooth SNES controllers, they wouldn't pair with the receivers (pretty sure that's what it was), and after checking if there were firmware updates for the receivers, there were none. I decided to take matters into my own hands since I was able to pair the controllers just fine with Pod or my phone, and it shouldn't be that hard to translate the inputs to GPIO outputs. I looked up what ways I had to level shift the 3.3-volt outputs to 5 volts, and besides transistors, I found the SN7407. I also found the CD4021 used in some example SNES/NES controller circuits.
While attempting to design a board, I ran into the issue of where to source the voltage for the SN7407, the pull-up resistors, and the CD4021. I designed an experimentation board that allowed me to switch which 5-volt source to use (either the Raspberry Pi or theSNES Super NT), and which ground to use (only for the ICs). It also had some small tactile buttons so I'd be able to test with a game running and a 5-position tiny XLR connector for connection to the Super NT (more on this later). What I found was to power the CD4021s from the Super NT, and everything else from the Raspberry Pi. I think I modded the board for some reason, but it's escaping me (I think it might've been that the buttons were supposed to connect the SN7407 input pins to ground and not 3.3 volts). With the needed information, I was able to continue on with the final board.
Originally I was going to make one Raspberry Pi handle one player, but I can't remember what lead me to making a board for both players and having one Raspberry Pi handle both players. I also had done some testing with Pod and one of the controllers to poke around with the button values and such.
With all the work I had done (thankfully no other boards besides the experimentation was made), 8Bitdo had finally released the firmware update that included Nintendo's Bluetooth SNES controllers, and I dropped the project since it was no longer needed. Unfortunately I already had bought two Raspberry Pi 0 W boards (from different vendors), but they would end up reserved for another project.
I think it might've waited a while between when Nintendo launched the Bluetooth SNES to starting this project, since the experiment board was designed in June of last year.
Resources I used before I dropped the project:
The reasoning for the 5-position tiny XLR connectors was that the Mad Catz controller had a wire break near the plug, so I had to hack something together to get it working once more (besides taping the wire to the connector in a position that it would work). I used some SNES controller extension cables to make an adapter to connect the Mad Catz controller to the SNES, an XLR to XLR extension (or to be able to plug in the experiment board), and another adapter so that the SNES to SNES extension can still happen if needed.
To fix the directional pad, I grabbed the old directional pad top and bottom from my XBox 360 controller (I reshelled it from white to black), and used the bottom to model the receiver and bottom plate for the Mad Catz controller. I got a stepper drill to increase the hole size in the controller for the new directional pad assembly and drilled it out to the approximate size of the one in the Xbox 360 controller.
I had the receiver 3D printed via FDM process and while it looked okay, it really wasn't. Besides it having a little more flex than I wanted, some of the holes were undersized, so when I did some sort of test fit (can't remember if it was with or without the Mad Catz controller), I had to use a drill to be able to separate the top piece from the receiver, destroying the only spare XBox 360 directional pad top I had. It was a little tough to decide whether to buy a button set that included the piece I needed or to order a couple dozen of the piece I needed, but I eventually went with the latter.
I think I just had the receiver reprinted with MJF (multi-jet fusion), but with it showed that I had a portion too thick because I screwed up the maths — the button press pads and the connecting plate were supposed to be 3mm thick total, not the plate itself. After the fix (and some tweaks to the keying in the plate), I sent it off to be printed (still MJF), and when I got it, it worked as intended. I also did have to find my own screws to join the top to the receiver (no screws was included with the reshelling kit), but with a small box of salvaged screws, I found something that worked (this was confirmed before I had the FDM receiver).
It looks a bit weird because the XBox 360 directional pad top leaves a larger gap in the recess than the original (though the original was long gone before this, so I don't have a proper size comparison), but it's functionally fine otherwise. I didn't realise that I adjusted the angle of the directional pad until now, but from the testing after finishing the project, I didn't notice any issues? Or maybe I'm just seeing things, I dunno.
I dunno how they assembled the directional pad, but I do remember it had a 5-6mm diameter plastic shaft connecting the inside piece to the top piece, and because there was a lot of space below the top piece when pressing down, it slowly strained the plastic where the top piece and shaft meet until the top piece broke off. I think I tried to super glue it back on, but it didn't work (also, this was numerous years ago).
Since I found pictures that I had...
Anyway, Nintendo released their SNES emulator for Switch Online subscribers (I'm calling it a SNES emulator because that's pretty much what it is and it'll be easier to make the distinction), and I was able to use the 8Bitdo controller fine except for the screenshot or home buttons (which were needed for the emulator menus), but I ended up just using the Joy Cons instead. I forgot when Nintendo launched their Bluetooth SNES controller (again, making distinctions), but I bought a set of four (the max per account) so that I'd have two for the emulator and two for the Super NT. I also bought another 8Bitdo Bluetooth controller receiver for the SNES, which kinda sat after I made sure it worked with the 8Bitdo controller.
When I finally got Nintendo's Bluetooth SNES controllers, they wouldn't pair with the receivers (pretty sure that's what it was), and after checking if there were firmware updates for the receivers, there were none. I decided to take matters into my own hands since I was able to pair the controllers just fine with Pod or my phone, and it shouldn't be that hard to translate the inputs to GPIO outputs. I looked up what ways I had to level shift the 3.3-volt outputs to 5 volts, and besides transistors, I found the SN7407. I also found the CD4021 used in some example SNES/NES controller circuits.
While attempting to design a board, I ran into the issue of where to source the voltage for the SN7407, the pull-up resistors, and the CD4021. I designed an experimentation board that allowed me to switch which 5-volt source to use (either the Raspberry Pi or the
Originally I was going to make one Raspberry Pi handle one player, but I can't remember what lead me to making a board for both players and having one Raspberry Pi handle both players. I also had done some testing with Pod and one of the controllers to poke around with the button values and such.
With all the work I had done (thankfully no other boards besides the experimentation was made), 8Bitdo had finally released the firmware update that included Nintendo's Bluetooth SNES controllers, and I dropped the project since it was no longer needed. Unfortunately I already had bought two Raspberry Pi 0 W boards (from different vendors), but they would end up reserved for another project.
I think it might've waited a while between when Nintendo launched the Bluetooth SNES to starting this project, since the experiment board was designed in June of last year.
Resources I used before I dropped the project:
- https://www.digikey.com/en/maker/projects/diy-super-nintendo-breadboard-controller/788fd6f521824fb58715ca0b95b92840
- https://gamesx.com/wiki/doku.php?id=controls:nes_snes_controller
- https://elinux.org/RPi_GPIO_Interface_Circuits
- https://core-electronics.com.au/tutorials/using-usb-and-bluetooth-controllers-with-python.html
The reasoning for the 5-position tiny XLR connectors was that the Mad Catz controller had a wire break near the plug, so I had to hack something together to get it working once more (besides taping the wire to the connector in a position that it would work). I used some SNES controller extension cables to make an adapter to connect the Mad Catz controller to the SNES, an XLR to XLR extension (or to be able to plug in the experiment board), and another adapter so that the SNES to SNES extension can still happen if needed.
To fix the directional pad, I grabbed the old directional pad top and bottom from my XBox 360 controller (I reshelled it from white to black), and used the bottom to model the receiver and bottom plate for the Mad Catz controller. I got a stepper drill to increase the hole size in the controller for the new directional pad assembly and drilled it out to the approximate size of the one in the Xbox 360 controller.
I had the receiver 3D printed via FDM process and while it looked okay, it really wasn't. Besides it having a little more flex than I wanted, some of the holes were undersized, so when I did some sort of test fit (can't remember if it was with or without the Mad Catz controller), I had to use a drill to be able to separate the top piece from the receiver, destroying the only spare XBox 360 directional pad top I had. It was a little tough to decide whether to buy a button set that included the piece I needed or to order a couple dozen of the piece I needed, but I eventually went with the latter.
I think I just had the receiver reprinted with MJF (multi-jet fusion), but with it showed that I had a portion too thick because I screwed up the maths — the button press pads and the connecting plate were supposed to be 3mm thick total, not the plate itself. After the fix (and some tweaks to the keying in the plate), I sent it off to be printed (still MJF), and when I got it, it worked as intended. I also did have to find my own screws to join the top to the receiver (no screws was included with the reshelling kit), but with a small box of salvaged screws, I found something that worked (this was confirmed before I had the FDM receiver).
It looks a bit weird because the XBox 360 directional pad top leaves a larger gap in the recess than the original (though the original was long gone before this, so I don't have a proper size comparison), but it's functionally fine otherwise. I didn't realise that I adjusted the angle of the directional pad until now, but from the testing after finishing the project, I didn't notice any issues? Or maybe I'm just seeing things, I dunno.
Normal (probably about 2mm around the directional pad) and mine (about 5mm around the directional pad).
I dunno how they assembled the directional pad, but I do remember it had a 5-6mm diameter plastic shaft connecting the inside piece to the top piece, and because there was a lot of space below the top piece when pressing down, it slowly strained the plastic where the top piece and shaft meet until the top piece broke off. I think I tried to super glue it back on, but it didn't work (also, this was numerous years ago).
Since I found pictures that I had...
Boards, finished board top, finished board bottom, and modded board.
14 June 2021
Pod 126
Forgot where I wrote about wanting to wait to build another full computer until AM4+ or AM5, but I decided to build something because i3rd has a maximum output of 2 displays and I was really needing a third. I was thinking of doing an AMD mini-STX build (because by then ASRock released an AMD version of the DeskMini) because it's capable of outputting 3 displays, but with knowing how much i3rd cost, it was a tad bit hard to justify (even if I was going to reuse the storage and possibly the RAM). It also would've kinda thrown a wrench in my plan of building the AM4+ or AM5 system and a Threadripper system (at different times) while using a Nier:Automata theme.
So with the launch of Ryzen 3000 series and the X570 chipset, I began to wait for ASUS to release either their X570 mini-ITX board or their X570 mini-DTX board because of the amount of rear USB ports and such. In anticipation, I bought Thermaltake's Core V1 case because I was wanting to use a spare ATX/EPS power supply instead of buying an SFX power supply to keep the case small. I think it was about September when I gave up waiting and went with Gigabyte's X570 mini-ITX board instead and also grabbed a Ryzen 5 3600 since I was planning on doing a CPU upgrade to whatever the last supported high-core count CPU would be. It took me a while to find the motherboard because the local computer store said they had 4 in stock, but I couldn't seem to find it. Why? Because it was on the bottom shelf and practically shoved all the way back (not front-faced). (Captain Picard or Uncle Iroh facepalm here) To make matters worse, no employee was available for help, so it took 10 or so minutes before I found it.
I did a post test at my friend's because he lives much closer, and it posted just fine. At home the following day, I found out the Core V1's standoffs are just bent pieces of the metal tray, so I had to remove the motherboard's backplate. Oh right, I also grabbed 16GB of DDR4 3200 RAM from the computer store since it was the cheaper option than buying online. For the CPU cooler, I went with Noctua's NH-U9S because it was the largest I'd be able to fit in the case and Noctua's site says the cooler would handle the Ryzen 9 3950X (I think they were out and tested by Noctua at that point). Went with a Sapphire Radeon RX570 because it has 5 display outputs (two DisplayPort, two HDMI, one DVI-D) instead of the three that the RX560 has (DisplayPort, HDMI, VGA) because it'd allow a little more flexibility, even though I'd be using adapters.
"Pod 126" came from my deconstruction of the Pod numbers compared to the Yorha units. It took a while to figure out, and I think I had to do it twice because I didn't save the first spreadsheet where I figured it out. 2B's Pod unit is numbered 042 while 9S' Pod unit is numbered 153, and the way I figured it out was that 42 divided by 2 is 21 while 153 divided by 9 is 17. With 6 numbers between 2 and 9, the multipliers would have to be doubled... A table would make this easier...
I'm not entirely sure what I did to originally figure it out (I only really remember that the original spreadsheet is larger than the one I have now), but this is pretty much what I came up with. I think when I first did the spreadsheet, I was under the impression that the Threadripper build would be the 8th AMD computer I built for myself, but I think when I was figuring it out again, I ended up with it being the 7th (and consequently, I had to get the corresponding Pod number since I originally was under the 8/144 impression).
Anyway, I had also gotten a couple 3.5 inch drives to replace the 2.5 inch drives from i3rd because the Core V1 case was able to accommodate them (technically, it can handle two 3.5 inch drives and two 2.5 inch drives or four 2.5 inch drives). I also took the ThermalTake badge off the front of the case because I wanted it to look a little cleaner, even if it meant having a weird depression in the front where the badge was. The back of the Core V1 has spots for two 80mm fans, which is a weird decision since there's plenty of space for two 92mm fans instead, but I still filled it out to try to help exhaust the air. I also swapped the stock 200mm fan for Noctua's, but with how the case ended up being, I had positive pressure that ended up exhausting air out of the side intake where the GPU is.
Eventually, SilverStone Technology announced the SUGO 14 case and I was quite interested in it because it allowed installation of one 5.25 inch device, had removable filters on the side panels (the Core V1 has non-removable foam in the front bezel and nothing else for filtration), and had normal motherboard standoffs (or at least much closer to normal compared to the Core V1). After really looking around at it from the images and deciding to replace the Core V1, I preordered it and got it on launch day.
I had to go back to 2.5 inch hard drives since I wouldn't be able to mount any 3.5 inch drives with the optical drive (well, the CPU cooler also prevents this), but it wasn't too big of deal since I also ordered a 2.5 inch 2TB drive for the files and used the old 1TB from Bazett/i3rd for micellany. I had to put the 1TB drive on the front while I finished engineering (and waiting for the MJF 3D print to arrive) the adapter bracket to mount it on the removable side frame next to the CPU cooler since there was enough space to do so.
Unfortunately, after transplanting everyting from the Core V1 to the SUGO 14, Pod didn't boot. I tried borrowing Lie-chan's PSU (which was the same model), reseating the RAM, reseating the CPU, trying one stick of RAM in one slot, but I couldn't get Pod to post. My thoughts were the motherboard, CPU, or PSU since I didn't have any extra on hand, and I decided to head to the computer store with Pod without storage for their diagnosis/repair service. Fortunately, the tech did a basic diagnosis with a different set of RAM and different PSU and Pod booted, confirmed that it was the PSU after the tech put my RAM back in and used a PSU tester on Lie-chan's PSU (I didn't feel like putting Pod's PSU back in when doing my bit of diagnosis). After buying a PSU, I went home and everything was fine, but I didn't think about how the case holds the PSU, so Corsair's PSU was not the best choice because of the large chamfers on the edges. I decided to just make some adapter wedges to make it sturdier, and after a second round, it worked (first sets were bad because I didn't get proper measurements). Also had some of the other employees at the computer store ask about my case, which was kinda cool to incidentally show off a brand new case.
With the new PSU, I decided to try CableMod cables out for the ATX connector because I didn't feel like taking Pod offline to see how Corsair wired their cable to make my own. While the CableMod cable was better than the one from Corsair (in terms of excess length), I ended up figuring out the wiring of it (before using it) and the Corsair cable (after the cable swap) and made my own which would be shorter and less annoying than either. I also did a custom PCIe power cable adapter back when using the Core V1, and then made a custom cable for the Corsair PSU. I also made a custom EPS connector for the Corsair PSU. I think it was sometime after I got the custom 2.5 inch HDD bracket when I made the custom SATA power cables for all the drives, including the two bays in the front.
I only have a 120mm and 140mm fan as the top and rear exhausts so that it's negative pressure, and I was planning on the PSU also be exhaust, but the PSU has a 0RPM mode, so that plan fell through. At least with the airflow being negative pressure instead of positive, the GPU stays cooler now.
I also made a magnetic swivelling cover for the power button that has Pod's name on it because I didn't want to accidentally press it (though I have it set to do nothing in Linux and Windows) and to also be able to have the power on light on because it looks nicer than the power on light on the Core V1.
Underneath the small hexagon at the top is a 4mm diameter magnet press-fitted into a recess, and another 4mm diameter magnet is double-sided taped (the thin stuff, not the foam stuff) to the inside of the case so it's easy to remove if I decide to remove it for whatever reason.
I also got another NVMe SSD for Windows installation, and GRUB ended up detecting it just fine. One weirdness is that with UEFI/BIOS, I have to have CSM off and not have anything in the boot order because if I choose the Linux SSD, Pod will boot to Windows.
When Ryzen 5000 series was launched, I had the ability to buy the Ryzen 9 5950X that I wanted (since the 5000 series would be the last of the AM4 CPUS), but I didn't and had to wait until mid-February this year before the computer store had enough in stock for me to be able to get one right after work. I was going to run some benchmarks with Phoronix Suite, but I didn't know it needed to download the tests, so I ended up giving up the idea because I wanted the 5950X in ASAP. Though I don't have too much of a comparison, it's still crazy to be able to convert 32 songs at the same time compared to 12. (Song conversion's one of the few things that's multi-threaded that I can use as a loose benchmark.) I was also considering compiling C++abi or something like that for a test comparison (old dependency for FreeFileSync required it before the dependency was changed), but I probably forgot at that point.
I haven't used Pod so much in a way to flex the the CPU that much, besides compiling dependencies when needed, and the "converting my library to OGG" has a bit of a problem. I thought the MP3 gain programme is multi-threaded, but I was sorely wrong when testing it out. The reason for mentioning it is that back in the days where I primarily used Windows, I had used MediaMonkey to apply a permanent volume levelling to all of my songs, and because OGG is gained by adding replay gain info to the tags, I would need to re-gain all the MP3s to "CD loudness" (about 99dB) before converting to OGG. While I don't know how long it would take to do the re-gain of all the MP3s, I do know that the conversion would be quite quick in batches of 32. (I think there's also some weird crashing issue with the gain programme anyway.)
RAM might be the next upgrade later on, but I dunno when that'd be. I could also swap the RX570 for Melty's RX480, but we'll see.
I think that's it, unless I forgot something, to which I'd probably edit this post or something.
So with the launch of Ryzen 3000 series and the X570 chipset, I began to wait for ASUS to release either their X570 mini-ITX board or their X570 mini-DTX board because of the amount of rear USB ports and such. In anticipation, I bought Thermaltake's Core V1 case because I was wanting to use a spare ATX/EPS power supply instead of buying an SFX power supply to keep the case small. I think it was about September when I gave up waiting and went with Gigabyte's X570 mini-ITX board instead and also grabbed a Ryzen 5 3600 since I was planning on doing a CPU upgrade to whatever the last supported high-core count CPU would be. It took me a while to find the motherboard because the local computer store said they had 4 in stock, but I couldn't seem to find it. Why? Because it was on the bottom shelf and practically shoved all the way back (not front-faced). (Captain Picard or Uncle Iroh facepalm here) To make matters worse, no employee was available for help, so it took 10 or so minutes before I found it.
I did a post test at my friend's because he lives much closer, and it posted just fine. At home the following day, I found out the Core V1's standoffs are just bent pieces of the metal tray, so I had to remove the motherboard's backplate. Oh right, I also grabbed 16GB of DDR4 3200 RAM from the computer store since it was the cheaper option than buying online. For the CPU cooler, I went with Noctua's NH-U9S because it was the largest I'd be able to fit in the case and Noctua's site says the cooler would handle the Ryzen 9 3950X (I think they were out and tested by Noctua at that point). Went with a Sapphire Radeon RX570 because it has 5 display outputs (two DisplayPort, two HDMI, one DVI-D) instead of the three that the RX560 has (DisplayPort, HDMI, VGA) because it'd allow a little more flexibility, even though I'd be using adapters.
"Pod 126" came from my deconstruction of the Pod numbers compared to the Yorha units. It took a while to figure out, and I think I had to do it twice because I didn't save the first spreadsheet where I figured it out. 2B's Pod unit is numbered 042 while 9S' Pod unit is numbered 153, and the way I figured it out was that 42 divided by 2 is 21 while 153 divided by 9 is 17. With 6 numbers between 2 and 9, the multipliers would have to be doubled... A table would make this easier...
| Yorha Unit Number |
Pod Unit Number |
Multiplier |
|---|---|---|
| 2 | 42 | 21 |
| 3 | 60 | 20 |
| 4 | 80 | 20 |
| 5 | 95 | 19 |
| 6 | 114 | 19 |
| 7 | 126 | 18 |
| 8 | 144 | 18 |
| 9 | 153 | 17 |
I'm not entirely sure what I did to originally figure it out (I only really remember that the original spreadsheet is larger than the one I have now), but this is pretty much what I came up with. I think when I first did the spreadsheet, I was under the impression that the Threadripper build would be the 8th AMD computer I built for myself, but I think when I was figuring it out again, I ended up with it being the 7th (and consequently, I had to get the corresponding Pod number since I originally was under the 8/144 impression).
Anyway, I had also gotten a couple 3.5 inch drives to replace the 2.5 inch drives from i3rd because the Core V1 case was able to accommodate them (technically, it can handle two 3.5 inch drives and two 2.5 inch drives or four 2.5 inch drives). I also took the ThermalTake badge off the front of the case because I wanted it to look a little cleaner, even if it meant having a weird depression in the front where the badge was. The back of the Core V1 has spots for two 80mm fans, which is a weird decision since there's plenty of space for two 92mm fans instead, but I still filled it out to try to help exhaust the air. I also swapped the stock 200mm fan for Noctua's, but with how the case ended up being, I had positive pressure that ended up exhausting air out of the side intake where the GPU is.
Eventually, SilverStone Technology announced the SUGO 14 case and I was quite interested in it because it allowed installation of one 5.25 inch device, had removable filters on the side panels (the Core V1 has non-removable foam in the front bezel and nothing else for filtration), and had normal motherboard standoffs (or at least much closer to normal compared to the Core V1). After really looking around at it from the images and deciding to replace the Core V1, I preordered it and got it on launch day.
I had to go back to 2.5 inch hard drives since I wouldn't be able to mount any 3.5 inch drives with the optical drive (well, the CPU cooler also prevents this), but it wasn't too big of deal since I also ordered a 2.5 inch 2TB drive for the files and used the old 1TB from Bazett/i3rd for micellany. I had to put the 1TB drive on the front while I finished engineering (and waiting for the MJF 3D print to arrive) the adapter bracket to mount it on the removable side frame next to the CPU cooler since there was enough space to do so.
Unfortunately, after transplanting everyting from the Core V1 to the SUGO 14, Pod didn't boot. I tried borrowing Lie-chan's PSU (which was the same model), reseating the RAM, reseating the CPU, trying one stick of RAM in one slot, but I couldn't get Pod to post. My thoughts were the motherboard, CPU, or PSU since I didn't have any extra on hand, and I decided to head to the computer store with Pod without storage for their diagnosis/repair service. Fortunately, the tech did a basic diagnosis with a different set of RAM and different PSU and Pod booted, confirmed that it was the PSU after the tech put my RAM back in and used a PSU tester on Lie-chan's PSU (I didn't feel like putting Pod's PSU back in when doing my bit of diagnosis). After buying a PSU, I went home and everything was fine, but I didn't think about how the case holds the PSU, so Corsair's PSU was not the best choice because of the large chamfers on the edges. I decided to just make some adapter wedges to make it sturdier, and after a second round, it worked (first sets were bad because I didn't get proper measurements). Also had some of the other employees at the computer store ask about my case, which was kinda cool to incidentally show off a brand new case.
With the new PSU, I decided to try CableMod cables out for the ATX connector because I didn't feel like taking Pod offline to see how Corsair wired their cable to make my own. While the CableMod cable was better than the one from Corsair (in terms of excess length), I ended up figuring out the wiring of it (before using it) and the Corsair cable (after the cable swap) and made my own which would be shorter and less annoying than either. I also did a custom PCIe power cable adapter back when using the Core V1, and then made a custom cable for the Corsair PSU. I also made a custom EPS connector for the Corsair PSU. I think it was sometime after I got the custom 2.5 inch HDD bracket when I made the custom SATA power cables for all the drives, including the two bays in the front.
I only have a 120mm and 140mm fan as the top and rear exhausts so that it's negative pressure, and I was planning on the PSU also be exhaust, but the PSU has a 0RPM mode, so that plan fell through. At least with the airflow being negative pressure instead of positive, the GPU stays cooler now.
I also made a magnetic swivelling cover for the power button that has Pod's name on it because I didn't want to accidentally press it (though I have it set to do nothing in Linux and Windows) and to also be able to have the power on light on because it looks nicer than the power on light on the Core V1.
Without and with magnetic swivelling cover.
Underneath the small hexagon at the top is a 4mm diameter magnet press-fitted into a recess, and another 4mm diameter magnet is double-sided taped (the thin stuff, not the foam stuff) to the inside of the case so it's easy to remove if I decide to remove it for whatever reason.
I also got another NVMe SSD for Windows installation, and GRUB ended up detecting it just fine. One weirdness is that with UEFI/BIOS, I have to have CSM off and not have anything in the boot order because if I choose the Linux SSD, Pod will boot to Windows.
When Ryzen 5000 series was launched, I had the ability to buy the Ryzen 9 5950X that I wanted (since the 5000 series would be the last of the AM4 CPUS), but I didn't and had to wait until mid-February this year before the computer store had enough in stock for me to be able to get one right after work. I was going to run some benchmarks with Phoronix Suite, but I didn't know it needed to download the tests, so I ended up giving up the idea because I wanted the 5950X in ASAP. Though I don't have too much of a comparison, it's still crazy to be able to convert 32 songs at the same time compared to 12. (Song conversion's one of the few things that's multi-threaded that I can use as a loose benchmark.) I was also considering compiling C++abi or something like that for a test comparison (old dependency for FreeFileSync required it before the dependency was changed), but I probably forgot at that point.
I haven't used Pod so much in a way to flex the the CPU that much, besides compiling dependencies when needed, and the "converting my library to OGG" has a bit of a problem. I thought the MP3 gain programme is multi-threaded, but I was sorely wrong when testing it out. The reason for mentioning it is that back in the days where I primarily used Windows, I had used MediaMonkey to apply a permanent volume levelling to all of my songs, and because OGG is gained by adding replay gain info to the tags, I would need to re-gain all the MP3s to "CD loudness" (about 99dB) before converting to OGG. While I don't know how long it would take to do the re-gain of all the MP3s, I do know that the conversion would be quite quick in batches of 32. (I think there's also some weird crashing issue with the gain programme anyway.)
RAM might be the next upgrade later on, but I dunno when that'd be. I could also swap the RX570 for Melty's RX480, but we'll see.
I think that's it, unless I forgot something, to which I'd probably edit this post or something.
Bazett
Not too much to say, so it'll be fairly short.
At some point I decided to have something a little more portable than Triela, and decided on HP's ENVY x360 with the Ryzen 5 2500U (Zen) and 1TB HDD upgrade (256GB M.2 NVMe SSD standard). And while waiting for it to arrive, I was curious on it's performance compared to Melty, and by UserBenchmark's scores, the 2500U was better... Oof. (Since UserBenchmark changed stuff, it seems like the FX-8320 is slightly better? Weird.)
I replaced the 256GB M.2 NVMe SSD (from Lite-On) with a used 512GB Samsung EVO 970, and gave the 256GB NVMe SSD to i3rd for an OS drive. The 1TB HDD was replaced with a 2TB HDD, and the 1TB HDD also went to i3rd for the local copy of my files (the 500GB HDD became a catch-all). I also manually upgraded the ram to 16GB because it was slightly cheaper than what HP was asking for.
For naming, it was a bit tough because there's a "professional" look to the laptop and so I kinda wanted to match that as best as possible. I used AniCDB's search and I think I looked for characters with the suit tag, and then looked through them all. Eventually came upon Bazett Fraga Mcremitz from Fate/hollow ataraxia, and though her appearance was what I was looking for (ignoring additional images), I think there were still results to go through.
Because of Bazett's portability, I used to spend every Friday (or every other Friday, I don't remember now) at a coffee shop to (try to) work on my stories, and then a nearby library later since the coffee shop's internet was really poor.
The ability to fold it is nicer than than I had originally expected (I think I didn't really care), so I can arrange it where the keyboard faces the table to put the screen closer to me (I usually have an external keyboard in this mode) or in either "tent" mode (screen facing in or out) when I have it doing background stuff (such as Windows updates) while on my bed to shed heat a little better. I rarely use the tablet mode since I'm hardly ever in Windows and Linux doesn't disable the keyboard (there's probably ways to make it aware of tablet mode, but meh).
At some point I decided to have something a little more portable than Triela, and decided on HP's ENVY x360 with the Ryzen 5 2500U (Zen) and 1TB HDD upgrade (256GB M.2 NVMe SSD standard). And while waiting for it to arrive, I was curious on it's performance compared to Melty, and by UserBenchmark's scores, the 2500U was better... Oof. (Since UserBenchmark changed stuff, it seems like the FX-8320 is slightly better? Weird.)
I replaced the 256GB M.2 NVMe SSD (from Lite-On) with a used 512GB Samsung EVO 970, and gave the 256GB NVMe SSD to i3rd for an OS drive. The 1TB HDD was replaced with a 2TB HDD, and the 1TB HDD also went to i3rd for the local copy of my files (the 500GB HDD became a catch-all). I also manually upgraded the ram to 16GB because it was slightly cheaper than what HP was asking for.
For naming, it was a bit tough because there's a "professional" look to the laptop and so I kinda wanted to match that as best as possible. I used AniCDB's search and I think I looked for characters with the suit tag, and then looked through them all. Eventually came upon Bazett Fraga Mcremitz from Fate/hollow ataraxia, and though her appearance was what I was looking for (ignoring additional images), I think there were still results to go through.
Because of Bazett's portability, I used to spend every Friday (or every other Friday, I don't remember now) at a coffee shop to (try to) work on my stories, and then a nearby library later since the coffee shop's internet was really poor.
The ability to fold it is nicer than than I had originally expected (I think I didn't really care), so I can arrange it where the keyboard faces the table to put the screen closer to me (I usually have an external keyboard in this mode) or in either "tent" mode (screen facing in or out) when I have it doing background stuff (such as Windows updates) while on my bed to shed heat a little better. I rarely use the tablet mode since I'm hardly ever in Windows and Linux doesn't disable the keyboard (there's probably ways to make it aware of tablet mode, but meh).
Subscribe to:
Posts (Atom)