I can't help but feel that progress is slow on ELIUS, my from-the-ground-up programming language. This is a natural and expected side-effect of only being able to work on it in spare time during the evenings and weekends, but it is still frustrating.

Today I made some progress on adding the first set of "primitive" words to the language. My first target is to be able to create the minimum set of words needed to define new words. That means manipulating the in-memory data for the "dictionary" which holds the definitions, so the first few words are all about memory: B+ and W+ advance a memory address on the stack by one byte or one 32-bit "word". B@ and W@ read a byte and a word respectively from the memory address on the top of the stack. B! and W! store the value second on the stack to the location given on the top of the stack.

I'm a big fan of bats. I even went so far as to make a video at Natterer's Wood in Bury St Edmunds.

I have borrowed a "bat detector" (a device for listening to the ultrasonic noises made by bats as they fly and hunt) a few times, and it has always been very interesting, but I have never had one of my own. There are several types of bat detectors on the market, with wildly varying prices and capabilities. The lowest priced ones need to be tuned for specific frequencies of bat sounds, and don't offer any recording or analysis features - fun but pretty much toys. The fancier ones with these kinds of features can end up very expensive.

Following on from yesterday's post about developing code which uses the memory-mapped IO on the Raspberry Pi, but on a separate development system which does not have the same hardware, I began to think about the steps needed for testing such code.

The first stage is unit-level testing. As much of the code as possible should be tested independently of the hardware access. At this level a lot can be tested by just checking that the right primitives are called, but there comes a point where we need to check that the primitives are having the intended effects.

I'm trying to make a concerted push on a first working version of CORNELIUS at the moment, and it's throwing up all sorts of interesting aspects of software development.

For the first version I am building the minimum OS and language in C. However, I am trying very hard to minimise the amount of C code involved, so that (a) I can move some/all to assembler for maximum performance and minimum size and (b) so that I can get the maximum benefit and portability of building the great majority of the system in its own language.

When I set up this blog, I made a commitment to myself that it would not be just a "link blog" where I note down interesting pages, articles and sites I have found in my travels around the web. I have another blog which pretty much covers that function, even though I have been busier here of late.

However, today I really must post a link. Thanks to the comprehensive and precise steps posted by C Theroux I have finally got my tiny bluetooth keyboard working with my Raspberry Pi.

I mostly seem to post here when I am thinking about ideas which may have something to contribute to some project or other, but less often when I am just plodding along making progress. Today, though, I have spent my time actually working on the code for ELIUS and making some fairly significant internal changes.

When I first started to write it I was not sure how I was intending to lay-out the memory, so I created separate arrays for each of the major parts (dictionary, data and return stacks, string pool, input buffer and so on) Once the code for manipulating each bit individually seemed to be working, I then needed to combine them, so that (for example) dictionary entries could refer to strings in the pool. This was a bit tricky, because some of the arrays I had created were "word" (32 bit) sized, and other were "byte" (8 bit) sized. To combine them in a single byte-addressable memory area I had to make sure that all memory access went through functions (read and write byte, read and write word) which did the right things with the bytes in the array. I continued with this process of combining until I ended up with a single array of bytes (initially sized at a relatively conservative 64K). I had reached this point a few days ago.

A few years ago I did some work on a project which used RFID (Radio Frequency IDentification) to do all sorts of cool things. There were several problems with this, though. The first was that even high-quality UHF RFID readers and antennas would sometimes struggle to see and recognize the "tags" we had attached to various objects as we ran through doorways and the like. The second was the cost of getting involved. Readers and antennas cost hundreds or (more often) thousands of pounds, and despite having their own intelligence of sorts, these readers also required a "proper" computer to control them.

I feel as though I have been spending most of my CORNELIUS efforts on the ELIUS (language) part, and neglecting the CORN (operating system) part.

Recently, though, I have been thinking about the notion of a "hardware abstraction layer" (HAL). This is a common part of many systems, and serves to isolate the messy, hardware-specific details from the core functionality of the OS (memory management, process management, etc.) For most systems this is a good thing. If we had to build or download a whole new OS for every small hardware change nothing would ever get done. Typical PC boxes have a huge range of possible components, processors, storage, network and display cards, and so on. Even apparently simple things such as keyboards and mice come in a multitude of variants.

As I slowly build my bare-metal operating system and language for the Raspberry Pi, I like to keep looking around for more sources of inspiration. I found a list of stack-based languages somewhere which (among many others) pointed me at Raven, an interesting combination of FORTH, Python and perl. A bit more digging on the author's site also turned up three other FORTH-like stack-based languages. "enth" seems to be a fairly standard FORTH, "flux" is an interpretation of the ideas in Charles Moore's ColorFORTH, and "reforth" is an attempt to harmonise the best parts of the other three.

Following yesterday's bumpy start, I was determined to make some progress with Minecraft today. I had hunted round our storage and gathered the following:

1. A Dell Vostro 200 desktop with 1GB RAM which my wife used before she got her laptop. We stopped using this because its hard drive broke and it refused to boot from CD
2. A grubby but workable 1024x768 VGA monitor
3. A USB keyboard and mouse
4. A 1GB USB stick
5. A SATA disk drive which I had been using to store some old backups
6. various power and network cables etc.

The first step was to connect the keyboard and mouse to the Raspberry Pi. I'd not done this before so I was a bit wary about power consumption, given all the warnings about powered USB hubs, but there was no problem at all. I connected the Pi to my Mum's old HDMI TV, and started up Minecraft Pi Edition (mcpi). It didn't use all the screen, but I'm guessing it has a fixed size "baked in". It seemed to work as I clicked randomly with the mouse and spun round chopping and creating blocks.