Franken-linus' N64 :: Postmortem :: Part 1
Jul. 9th, 2022 11:51 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kradeelavAs long time readers will know, these days I have a ritual that I picked back up from the middle-school years of playing console games after school (and work, now). I missed out on a lot of the hits of the N64/PS1 era, and wanted to recreate that special feeling of siting by the TV away from the laptop with some new games from the best era of gaming.
(Mind, there's nothing wrong with emulating/playing via keyboard ... but you're stuck to a laptop screen, and it's not quite that childhood sensation before work laptops were a thing.) Until now. :D
Behold, the rig that contains of:
Work in progress of the rig!
the how:
First up, getting the emulator running with a live game. Ubuntu's thankfully such a common linux distro that it's pretty easy to grab one from the default software installer (games>emulators); the relevant one here is mupen64plus for the N64. Download, install, open. Use, errr, subreddits to find and get a "discount" for the relevant game as it were, wink wink, in this case Super Mario 64. I went with that one partially for nostalgic reasons (only time I got to play a bit of it is right before a major neck surgery in a pediatric waiting room), and partially for practicality - presumably less bugs on the most popular game in the system, so if there "were" any bugs, it'd be easier to track down.
Drag the iso in a folder that makes sense, start a test to confirm the iso works for boot-up, hit run. There's all kinds of minor bugs one can encounter at this point; you're never gonna have an emulation that works from the start, just count on it. :P
The immediate bug for me at launch was the screen flickered white/was strobing/lagging badly enough it was unplayable. A few googles later led me to "Screen flickering issue in paper mario 64" that was close to what I was experiencing (linux, flicker, mupen64); and the winner solution was changing the video plugin (settings > configure > plugin > video plugin) from rice to glide64.
bam! I still don't have save states working, but at least it's running, there's sound, video, and ol' Mario runs around with keyboard controls now.
Next is getting the controller live. At first I started off with the idea of a wiimote (had a few extra, have another emulator for GC/Wii, and remembered there had been a number of homebrew linux projects using wiimotes). Found a program called xwiimote that was essentially the driver for ubuntu. Getting the physical remote hooked up was as easy as going in the bluetooth dialog on ubuntu, pressing the red "sync" button on the back of the wiimote and connecting like any other bluetooth device.
(I have an old 2010 laptop I still use as my main drawing device -don't ask- and the only way I can transfer artwork from it to the ubuntu is via bluetooth, so those pains are fully well known and mostly de-bugged).
it lives! However, that's where the easy part ended :l
The "good" news is that Mario natively ran around left/right/front/back with the wiimote d-pad buttons (without having to change any settings), the "bad" news is that none of the other buttons worked. "All right," I thought, "Sounds like we need to re-map some buttons."
(Easier said than done.)
Mupen64plus is the kind of project where they give you just enough docs for hints that might work for a sysadmin but makes for one interesting rabbit chase for somebody who's at an intermediate-leaning-towards-beginner (at best) tech level. Under (Help>Default Controls), there's a map of the N64 buttons, and then under (settings > edit mupen64.cfg ) (fuck that one file with a crisco cactus) there's a tantalizing hint of something about SDL controls, something that looked vaguely like button mapping, and then a hint of key code references(?) that linked up with the SDL-something (i don't know I'm a hacker wannabe not a paid programmer lol).
The first line of attack was seeing if there was an easy GUI (graphical user interface, basically shit that's not command line) software already available for wiimotes and there kind of is one with xwiimote newly/partially already installed with Ubuntu, which is why it had been so easy to link up with bluetooth. "Great, so let's find out the default keymaps of xwiimote and then link it over in mupen, should be easy, right?"
".....right?" [stares intensely at the docs]
Lord, I was in the archwiki, personal blog of the dude that wrote the shit, reading the manpages in the official github repo, forums, more manpages and honestly it all started blurring a bit together. tl;dr was the wiimote buttons don't default to "normal" keys on a keyboard, and there was no tangible GUI way to remap them to physical keys other than a literal low-level kernel hack (xwiikeymap) that had me squinting suspiciously because oh my god so many things could go wrong when I'm still at the 'copy and paste command line sudos' phase. I know my limits!
(sidenote: a neat thing that I found halfway through these searches was xwiishow - a fun little command line sub-program that actually rendered a wiimote, real-time accelemeters and all :D
(using somebody else's screenshot because I don't care to pull everything out again; needless to say, similar to this!)
After uhhh, 246 google searches / these pages over a span of 4 hours: "alright, fuck it, i'm not going kernel hacking when there's an easier solution". What helped was during one of these many, many, googles I ran across somebody mentioning using a PS3 controller with a USB cord as a perfectly good controller, and I remembered I had a box of old ones in the closet. Took it out, gingerly did the bluetooth rigmarole, system recognized it decently enough.
Then it didn't.
A VERY long and technical story short, for some reason the InputAutoCfg.ini file didn't come with my first install of mupen, something I only found out after another 4 hours of googling. Downloaded the ini file from the browser, manually went hunting in the .config folders, stuffed it in there. Still didn't work. Slept overnight to get some distance from the frustration, and the next-day advice to the self was, okay, fuck it, uninstalling and reinstalling mupen might do the trick?
The heavens must have been smiling on me because the emulator inexplicably started recognizing the PS3 in the error logs after that ~with no changes~.
(if I never see this page again I will be very happy.)
However, if that detour wasn't bad enough, I was running into the same problem as the wiimote; there was still no fucking way to tell WHICH PS3 button I was randomly pressing aligned up to <=> Mupen's mapping to <=> the N64 controls. By now I could click "start" on the PS3 controller and have the title screen respond, but none of the other buttons worked (again).
Thankfully before I could seriously start to think about ragequitting, I found jstest-gtk which is an essential nifty little program that gives you that GUI I've been looking for, all this time.
(Naming my firstborn after whoever coded this program.)
The other problem I had been having before now was that this specific PS3 controller is very ... finnicky. Even on the console it tended to disconnect because of a loose port connection, so jstest-gtk was a boon because you could "see" in real time whether the button presses / axis were responding and whether it was a badly mapped button or it was plain not connecting or mupen being buggy. After a few false starts, the remapped buttons actually did what they were supposed to, and I could play the first two minutes with nothing worse than the laptop fans going 'whrrr' -- hallelujah!
(Here's the process of writing the keycodes down, before I got too excited and forgot to write down the final edits.)
( I sense that jstest-gtk is going to be invaluable when my microsoft sidewinder actual-honest-to-god-from-the-90's-joystick for Win98/XP-games arrives for my test in the next month. :3 always regretted tossing out the old one, and yes i might have a problem.)
While researching ahead for the VCR input step, I learned very quickly I wasn't going to be able to lean on a bluetooth or wifi crutch to connect the shit to the TV directly and to bypass the VCR (i thought smart tvs could do all kinds of shit??) -- sure, there was technically a thing called wifi P2P, and I guess there's the ol' have-the-tv-on-the-wifi-system proper but I'm a big believer in keeping things as Old and Offline as possible for Pragmatic Security Reasons, and any other streaming workaround was usually just for singular media/movie files and not, y'know a whole-ass screensharing for games -- and so the thing that felt the most practical was a AVI-to-HDMI connection. Ordered it, back to fixing the minor bugs!
preview of part two:
(1) fixing the savestates bug I've been procrastinating on
(2) testing on Majora's Mask to confirm durability of emulation (so it's truly for leisure and not just a tech flex)
(3) AVI/HDMI connection and chaining it all together physically
(4) the moment of truth ...
[ PART 2 LINK PLACEHOLDER ]
(Mind, there's nothing wrong with emulating/playing via keyboard ... but you're stuck to a laptop screen, and it's not quite that childhood sensation before work laptops were a thing.) Until now. :D
Behold, the rig that contains of:
- an old PS3 USB controller that connects to ...
- a System76 Ubuntu laptop with Mupen64Plus running [ $definitely_a_legally_acquired_game ], also connected to ...
- a HDMI/AVI converter that's tethered to...
- a VCR with AVI input from the 00's (because that's how we roll, if it ain't broke, don't fix it) which hooks up to ...
- the flatscreen TV we only replaced the CRT gigamonster with because a family member wanted more real estate for sports (
which is a choice i regret tbh because i hate smart tv's, but that's a story for another day)
Work in progress of the rig!
the how:
First up, getting the emulator running with a live game. Ubuntu's thankfully such a common linux distro that it's pretty easy to grab one from the default software installer (games>emulators); the relevant one here is mupen64plus for the N64. Download, install, open. Use, errr, subreddits to find and get a "discount" for the relevant game as it were, wink wink, in this case Super Mario 64. I went with that one partially for nostalgic reasons (only time I got to play a bit of it is right before a major neck surgery in a pediatric waiting room), and partially for practicality - presumably less bugs on the most popular game in the system, so if there "were" any bugs, it'd be easier to track down.
Drag the iso in a folder that makes sense, start a test to confirm the iso works for boot-up, hit run. There's all kinds of minor bugs one can encounter at this point; you're never gonna have an emulation that works from the start, just count on it. :P
The immediate bug for me at launch was the screen flickered white/was strobing/lagging badly enough it was unplayable. A few googles later led me to "Screen flickering issue in paper mario 64" that was close to what I was experiencing (linux, flicker, mupen64); and the winner solution was changing the video plugin (settings > configure > plugin > video plugin) from rice to glide64.
bam! I still don't have save states working, but at least it's running, there's sound, video, and ol' Mario runs around with keyboard controls now.
Next is getting the controller live. At first I started off with the idea of a wiimote (had a few extra, have another emulator for GC/Wii, and remembered there had been a number of homebrew linux projects using wiimotes). Found a program called xwiimote that was essentially the driver for ubuntu. Getting the physical remote hooked up was as easy as going in the bluetooth dialog on ubuntu, pressing the red "sync" button on the back of the wiimote and connecting like any other bluetooth device.
(I have an old 2010 laptop I still use as my main drawing device -don't ask- and the only way I can transfer artwork from it to the ubuntu is via bluetooth, so those pains are fully well known and mostly de-bugged).
it lives! However, that's where the easy part ended :l
The "good" news is that Mario natively ran around left/right/front/back with the wiimote d-pad buttons (without having to change any settings), the "bad" news is that none of the other buttons worked. "All right," I thought, "Sounds like we need to re-map some buttons."
(Easier said than done.)
Mupen64plus is the kind of project where they give you just enough docs for hints that might work for a sysadmin but makes for one interesting rabbit chase for somebody who's at an intermediate-leaning-towards-beginner (at best) tech level. Under (Help>Default Controls), there's a map of the N64 buttons, and then under (settings > edit mupen64.cfg ) (
The first line of attack was seeing if there was an easy GUI (graphical user interface, basically shit that's not command line) software already available for wiimotes and there kind of is one with xwiimote newly/partially already installed with Ubuntu, which is why it had been so easy to link up with bluetooth. "Great, so let's find out the default keymaps of xwiimote and then link it over in mupen, should be easy, right?"
".....right?" [stares intensely at the docs]
Lord, I was in the archwiki, personal blog of the dude that wrote the shit, reading the manpages in the official github repo, forums, more manpages and honestly it all started blurring a bit together. tl;dr was the wiimote buttons don't default to "normal" keys on a keyboard, and there was no tangible GUI way to remap them to physical keys other than a literal low-level kernel hack (xwiikeymap) that had me squinting suspiciously because oh my god so many things could go wrong when I'm still at the 'copy and paste command line sudos' phase. I know my limits!
(sidenote: a neat thing that I found halfway through these searches was xwiishow - a fun little command line sub-program that actually rendered a wiimote, real-time accelemeters and all :D
(using somebody else's screenshot because I don't care to pull everything out again; needless to say, similar to this!)
After uhhh, 246 google searches / these pages over a span of 4 hours: "alright, fuck it, i'm not going kernel hacking when there's an easier solution". What helped was during one of these many, many, googles I ran across somebody mentioning using a PS3 controller with a USB cord as a perfectly good controller, and I remembered I had a box of old ones in the closet. Took it out, gingerly did the bluetooth rigmarole, system recognized it decently enough.
Then it didn't.
A VERY long and technical story short, for some reason the InputAutoCfg.ini file didn't come with my first install of mupen, something I only found out after another 4 hours of googling. Downloaded the ini file from the browser, manually went hunting in the .config folders, stuffed it in there. Still didn't work. Slept overnight to get some distance from the frustration, and the next-day advice to the self was, okay, fuck it, uninstalling and reinstalling mupen might do the trick?
The heavens must have been smiling on me because the emulator inexplicably started recognizing the PS3 in the error logs after that ~with no changes~.
(if I never see this page again I will be very happy.)
However, if that detour wasn't bad enough, I was running into the same problem as the wiimote; there was still no fucking way to tell WHICH PS3 button I was randomly pressing aligned up to <=> Mupen's mapping to <=> the N64 controls. By now I could click "start" on the PS3 controller and have the title screen respond, but none of the other buttons worked (again).
Thankfully before I could seriously start to think about ragequitting, I found jstest-gtk which is an essential nifty little program that gives you that GUI I've been looking for, all this time.
(Naming my firstborn after whoever coded this program.)
The other problem I had been having before now was that this specific PS3 controller is very ... finnicky. Even on the console it tended to disconnect because of a loose port connection, so jstest-gtk was a boon because you could "see" in real time whether the button presses / axis were responding and whether it was a badly mapped button or it was plain not connecting or mupen being buggy. After a few false starts, the remapped buttons actually did what they were supposed to, and I could play the first two minutes with nothing worse than the laptop fans going 'whrrr' -- hallelujah!
(Here's the process of writing the keycodes down, before I got too excited and forgot to write down the final edits.)
( I sense that jstest-gtk is going to be invaluable when my microsoft sidewinder actual-honest-to-god-from-the-90's-joystick for Win98/XP-games arrives for my test in the next month. :3 always regretted tossing out the old one, and yes i might have a problem.)
While researching ahead for the VCR input step, I learned very quickly I wasn't going to be able to lean on a bluetooth or wifi crutch to connect the shit to the TV directly and to bypass the VCR (i thought smart tvs could do all kinds of shit??) -- sure, there was technically a thing called wifi P2P, and I guess there's the ol' have-the-tv-on-the-wifi-system proper but I'm a big believer in keeping things as Old and Offline as possible for Pragmatic Security Reasons, and any other streaming workaround was usually just for singular media/movie files and not, y'know a whole-ass screensharing for games -- and so the thing that felt the most practical was a AVI-to-HDMI connection. Ordered it, back to fixing the minor bugs!
preview of part two:
(1) fixing the savestates bug I've been procrastinating on
(2) testing on Majora's Mask to confirm durability of emulation (so it's truly for leisure and not just a tech flex)
(3) AVI/HDMI connection and chaining it all together physically
(4) the moment of truth ...
[ PART 2 LINK PLACEHOLDER ]
