A design change which didn't quite make it into the final release only enables the 5V and 3V3 lines on the GameCube controller when the tip-switch on the TRRS jack is activated.
The short-proof approach/strategy would be to use small magnetic pogo connectors, but I really wanted to maintain compatibility with the GC Nano!
The disc could then just be a caddy for a micro SD memory card, which when inserted on the disc slot would promptly launch a game stored in there.
Selecting games from a virtual library never has the same kick as when you insert a cartridge or a dis[ck] into a machine and have it boot from that.
Edit: I also realized you may as well cut out the memory card and just have each "fake" disc encode (perhaps optically) a little ID which the machine could read (perhaps a cheap camera) and associate to a game already stored in the machine's internal memory.
As a longtime observer of the scene, no. Creating the smallest board possible while maintaining original game compatibility are about the only metrics to stick to. Usually this boils down to keeping the CPU, GPU, NAND (if exists like the Wii), and most times the RAM.
There are some nuts people out there like Redherring32 with his TinyTendo project that go above and beyond just putting the components on a new board. He designed the TinyTendo which requires cutting down the DIP-packaged CPU and PPU from the NES into a smaller package. These components were only produced for Nintendo systems of the era and are the special sauce for overall game compatiblity.
https://github.com/Redherring32/TinyTendo
Heads up - I co-wrote this article with Kristine and this is based around the whole thesis of our company existing - I'm a software developer by trade with 15 years of experience. Having said that, dismissing the content based on the author I think comes across as an ad-hominem attack - after working with her for 4 years I count Kristine as an expert on this matter.
The overall point here isn't to use this as an excuse to not fix bugs, more that you should consider applying the same logic as devops/sre teams use for "uptime and availability" (5 nines, etc) to software stability to help you move faster as a company.
It's not an ad-hominem. It's an inference on the predictive power of the article as a function of the commenters prior belief on the expertise of non-developers.
They may or may not be right, but you can't just dismiss things you don't like by classifying them as a "fallacy."
I just want to note -- I didn't dismiss the article based on the author's background; I was baffled after reading the article because it made no sense to me when I was reading it from the perspective of someone I initially assumed was a developer. I'm not really sure how someone can develop expertise in software development without having participated in the process, but if you cowrote the article maybe you can explain? Do you agree 97% of developers are following agile principles and that this stability formula is a good way to measure the overall bugginess of an application?
Interestingly, Apple's move seems to squarely aim at Rollout.io and tools that modify the "native" parts of the app rather than React Native/Code Push.
We're helping software teams focus on building great software by building automated crash monitoring for web and mobile apps. Half of a typical developer’s time is currently spent finding and fixing bugs; we aim to bring that number as close to zero as possible, by automating the entire error monitoring process.
We already work with some of the world's fastest growing companies like Square, GitHub, Mashable, Goodreads, Buffer, Heroku (and thousands more). We’re currently doubling revenue every few months and we're now expanding our team.
The short-proof approach/strategy would be to use small magnetic pogo connectors, but I really wanted to maintain compatibility with the GC Nano!