mailto: blog -at- heyrick -dot- eu
Last week was a holiday. I had some time in hand, and for boring tax-year-end reasons, had to take this time by the end of March.
Well... didn't I luck in with the weather? We visited the Clisson area several times, and went to a very peculiar 'museum'. Photos and such to follow.
RISC OS coding
In the background, RISC OS split into two - the RISC OS Ltd (commercial) branch that makes RISC OS for older generation machines; and the Castle branch that updated RISC OS to be 32 bit safe for new hardware.
Castle's RISC OS appeared to cease when the Iyonix stopped being made (I understand the RoHS certification would have been too costly), but arrangements were made and today RISC OS is available as open source (if not entirely as "free" as Richard Stallman would like) which means RISC OS is available for the Beagleboard, and work is underway on a RaspberryPi build. Some other more obscure ports are apparently kicking around too.
- To briefly explain, the original ARM processor stuffed the processor flags (is result equal, negative, was this a carry, and so on) into the same register as the program counter. This worked because the original memory controller could only address 64MiB and physically cater for 4MiB at a time. Up to four such controllers could (precariously) be daisy-chained allowing a maximum memory of 16MiB (which, within the logical 64MiB block was sectioned off into "real memory", "mapped memory", "ROM", "i/o interfaces", etc). 64MiB can be represented with 26 bits. This left six bits for flags, and since ARMs are word aligned (thus meaning the low two bits were always going to be zero), the low two bits held the processor mode (user, service, interrupt...).
This mechanism was a marvel. It allowed you to exit a function, restore all of the saved registers and the flags and the processor mode... in one instruction.
If you think this is a silly limitation, Acorn were, at the time, selling BBC Masters with 128KiB on board, and the typical PC of the era maxed out at 640KiB. I'm sure gamers from back then will be well used to custom boot floppies optimised to load only as much as absolutely necessary to give over maximum amounts of memory to the game. And if you happened to have an expansion up to a megabyte, there were some god-awful kludges (XMS, EMS, etc) to get it to work, but you can rest assured that from plain DOS you could have all the memory in the world and the machine would tell you that you have a 'mere' 640KiB.
Fast forward to Present Day where 64MiB is comically restricted. The average smartphone has something like ten times that, and a generic feature phone that doesn't do a lot really will have similar amounts of memory. In order for the ARM to remain relevant (and, indeed, power these smartphones) it will need to ditch that combined program counter and flags stuff and go for a specific 32 bit (can address 4GiB RAM) program counter with flags in their own register. Not to mention with new requirements (Thumb, saturated maths, etc), more and more flags were required.
Back to RISC OS, discarding the 26 bit mode... pretty much broke everything. Much of RISC OS was okay, but programmers had to work through every line of code to change things that relied upon older behaviour. It was a job long overdue, but if you imagine RISC OS is largely written in assembler, you can perhaps start to understand why Acorn kept putting it off.
So getting back into the (ever smaller) scene, it was John Williams who asked about an easier way to enter foreign characters and symbols. RISC OS is pretty good on this front, however there is still a need to know ASCII codes for numerous things are not available using the shortcuts.
Now the thing with RISC OS is that it is heavily dependent upon the mouse. While Windows had to develop with whatever hardware the host computer offered, RISC OS ran on specific machines built by the same company that wrote the OS which meant they knew well that every machine would offer a mouse. This meant the Desktop could take full advantage of the mouse, but at the same time it meant that non-mouse operation is difficult. This means for tasks such as inserting custom characters, people are just accustomed to using the RISC OS version of Character Map:
While this is pretty easy, just move the mouse over a character and press Shift to insert it, it does mean leaving the keyboard to use the mouse. There must be a simpler and more logical way, surely?
It appears not.
Looking for how to approach this problem, and specific design criteria were that it must work as transparently and unobtrusively as possible and it must be capable of working entirely from the keyboard (with mouse control as well if desired).
I took inspiration from my Android phone. If you long-press on a key, a list of accented alternatives pops up:
And with that in mind, I created MoreKeys.
Acorn defined Ctrl-Alt-Fkey to control certain region-specific things, namely the configured country. I have expanded upon this so that Ctrl-Alt-letter will pop up a choice of available accents, as shown above. And, yes, under RISC OS 5 it will work with the extended range of UTF-8 characters.
Internally, the software works as two parts. The first part is a small module (akin to a DLL in Windows terms, or a .mo in Unixy terms). This sits in the background and keeps an eye on the keyboard. If the user presses a character key whilst Ctrl and Alt are both held down, the key is intercepted and discarded after being recorded. Essentially we suppress the key.
Control then passes to the front-end application. The module stuff is a bit low-level so there is a clear division between the two. One thing that bugs me with RISC OS is how easily user-land applications can fiddle around in system memory areas. This ought to be locked down, and hard. But I digress. Anyway, the front-end UI pops open a selection of keys. Left and right cursors to choose and Enter to insert the (accented?) character. Or Esc to cancel. Or, of course since this is RISC OS, do the pointy-clicky thing.
Having not cut code for RISC OS in ages, it was quite nice to get back into the swing of things. The cut'n'paste is childishly primitive compared to modern systems, but there is a sort of freedom inherent in RISC OS. I found I remembered a lot more than I expected, and away from the cookie-saccharine of VisualBasic, it was nice to do some real programming with the cupcake-sweetness of pure ARM code. You don't get closer to the processor than speaking it's own language, and you don't get a nicer processor than the ARM. That, coupled with RISC OS's to-the-point UI that isn't stuffed with fluff and "wizards", is a winning combination. I just hope many more people see it as such when the RaspberryPi (eventually) turns up.
Please note that while I check this page every so often, I am not able to control what users write; therefore I disclaim all liability for unpleasant and/or infringing and/or defamatory material. Undesired content will be removed as soon as it is noticed. By leaving a comment, you agree not to post material that is illegal or in bad taste, and you should be aware that the time and your IP address are both recorded, should it be necessary to find out who you are. Oh, and don't bother trying to inline HTML. I'm not that stupid! ☺ ADDING COMMENTS DOES NOT WORK IF READING TRANSLATED VERSIONS.
You can now follow comment additions with the comment RSS feed. This is distinct from the b.log RSS feed, so you can subscribe to one or both as you wish.
|Martin Bazley, 9th June 2012, 00:01|
"One thing that bugs me with RISC OS is how easily user-land applications can fiddle around in system memory areas. This ought to be locked down, and hard."
Meanwhile, over at <http://www.heyrick.co.uk/software/program.html>:
"The computer will do exactly what you tell it to do. Nothing more, nothing less. Though, admittedly, the operating system sometimes gets in the way with a "no, you didn't want to do that" sort of message - but that's why I like RISC OS, I don't want my OS telling me what it thinks I shouldn't be doing. Hell if I feel like poking the processor to NOT use the page tables, from a taskwindow, I'll bloody well do it! And I expect my OS to crash accordingly, not start an argument. I am the GOD of my machine, and I don't expect my foolish experiments to be responded to by Couples Therapy."
|Rick, 11th June 2012, 19:01|
Hahahahaha! Good call!
There is, however, twelve years between these articles. Perhaps twelve years to contemplate reality? ;-)
That said, there is a huge gulf (a gaping chasm) between a system allowing you to experiment and poke around, and a system that allows other processes and applications to stamp upon each other. For example, a user mode application should not have write access to the RMA (and I'm unsure if it should even have read access). Pollwords are handled by the WIMP, so the app doesn't need to read that address. There's a call to insert code into the RMA. Perhaps trickier is keeping data in the RMA, however some mechanism could be devised to work around this?
It is a fine balancing act.
List all b.log entries
Return to the site index
PS: Don't try to be clever.
It's a simple substring match.
Last read at 01:21 on 2020/09/21.
© 2012 Rick Murray
This web page is licenced for your personal, private, non-commercial use only. No automated processing by advertising systems is permitted.
RIPA notice: No consent is given for interception of page transmission.