Ello Is A Tiny Computer With A C — Interpreter?

When we talk about a retrocomputer, it’s our normal practice to start with the hardware. But with [KnivD]’s ELLO 1A while the hardware is interesting enough it’s not the stand-out feature. We are all used to microcomputers with a BASIC interpreter, but how many have we seen with a C interpreter? The way C works simply doesn’t lend itself to anything but a compiler and linker, so even with a pared-down version of the language it still represents a significant feat to create a working interpreter.

The hardware centres around a PIC32MX, and has onboard SD card, VGA, sound, and a PS/2 keyboard port. The PCB is a clever design allowing construction with either through-hole or surface-mount components to allow maximum accessibility for less advanced solderers. Full information can be found on the project’s website, but sadly for those wanting an easy life only the PCB is as yet available for purchase.

We’re privileged to see a huge array of retrocomputing projects here at Hackaday, but while they’re all impressive pieces of work it’s rare for one to produce something truly unexpected. This C interpreter certainly isn’t something we’ve seen before, so we’re intrigued to see what projects develop around it.

Hackaday Links: January 24, 2021

Code can be beautiful, and good code can be a work of art. As it so happens, artful code can also result in art, if you know what you’re doing. That’s the idea behind Programming Posters, a project that Michael Fields undertook to meld computer graphics with the code behind the images. It starts with a simple C program to generate an image. The program needs to be short enough to fit legibly into the sidebar of an A2 sheet, and as if that weren’t enough of a challenge, Michael constrained himself to the standard C libraries to generate his graphics. A second program formats the code and the image together and prints out a copy suitable for display. We found the combination of code and art beautiful, and the challenge intriguing.

It always warms our hearts when we get positive feedback from the hacker community when something we’ve written has helped advance a project or inspire a build. It’s not often, however, that we learn that Hackaday is required reading. Educators at the Magellan International School in Austin, Texas, recently reached out to Managing Editor Elliot Williams to let him know that all their middle school students are required to read Hackaday as part of their STEM training. Looks like the kids are paying attention to what they read, too, judging by KittyWumpus, their ongoing mechatronics/coding project that’s unbearably adorable. We’re honored to be included in their education, and everyone in the Hackaday community should humbled to realize that we’ve got an amazing platform for inspiring the next generation of hardware hackers.

Hackers seem to fall into two broad categories: those who have built a CNC router, and those who want to build one. For those in the latter camp, the roadblock to starting a CNC build is often “analysis paralysis” — with so many choices to make, it’s hard to know where to start. To ease that pain and get you closer to starting your build, Matt Ferraro has penned a great guide to planning a CNC router build. The encyclopedic guide covers everything from frame material choice to spindle selection and software options. If Matt has a bias toward any particular options it’s hard to find; he lists the pros and cons of everything so you can make up your own mind. Read it at your own risk, though; while it lowers one hurdle to starting a CNC build, it does nothing to address the next one: financing.

Like pretty much every conference last year and probably every one this year, the Open Hardware Summit is going to be virtual. But they’re still looking for speakers for the April conference, and just issued a Call for Proposals. We love it when we see people from the Hackaday community pop up as speakers at conferences like these, so if you’ve got something to say to the open hardware world, get a talk together. Proposals are due by February 11, so get moving.

And finally, everyone will no doubt recall the Boston Dynamics robots that made a splash a few weeks back with their dance floor moves. We loved the video, mainly for the incredible display of robotic agility and control but also for the choice of music. We suppose it was inevitable, though, that someone would object to the Boomer music and replace it with something else, like in the video below, which seems to sum up the feelings of those who dread our future dancing overlords. We regret the need to proffer a Tumblr link, but the Internet is a dark and wild place sometimes, and only the brave survive.

https://commiemartyrshighschool.tumblr.com/post/640760882224414720/i-fixed-the-audio-for-that-boston-dynamics-video

C++ Compiler Targets The Web

It is a common problem these days. You have a piece of code in C or C++. Maybe it is older code. Or maybe you prefer prototyping your ideas using C. But, inevitably, someone now wants your code to run in a Web browser. The options for making this happen have expanded quite a bit lately and one possibility is Cheerp, an open-source compiler that handles up to C++ 17 and can output to WebAssembly, JavaScript, or asm.js.

The compiler is free to use for GPLv2 projects. If you aren’t open yourself, it looks like you have to cut a deal to use Cheerp with its maker, Learning Technologies.

Continue reading “C++ Compiler Targets The Web”

Micropython On Microcontrollers

There are plenty of small microcontrollers available for all kinds of tasks, each one with its unique set of features and capabilities. However, not all of us want to spend time mucking about in C or assembly to learn the intricacies of each different chip. If you prefer the higher planes of Python instead, it’s not impossible to import Python on even the smallest of microcontrollers thanks to MicroPython, which [Rob] shows us in this project based on the ESP32.

[Rob] has been working on a small robot called Marty which uses an ESP32 as its brain, so the small microcontroller is already tasked with WiFi/Bluetooth communications and driving the motors in the robot. Part of the problem of getting Python to run on a platform like this is that MicroPython is designed to be essentially the only thing running on the device at any one point, but since the ESP32 is more powerful than the minimum requirements for MicroPython he wanted to see if he could run more than just Python code. He eventually settled on a “bottum-up” approach to build a library for the platform, rather than implementing MicroPython directly as a firmware image for the ESP32.

The blog post is an interesting take on running Python code on a small platform, and goes into some details with the shortcomings of MicroPython itself which [Rob] ended up working around for this project. He’s also released the source code for his work on his GitHub page. Of course, for a different approach to running Python and C on the same small processor, there are some libraries that accomplish that as well.

Write In PipelineC For FPGAs

The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.

[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.

PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.

If you want to dive head-first into pipelining, give [Al Williams]’ two-part mini-series a look.

Pipeline graphic CC BY-SA 3.0 by CBurnett

Gaming In Different Languages

One of the perks of using older hardware is its comparative simplicity and extensive documentation. After years or decades of users programming on a platform, the amount of knowledge available for it can become extensive. This is certainly the case with the 6502 microprocessor, used in old Apple computers and some video game systems from the ’80s. The extensive amount of resources available make it a prime candidate in exploring various programming languages, and their advantages and disadvantage.

This project looks into those differences using a robot game, which has been programmed four different ways in three languages. [Joey] created the game in Python first and then began to port it to the 65C02, a CMOS variant of the 6502. The first iteration is its assembly language, and then a second iteration with optimized assembly code. From there, he ports it to C and then finally to Forth. Each version of the game is available to play in a browser using an emulator to run the 6502 hardware.

Since the games run in the browser, other tools are available to examine the way the game runs in each language. Registers can be viewed in real time, as well as the values stored in the memory. It’s an interesting look at an old piece of hardware and of its inner workings. For an even deeper dive into the 6502, it’s possible to build a working computer on breadboards using one.

The Seedy World Of Message Serialization

Look, I’ve been there too. First the project just prints debug information for a human in nice descriptive strings that are easy to understand. Then some tool needs to log a sensor value so the simple debug messages gain structure. Now your debug messages {{look like : this}}. This is great until a second sensor is added that uses floats instead of ints. Now there are sprinklings of even more magic characters between the curly braces. A couple days later and things are starting to look Turing complete. At some point you look up and realize, “I need a messaging serialization strategy”. Well you’ve come to the right place! Continue reading “The Seedy World Of Message Serialization”