Pi Pico-Powered ATX Motherboard

For a couple of years, embedded developer and Rust addict [Jonathan Pallant] aka [theJPster] has been working on a simple computer which he calls the Neotron. The idea is to make a computer that is not only easy to use but easy to understand as well. He describes it as a CP/M- or DOS-like operating system for small ARM microcontrollers. His most recent project is powered by a Raspberry Pi RP2040 Pico and built in the format of a microATX motherboard. This board packs a lot of features for a Pico-based design, including 12-bit color VGA and seven expansion slots. See his GitHub repository for a full list of specifications, and all the files needed to build your own — it is an Open Source project after all.

Besides the Neotron Pico itself, a couple of gems caught our eye in this well-documented project. [theJPster] was running out of I/O pins on the Pico, and didn’t have enough left over for all the peripherals’ chip selects. Check out how he uses an MCP23S17 SPI-bus I/O expander and a tri-state buffer to solve the problem.

On a more meta level, we are intrigued by his use of GitHub Actions. Per the standard concept of repositories, they shouldn’t contain the results of a build, be that an executable binary or Gerber files. Distribution of the build products is typically handled outside of GitHub, using something like GitHub’s Large File Storage service, or just ignoring convention altogether and putting them in the repo anyway. [theJPster] uses another method, employing GitHub Actions to generate the files needed for PCB fabrication, for example.

The Neotron Pico is the latest in a series of boards made to run Neotron OS. Previous boards include:

  • Neotron 9x — Microchip SAM9X
  • Neotron 1000 — STM32H7 + Lattice Semi iCE40 FPGA
  • Neotron 600 — Teensy 4.1
  • Neotron 340ST — ST 32F746G-DISCOVERY

18 thoughts on “Pi Pico-Powered ATX Motherboard

      1. If you look at page 628 of the datasheet for the RP2040 the graph of “Power Consumption versus frequency” the X axis goes from 10 MHz all the way up to 150 MHz. So in-house they must have clocked them up to 150 MHz.

    1. If you see something that is not exactly what you want in your mind, the general rule is to connect with the developer and find out if they would be receptive to a branch or patches.
      If they are receptive then you implement all the feature creep you want using YOUR time and send a pull request.
      If they are not and the license allows, then fork it and go crazy.

      But the usual reason to start simple is to get something working and then make it more complex. The very first step in walking on the moon is getting a rock to go really high up in the air!

      I have to admit that I did think for one second, I wonder what you could do on a board with say 64 dual Cortex-M0+ cores clocked at 150 MHz (0.93 DMIPS/MHz ~17856 DMIPS which would be approximately equivalent to a Core i7 930 or Core i7 4820K in terms of integer maths only). It would be a massive undertaking, it would be frustrating on almost every conceivable level. But you would definitely gain your 5 minutes of Internet fame if that is what you were chasing. The hardware would probably end up being easy compared to the software and limited set of problems that the hardware could solve well.

      Well, I’m off to do some reading on massive parallel processing with limited communication.

  1. In his list of things [Pallant] says Neotron will “probably never be able to do”, he includes “be useful for day to day use”. I think this is complete bunk. Okay, so maybe a full-featured web browser that can keep up with today’s web sites is beyond its reach, but this sounds like a failure of imagination. He also rules out support for 3D graphics, which is another thing that 6502s and Z80s were fully capable of in the early 1980s.

    I do think it’s nice that he is intending to make this a platform that is binary compatible across a wide range of Cortex-M microcontrollers. I think that we have gotten far too dependent on protected memory multi-tasking operating systems, and the modern crop of Cortex-M development boards provides an opportunity to explore just what can still be done with single-thread systems. Most of us never split our screens on our smart phones, so as long as programs can save their state when they exit, and pick back up where they left off, my own daily needs don’t even need multi-programming.

    Another “will probably never do” is “be directly targetable from Rust”, which is a shame. I mean, it’s great that people now have multiple tiny platform options that they can run Python programs on, I think if one’s primary programming language is Rust, there needs to be a Rust option. And if that’s not possible, it may be that Rust is fundamentally more complicated than it should be. For a long time, C development for microcontrollers was just out of reach, but we got past that, even if we don’t have an option for developing C programs ON a PIC or AVR. Fact is, anything that was doable under CP/M should now be doable on a Cortex-M ARM system, and that includes writing, building, and debugging compiled code.

    1. I try to set expectations low.

      The target from Rust is specifically about having libstd support, for opening files, allocating memory, creating queues, etc. It’s a big endeavour if you aren’t POSIX compatible. The solution is to use a bare metal target and supply a crate which sort of looks a bit like libstd but only has what Neotron can actually support.

      Neotron will never run rustc simply because the compiler needs hundreds of MB of RAM and support for threads and processes. tinyc or some other kind of CP/M era C compiler is totally in scope though. But I’ll probably start with an Arm monitor and assembler.

  2. … hard to take someone seriously when they claim that modern ARM is “clean” RISC and the original 68000 is “messy” CISC. That’s basically only the sort of thing you’d say if you’ve never actually worked with 8086 or 8080 (actually messy CISC) or very early ARM/MIPS/SPARC/POWER (actually clean RISC)

    1. These board form factors are cool, but the chip shortage means you will have to wait till mid 2022 to even build one.
      I think everyone does their own version eventually, and usually built to solve a specific use case (we needed 10A outputs for hot-ends etc.). The expansion sockets also seem kind of redundant,,, especially if you are going to re-spin a simple PCB card anyway… if one stuck a proto-board area on it, than it would start to make more sense. ;-)

      Ben Eater does a great series on building a 6502 breadboard VGA card with logic ICs:

      He also sells very reasonable hobby CPU kits similar to ones from the late ’80s.

      Much of ARM higher complexity ops are still a mess in many ways (hence disabled in most compilers by default for safety reasons), but it could always be worse after a few decades… Risc-V may offer a real solution if the vendors can resist deforming it like the bluetooth standard.

  3. My boards arrive in the post today. I have all the components to complete the build of five boards in stock.

    Yes, shortages are a problem. But there’s also a wide choice of parts that do broadly the same job, in a range of footprints, so you can usually find something.

  4. Good point, well made. I’m not a 68k expert beyond booting a CDTV and reading H&H version 2, which has a lovely worked example of a 68008 based lab instrument.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.