Look up the boards that use the Lattice ECP5 chips, I think these are the largest FPGAs that have a fully open toolchain: https://github.com/YosysHQ/nextpnr

You'd need to learn some digital design for any FPGA board. I recommend the book "Digital Design and Computer Architecture" by David and Sarah Harris.

You don't need to write a software stack for that, just install something like netbsd.

I'm sympathetic to your argument, but I think also many problems (or popular implementations) turned out to be quadratic. For example, the resolution of windows 95 applications vs today.

My solution to that is to punt on the actual bit blitting pixel pushing stuff. :-) I still want my high dpi fonts and I’m willing to cheat a little to get them onto the monitor. And given that we are all probably using a modern monitor with multiple powerful processors on board I can pretend that the SBC I use as a video card is just part of the monitor.

Windows 95 could be very snappy... except when you started copying files to an external hard disk, or if your disk was too fragmented, or if you ran out of memory and things started being swapped out, or you had a buggy hardware driver, or you had a virus, or you had an antivirus program, for that matter...

I think there's a lot of nostalgia at play here. There's a lot of ways in which modern computing is far nicer than it was in the past.

> I think there's a lot of nostalgia at play here

I don't think that's the case with latency, as we can measure that directly.

> There's a lot of ways in which modern computing is far nicer than it was in the past.

And resource consumption and latency isn't one of them.

My delight at lower latency pretty quickly evaporates in the face of a spinning hourglass. I'd rather have consistent availability at the expense of latency.

>computers are orders of magnitude nimbler than what experience in our day-to-day

True but that's looking at it from only a technical POV. The market clearly doesn't care about some extra latency, and in return bloat means a massive decrease in the cost and time taken to develop software. Electron allows a company to use a single team of web devs (most common skillset, cheaper labor pool) cross-platform, why would they give that up for better performance? The bloat will keep piling as long as that's the case.

> bloat means a massive decrease in the cost and time taken to develop software.

In the past, programmers bit-banged I/O bare metal, and hardware tinkerers soldered computers from TTL IC's.

Today, programmers code in Python & glue software libraries together. Hardware folks wire CPU-powered peripherals onto creditcard sized supercomputers.

Same concept. Only the building blocks have increased in their (internal) complexity.

I agree, there's no point being mad at it since there's good reasons why it ended up this way

You might check out what the Precursor open source phone project is up to [0], they tout a compile-it-yourself RISCV cpu running on a Xilinx Spartan 7

There's also a FPGA implementation of the 6502 CPU running at 100Mhz, that's on a Spartan 6 [1]

I have some overlapping goals as you but plan to start with Ben Eater's 8 bit machine and NAND to Tetris. I'm curious about ternary logic - true false and maybe - like charlieplexing. I think Konrad Zuse had built something like this. Move onto designing an instruction set from there, how much can I keep it as an analogue dataflow computer instead of a stepwise serial instruction machine. I heard someone say the ENIAC was a parallel machine before von nuemann ruined it :)

[0] https://www.crowdsupply.com/sutajio-kosagi/precursor

[1] https://hackaday.com/2021/10/15/heres-a-100-mhz-pin-compatib...

> There's also a FPGA implementation of the 6502 CPU running at 100Mhz, that's on a Spartan 6

There are plenty of free RISC-V soft cores that will run at 100 MHz on an FPGA, and that's at 1 instruction per cycle, not the 2-6 cycles per instruction that 6502 takes. Also a 32 or 64 bit RISC instruction does a lot more useful work than a 6502 instruction e.g. `add Rd, Rs1, Rs2` is one instruction and one clock cycle vs 13 instructions and 38 clock cycles for a 6502 to add two 32 bit numbers at fixed locations in Zero Page (virtual registers, if you like).

"Modern interfaces" like USB, PCIe, HDMI etc tend to be complex. So forget wrapping your head around those.

I think you have a few options:

a) Go the FPGA route. FPGA design is not for everyone, and you're working on a black box in a way. But FPGA's capabilities & their architecture tend to be well-documented. And yes there are some supported by open source toolchains.

If you can overcome the hurdle of the FPGA design flow, then... your fantasy (and FPGA size) is the limit. Check out OpenCores.org for some ideas on ready-made-building-blocks to use.

In this case, you'd want to pick a board where high-speed interfaces you plan to use (like RAM and video output) are on-board. Low-speed / simpler peripherals you can wire up as needed.

b) Just pick a reasonably documented SBC (Raspberry Pi, a recent/smallish RISC-V board, or Beagleboard come to mind). Ignore the more complex interfaces (for example, video: start with small RTOS or bare Linux kernel, figure out how to initialize a framebuffer & go from there. No hardware-accelerated 3D shenanigans). Or just use them through OS-provided interfaces to hookup things like a keyboard.

c) Forget those modern / complex interfaces, and dive down into the microcontroller world. For example a RP2040 based board + graphical or character LCD hooked up, and you can wire a keyboard from individual switches if desired. :-)

I’m doing something similar right now. The eZ80 is a modern implementation of the Z80 that runs 50MHz, is pipelined like a modern CPU, and runs most instructions in a single cycle rather than 5-10 like the Z80. It’s also 24 bit in both days and address. So it’s a lot easier to program and a LOT faster than the original.

The 68000 is also a processor from a simpler time that is easy to source and still being made. There’s a CMOS version with a static core too so you can spin down the frequency to 1Hz and it will still work.