I've done a bit of NES programming and really enjoy trying to cram stuff into such a tiny system.
One benefit of developing games for these old systems is that they are not moving targets. For hobby programming, you probably don't want to keep testing and recompiling old stuff to keep up with OS updates.
Even better, you'll have a small army of emulator developers making sure your games will work forever on every new platform. That includes browsers, since there are Javascript emulators for many systems. If your games are particularly tricky to emulate, that's no problem. They will probably be added to everyone's test suites.
I liked the 32F746GDISCOVERY which is $56 at Digikey. It has a Cortex-M7 CPU, 1 MB built-in flash, 8 MB of SDRAM, and a 480x272-pixel touchscreen. Games can go on a microSD card. There's a USB OTG port you can use for input.
A low-res screen like this works well because the chip can't rescale its video output.
ST provides libraries for all the peripherals so it's pretty easy to jump in if you know C. I think microPython works on a lot of these boards, too.
I guess it depends on which part you think is fun. Using a big microcontroller is more about pushing the hardware to its limits. Using a small Linux system is about taking advantage of existing libraries. The Playdate has an STM32F7 and it seems to do pretty well as a console.
Something like an STM32 Discovery board is a good option for recapturing the mid-90s magic. You can get a ~200-MHz Cortex-M4 or M7 with a few MB of flash, external SDRAM, and a display for less than $100. They have really basic hardware 2D accelerators.
The on-chip peripherals are well-documented, but off-chip peripherals require some digging to figure out how to program correctly.
You can debug with GDB surprisingly easily, or find a Forth to throw on there and just start poking registers.
I've been bitten by reordering. In my case, the toolchain developers implemented the reordering step in the assembler as an extra optimization step (on by default of course), so I had to disassemble the binary to even find the problem. They had redefined the assembly language semantics to require "volatile" keywords wherever you needed ordering maintained. I turned that particular optimization off.
It's tough but doable. You have to get on people's calendars a week or two out whenever you can, and if you're lucky, it eventually turns into easy, low-stress, open-ended playdates.
Meeting other parents is a huge effort, though! It's basically dating all over again. If your kids ride the school bus, that's a big help because you automatically meet nearby parents who are home in the afternoon. Otherwise, you have to go to lots of events and ask parents for their phone numbers, but the majority don't work out for random reasons.
A company I worked at had one of the guys behind the TrackPoint come in and give a technical talk once. He was great, absolutely obsessed with building a great user experience. The amount of thought and testing that went into that little nub was incredibly impressive. I'm not surprised that people love it so much.
Touchpads have a hard time competing on user experience because they need to be physically large to work well, and that's expensive.
I interned at Sandia Livermore and Los Alamos in college, then worked at Sandia's main site for a few years before moving out to the Bay Area to work in the more dynamic world of consumer electronics.
The labs are not for everyone, but it's the perfect job for some. If you want to work with fantastically smart people and don't mind following a lot of arbitrary rules, it can be a lot of fun. Most of my coworkers intended to spend their entire careers there.
Just like anywhere else, a lot of the day-to-day experience depends on the group you work with. In general, it's somewhere between a university campus and a defense contractor, and the mix is different for each project. The good part is that once you get a security clearance and make some friends in other groups, you can move around.
There might be some culture shock. Most employees have to be US citizens, so the labs are probably less diverse places than you might be used to. And you will really be hitting the brakes while you wait for a security clearance.
I'd say look at the job postings and give it a try! It didn't end up being for me, I don't regret the time I spent at the labs. And it's tough to beat the work-life balance. You can't take a lot of the work home, and most people take every other Friday off (9/80 schedule).
But do consider the location carefully. For example, Sandia and Los Alamos are both huge and have a huge variety of projects, but you're stuck in Albuquerque or Los Alamos which can be limiting unless you really enjoy hiking.
If you can afford it, do it! The worst that can happen is you'll just get another job.
I quit a job about 15 years ago with no plans and enough money to last me a year or two. It taught me a lot about myself. I had planned on hiking and skiing and maybe starting my own company, but mostly I just sat around catching up on TV shows and movies because all my friends were working full-time. I also did some volunteer work to fill the time and keep up contact with other people.
After about a year of that, I was really bored, and it only took a month or two to line up another job, even in the 2008 recession. I took a pay cut relative to my previous job, but I met great new people, learned a lot of new stuff, and eventually got enough equity to more than make up the salary difference.
Google asked if I would do a phone screen a few years ago for an SRE position, and I thought that process was hilarious. In my case the questions had nothing to do with my background (microcontroller firmware for sensors) and it was only by incredible luck that I could answer them. For example, I had just read about some data structure the day before.
The recruiter didn't spend much effort telling me what the job was or why I should consider leaving my current great position for it. I said, "no thanks!" when I found out what an SRE actually does.
It seems like Google's interview process is designed to measure how much a candidate wants to work at Google. This is probably okay for them, but it's going to result in them overpaying for good people.
Under those constraints, Chebyshev approximation will probably outperform minimax. Minimax approximations have non-zero error at the endpoints, so they wouldn't quite hit zero at sin(pi) and your relative error would be horrible.
You can do a little better with a minimax polynomial that you can derive with the Remez algorithm. If you have Matlab, you can use the excellent Chebfun package's remez command to do this almost instantly for any well-behaved function.
The best approximation I could find calculated sin(x) and cos(x) for [-pi/4,pi/4] and then combined these to cover all other inputs. These functions need only 4 or 5 terms to get +/-1 ULP accuracy for 32-bit floats.
I thought the harder problem was the argument reduction to enable calculating something like sin(10^9). It turns out that you need a lot of bits of pi to do this accurately. While testing my implementation, I was surprised to learn that the x87 fsin implementation only has 66 bits of pi, so it gives extremely wrong answers for large inputs.