It sometimes seems that all we have done over that period is add layers and layers of complexity.
The machine itself was not necessarily faster, but the extra memory was a real game changer.
Even segmented like on the 8086 was a better solution than the banking options on 8 bit hardware. The ‘86 segment registers were much more flexible.
Long term, 640k may not have been enough, but in a text based environment, 640k is just so much more from both a data and code aspect to be really empowering.
256k and Lotus 1-2-3 was much more capable than anything an Apple could do. Having much more room for more capable code aspect as well as richer and more data.
You could do gymnastics with code overlays and data paging, but that was hard software to write and just painfully slow.
Extra memory just made things that much better.
First, they're more granular. Segment represents 16 byte blocks, most banking systems had 4K blocks.
Second, the segments can overlap. The most basic example is the Tiny model where CS and DS are identical. 64K of shared code and data. Separate them, and you can have 64K of code and 64K of data with almost no code changes. (The Small memory model).
Third, you can move memory between segments. With banks, the typical setup if you wanted to move data from Bank A to Bank B, you had to move it out of Bank A, enable Bank B, and then move it back in. Obviously with more sophisticated banking architecture, you can do whatever you want. Eventually you creep into more of a MMU logic than simple banking.
Finally, somewhat related to the previous, you have the ES, Extra Segment. While more limited than the CS/DS in terms of capability, it was enough to let you shove things around without having to clobber your CS/DS if you didn't want to. Saved a bit of juggling there.
Regarding the part about code spanning, yeah, that's an issue in terms of continuity. You simply couldn't have code that was larger than 64K, the PC will wrap on the CS.
But, you had direct support for "far pointers". You could "Jump" to SSSS:XXXX, storing the entirety of the pointer, and do a far jump directly. The jump resets the CS for you. You can't do that with a banked system. You're responsible for banking things in at the right time. So, if you commit to far pointers for all of your function calls, the code just links and it "just works" without you having to do anything manually.
More expensive of course, so folks would make internal little worlds of code and data and contextually bounce between them. But you have the option of not having to do that if you didn't want to.
Banking registers also weren't always readable, in which case either you'd need to shadow the banking register or avoid nested/interrupt scenarios.
I'd prefer 8086 segmentation any day over the headache of trying to execute 6502 code from a bank-switched cartridge with a single banking window and a write-only banking register.
I don't think anybody would use such a machine full-time, but with a radio and a cabin it would suffice for offline work.
Of course there's no native CP/M for the 6502, but remakes have been made..
In that sense I'd regard it as a remake, rather than a port. But it's impressive it is possible at all, and it does look like a fun project. (I remember watching some of the porting/building videos when I was working on my own understanding of CP/M for emulation purposes.)
As late as 1997 I was repairing Amstrad PCWs that were still in Real Live Active Service on oil platforms.
And then after that, I was reading those funny 3" disks in and converting them to WordPerfect.
And then from WordPerfect to Word, a little later.
Be the guy selling shovels I guess.
We had record players for that, and Walkmans for when we were out and about.
Because most people I know certainly have different workloads and need their rendering as part of the work, not to decorate it nicely.
But for keeping a distraction free digital diary, it might be a nice device.
Maybe Bullshit Jobs was onto something, it seems that my entire work day consists of work decoration.