What I've noticed(as someone relatively active around retro hardware communities) is that the users sort into demographics with rather conflicting goals: * I w

What I've noticed(as someone relatively active around retro hardware communities) is that the users sort into demographics with rather conflicting goals: * I want to run Linux, or CP/M, or a particular version of Basic, or something else with existing software. * I want to recompile existing C code to the new hardware * I want to directly control the hardware with the most minimal kinds of OS layer, and probably using assembly, not C. * The challenges of the hardware are part of my motives for using this platform * I want to work within a certain retro aesthetic and I don't mind adding more hardware or leaning on other people's code to get there So in practice, users tend to arrive in waves according to what developments have happened on that platform previously: neo-retro micro designs released in the past few years like X16, Agon, or Neo6502 first attract people doing the essential hardware bringup tasks. Then they settle in to a cycle of incremental porting and toolchain construction. Gradually the platform becomes understood well enough to do some decent applications. The whole while, everything you wanted to do on the device would be accomplished more readily by using a commodity Linux box, but part of the appeal is in having control over the details. When we use computers to be productive we're usually giving up a lot of the details to software packages and dependencies that are poorly understood by the larger software world and have become the defacto thing everyone uses simply because no equal to them exists. In the time when the retro stuff was actually new, there was a lot of anticipation for those tasks becoming possible someday, but they weren't yet, and that characterized computing as unrealized potential instead of a dull, opaque reality.