Rick's b.log - entry 2013/10/27

iMac (for a fiver!)

No.

What this does mean, mind you, is that the thing actually started. MacOS is... bizarre. The oddly round mouse only has one button, just like old style Macintoshes. It took a few moments before I realised that the persistent menu bar changed depending upon the currently active program.

The specs are:

So, if any of my readers are Mac people, I would appreciate some help...

• Is it possible to change Mac OS to English?
• Any chance of Mac OS X on this? I dimly recall an early one around the time of change to x86, but that might be a faulty memory.
• What can I do with this? Is there a software repository?

In technical terms... Do you remember the adverts when the iMac was introduced and this thing would come spinning across an otherwise white screen? Well let me tell you, it is unbelievably heavy. The keyboard is dinky, and the mouse...is round... perhaps taking "rounded corners" to a new extreme?

Inside, it is a fairly standard monitor. 1024×768. Looking at the connections, I'm guessing it is an analogue (VGA) style interface internally. Slung under the monitor, in a wire mesh cage, is the remarkably small system board.

The battery is dead. The machine reverts to thinking it is 1904. Also, the CD drive doesn't properly eject (which is why I had the thing open in the first place). I got the CD out, but it looks way too fiddly to think about fixing right now.

Of course, this is from the days when upgrading a Mac meant opening a nifty little hatch and inserting stuff. As opposed to modern Apple kit that looks like components held in place with great globs of glue and custom-designed screws.

A dabble in ARM assembly

So... Design, develop, test, and have a working system ready in a week around work hours? "No problem!", I said, somewhat unconvincingly.

I had known Chris wanted this for a while, but there were issues in the level of support within RISC OS for soft-off control. On some devices (Iyonix, Pandora) you can call the OS_Reset SWI with R0 set to &0FF to power down the device. However the RISC OS HAL is, in general, not sophisticated enough to permit the use of plug-ins to allow soft-off to be provided by a module loaded at boot time. Either it is present in the build, or it isn't.
Somebody else working on behalf of CJE modified the TaskManager module to support soft-off with the power control board, and while that is one way of approaching the problem, to my mind it suffers from two pitfalls:

• Firstly, do they have permission to distribute modified versions of RISC OS modules?
• And secondly, is it wise to modify a core RISC OS module when there is a way to hook into RISC OS to provide the same sort of functionality as an extension? Okay, TaskManager (aka Switcher) hasn't been updated in 11 months but that could just as easily change tomorrow, requiring the modified version to be recreated and then distributed to all users. Messy.

With the pressure of getting it ready by Friday night looming, I decided to say "sod it" to any hope of working with RISC OS's own ideas of soft-off. They work well for devices that have native power control, but the whole API/system is lacking when it comes to devices that don't have this as standard. So I decided to just ignore anything the HAL may or may not be capable off and ignore any new service calls/SWIs and just work with plain RISC OS. Therefore, this code should work on any version of RISC OS 5 for which the CJE power control board can be physically attached.

The first step that I tackled was to trap Ctrl-Break and Ctrl-Shift-F12. The first is unbelievable. If you are reading this on a Pi, save your files then press Ctrl-Break.
The result? Instant reboot. No prompt, no warning, no nothing. This BBC Micro anachronism has no place in 2013, a simple single keypress should not be capable of throwing away all your work to perform a reboot.
The second is the keypress for a Desktop shutdown. It, too, will not prompt for confirmation. Instead, other tasks will interrupt and warn you if there are unsaved files. I might make a few enemies by putting a prompt on the exit keypress, but I have more than once shut down the Wimp (Ctrl-Shift-F12) when I meant to open a TaskWindow (Ctrl-F12), so a prompt it is.
This prompt:

How this works is to continually record the state of the Ctrl and Shift keys, and then look for Break and F12 and test them against the correct combination of keys. If the combination matches, discard the keypress (stops anything further up the chain seeing it) and then tell RISC OS to jump back into your code the moment it is 'idle' (a "callback", because you are limited in what it is safe to do in the middle of low-level keyboard handling; and user dialogue boxes isn't one of the 'safe' things). It is further complicated by the requirement to use an interlock so your handler doesn't get called while you are in your handler (messy!) - for example, user presses Ctrl-Break and while your prompt is on-screen, user presses Ctrl-Break again.

The logic looked good, and the machine rebooted at the correct time and should have powered down, only I don't run my control board from a PSU so I couldn't test it actually worked. The problem, unfortunately, is that some Ctrl-Shift-F12 keypresses were getting through. Either there is a dark hole in my program that I cannot see, or in certain cases the Desktop/Switcher is testing these keys literally. I trap the two keypresses, and if my handler is already in use, I notice and discard the two keypresses. No Ctrl-Break makes it further into the system, so I don't understand why Ctrl-Shift-F12 is able to.

The next day, I had planned to write code to power down/reboot nicely, instead of the hacky version I put together one day one. But I was on a roll. I did that, no probs. Then I looked to detecting the state of the two buttons. For this, I need to poll the power control board. So as not to interfere with normal activity, I poll every half second. It is a two byte IIC transfer which works out to be about six bytes in total (one byte write, one byte read). Furthermore, the poll is not periodic, but rather the poll schedules itself again when it is done. In this way I only poll when necessary. If there is a dialogue on-screen, polling any more would be unnecessary.

So, if the Reset button is pressed, this will appear:

Likewise for pressing the Power button:

When a choice is made, my module remembers the choice and then kicks off the standard shutdown process. The Desktop is instructed to exit to the command line (less rubbish on-screen).

It is at this point, when the shutdown is nearing completion, that the TaskManager, as its dying act, broadcasts the DesktopShutdown service call. This is a notification through the system to say "it is done". At this point drives should be dismounted, and you would normally see the following on-screen:

It is at this point that my module wakes up again, clears the screen, and displays the following:

It is the same for reset, only there is an additional step in that a callback is set to call OS_Reset in one second, in case the power control board does not perform the hard reset (as in my case, since I have no PSU attached!). In any case, the machine will reset, it's just a matter of how severely (the power control board actually turns the power off and, after a short delay, back on again).

The three second timeout is, essentially, thumb twiddling. There is a very specific reason for this, however. The reason is that RISC OS does not appear to be able to properly shut down USB media (and likely the same for SD cards).
You see, if you "Safely remove USB Mass Storage Device - Drive(X:)" under Windows, if your USB flash memory has an LED you will notice the LED goes off. If it is a harddisc, it is quite likely the drive will park and spin down.
This does not happen under RISC OS.

The consequence is important. At the point of shutdown, the drives will have been dismounted from RISC OS, which may result in various filesystem writes. Writes which, in modern media, are likely not committed to the media itself due to write-behind caching, not to mention flash devices needing to erase entire chapters (in the order of 128Kb-2Mb) just to modify one byte in a 1024 byte sector. Oh, and add the potential for shuffling data around to cater for wear levelling. In short, if the system writes to media and then immediately powers down, you are asking for trouble. It is possible that this behaviour could account for the random unexplained SD card corruption issues? It isn't a bug in RISC OS, but rather RISC OS' inability to inform the card that power is going down (as in, flush everything to media NOW) coupled with the power going off rapidly following the last writes.
As far as I am aware there are no empirical methods of knowing how long a write-behind cache will wait before committing, so I am hoping that three seconds will be enough.

It turns out that I made an error in reading the spec for the control board so the power was not turning off. It was a simple fix.
At same time, I looked again at the problem of the spurious desktop shutdowns. I decided the simple fix was to set a flag to claim any shutdown service call within a second of the Cancel button being clicked. That did the trick.

Module ready, sent to Chris, demonstrated and worked exactly as intended on a RaspberryPi. It was less pleasing on the Panda because Chris used one with the modified TaskManager, so essentially two things were responding to the power control board - that's not going to work! However, for my part, it is done.

Oh, sure, I'll tweak the module and revisit the code at some stage, but not today. Today an Epic Storm is supposed to blow through. Given what happened just under two years ago, though thankfully it doesn't look as bad as back in February 2010.

Your comments:

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.

YogiCK, 27th October 2013, 23:59

About iMac:  1/ No, there's no way to change language of installed classic MacOS. You need to obtain an instalation disc of language version you need and reinstall it.  2/ Yes, it's possible to run OS X on first iMac. Latest version possible to install on your machine is 10.3.9 Panther, but generally you have not enough RAM to run any version of OSX flawless, recomended minimum is 256MB  3/ For example macintoshgarden.org & www.cornstalker.com/freeware/archive.php  4/ As a browser try Classilla or iCab

DavidS, 22nd December 2020, 18:16

On the Macintosh, I am actually familiar with the classic Mac OS, so I am happy to answer any questions. I actually would not mind getting something of that ventage for an Apple PowerPC computer.    Yes the menu bar changes. Also if you close all the windows in a program, and go to the finder, if you look in the application menu you may find that you left the program running. Kind of like the mistake Windows users make coming to RISC OS and not quiting at the IconBar Menu, just it is at the programs menu when there are no windows.    Any further questions, try to catch me on ChatCube. There are a lot of similarities in the Classic Macintosh User Interface and that of the Atari TOS/MaGIC/MiNT/etc if that helps.

Add a comment (v0.11) [help?] . . . try the comment feed!
		Your name
		Your email	(optional)
		Validation	Are you real? Please type 77758 backwards.
		Your comment