Ask HN: What is the most powerful, fully open, fully programmable computer?
I'd like to write a software stack from scratch, starting from low level assembly to explore alternative and novel avenues for computing.
I'm looking for some hardware that comes with as many modern features such as multiple cores, USB, PCI, etc., and with datasheets and open specs for all components of the board, that are reasonably possible for a single person to grok.
That cuts out all modern x86 and ARM systems (you need a lifetime just to program a single GPU driver), RISC-V boards still depend on binary blobs and underdocumented auxiliary chips.
Without going as far down to a Z80 microcomputer, what is the most powerful and programmable computer I can plug a keyboard and monitor to, and start hacking?
42 comments
[ 2.8 ms ] story [ 104 ms ] threadIn any case, I don't know anything about FPGA, any board to recommend, that's useful for a pure software engineer with only a passing knowledge of electronics?
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.
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.
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 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.
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.
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.
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 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).
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. :-)
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.
Two orders of magnitude.
It's a struggle to get over 100 RISC MIPS on an FPGA, while current CPUs cores from Intel, AMD, Apple can maintain over 10 billion instructions per second.
https://www.raptorcs.com/TALOSII/
5000 dollars. Geez, why the hell is this thing so expensive? Who is their target customer?
The cost is high because it’s a niche product. IBM makes the CPUs for systems that they sell to enterprise customers (presumably at enterprise prices). Raptor made their own motherboards for them. Limited production runs mean higher production costs, plus you’re buying a whole pre–built system rather than individual parts to assemble yourself.
The first PowerPC chip was the PPC601 (G1) which was used in Apple's Powermac 6100/7100/8100 series as well as some of IBM's RS/6000 workstations (e.g. the 250) - later chips were PPC603/604 (G2), PPC750 (G3), PPC74xx (G4) and finally the PPC970 (G5). More on the early part of the PPC's history and also Linux on PPC can be found in my (German only, sorry) talk at the LinuxTag 1999. Amazingly, the slides are still online at https://www.unix-ag.uni-kl.de/~linux/linuxtag99/linux_auf_po...
The Power9 chip in the Talos-II is derived from later Power chips which were used for later RS/6000 (p-Series) servers and workstations as well as some i-Series or AS/400 midrange computing systems.
It's uses the open source CV32E40P RISC-V core (in-order 4-stage RISC-V RV32IMFCXpulp)
> It’s probably the most “open-source hardware” board we’ve covered so far, since not only the hardware design files and SDK are open-source, but also the MCU core used in the CORE-V MCU. [1]
[0] https://www.openhwgroup.org/core-v-devkits/
[1] https://www.cnx-software.com/2023/08/04/core-v-mcu-devkit-fe...
I've written from bare metal: keys, display, networking, with hard realtime stuff (response times in millionths of second). It's not actually the bad.
E: we’re talking about picos… I actually don’t remember if they’ve been normal price wise lately or not- apologies if that was a mildly irrelevant comment lol
That's what I spent for dinner yesterday so I'm not gonna lose sleep over this figure.
As you progress so will the RISC-V environment and choices. And the cost of SBCs will continue to come down. Buying the most powerful SBC now is an expensive overkill. When working at the low-level you won't be programming PCI and USB straightaway.
With your stated goals, your growing RISC-V expertise will become increasingly valuable.
https://www.raptorcs.com/content/TL2DS1/intro.html
Openess might be impacted by add-on hardware. For servers, more powerful OpenPOWER systems are available from IBM.
Ok... lemme take you down a rabbit hole.... imagine an FPGA, but with no routing hardware what so ever... just a vast sea of LUT (Look Up Tables) base cells with 4 bits of input and output, from each of its neighbors. A latch on the inputs is clocked like a chessboard... all of the white, then all of the black... this slows down processing, but completely removes timing issues.
Properly programmed, a large fraction of all the LUTs could be doing computation on every clock cycle. Imagine a 1024x1024 grid of these.... you could throw inputs in one side of the array, and get outputs every clock cycle, as everything is pipelined.
Programming.... no coherent ideas about that... I have some, involving working backwards from the output.
Lets assume 1024x1024, 100 Mhz clocking, and a FP16 taking 24x24 cells... you could have 42x42 computes on each and every clock cycle, about 175 Billion FP16 ops/second... for something that takes up the same space as 64 megabytes of static ram. Bear in mind, that's being very conservative without optimizations.
At present, I can simulate that 1024x1024 grid at about 37 Hz on my desktop.[1]
[1] https://github.com/mikewarot/Bitgrid
You definitely need a new language to program it well - one where latency is not defined.
If this is for enrichment, you may as well compromise and let system firmware set up a framebuffer for you. Then you won't need to have much in the way of a driver. Personally, I'm pretty happy with VGA text mode, but that has significant limitations (only 256 characters, support is disappearing rapidly and is inconsistent already). Serial console works pretty well too.
If you're using prebuilt processors rather than fabbing your own, you can compartmentalize around using someone else's firmware to initialize the hardware. One day, maybe, replace coreboot/u-boot, but you don't need to do that to start. Plenty of valuable knowledge of low level stuff to gather without starting by doing everything.
IMHO, x86 is a good place to start if you want a lot of modernity. There's actually tons of official documentation on the processors and the basic perihiperals (many of which are integrated into modern processors) and there's also tons of contributed documentation, tutorials, and examples out there. Yes, there's a trail of destruction in the way of legacy bits and bobs, but you can draw a line in the sand and say only support processors with local apics, stable TSC, etc, and skip a lot of the legacy or at least do the bare minimum of legacy to enable the modern versions.
osdev.org is a good resource to help you get started on that adventure.
I know it’s a fairly popular resource here - has anyone extended the content to go all the way with an FPGA implementation?