Dinghy index concept papers PIC32 Platform . Abstract This paper is part of a larger project to create a new computing platform that feels nible and light. This concept is called Dinghy. Dinghy is a reaction to the heavy platforms that currently define desktop computing. See songseed.org/dinghy for more. This paper considers whether the PIC32 architecture would be a strong foundation for Dinghy. It concludes that it would not. Through this project, I reached a better understanding of the evolution of Unix. Intro 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. 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 it is not for me. It is possible to get gcc running for this platform MIPS32. See https://github.com/RetroBSD/retrobsd/issues/78 Serge Vakulenko has produced several console-based 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 Maximite on PIC32MX 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.  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 peek code over the top of part of the basic interpreter in order to escape it. I doubt it is particularly difficult, but have not done it so far. 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 VGA. 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. RetroBSD on PIC32MX 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 Olimex. 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. RetroBSD seems to be an unusual port of 2BSD in the way it does not need any kind of MMU. Discussed at hacker news, https://news.ycombinator.com/item?id=29352463 (The top comment at that link is wrong about "did not use a MMU", a bad inference from me. Read on for comments by people who have worked with the codebase.) LiteBSD on PIC32MZ 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. The PIC32MZ has 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. 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, and LiteBSD being forced to implement protected memory in order to support shared object libraries. Interacting with RetroBSD feels like a sailing a dinghy or driving a track car. 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 1983. 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 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. RetroBSD 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. LiteBSD 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 parallelism. Method, Build a new kernel for the existing maximite, as described above. 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 cards. Build a static-ram daughter card. This will evolve into swap. Build a disk-io daughter card. Build a network daughter card. --  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 code.