After having some flakiness with the wifi interface in my Chumby, I finally got around to contacting customer support. After a short determination that it really was faulty, they cross-shipped me a replacement and I got it very quickly. Well, I would have, but UPS made a slight mess of things while I was out of the country, and I got it a couple days after I got back.
I haven’t had a lot of time to dig into the device, either as far as flash development, or repurposing it for other non-flash stuff (it is essentially open source, below the level of the flash player.) However, these are my two favorite “widgets” for it so far: Clockr and ChumbySpy.
I think the Chumby needs an implementation of WebCollage, but at the moment, I haven’t the time to do it. I’ve also considered making a reader for the entire English language Wikipedia, but that would require some other work, like an on-screen keyboard for entering search terms and article titles.
I’ve been having a pretty quiet weekend here. I’d run out of both entertainment and the desire to be entertained, having re-read The Star Fraction and watched another disc of Ghost in the Shell: Stand Alone Complex. I really like the former for its “What if capitalism is unstable and socialism is impossible?” premise. It’s a fun, action-filled tale.
I was thinking, there’s an interesting sort of game which I’ve never seen, which might be quite playable — a first-person shooter, where the enemies are all invisible, but with sufficiently good audio processing that with headphones or surround speakers, an average person can develop the ability to play it rather well, based on the sound of the enemy’s movement, etc.
And, it looks like someone did this, in a different fashion than I was thinking of. Demor takes that idea and makes it into an augmented reality game. Pretty cool, though I’d like to see this idea in a mainstream FPS somehow — like, certain levels you could only pass via auditory techniques?
I think I’m going to have more to say about HCI in the future. The matter of how people interact with computers seems really important to me. It’s hard to imagine not trying to improve it in some way. I feel that development of user interfaces has lagged behind the pace of development of computer hardware. Most of the time, we apply new hardware capability to ‘eye candy’ because it’s easier to do that than make definite innovation in usability, either incremental improvements in the tasks we already do, or larger attempts at completely different styles of human-computer interaction.
I finished reading Stack Computers. This class of processors is a bit different from the mainstream today — neither is it like the classic RISC load/store architectures (MIPS, SPARC, PPC, etc…), nor is it like the surviving (x86) or dead (VAX) CISC architectures. In a way, it’s slightly reminiscent of the high-level language architectures of the 1970s which never even saw commercial application. They were processors designed intended to implement much of the semantics of a high-level language in hardware — quite the opposite of the RISC approach. (The difference being that RISC architectures provide a simple, orthogonal set of operations and a large register file to make it possible for modern compilers to compile high level languages with high performance results, while these high-level language architectures aimed to make the task of compilation for a particular language trivial.)
The analogy here is that most Stack Computer architectures (at the very least) have a close match to the execution model of the Forth languages, and often have opcodes which directly correspond to some common Forth primitives. However, I think the reason stack architectures are not entirely without commercial success is that most of those forth primitives are very low-level operations — it doesn’t require a lot of silicon to implement one of these stack CPUs, and it can be a very reasonable choice for an embedded system.
One downside of some of these stack CPUs is that while they all provide at least two hardware stacks (data stack and return stack), some of them do not provide a high-performance means of loading and storing from a base-pointer-plus-offset, making them poor targets for the C language since it generally accesses function arguments and local variables that way. (A few do extend the processor with enough operations to make them a decent target for C and similar languages.)
Besides reading that, I’ve been slowly trying to beat Forth into my head — the basics are incredibly simple, but doing serious projects in it requires a change of perspective. It seems that there are a number of techniques people have developed to provide abstraction and work with particular problems using domain-specific “little languages”, but it still seems like one unavoidable part of Forth is that it’s essentially untyped.
I’m still aiming to develop a small computer in an FPGA with Forth as the OS and programming language. Not for practical reasons, exactly, but as a way to learn two fairly big things at once.