When people ship impressive stuff like this, I can’t stop wondering what motivated them to 1) work on it for free 2) have the persistence to finish it. Incredible feat
You start with a "What if", and it tends to nibble at the back of your brain. Then it evolves to "Why not?"
You hack it and see the light, or more specifically you fail to find a reason for the "not" part, and you make it.
And yes, there's an immense satisfaction for doing it. Not from "look at me" angle, but from "ach, it was possible, and I made it. It turned out I was capable enough to make it work. Let me get some tea" angle.
I like feats like this. Honestly kudos to them. Both impressive and fun. Delightful, more precisely.
Exactly! Curiosity, desire to learn and also desire for satisfaction that it brings, when you finally got something like this running. It wasn't all shiny though, that audio issue became pretty frustrating until I discovered that it is not an issue of audio code itself, but the Watch speaker just does not like certain low frequencies.
"What if?" is the one thing that brought me into computing as a hobby when I was a teen and has consistently been with me in my 2+ decades of work. Everyone has different motivators, but for me, this has been the single most powerful driver of all my successful projects.
Along the way, I learned that when "what if?" becomes "I have to", the drive in me just dies. So I've had to learn how to stay in "what if?" mindset even when I have a deliverable I have committed to.
Sometimes, this means picking at a totally unimportant part of a project, getting it working and then—while in the same mental groove—shift to delivering the core feature.
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
People who do this kind of stuff don't think of it as "free" necessarily. It's highly rewarding at the most abstract, but more tangibly develops skills that make them more valuable in the workforce, allowing them to demand very high salaries from top companies.
As a web developer, I'm kinda jealous of how someone can just say "I'm gonna make this device this specific nostalgic game I love" and then just do it.
This is a step by step process. The author has some prior experience, probably, but let me try to outline something from my own journey.
As you take small steps, you need to start with small targets.
In my second internship, my mentor shown me a PC, and said "This is yours". Then produced a Nokia 7110 and a serial cable for said phone. He continued: "We need this phone to send SMS messages, via an application on this PC". Catch: The PC had no OS, and the software he wanted was nonexistent.
I said OK, and he asked: You know Linux, right? I truthfully said "Installed a couple of times, spent time with it." He produced a Debian 3.0 CD from a drawer, and said "Let's see whether you can install this" (Debian was hard, then).
My first target was to get Debian run on that system, then make it connect to the network.
Then, I learnt how to install and manage packages on it via "dselect".
Next, I managed to found the user manual of the phone to find out that it has a serial modem on it. I also found the AT reference guide for the phone the same day IIRC.
Next day I managed to connect it via minicom, talk with it and send a couple of SMS messages to myself.
With the knowledge I had, I found how to talk with that phone over C (Thanks Beej, and his guides). In 6th day, I was sending messages. In 8th day, the tool was a daemon waiting for messages via a specified port in a specified format.
The IT department written file watching daemons and embedded to their systems, allowing them to create many many "wire traps" inside system to detect when something went wrong. That system worked for 6 years and saved enormous effort by notifying from the right place, at the right time.
This experience allowed me to discover Debian from top to bottom. I still use Debian, still do the research same way, and move step by step, because I built the confidence over that week.
The key is proverbially "not looking down", and just "thinking the current mile", like a marathon runner. You're a web developer? I don't care. If you start from the edge of your knowledge and just walk, you can go great distances. The target is incidental here. A Quake port, an SMS daemon, something bigger/smaller... Doesn't matter.
What matters is going somewhere new, learning something you don't know. Then you can build upon this. One day, you may find yourself beyond the people who inspired you, which happened to me without noticing, but it's a story for another time.
If you want to talk on this further, you can also reach me via my webpage (see my profile), or we can continue via here.
P.S.: I still have the AT Reference Guide, both digital and in printed and bounded form. :)
Hey, thanks. I'm glad it made you happy and inspired you. Hope you have more of these kind of stories yourself, take a look back and feel delighted about them, too.
As a web developer who is increasingly getting into tinkering with embedded systems for fun:
The first step of displaying a test pattern, sending test bytes between devices, etc. is the biggest one, and in my case usually involves finding an open-source program that is capable of doing the thing and butchering it until it only does the thing. Every step after that is incremental, just like any other development.
One of the reason I chose Quake (apart from it being awesome game and well written code) is also that it has software renderer, these things have their flaws, but are highly portable. Porting original GLQuake to Metal would be far more taxing.
Just the excitement to see it done, for the sake of it. I think money won't even remotely come to mind.
For the second point on persistence, this guy must have a lot of patience. I've struggled on this actually. If the initial push is strong enough I sit through 3-4 days but at least for me I can't seem to come back and finish it if I put it away for more than a day.
Some people build hot rods or fix old tractors, some people collect all 7,341 achievements in some game, some people catch up on the complete available catalog of Doctor Who, some people go out and bag peaks or train for better times on their marathon, some people grind on their karaoke performance of Tainted Love, some people devote themselves to being close with and available to their kids.
This is a beautiful project, but what makes you feel like the motivation is somehow different here than it is for those?
It might not be entirely altruistic or a personal challenge as mentioned in other replies. If I were someone who wanted to recruit a developer for some performance-critical Apple Watch work, I would put this person on a short list of people to reach out to.
