index concept papers

PIC32 Platform

MIPS is a CPU architecture that has been around for decades. In the late 80s
and early 90s it was a leading processor family in workstations.

MIPS is an elegant instruction set, and well-regarded. My generation were
taught 32-bit MIPS instruction set programming at university.

PIC32 is a SoC architecture produced by Microchip, built around a 32bit MIPS
core. Separate to the MIPS core, a PIC32 SoC contains controllers for CAN bus,
analogue comparators, UARTS, DMA, SPI, and much more. It also contains 128k of
system RAM.

The PIC32 family is oriented towards embedded work. But, it is a flexible
platform and has been adapted to other purposes.

I poked around on this platform before Dinghy had become a clear effort.

Platform resources

    The tooling situation for PIC32 is unpolished. Microchip make a large,
    highly-integrated IDE. Some may love it. I live in the command line, and
    IDE-first approaches alienate me.

    It is possible to get gcc running for this platform MIPS32. See

    Serge Vakulenko has produced several hacker-oriented development tools for
    this platform, including a tool to install binaries on the target platform
    (as an alternative to the Microchip IDE) and a port of QEMU that emulates
    PIC32 systems.

    There is a strong book resource for the PIC32 platform, _Programming
    32-bit Microcontrollers in C_ by Di Jasio. I have not worked through it
    methodically and am a novice in the embedded space. My impression is that
    this is an excellent one-stop-shop guide to fundamental concepts and
    developing on embedded platforms, with a specific focus on the PIC32. This
    book keeps close to an ancient, buggy and obsolete version of the
    Microchip IDE. Still, it is a good resource.

Notable PIC32 projects


        This is a hardware+software platform that originated via an article in
        an Australian electronics magazine. It offers a BASIC repl and feels a
        lot like an early-80s home computer.

        The PIC32MX chip used in the Maximite is roughly equivalent in power
        to a high-end 386DX. Hence, the Maximite is far more powerful than any
        systems from the era that it imitates. PIC32MX was released in 2007
        and has no built in support for memory protection.

        The hardware does offer sound and graphics, and this can be accessed
        from the BASIC console. The BASIC dialect is impressive, as is the
        story of the Maximite designer building it from scratch on his kitchen
        table. It is called MMBASIC.

        Alas, MMBASIC goes out of its way to prevent users from interacting
        with machine code. It offers nothing like PEEK or POKE.

        There are also licensing issues with MMBASIC. I found the author's
        ideas about copyright to be confusing. It seems likely that the source
        will never be released under a free software license.

        There will be a way to leverage the lack of memory protection in order
        to find a way past this. Loosely: you would find a way to populate
        MIPS machine code into some memory, and coax basic to jmp to the start
        of that memory block. It is probably not all that hard, but I have not
        yet done it.

        You can pick up Maximite clones from a number of sources online. It is
        best to find one in your region.
        I have bought several from Olimex and had no issues with these. If you
        decide to get into it yourself, note that you will need an unusual
        type of USB cable for powering the Maximite. I think it is called
        CABLE-USB-A-MINI-1.8M on the Olimex website.

        You can connect it to a VGA monitor and PS2 mouse. The PIC32MX does
        not have native support for VGA. Rather, the Maximite creator created
        a clever hack by repurposing the outputs of the on-chip interfaces.

        Alternatively, you can connect to it using a serial interface over
        USB. From linux, I find this works well,

            sudo picocom -b 9600 /dev/ttyACM0 --omap delbs,crlf

        The platform has some graphics features that are only visible from

        MMBASIC offers a text editor. It works, but is flawed. The editing
        context has a fixed resolution, even when you connect over serial. The
        screen-update code is primitive and lethargic. And it has almost no
        features beyond arrow keys, typing text.

        Similarly, MMBASIC offers a minimal shell for moving files between the
        SD card and memory, and for launching things.

        The Maximite does not support networking. There is an Olimex variant
        of the Maximite that comes with an ethernet port, but there is no
        integration to it in MMBASIC.

        Serge Vakulenko has ported 2.11BSD to the PIC32MX chip. This system
        can be installed onto Maximite hardware. This is fiddly, but there are
        decent instructions on the RetroBSD website. Extra parts are needed.
        For example, a PIC32 programmer. I got all the parts I needed from

        RetroBSD is sensitive about SD card performance. I had to try several
        cards before I found one that worked. If you are trying it and get
        weirdness, this is something you should look at. The card that worked
        for me was a SanDisk Ultra 16G.

        Once RetroBSD is up, it is a riot. Wondering around it feels a bit
        like being inside someone's monograph. There are editors and an
        assembler and a tight C compiler, and three dialects of Forth, and
        Scheme and console games. Several of these things are Serge's own
        work, from a long career.
        When you compile things, it doesn't produce an ELF file. Hell no. It
        just dumps raw MIPS machine code to a file and marks it executable.
        You can open a MIPS architecture book, and read the machine code
        directly. Or, open the file in a hex editor and flip bytes around to
        change the logic. It is glorious, and feels accessible in a way that
        x86 *nix systems never have to me.

        When RetroBSD came out, people in the forums were blown away that it
        had been done at all. Unix, converted to an embedded platform. It is a
        magnificent hack, and I feel my life has been a bit richer from having
        experienced it. I have bought several duinomite/retrobsd kits to give
        to friends.

        RetroBSD has no TCP/IP. (I think TCP/IP only came to BSD in 4.2.)

        From memory, the Maximite VGA and keyboard interfaces do not work
        either. It is serial only.

        I attempted to integrate a Gameduino, via the Arduino shield on
        socket. My aim was to get it to present vga and sound, via the
        Gameduino. But, in my ignorange, I think I have fried my Gameduino.
        Fortunately, this did not damage the Maximite.


        In 2013, Microchip released a faster, more powerful version of its
        PIC32 the PIC32MZ. This is probably roughly equivalent in power to a
        Pentium (P5), although not for FPU purposes, and it has far less
        avaialble RAM than a standard Penium system would have.

        It had a new feature: support for protected memory.

        Serge responded by porting 4.4BSD to this. Amazing. This is LiteBSD.
        It is run as a separate project from RetroBSD.

        Olimex released some boards that will run LiteBSD. I tested the EMZ64.
        Not all of the EMZ64 hardware is supported by LiteBSD. For example,
        the small display does not work. Also, there is no VGA. Only serial.

        LiteBSD on EMZ64 does support TCP/IP networking.

        Separately, you can run LiteBSD under Serge's qemu port. I found it
        fiddly to get going.

        LiteBSD feels very different to interact with than RetroBSD.
        But Serge and his team had all kinds of problems getting development
        tools working for it. There is no hosted assembler or C compiler.

        Potentially you could get a Forth repl going for it, but this would
        give you less power than in RetroBSD, due to the presence of memory

        The community for both LiteBSD and RetroBSD has dried up over the last
        five years. The forums were closed. There are still github pages.
        Serge is consistently responsive, and will investigate and integrate
        bugs. There is no evidence of active work on this project.

I was surprised at the contrasat between RetroBSD and LiteBSD. They are both
adaptations of the same source system, and adapted to PIC32 by the same
author. But they have an entirely different character.

    RetroBSD feels like a cheeky challenge-response interaction. You type
    something in at the console, it reacts to you. And, it feels light to
    interact with, yet rich.

    LiteBSD feels heavier to interact with. You have a sense that it is doing
    more. But, its potential is unrealised due to the tooling problems. The
    difficulties the team had porting tools to the platform relate to BSD4.4
    being a much more complex foundation. It has protected memory, and
    binaries need to respect ELF.

Interacting with RetroBSD feels like a sailing a dinghy. Interacting with
LiteBSD does not.

Design Pressure

    It seems plausible that the design pressure to accomodate networking
    raised the complexity bar on BSD unix over a short space of time. The gap
    is about four years: 2BSD was released in mid 1979, 4.2bsd was released in
    mid 1983.

    That is not the only account for the chasm between RetroBSD and LiteBSD.
    ELF emerged partly to allow support for shared-object libraries. This is
    unrelated to networking concerns.

    Still, I feel confident that support-for-networking is a heavy design
    pressure on a platform. More if the challenge for Dinghy.

Evaluate the reviewed system against the Dinghy concept


        Maximite is really two things. A solid hardware platform, and a
        troubled software system that sits on top of it.

        :: hardware

        The hardware is pretty good. It is partly the result of a clever hack
        (the VGA implementation), it has lots of expansion options. The
        concerns with it are storage and networking.

            Storage. It uses sdcard only. There is nothing resembling a hard
            disk option.

            Networking. It doesn't have any. There is an Olimex variant which
            does, but I don't know if support has ever been built for it.

        Some of the issues above could be overcome by adding devices on the
        arduino shield interface on the board. I don't know how fast or slow
        that interface is, and whether that would impede such attempts.

        :: software

        MMBASIC consciously limits the user's power by denying machine code
        interaction. This could be overcome: you could use memory tricks to
        hack a new kernel into place at each boot and thereby reach the the
        Bedrock and Mechanical Sympathy design goals.

        :: stepping back

        Conclusion: It would be modest work to get a forth going, significant
        work to get an event-loop+ethernet-drivers+tcp-stack going. And, at
        the end of that, it is still only a single PIC32MX processor.


        There is basically no support for its VGA or audio at the moment.
        Several people in the forums report on having had this working, but
        I could not find source.
        Hypothetically you could add support for these things, but I found
        RetroBSD to be pushing close to the PIC32MX RAM limits. I expect you
        would not have enough RAM left to do worthwhile applications.
        Also, I think it already swaps to the SD card at times.

        With arduino-shield extensions, someone who was sufficiently
        determined would be able to make something work. But, you would be
        building substantial parts of a clean computer on those Arduino
        shields, and I expect you would hit unacceptable IO bottlenecks.

        Conclusion: stacks of work, inadequate outcome.


        Like RetroBSD, it does not currently support VGA or audio. All
        interaction is through serial. It has more RAM, and you should be able
        to add support for those things.

        The existing hardware has fewer connectivity options.

        Conclusion: stacks of work, inadequate outcome.

There would be value to creating a small kernel for the high-end Olimex
hardware, hosting a forth or scheme repl. It would not be Dinghy, and it
probably won't do networking, but it would be cool.

If you were building a new system, you could seek to incorporate
several pic32 chips in the specification, and get extra power via


    Build a new kernel for the existing maximite, as described

    Create a new single-board computer consisting of a pic32 running
    the kernel and handling video and keyboard IO. This is the core of
    the new system.

    Create a bus from the fastest/most-flexible of the built-in buses
    (can, i2s, etc), in order to support the addition of daughter

    Build a static-ram daughter card. This will evolve into swap.

    Build a disk-io daughter card.

    Build a network daughter card.