GBA is a great platform for CS pedagogy too. There are a number university-level computational architecture classes that use it. And I think Nintendo could be amenable to licensing their IP for more curricula ;)

NDS development has always been something I wanted to explore. This article provides a nice excuse to get started.

Just to put things in perspective. DS could run a full 3D platformer like Super Mario 64 DS back in 2005 using only 32-bit ARM7 at 34 MHz. New PS5 specs: 8-core Zen 2 at 3.5GHz, 10 TFLOPs GPU, 16 GB GDDR6

The original DS had some impressive full 3d capabilities. Between Mario 64, mario kart DS, as well as some of the beautifully rendered scenes like the Sky Arrow Bridge in pokemon black:https://www.youtube.com/watch?v=IE16BT9RFEc

I remembered having my socks knocked off the first time I walked down Sky Arrow Bridge! I always wondered if it was truly 3d or if they were using some doom-style hack, but watching the video again I think it must have been true 3D. Also, it's amazing how much higher-fidelity it looked in my memory

3d DS games look terrible on larger screens, because there's not much of anti aliasing going on in the original hardware.

Luckily if you play on something like DraStic, you can add AA yourself which looks much better upscaled.

The PSX had similar MHZ but with a less powerful MIPS CPU and less RAM.

I would love to run a university course like this, but I am too afraid of getting the Nintendo banhammer half way through the year.

What bannhammer? Home brew is completely legal in the US and they can’t just come and take your hardware or devtools away (provided you use the open source ones.)

One does not simply avoid Nintendo’s lawyers by following the law :P

Don't the flashcarts count as breaking DRM and thus not allowed by the DMCA?

Usually the students would run their programs on an emulator instead of the original hardware (this also means they don't need to be provided with a GBA each).

Well, there is not just Android & iOS - there are other Smartphone OS (such as Sailfish OS which I use on my daily device) & with PinePhone we can hopefully see mobile Linux distro explosion, like what happened on PCs in the past.

Basically, I think modern mobile hardware is fine, it's just the software from Google & Apple that makes it often unusable & out of user control.

Thankfully there are people working on that & I'm sure they are looking for contributors. :)

It's nice to have a fixed resolution to develop for instead of any and all resolutions

I totally understand why they decided they didn't actually want to die on this hill, but it has always seemed to me that the introduction of multiple screen widths was the moment when the average UI quality in iPhone apps took a turn for the worse.

I have this 4y old Android smartphone which is slow for no good reason. I tried everything, removing/disabling apps, reset etc.

The problem is that apps are just too big. Tinder is unusable.

I thought I could root it and install a custom Android, but I realize now that it's not as easy as installing Debian on a desktop.

If you combine capitalism with wirth's law, you end up with expensive hardware that you cannot use. It's the same problem with JavaScript and web page size.

Everything is bloated.

Not everything; at least early on, iOS apps were great. But over time, on the one side the developers started adding more and more features, or switched to web tech or some hybrid technology, convinced that it would save them time and money (it didn't and the user experience is the worse for it). I also believe Apple itself added more and more cruft to the system.

One thing my colleague (who was a bit more hardcore than me) was convinced of is that hand-coding interface code was faster than using Interface Builder. I want to believe; I can imagine that the IB interface was just an XML file that had to be read, parsed and its layout built up, whereas handcoded layouts is very dumb code that would compile easily and execute quickly. But at the same time, I want to believe Interface Builder would be converted to obj-c code and compiled as normal.

Anyway Apple had years of head start in terms of performance and user experience (= perceived speed) to Android, their technology decisions was one of the reasons.

And yet, thinking about it, it wasn't even as fast as I could be; because of how objective-C works, function calls are somewhat dynamic so every function call, the runtime has to look up what to call the function on. Later on (with Swift) they managed to add an optimization that could omit this check if they detected the target could not change.

I'm rambling a bit and speaking from memory here btw, take this comment with a grain of salt. I'm no computer scientist, just a developer.

Objective-C message sends are ridiculously fast these days, like less than a handful of nanoseconds on average (1-2 on the fast path). There are ways of making it go even faster, but Apple has chosen to sully the language by taking away some of its dynamism instead :( It’s kind of sad to think about how much the original iPhone could do and how much code goes into the average app these days in comparison. You’d guess it was assets or something but no, if you look at major apps these days they have all sorts of framework dependencies with multi-megabyte binaries. It’s so sad to see…

(And Interface Builder files get compiled to a format that is then read out at runtime and deserializes the right things.)

There are a handful of natively written apps on iOS that have maintained the discipline to avoid bloat. One that I always admire is Overcast for podcasts. It's 5.9 MB and takes < 5 seconds to download and install.

It always makes me slightly resentful or sad about apps that are collections of web views but somehow 100+ MB.

> I have this 4y old Android smartphone which is slow for no good reason. I tried everything, removing/disabling apps, reset etc.

Does it use eMMC storage, or is it new enough to be NVMe? Any pre-2016-ish smartphone is built with basically the guts of an SD card (or MultiMediaCard rather) for internal storage and is a ticking time-bomb with a limited number of write cycles. They'll get slower and slower and then eventually stop working completely. My NoteⅡ and then later my NoteⅣ both succumbed to this. I never owned one but I remember the Nexus 7 being especially notorious for dying this way. You can replace those chips with the right equipment but I've never tried.

Why would eMMC NAND flash memory be less reliable than NVMe NAND flash?

The bus itself doesn't affect reliability obviously, but the storage chips they use on modern phones are much nicer and more expensive better parts :)

> The problem is that apps are just too big.

At least in part, I expect this is because of the AppCompat library that Google recommends using. If you pull in the whole thing, as tutorials show, it adds a huge number of images (icons and such) that don't get trimmed during compilation (which they're supposed to, if unused) - these make up something like 95% of the size of an app I'd recently been working on. I'd only noticed it because this was a rework of one I'd made ~10 years ago, before AppCompat existed.

I can't help but wonder if some of the "optimizations" done by Google when you turn over your keys and let them compile the apk is just removing this extra bloat.

A new out-of-box “Empty Activity” app project in Android Studio compiles to a 1.59 KB APK (if implemented in Java; it goes up to 2.26 MB APK with Kotlin). Rip out the dependencies on AndroidX, and the APK size plummets to 103 KB. (The APK for the de-Appcompat'd Kotlin version is, correspondingly, 709 KB.) 1.5 MB overhead – fifteenfold – for a more convenient layout[0] and the Material theme. Mind-numbingly wasteful. In a big enough app, that overhead will be overshadowed by the size of the meaningful bits, but how many apps really get that big? How many games include Appcompat and then draw their own UI anyway?

[0]: https://developer.android.com/training/constraint-layout

Is the battery easily replaced? I feel like at least some part of slow down I've encountered is deterioration of the battery, since the battery can't deliver the same power for peak moments like before the device feels slower.

As to whether installing an AOSP-derived Android distribution is easy to install or not mostly depends on whether the device is locked in some way or other. If it is you'll need to unlock it which - again depending on the device - can be as easy as flipping a switch or as hard as trying to get some code from a vendor which doesn't really want to give that code or which might not even exist any more. Installing a distribution is no harder than installing Debian, keeping it up to date is easy as it supports OTA updates. Once you're over the first hurdle - unlocking - it should be easy enough.

As an alternative you could root the device and disable (or remove) the bloat in the stock distribution, this often goes a long way towards getting a more usable device. This is what I did on those few devices which I've used on the stock distribution - remove as much bloat as possible, remove all social media cruft, etc. This can lead to surprising results like the battery lasting twice as long and with that giving new life to a tired old device.

How exactly do you install a custom android?

I use LineageOS, which has step-by-step instructions on how to prepare your phone/install the OS. A list of supported devices is at https://wiki.lineageos.org/devices/, with various guides on each device-specific page.

Try buying an iPhone.

I didn't realize there was much of a homebrew DS scene. What is the state of it?

Weirdly there is a fresh homebrew scene for the dsi which lets you install custom firmware and run games off the built in sd card slot.

You can play Rogue in the GBA and Nethack/SCummvm ports exist for the NDS.

You say that like it's an impressive feat for the GBA, but Rogue was originally developed for a computer that had less than 1/3 of the clock speed of the GBA's CPU. :)

But the GBA is pretty tiny on storage and limited on input ;).

Yes, I know you could play Rogue under an 8mhz-m68k mac perfectly, but bear in mind GBA cartridges and RAM are really tiny.

But hey. On input, I played Nethack under a PSP, underclocked to 25-50MHZ, the battery lasted a week and more.

Now I am trying to test which older machines could run Nethack 3.6.6. I guess a 2MB m68k Mac would be enough.

No, using telnet/ssh is cheating.

> web browsers and all kinds of stuff on a machine with just 4mb of ram

The PDA's have less RAM and they still had browsers and in some cases, even emulators.