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 does offer PEEK or POKE, but no command to jump
        to specific memory addresses. [1]

        There will probably 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 then 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.

        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.

        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.

        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
        protection in LiteBSD.

        The LiteBSD/RetroBSD slowed after 2015. The forums have been closed.
        There are still github pages. Serge is consistently responsive, and
        will investigate bugs and integrate fixes. Other than that, there is
        no evidence of active work on this project.

I was surprised at the contrasat between RetroBSD and LiteBSD. They are both
unix adaptations, and both target similar hardware. 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

    1) Networking. I guess that the design pressure of 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

    2) ELF. ELF emerged to allow support for shared-object libraries. In
    RetroBSD, you can put raw MIPS instructions in a file, chmod it, and then
    run the result. You can't do this in LiteBSD.

Of these, networking will be a challenge for Dinghy. Shared Object libraries
are probably unnecessary.

Evaluate the reviewed system against the Dinghy concept


        Maximite is really two things. A solid hardware platform, and a
        troubled software layer 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 gives 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 denies 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. (Or, there is an old fork of MMBASIC
        in the Olimex code repositories, left over from a time when the code
        was open. You could start with that.)

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

        Bad tooling story.

        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. That system would not be Dinghy, and
it would not be able to network. 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.


[1] 20200527. There is a new platform release coming, the Maximite 2. This
will be based on a faster ARM processor. Geoff's decision to bedrock to
mmbasic will allow this to be a seamless transition for any existing maximite