Thanks for your help and I’m happy to try to explain what I’m trying to do.
I grew up in the UK in the late 1970s and learned to program in assembler at school during “A” level computer science, and at home on my old ZX81 and Spectrum. My second job was spent writing real-time data capture software in 6502 on (of all things) a BBC B Micro. I thoroughly enjoyed programming in assembler, but times were changing quickly, PCs and Windows took over and I spent 20 increasingly miserable years in the computer industry. For the past five years, I’ve been making my living as a freelance technology writer (and writing books for macgicans - don’t ask).
Earlier this year I was putting together a feature about homebrew computer builders (guys who’ve literally designed their own CPUs from scratch, then sat down with the relevant 7400 series ICs and created something I personally find astonishingly cool.) I started wondering whether it’s possible to go a bit higher level than a bag of TTL chips. The logical choice was microcontrollers. I stumbled on the Orangutan, saw the facilities it offers, thought “Oh my God, it’s assembler time!”, and started wondering about building something “interesting” with it.
My first thought was to create a neural network and have two buttons - for praising and chastising the unit – and have it learn whether it’s doing the right thing to its outputs when it encounters certain patterns of values on its inputs. Then I thought about using data structures to hold abstract information about the machine’s state, rather than simple data. Instead of a neural network, code would deliberately change the “activation” levels of each of these structures depending on the current combination of inputs. It would then test for certain combinations of activation levels and decide what to do to the outputs.
Here’s a simple example: supposing one data structure determines how “bold” the machine is (how far it moves each time), it would normally hold a certain value as its activation. Now suppose that the code running the motor ports uses that activation value to time each burst of movement. Supposing the machine is programmed so that darkness makes it slowly decrement the structure’s activation value over a few seconds. The effect would be to to cause the robot to progressively grind to a halt. Conceptually, the machine could on some level be said to become “fearful” of moving the longer it spends in the dark as a defence mechanism. At a certain threshold of fear, it may also be programmed to turn on a high power LED headlamp. This would have the effect of increasing its boldness again by it detecting the presence of light and removing the inhibitory effect.
Now, supposing the device encounters the family cat, which decides to press robot’s front bumper repeatedly. If the unit is programmed to also become less bold when it’s bumper strikes something, it will gradually “play dead” due to the increasingly inhibitory effect repeated bumper pressing has on it. If the cat continues, the fear threshold triggers, the headlamp snaps on, the inhibitory effect is lifted, and the device rushes forward in a display of apparent aggression - different context, different meaning. If the cat is playing with the robot in a room sufficiently dimly lit for the unit to feel the inhibitory effect of the gloom, two inhibitory effects will be acting on its state, and it will stop faster.
By making inhibitory effects transitory, the robot would gradually move again of its own accord if the cat were to walk off and leave it motionless for long enough, and may overcome its fear of the dark in some gloomy places rather than stop, but it would still stop to turn on its headlight in complete darkness. Imagine what you could do with a few more of these structures coding information about other aspects of the robot’s state. How about some gradually increasing or increasing in value to indicate a state that changes over time - like loneliness or boredom.
It’s the possibilities for emergent behaviours like these and a minimalist approach to the hardware that interests me. I need to pack a lot into 16k, I’m completely comfortable with assembler, and having 20 MIPS all to myself sounds great! I’ve studied the instruction set and how the unit functions (both look very nice indeed), I have a data model worked out, the first cut of the main duty cycle code designed, and the Orangutan LV-186 looks exactly what I need to get started. I love the idea of EEPROM. It looks like backing store to me, for the robot to store a persistent “mental state” between runs. I’ve also have some weird ideas for passive sensors but they’re less well defined at the moment. So, I’m basically looking forward to “tapping on tin” again, and packing as much into 16k as I can, just like the good old days 
Does that make any sense?
