Ask HN: What is the most powerful, fully open, fully programmable computer? | Hacker News Reader

Ask HN: What is the most powerful, fully open, fully programmable computer?

44 pointssph41 comments

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?

View on HN

Have you considered working off a commercial ARM microcontroller, say ARM M3, from STM, NXP, or Infineon? It's orders faster than a Z80, the documentation is world class, you can control every bit code that it runes, and there's a whole industry of people who spend their lives writing code for them.

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.

that's what i plan to do also either on stm32 or microblaze

The RP2040 is a great platform IMO to explore this with both because it’s very cheap for a microcontroller of its tier, it has some interesting features like dual core not typically found on microcontrollers, and the programmable IO means that you can “””in hardware””” implement protocols that would normally be completely absurd to run on a micro controller, like DVI.

I didn't know it was so cheap. Just got a Pico W with 2" display for less than £30. Now I gotta port my Forth interpreter to ARM... looking forward to a fun weekend!

30 euros is robbery, the MSRP for the Pico is $4 and the MSRP a for the Pico W is $6

pi’s have been in a state of godawful inventory status, and consequently godawful pricing if you can even find stock, since 2020. I saw a thread recently that alleged that stock was kind of returning to normal ish, but I didn’t get a chance to read into it.

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

Yeah the picos should be priced reasonably lol and if they’re not you should get an SAMD21/51, ESP32, or NRF52 and save your money

The Pico W was £6, I said I also got a display for it, and delivery was almost £10 for some reason.

That's what I spent for dinner yesterday so I'm not gonna lose sleep over this figure.

Perhaps the Talos-II Power 9-based systems. Unfortunately, these are rather expensive, systems start at around US$5k.

https://www.raptorcs.com/TALOSII/

> "a price that won't break the bank"

5000 dollars. Geez, why the hell is this thing so expensive? Who is their target customer?

The target customer is basically you. Someone who wants to get away from x86, have complete access to all of the firmware and microcode, but still have all the performance of a modern system.

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.

Is this the descendant of PowerPC chips used in Macs? The last they used was a "G5", is this a "G9"?

Not in a direct line. The PowerPC was derived from IBM's Power chips (and chipsets) in the 1990s as a joint effort of Apple, IBM, and Motorola - for example, Motorola contributed the 88k bus interface (Apple had some working 88k-based prototypes) and low-power manufacturing experience and IBM streamlined the Power instruction set and created a single-chip implementation.

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.

> That cuts out all modern x86 and ARM systems (you need a lifetime just to program a single GPU driver),

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'm bot sure exactly how open this is, and how good the documentation is, but maybe the Core V MCU devkit [0]? This is very new, so I'd probably wait a bit for it to mature.

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...

If you are writing a software stack from scratch, perhaps you should start with a relatively low-end RISC-V SBC. Once you have accomplished that, you would step-up to a more advanced SBC and implement the next higher levels of abstraction.

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.

The most powerful, fully open, fully programmable desktop computer today is the Raptor Computing Systems Talos II workstation. It uses IBM OpenPOWER CPUs and the OpenBMC board firmware.

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.

What kind of things is this generally used for?

https://www.crowdsupply.com/sutajio-kosagi/precursor

>explore alternative and novel avenues for computing

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

Place and route would be just as much of a nightmare as it is on FPGAs. Sure, you measure latency in cycles instead of picoseconds, but you probably can't solve a larger fraction of netlists.

You definitely need a new language to program it well - one where latency is not defined.

I think I've got an algorithm figured out for the programming. It's an iterative process to get something usable. I should know in a few weeks.

You might just want an FPGA at that point. It won't be competitive with modern CPUs (by an order of magnitude), but it will be fairly well-documented and more flexible than most other boards. You could target RISC-V with emulated cores, or try your hand at implementing custom logic.

Raw performance isn't much interesting to me: I'm not planning on running production Postgres on it, just to prove to myself that computers are orders of magnitude nimbler than what experience in our day-to-day. Windows 95 had less latency on a 486 than most desktop OSes on a Ryzen 7. The sheer amount of layered abstractions we keep piling on and on isn't helping.

In 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?

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 data 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.

> It won't be competitive with modern CPUs (by an order of magnitude)

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.

Why not make a fully open SoC on an FPGA? It's pretty straightforward with LiteX. You can use the open source tools to synthesize and flash. And then run Linux on it. Essentially everything is open.

One notable contender for the title of the most powerful, fully open, and programmable computer is the RISC-V architecture. It's gaining traction as an open-source alternative to proprietary instruction set architectures. RISC-V allows for customization and innovation at a fundamental level, making it a promising choice for various applications.

If you’re interested in the journey, and happy to run on a simulator rather than hardware, https://www.nand2tetris.org/ is a decent ‘full stack’ experience.

I know it’s a fairly popular resource here - has anyone extended the content to go all the way with an FPGA implementation?

Reply on news.ycombinator.com