Funnily enough, in a world with WASM, we might actually have Java in the backend and C in the frontend rather than vice versa as it would've been likelier in the 90s.
The smallest transfer done from memory is a single cache line, which on most desktop machines is 64 bytes, or 512 bits. You could imagine a memory bus that was 512 bits wide and transferred a cache line per clock, and this would improve latency when compared to a serial bus with higher clock speed. HBM doesn't do that, though, instead every HBM3 module has 16 individual 64-bit channels, with 8n prefetch (that is, when you send a single request to a single channel, it will respond with 512 bits over 8 cycles).
Not likely, unless they make a headset which doesn't do much of anything by itself and is just meant for streaming from a PC. To make a standalone headset which can draw on the Steam catalog they would almost certainly want to use a variant of their SteamOS Linux distro.
Valve already has its own OS for a mobile device: Steam OS (based on Arch) on the Steam Deck. My bet is that they'd just modify that for a standalone headset.
I would say 6502 < Z80 (cheaper in a good way leaving more for graphics+sound support chips).
The first time I used dBase II on a Xerox C/PM machine was when I realized what a business computer could be like. It seemed standardized more than the PETs or TRS80s.
> The 6502 needs access to memory only half the time, during the what is usually called the ϕ2 phase of the clock. The other half of the time, so long as you tri-state the CPU address pins,² the bus and memory are available to other systems.
> The Z80 does not have such a well-defined, synchronous system of accessing RAM. Many cycles don't need RAM access, but many do, and which particular ones do and do not depend on the instruction mix.
> There is no "do nothing" solution to this constraint, and Z80-based systems that wanted consistent video output would have to solve this one way (hardware) or the other (software).
As with all tools the goal is to be able to use the tool without fear.
Remember the first weeks of coding C? It took me 4 years to not get cold sweat just thinking about using it when the compiler didn't inform you about a typo and you have to rollback the code all the time to fix problems and learn assembly (in X86, ARM and now Risc-V).
And that was without deadlines or any delivery pressure.
Today I realize C is for mad people, but I learned to respect the thing while no longer being afraid to use it in a real scenario.
Multiply that by all the C(++) coders on the planet and we have lost a billion man hours...