I've been trying to make my latest attempt at writing a programming language (which I'm currently calling H2D2) as portable as possible. So I decided to try and recompile it for AVR microprocessors using WinAVR. It worked fine with just some very minor tweaks (and the odd bug fix). So here's a simple H2D2 program running on a (simulated) AVR microprocessor:
Specifically, it's a simulated ATmega128 running inside VMLAB. The program just writes out a series of ASCII characters in a loop, like this:
repeat (c=c+1 if c<91)
There have also been some more improvements to the syntax, where I'm continuing to draw on DALIS for inspiration. This time round I seem to be making more use of brackets. More things are coming out looking like C functions, which is why we have loop() and repeat(). I'll probably enforce brackets with if() as well I expect.
Currently, the microprocessor is parsing the source code, generating the syntax tree (i.e. compiling to H2D2 bytecode) and then running it in the H2D2 Virtual Machine. It might be better to just have the VM on a microprocessor and somehow get the bytecode onto the device pre-compiled.
But at least this microprocessor example demonstrates that my C code is reasonably portable, hopefully I can keep it like this. In reality running a Virtual Machine on top of a small microprocessor might not be very practical, but I'm just trying to make sure that my code can target other devices really...
I'm tempted to try running this code on my Fez Panda II by means of RLP, which should allow me to run H2D2 as native ARM code (being called from inside the .Net Micro Framework), that might have to be tried out.
On one of my web-wanderings I discovered a piece of software called VMLAB. It allows you to build a virtual prototype of a microprocessor circuit, without any actual hardware! Very cool. Even better - it's freeware. This had to be downloaded and tried out :-)
Since I have recently been messing about with HD44780 compatible LCD displays, I couldn't resist trying that. So here is an example I knocked up:
Not bad ... an ATmega168 driving an HD44780 compatible LCD all done virtually, without all that mucking about with actual hardware. I did try sending some user defined characters to the virtual LCD, but that didn't seem to work, maybe that was pushing it.