1. 22
  1. 8

    This is such a great idea compared to those “hairshirt” projects that are just recreating old systems. I’m old enough to remember the microcomputer era, and the thought of going back to a 6502 or to CP/M fills me with as much joy as going back to the 1400s and experiencing feudalism and cholera. (As long as I’m speaking of time travel: if you went back in time and offered teenage me a fist-sized computer with a 32-bit CPU and a freakin’ megabyte of memory, running hundreds of times faster than a 6502, I’d have thrown my beloved Apple II in the trash without a qualm.)

    I actually think Neotron is aiming a bit too low. I’d love to see this target systems with an MMU, and the capability of running a real microkernel OS. Then this system would actually be reaching toward the future, exploring a world beyond Linux/Darwin/Windows and their baggage. There are a bunch of tiny microkernels, some written in Rust, that would work well in a small experimental platform like this.

    1. 4

      RISC-V is the best bet for those of us that want this. I think the BeagleV will be the first truly useful (by my definition) board available for us plebs: https://beaglev.seeed.cc/ although Intel has announced they’re going to be building some RISC-V boards in a year or so. I’m really hoping these are paired with a cut-down version of Intel’s core GPUs, which would make them an excellent hobby / exploration system.

      1. 2

        Why RISC-V specifically? I haven’t worked with it, but what I’ve heard is that it lags behind ARM in price-performance; its benefit is being an open source design, which is a good thing but not directly relevant here. (Or maybe that’s just me. My wanting to tinker with a system doesn’t extend to wanting to redesign its CPU!)

        1. 3

          It’s just more likely to be where home-tinkering-compatible stuff is originated. Seems to me that you’re far for likely to have an open documented system being built around RISC-V than ARM, which seems to be about 30% binary blobs by weight.

      2. 3

        If you want an MMU and a microkernel, but still something much simpler than Unix, you might like Precursor and the Xous operating system being developed for it.

        1. 2

          The Precursor looks neat, but the security focus seems to make the price unreasonable for anyone who doesn’t share that requirement. $500 is a lot to pay for a 100MHz CPU and 16MB RAM! It makes more sense when you realize the CPU is running on a hefty FPGA, but that’s not interesting to me.

          1. 2

            I (maybe stupidly) bought one, with the hope of being able to run Palm OS. It’ll be the fastest Pilot yet!

        2. 2

          I’m old enough to remember the microcomputer era, and the thought of going back to a 6502 or to CP/M fills me with as much joy as going back to the 1400s and experiencing feudalism and cholera

          I mostly agree, but I do miss one thing: The BBC Model B came with circuit board diagrams in the back of the book and the CPU was simple enough that I could write the verilog for a reimplementation. The software stack was small enough that you could read all of the code. The entire thing, hardware and software, was probably the last computer that I used where a single person could completely understand the entire hardware-software stack. That is something I miss.

          1. 1

            I wonder if it’s possible to have such a thing but with a CPU less awful than a 6502. (At least, that was my experience of the 6502 — I could write Z80 code but the 6592 was just too constrained, esp after Woz had taken up almost all of the zero page with system data.)

            Like, a basic RISC design with 16-bit data and addresses. I’ve never done any major hardware design so I’m not sure how complex that would be. (Of course one could build and run that on an FPGA these days.)

            1. 3

              The 6809 is an underrated 8-bit CPU from Motorola. It has two 8-bit accumulators (that can be used as a 16-bit accumulator for some operations) and four 16-bit index registers (one of which is the system stack pointer—no more 256 byte stack). You can also write position independent code. And like the 6502, it has a zero page addressing mode, but the “zero page” location can be changed.

              1. 2

                A 68030-ish would be a good basis for hobby / tinkering systems. This will be an unpopular opinion, but so would a (DX) 80386 or 80486 derivative, if you build it with a fixed set of peripherals and without all the BIOS legacy crap that only runs in real mode anyway.

          2. 5

            We are saddened by chat clients that require multi-Gigabyte installs, and systems with hundreds of millions of lines of source code that no one person could ever hope to understand. We want to build a machine that is sized for an individual to comprehend, not a trillion-dollar corporation.

            If “simplicity” and “comprehensibility” are goals, then Rust seems a poor fit for this project, given the complexity of its syntax, semantics, and compiler toolchain. Is there something that I’m missing? From my perspective right now, it looks like Rust was only picked because the authors wanted to use it, not because it was a good choice for the project’s goals.

            1. 6

              On the one hand, all that does sound a little hollow once you realise this system can’t run either the Rust compiler or get a port of Rust’s stdlib (both of which are acknowledged further down the page). I’m all for sticking it to trillion-dollar corporations, but there won’t be much sticking it to trillion-dollar corporation if you need a trillion-dollar corporation computers and software to do anything with the Neotron. (In fact, one of the sample applications is a 6502 emulator that runs Tiny Basic – it’s hard to escape the thought that maybe it would’ve been better to just port Tiny Basic instead!)

              On the other hand, cross-compilation for more resource-constrained systems wasn’t all that uncommon, not even for consumer software, until not so long ago. IIRC Doom, though released for the IBM PC, wasn’t developed on IBM PCs. The N64 dev kit ran on SGI (Onyx, IIRC?). And at the end of the day this is a hobby project, I think it’s certainly achieved its purpose if people are having fun with it…

              1. 2

                Originally you needed a Lisa to develop Macintosh software, although by 1986 or so there were native dev tools like Lightspeed Pascal.

                You still can’t develop iOS software on iOS … but that’s being addressed finally, in the next release.

                I think it’s fine if you can’t write system software directly on a device like this. It would be hell to debug anyways. (Ask me for horror stories about debugging on Macs before they had a solid OS with processes and memory protection.)

              2. 1

                Nim would actually be a good choice. It’s a much friendlier language (kind of looks like Python if you squint, and uses re-counting GC) but it’s also good at producing fast safe programs. I am not sure if running on bare metal is officially supported yet, but I know some people have done it.