FOLLOW-UP THOUGHTS

Ok. I have been looking at writing OS independent I/O handling of my keyboard. Not the easiest thing in the world to start with and clearly I am at the deep end of the swimming pool. I have trawled documentation on my baby's hardware but this is complex stuff. G suggested I look at NetBSD to find out how I/O is implemented there, but, although more graspable, is still beyond mine at the moment. C suggested I revisit 'peek' and 'poke' in the C64, but that was a little unkind of him. (but only a little). Ok. Take a step back. Play with VM Forth. And find the simplest hardware there is on the market to experiment with. To be continued ...

FIRST QUESTIONS

I'm a father: it's an UltraSPARC 10. So, what do we need to know? How to load instructions into memory. How to execute these instructions once loaded. This needs careful consideration.

FIRST POST

OK, this is D-5. A colleague will sell me his UltraSPARC for £125 next Monday. The thought still makes me GIDDYISH. As a student SPARC workstations were my first encounter with real computers and their touch and feel are indelibly imprinted in my memory (along with endless nights doing not so student- or work-related things, but that is an entirely other matter). For that price I could resist my colleague's offer for only one day. After that I even raised the price with £25.

Meanwhile, and with no nostalgia factor to consider, I'll keep reading about this seemingly amazing language (/methodology) called FORTH. Its creator, Charles Moore, appears to be a truly original thinker in his field. Why am I interested in this? Well, my interest is easily excited by things hitherto unknown, to begin with. If you add to this that my one year's experience programming for a major company has been filled with more blank-face-stare-moments (by me) because of the mind-bending complexity and the myriad details you have to deal with, than in, say, the previous ten years, this only has served to further my interest and got me wondering. Wondering if the layers of software and abstractions that we wrap around the problems to solve them the easier and the quicker may in fact be counterproductive.

I guess that's what I want to find out: is there another way to do this than what is generally accepted as the best, the necessary way to develop software?

Links! Online book by Charles Moore; tutorial on a minimal FORTH running on Linux; article about implementing FORTH in a virtual machine.