Sierra digital cameras on the Apple II
colino.net
colino.net
The Apple II has a very interesting and quirky software collection. Quite a few weird little games made by bedroom coders, along many of the earliest titles of the big names.
I highly recommend anyone who's interested in "retro games" to explore the Apple II collection. Many are unplayable by modern standards, but you can use walkthroughs and save states to see what these games have to offer. Today "retro" is largely about consoles, but there are only so many times one can watch NES speedruns on Youtube!
A bit pedantic, I realize, but the original Apple II had a max of 48k of RAM, while the IIc had significantly more ram at 128k. Software is (AFAIK) otherwise compatible between them.
In the 8/16 bit single tasking era I feel like system requirements were generally pretty accurate hard minimums where the program would either not run at all or not run reliably on lesser hardware. When you don't have swap memory becomes a hard limit, and when memory was measured in kilobytes or single digit megabytes programmers tended to have a good idea how much memory their software would actually use.
In the 16/32 bit cooperative multitasking era requirements necessarily loosened up because the application can no longer assume it can use the entire memory space, but in my experience they were still often pretty close, at least when it came to games. My first family PC was a 486SX with 2MB of RAM which met the requirements printed on the box for the Windows 3.1 version of Sim City Classic, but it did not run while throwing a "not enough memory" error. With hindsight I'm pretty sure my early WinModem was to blame and I probably could have rigged up an alternate autoexec.bat/config.sys/win.ini boot config to give Sim City as much room as possible, but I wouldn't learn the deep magic of DOS for a few more years. Classic Mac OS I recall being more straightforward because you could assign an amount of memory to an application ahead of time which it would not be able to go outside of so you always knew what could run.
In the modern preemptive multitasking era, especially once we went 64 bit, I feel like system requirements mostly stopped mattering as far as minimum capabilities go but instead shifted to a nebulous "below this we're not willing to stand behind its performance". It's rare to find anything that truly can't run on anything lower than the minimum specs, though they often will refuse to install (which can of course be "fun" years down the line when an unexpected change to CPU identifiers or previously unimaginable amounts of memory/disk cause those heuristics to fail despite being orders of magnitude more powerful than the hardware it was designed for).
Most desktop software I've seen system requirements listed for in the last decade or so has either listed a spec that would have been budget years prior or simply lists the earliest version of its intended OS that has upstream support at the time, and more often than not doesn't actually check either.
Monochrome only, and it downscales. Only 1/4th of the pixels' IDCTs are computed, for "speed". It is also hardcoded for 640x480 images, again, for "speed" :-)
It's based on picojpeg, heavily reworked to get rid of about all intermediate buffers, core decoder functions rewritten in assembly.