 |
ESP32-PC - Page 1 |
|
ESP32-PC - Page 1 |
After the semi-successful Z80 PC project, I wanted to do something a little less hardware involved, so that I could focus more on the experience and the software.
I decided to change direction, and try to use an existing basic hardware platform, and expand it to my specification, and then build software bottom up. The first direction I tried going for is taking a simple single board computer, and instead of running the typical Linux image, try to do some bare-metal programming to create a small & simple operating system.
Given that this system is supposed to be a retro style machine, the operating system is not required to support multi-user, or even multi-process. Think early 80s DOS. Since I also wanted to build the peripherals, such as keyboard and display adapter, I needed the hardware platform to support this.
For the keyboard, I decided to reuse my keyboard design from the Z80 project, which has a simple UART interface. That's not an issue, since almost (if not) all boards have a UART. The display, however, was a little more involved. Some boards have built in display output, such as HDMI, but require some elaborate driver code in order to use it. Other boards have a built-in parallel display output (40/50 pins), but I couldn't find a decent display that would connect successfully to these. The largest I could find was a 7" display, and it just felt too small.
I therefore decided to also reuse the display adapter from the Z80 project, meaning using an ESP32 controller that generates a VGA signal for the screen. I used the great ESP32Lib by Bitluni. Unlike Bitluni's original design, which utilized the ESP32 both as the signal generator and the processor to run the application, I wanted more freedom to load and run applications by users, without changing the device firmware. I decided to create a display protocol on top of the VGA signal generator, and connect it as an SPI slave to whatever will be running the programs.
The world of processors divides into two basic groups:
Microprocessors, to which the Z80 belongs, usually do not have RAM inside (ignoring cache), and are basically state machines. Once you connect some RAM and load it with a program, the processor will run that program.
Microcontrollers, however, contain both RAM and some storage (usually flash), and can usually only run a single program from its storage. This is great for embedded devices that are only supposed to do one thing, but for general computing that won't do. For example, the VGA signal generator is one task the ESP32 video adapter does, and if you don't need to update the protocol, it doesn't need to change, ever.
Microcontrollers are enticing because they are cheap, available and have a large amount of documentation and code libraries and examples. Ever since the Arduino project took off, this number has exploded.
A nice solution that simplifies the problem and still leaves enough fun to be had is by using MicroPython. This is a python implementation that is specifically designed for devices limited in resources, such as microcontrollers. Also, since the python virtual machine is the firmware, it is the one thing the microcontroller will do, and all the python scripts it will run are simply data it processes.
This seemed like a good solution, so it was just a matter of finding the right microcontroller board that provides the following requirements:
At first I wanted to try to use the Sipeed Maix, which is an implementation of the new open source RISC V architecture running at 400MHz. I got a hold of one board, but no matter what I tried, I couldn't get a reliable SPI connection between it and the ESP32 board. How frustrating.
I decided that for compatibility purposes, I would use another ESP32 board as the main controller.