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.
To quote the developer: “Trumpeting about great hardware and then leave the user banging his or her head in the wall, and having to search the Internet every time they need to write something, gives no pleasure to the user nor teaches them anything other than developing proficiency in using search engines. Hence, anything including the word “Linux” falls automatically into the “no-no” category of choices.”
I think that’s a bit over-the-top. Obviously there are so many ways you could spend your whole life learning with a Linux system.
It sounds like the operating system is deliberately an exercise for the user. Okay, but couldn’t I solder together an Arduino and code an OS for that?
But the compiler is not an exercise for the user. You’re supposed to interpret your OS.
The Interpreter and the hardware are really two separate projects. The developer should finish one before going farther on the other.
C Interpreter ++ Not giving attribution to hardware from Geoff Graham —
[https://geoffg.net/Maximite_Story.html ]
There’s absolutely nothing novel in the idea or in the implementation of the Maximite hardware, which has all been done in the past by others countless times. Add a bunch of peripherals to a microcontroller and you’re done.
Maximite’s value comes from it’s firmware and the community around it – unfortunately you get the occasional numpty who thinks it’s the holy oracle and demands obeisance from everyone else. Please stop.
I hope I’m not confusing this with another project. There is a very small TRS-80-model-100-like form factor computer called the Ello2M, also from KnivD, which is a PIC-based system built from a stack of PCBs that serve as the frame as well as the system board. This came with MMBasic, whose author (again, Geoff Graham) was clueless about open source software and insisted on having control over any use of his program.
The other side of THAT story is that while Graham’s complaint is that people just took his code, made slight variations on it, and called it their own, (which I think is an exaggeration – I don’t see anyone else claiming authorship without crediting Graham) others (don’t remember who, but I don’t think this was from KnivD) said that Graham would not allow changes that expanded the command set to support features of their particular hardware.
So I’m guessing that this C interpreter was KnivD’s way out of this nightmare. Maybe someone else here has further light to shed on this.
That’s quite an assertion to make with no evidence presented. Do you have anything to back that claim up, aside from them both being small form factor computers based on PIC microcontrollers and the fact that he’s aware of the Maximite’s existence (as he does credit Geoff and thanks him for the ASCII Video Terminal code that he based much of his I/O code on)?
This was supposed to be a reply to Paul’s claim above that the developer owes attribution to Geoff Graham for the hardware design, but I hit the wrong button.
Waiting for the
“Why C? Rust is better!” advocates to comment…
Who the heck told you that…C is easier to learn than freakin Rust , and Rust is not PL for Windows user at all.
I don’t think rust would fit.
I thought I recalled an article on a C interpreter in Dr Dobbs Journal back in the 80s, and indeed there was:
https://fdocuments.in/reader/full/build-your-own-c-interpreter
Also the Tiny-C Interpreter from Tiny-C Associates was available for $40 back int the late 70s early 80s IIRC.
These ran on far more challenged hardware than a modern PIC.
there was a c interpreter called Alice available back in the day. only ever saw it once, though.
Are you thinking of Looking Glass Software’s “Alice Pascal”, created by Brad Templeton? I ran that for a while on an Atari ST, the syntax-directed editor was really neat.
Sorry Jenny, there’s no fundamental reason why any language cannot be interpreted rather than compiled, its just moving the abstraction from assembly/machine code to a software based machine.
+1 for the Dr Dobbs article. I used that as a basis for a test script interpreter in ’89 when I worked for a telcoms company to generate test messages and verify the results. It grew into a fully fledged shell with graphics (SunOS).
Just as there’s no fundamental reason BASIC must be interpreted. My first experience with BASIC was Xerox’s Sigma 7 BASIC, which ws compiled. They hid this pretty well – it started out in edit mode, and of course you just typed “run” to start the program. The cool part was that if you interrupted the program, or the program executed a “stop”, it stayed in run mode and allowed you to execute commands at the prompt, so you could examine and change variables. You could even “run” an empty program, which allowed you to just execute commands directly at the prompt, similar to Python’s environment. You could stay in run mode as long as you wanted; it returned to edit mode when you typed a command with a line number.
And let’s not forget the Western Digital Pascal Microengine, a computer that executed UCSD Pascal p-code (Pascal pre-compiled bytecode) directly. So was the Pascal Microengine just a CPU optimized to interpret p-code, or was it a microcoded CPU whose native language WAS p-code? Very fuzzy.
I heard about Ch long time ago so googled it to leave a comment but it appears there really are a lot of C interpreters like PicoC, IGGC, Cinterp, CINT…
Kind of like a smaller version of the Handyboard (from MIT), with it’s Interactive-C.
Here’s a link to Interractive-C: https://www.cs.uml.edu/~fredm/handyboard.com/hb/index.html%3Fp=24.html
And here’s a link to the Handybaord:
https://www.cs.uml.edu/~fredm/handyboard.com/
And my own custom version I made so many years ago…. GadgetBoard: https://drive.google.com/file/d/1rPXMinG-dAxnQbv4N5DoRjNeTl0utv7G/view?usp=sharing
LILYGO have a nice ESP32 board, the TTGO VGA32 with VGA and PS/2 keyboard, etc. on the cheap. It should be able to run an interactive C variant like PicoC
“The way C works simply doesn’t lend itself to anything but a compiler and linker”
Ch: A C/C++ Interpreter for Script Computing
https://www.drdobbs.com/cpp/ch-a-cc-interpreter-for-script-computing/184402054
There are a lot of such tiles, but what matters to the end user is whether there is X program and whether it will run Y hours on a single charge.
So I propose to make a great remake of ello 2 with keyboard, panel and power supply. Package this marvel. Run old, proven CP/M or http://dmitry.gr/?r=05.Projects&proj=27.%20rePalm or Linux.
There’s already an Ello 2M, which is a self-framed stack of PCBs with keyboard, 7″ LCD, and flat LiPo battery. https://www.crowdsupply.com/yellow-beak-computer/ello-2m
The problem with trying to do CP/M on modern hardware is that CP/M is an 8080/8086/Z-80 OS, and isn’t going to run on any PIC. Nor should it – any OS that loads and runs programs (other than interpreted ones) is going to wear out the flash memory on any PIC or AVR based controller. Of course, an Ello 2Z could maybe be built that uses a Z-80 or CMOS HD64180, but that would be a whole other machine.
I’ve been playing around with doing a c interpreter on the esp32 pretty much since it came out – the trouble with most of the ones I’ve looked at is either the code is horrible to change/extend or they are to (relatively) big and complex (and not worth cutting down) ie PicoC. So I ended up doing my own which has never been finished. And Ch went commercial – https://www.softintegration.com/ – I haven’t found the original DrD code for it anywhere..
I’ll be interested to see what this project has been based on, but the source isn’t public yet.
Actually it is: https://github.com/knivd/C.impl
>The way C works simply doesn’t lend itself to anything but a compiler and linker
If you can parse and transform the C source code to assembly, then instead of spilling it out to a file, one can excute that. It is messy and sub-optimal, but is doable.
It is harder to compile an dynamic language that is intended for interpretor into a static form.
The line between interpreters and compilers can get fuzzy. One can argue that a language implementation that consists of an interpreter linked with the user’s source code into an executable program is a compiled language. Lua is kind of like this – it is meant to have its compiler rolled into C programs, in order to read and interpret configuration files. But without going to that extreme, there are also a number of languages that pre-compile into bytecode which is then “executed” (i.e., interpreted) at runtime. And let’s not talk about Java, which reaches the lower limits of performance by compiling at runtime, as I understand it.
Just the same, as I mentioned above, Xerox Data Systems came out with a BASIC compiler for their Sigma 5 and 7 computers, circa 1968. This was, as I understand it, a truly compiled language.
And then, look up Western Digital Pascal Microengine.
Ello? Is it C you’re looking for?
-apologies to Lionel Ritchie
Ho! Ho! Norton web security doesn’t like http://ello.cc web page.
It report:
This is a known dangerous web page. It is highly recommended that you do NOT visit this page.
Obviously Norton have not checked it yet. Their default strategy is to alert. I can confirm there is absolutely nothing wrong with the content on the website
The author states in his Hackaday.io project that he restricted his choice of microcontroller
and components to ones that could easily be assembled by an inexperienced constructor – i.e. no SMT.
This may have been a valid 10 years ago, when SMT assembly may have appeared to be a daunting challenge.
However, there is now no shortage of microcontrollers that are offered in a breadboard friendly, module format. This includes “Blue Pill”, Teensy, RPi Pico and many others.
It’s a shame that this project appears to be tainted by unacknowledged, done about a decade ago, by other parties. Had the author taken the Raspberry Pi Pico, and updated the C interpreter project to this platform, taking full advantage of the more advanced hardware resources, then I would have been very impressed.