Harinezumi

When my RISC OS boots up, I see this after the RISC OS startup text:

harinezumi v0.01*alpha* (2012/09/29) initialised
================================================

by Rick Murray, <heyrick1973 at- yahoo -dot- co -dot uk>.

Boot started    : Sat,29 Sep 2012.22:47:22
RISC OS version : 5.19
Memory available: 262144 bytes (256KiB)

Okay: FX 247 2_10101010
Okay: FX 229 1
Okay: If "<Run$Path>" = ",%." Then Set Run$Path <Boot$Dir>.Library.,<Boot$Dir>.Utils.,,%.
Okay: RMEnsure VProtect 4.00 RMLoad Boot:Utils.VProtect
Okay: If Boot$OSVersion <  350 Then RMEnsure CMOSUtils  0.00 RMLoad Boot:Utils.CMOSUtils
Okay: If Boot$OSVersion <  370 Then RMEnsure CallASWI   0.00 RMLoad Boot:Utils.CallASWI
Okay: If Boot$OSVersion >= 370 Then RMEnsure AppPatcher 0.00 X RMLoad Boot:Utils.PatchApp
Okay: IfThere <Boot$Dir>.^.!Territory Then /<Boot$Dir>.^.!Territory
Okay: If Boot$OSVersion >= 350 Then WimpSlot -next 256K
Okay: If Boot$OSVersion >= 350 Then FreePool
Okay: /<Boot$Dir>.Utils.SetChoices
Okay: Set Alias$BootLoad Echo %*0|mLoad %*0|mEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|m
Okay: Set Alias$BootRun  Echo %*0|mRun %*0|mEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|m
Okay: Set Alias$BootObey Obey -c %*0
Okay: Set Alias$@LoadType_FEB BootObey %*0
Okay: Set Alias$@LoadType_FF2 Error CMOS file found within !Boot (%0)
Okay: Set Alias$@LoadType_FF8 /%*0
Okay: Set Alias$@LoadType_FF9 IconSprites %*0
Okay: Set Alias$@LoadType_FFA RMLoad %*0
Okay: Set Alias$@LoadType_FFB BASIC -quit %*0
Okay: Set Alias$@LoadType_FFC /%*0
Okay: HOn
Okay: AddToRMA 768
Okay: If "<System$Path>" = ""   Then Error The !System directory has not been found
Okay: If "<Wimp$ScrapDir>" = "" Then IfThere <BootResources$Dir>.!Scrap  Then /<BootResources$Dir>.!Scrap
Okay: RMEnsure MimeMap 0.00 X RMLoad System:Modules.Network.MimeMap
Okay: IfThere <BootResources$Dir>.!Internet Then /<BootResources$Dir>.!Internet.!Boot
Okay: If ("<InetDBase$Path>" <> "") AND ("<Inet$MimeMappings>" = "") Then Set Inet$MimeMappings InetDBase:MimeMap
Okay: X ReadMimeMap
Okay: X BootLoad Boot:Utils.UnplugTbox
Note: Running PreDesk file...
Okay: BootObey Choices:Boot.PreDesktop
Note: Now handling BootLoad for "<Boot$ToBeLoaded>", scanning for files...
FAIL: BootLoad <Boot$ToBeLoaded>.!!DeepKeys
--->: [ Module 'DeepKeys' is not 32-bit compatible ]
Okay: BootLoad <Boot$ToBeLoaded>.!+Resource
Okay: BootLoad <Boot$ToBeLoaded>.!Country
Okay: BootLoad <Boot$ToBeLoaded>.ARPlayer
Okay: BootLoad <Boot$ToBeLoaded>.DALimit
Okay: BootLoad <Boot$ToBeLoaded>.NewLook
Okay: BootLoad <Boot$ToBeLoaded>.SetupNet
Okay: BootLoad <Boot$ToBeLoaded>.~SetupMimeMap
Note: Now handling BootRun for "<Boot$ToBeLoaded>", scanning for directories...
Okay: BootRun <Boot$ToBeLoaded>.Configure
Okay: BootRun <Boot$ToBeLoaded>.SoftSCSI
Okay: Unset Alias$@LoadType_FEB
Okay: Unset Alias$@LoadType_FF8
Okay: Set   Alias$@LoadType_FF9 SLoad %0
Okay: Set   Alias$@LoadType_FFA RMLoad %*0
Okay: Set   Alias$@LoadType_FFB Basic -load |"%0|" %*1
Okay: Unset Alias$@LoadType_FFC
Okay: Unset Alias$BootLoad
Okay: Unset Alias$BootRun
Okay: Unset Alias$BootObey
Okay: Unset Boot$Remote
Okay: AppSize 512000K
Okay: FX 247 1
Okay: FX 229 0

Now handing over to Desktop environment...

(hope that passes Textile’s horrible parser…!)

Better than that, it is colourised. Green = Good; Red/Magenta = OhCrap.

It has not been tested on actual hardware, only emulation; so as it is linked with ANSILib, I would be interested to know if it works on a Beagle/Pi at all.

Why ANSILib? Well, let’s just say a program starting as the first thing the OS runs that has to play with memory and cannot rely upon any of the Desktop environment… let’s just say I spent rather a long time banging my head off the wall at obscure quirks.
I’ll list a few.

• Why can’t you set how much memory a task has and pass the rest to be dispersed by the OS? You sort-of can under RO3.7, but this completely fails under 5.19, hence the slightly more complicated install sequence to prevent it failing with lots of RMA full / can’t fiddle memory (app in use) errors.
• Why am I using ANSILib? I change the program’s memory allocation within the program itself, and SetEnv the new amount. Later on I call _kernel_system in chained mode. In ANSILib it works, in SharedCLib it freezes the machine – is somebody making assumptions instead of GetENV’ing?
• Why does _kernel_system go horribly wrong when doing a *Set command? I had to specifically pull those out and throw them to _kernel_oscli – which works. WTF?
• Before anybody says use a library, etc, remember this is being run at boot to run !Boot, so there are a lot of assumptions we cannot make. To give an example, I convert to lowercase using the braindead or-with-32 method. I cannot use the nice Territory Manager lowercase table, as partway into the boot script we…look for and load (if present) a territory definition!

Anyway, if you fancy being a guinea pig and giving this a whirl, please feel free to try it and send me feedback.

http://www.heyrick.co.uk/software/harinezumi/

[ why “harinezumi”!? read the !Help file ;-) ]

Just tried it on RPi and no errors reported in the “bootlog”

On a RiscPC with RISCOS 4.02, StrongARM CPU and various other bits of hardware and software it seems fine too.

On an almost out of the box RiscPC 600, RISCOS 3.5 Arm 610 CPU, 32+16+1Mb memory. Only used for games that don’t work on the above.

I get :-

harinezumi v0.01*alpha* (2012/09/29) initialised
============

by Rick Murray, .

Boot started :
ERR!: Initial module is not “UtilityModule”? Custom build of RISC OS?
: (detected OS version may be incorrect)
RISC OS version : 0.00
Memory available: 0 bytes (0KiB)
ERR!: !! Available memory is less than 240K, this may not work correctly… !!

Okay: /Boot:Utils.HOn
Okay: Obey -c Choices:Boot.PreDesktop
Okay: Alias RML Echo %0|MRMLoad %0|MEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|M
Okay: Repeat RML <Boot$ToBeLoaded> -Type Module
Okay: UnAlias RML
Okay: Alias ICS echo %0|MIconSprites %0|MEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|M
Okay: Repeat ICS <Boot$ToBeLoaded> -Type Sprite
Okay: UnAlias ICS
Okay: Alias OBY echo %0|MObey -c %0|MEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|M
Okay: Repeat OBY <Boot$ToBeLoaded> -Type Obey
Okay: UnAlias OBY
Okay: Alias RD echo %0|MRun %0|MEcho |<11>|<23>|<8>|<5>|<6>|<0>|<0>|<0>|<0>|<0>|<0>|<11>|M
Okay: Repeat RD <Boot$ToBeLoaded> -Directories
Okay: UnAlias RD
Okay: AppSize 514000K

Now handing over to Desktop environment…

It starts up OK though. Hope this helps, or at least is a relief it works! :)

Anyway, if you fancy being a guinea pig and giving this a whirl, please feel free to try it and send me feedback.

Coo, a logging bootloader – I thought I was just mumbling to myself.

Anyway – works fine on RPCEmu install (latest ROM and HD4) here (what? on a real machine first?)
Testing on the beagle later.

Anyway – works fine on RPCEmu install (latest ROM and HD4) here (what? on a real machine first?)
Testing on the beagle later.

Hmmm, works on both beagle-xm and RPCEmu – BUT the RPCEmu install produces a file with type Data whereas the beagle produces a file typed text (I think that may be a default setting in the OMAP build)

“Anyway – works fine on RPCEmu install (latest ROM and HD4) here”
Sorry to go off-topic, but are you running 5.19 /and/ HD4 (HardDisc4) under RPCEmu? Does this mean the memory leak preventing use of HD4 hitherto has been fixed (or are you just taking a risk ;-) )?

Sorry to go off-topic, but are you running 5.19 /and/ HD4 (HardDisc4) under RPCEmu? Does this mean the memory leak preventing use of HD4 hitherto has been fixed (or are you just taking a risk ;-) )?

1. bq and a dot will give you shaded quotes

2. 5.19 september 26 september rom and HD4

3. Risk? It’s just an emulated machine for testing, sitting on work laptop. "Unsafe"Boot¹ is more likely to be a problem.

¹ My name for the encryption tat, designed to make your data inaccessible to an unauthorised person. In truth it does it to the genuine user more often.

Coo, a logging bootloader – I thought I was just mumbling to myself.

(^_^) Something RISC OS ought to be able to do for itself. But, hey, better twenty years late than never!

It starts up OK though.

How strange it doesn’t seem able to read the RISC OS version (it quiries module 0 in block -1, should always be UtilityModule; plus the OS_GetEnv for available memory also seems to fail…!? Thanks for the report.

Hmmm, works on both beagle-xm and RPCEmu – BUT the RPCEmu install produces a file with type Data whereas the beagle produces a file typed text (I think that may be a default setting in the OMAP build)

Great to hear it works on the Beagle. I was worried my older (Castle vintage) ANSILib might not have been entirely ARMv7 friendly.
No, I specifically set the filetype to text. It is the emulator that is incapable due to not being able to rename an open file, as discussed here:
https://riscosopen.org/forum/forums/10/topics/1316

Thank you all for testing this. Suggestions welcome…

No, I specifically set the filetype to text. It is the emulator that is incapable due to not being able to rename an open file, as discussed here: https://riscosopen.org/forum/forums/10/topics/1316

Create the empty file with the name you want and then send data into it?

It might be neater to create a Logs directory and put the output there rather than have the user have to dig into !Boot.
It might be nice to produce a switcher icon that records a bad boot (normal icon with a big red bar through it?) to point out to users something bad happened.

Doesn’t !Reporter offer the same functionality? Can’t read any of the help files on Android, sorry for the daft question!

Create the empty file with the name you want and then send data into it?

I think you misunderstand. Under the emulator, creating a new file would create a file initially typed as Data. So under the host operating system this would be “myfile,ffd”. When it comes to the SetType, it would become “myfile,fff” (or maybe .txt ?) but this fails because the emulator cannot rename an open file. It works perfectly fine under RISC OS on actual hardware; it’s an emulation issue.

It might be neater to create a Logs directory and put the output there rather than have the user have to dig into !Boot.

Makes sense. Where would you nominate – and should logs be dated and multiples (ie each boot makes a new log)? If so, what does garbage collection, or do we “do a Windows” and let the directory fill up with rubbish? ;-)

It might be nice to produce a switcher icon that records a bad boot (normal icon with a big red bar through it?) to point out to users something bad happened.

I could set a variable, like Boot$Failed for TaskManager to pick up on? The problem is, what constitutes a failure worth pointing out? You’ll notice the DeepKeys warning in mine. All of my installs of RO5 do that, it’s no big deal (really, that module shouldn’t be there, but…). The other problem is RO5 on RPCEmu and RO5 on the Beagle have different Switcher icons, as does RO3.7. I’m sure Select is different again. Better to let TaskManager deal with this, if the more experienced coders feel it is worth adding…

Doesn’t !Reporter offer the same functionality?

Reporter can log, AFAIK (don’t use it myself). The difference is that Harinezumi not only logs, but processes each part of the initial boot itself, and the carries on after a failure/error. Harinezumi was specifically designed to work around the “boot gives up when it goes tits up” problem; the logging is just an additional bonus feature.

I could set a variable, like Boot$Failed for TaskManager to pick up on?

But did it? PART of it failed but your utility is letting following items run so that user has a decent shot at a usable desktop.

The problem is, what constitutes a failure worth pointing out? You’ll notice the DeepKeys warning in mine. All of my installs of RO5 do that, it’s no big deal (really, that module shouldn’t be there, but…).

ALL failures are worth pointing out – take the example of the IconSprites bug which suppressed a real error. Now we know which software has the erroneous file entries and can clean up. How many other niggling items come from something like that?

The other problem is RO5 on RPCEmu and RO5 on the Beagle have different Switcher icons, as does RO3.7. I’m sure Select is different again. Better to let TaskManager deal with this, if the more experienced coders feel it is worth adding…

Examine the !Boot file of Utilities.!SparkFS and the content of the !SparkFS directory. It’s interesting looking at !SparkFS locally and remotely (via ShareFS) with different OS revisions on each end.

Or you could put a happy or sad hedgehog in a small window above the switcher. :)

Under the emulator, creating a new file would create a file initially typed as Data. So under the host operating system this would be “myfile,ffd”.

*help create
==> Help on keyword Create
*Create reserves space for the named file, optionally giving
it load and execution addresses. No data is transferred to
the file. Length and addresses are in hexadecimal.
Syntax: *Create <filename> [<length> [<exec addr> [<load addr>]]]

*create file 0 0 FFFFFF00 seems to work for me.

*create file 0 0 FFFFFF00 seems to work for me.

   lgf = fopen(LOGFILE, "wb");
   if (lgf != NULL)
   {
      sprintf(ln, "%%SetType %s &FFF", LOGFILE);
      _kernel_oscli(ln);
      return TRUE;
   }

I guess I could *Create and then fopen(), but it is working around a specific emulator bug/quirk, as an actual RISC OS machine does not exhibit this problem.

What does work, by the way, is to SetType the file manually. The new ones, when created, take on the existing filetype.

But did it? PART of it failed but your utility is letting following items run so that user has a decent shot at a usable desktop.

Hence we’re back to… what constitutes a failure ?

ALL failures are worth pointing out

I beg to differ. All failures are worth knowing if you are a programmer or somebody who can get changes made. For the end user… anything “minor” is usually worth ignoring. This is one of the reasons I specifically chose not to stop with a “Press Any Key” sort of prompt upon errors.
Back around ’95 I helped out at a place near Haselmere. It was an automatic stock system that talked to a cash register and a POS terminal. The thing is, they needed neither so neither was connected. When the stock system was rebooted, they had to click through half a dozen error messages for these non-connected things. For a while they also clicked through a message about “index integrity cannot be assured, please rebuild” (or some nonsense close to that). I got involved at the point where the database was so buggered up that half the stuff had ceased to exist and the remaining half was like scrambled egg. Had the minor warnings (for non-connected POS/till was an option) not appeared every boot, the person tasked with blindly OKing away the rubbish might have noticed the additional message and might have either looked in the manual or left a PostIt on the door of the Big Cheese.

So I believe that every problem needs to be recorded, but it’s only the Crowd Pleasers that ought to get the attention of Joe Average.

take the example of the IconSprites bug which suppressed a real error.

Alternatively, take the DeepKeys error. If this is/was a part of the standard !Boot for RISC OS 5, then every boot would be flagged sad-hedgehog. If later on something actually went wrong, user may well not notice as “well, it’s always a sad hedgehog, right?”.
This is simply a variation on the above story.

How many other niggling items come from something like that?

Just out of interest, what was the IconSprites bug? I have a vague recollection that the !Run tried to IconSprites !Sprites, and RISC OS would first look for a version with a suffix appropriate to the screen mode being used (!Sprites22 for instance). Was there a ‘side effect’ to this?

Examine the !Boot file of Utilities.!SparkFS and the content of the !SparkFS directory.

You mean this bit:

If "<Boot$OSVersion>" >= "500" Then IconSprites <Obey$Dir>.5Sprites Else If "<Boot$OSVersion>" >= "400" Then IconSprites <Obey$Dir>.4Sprites Else IconSprites <Obey$Dir>.!Sprites

I see !Sprites, !Sprites22, 4Sprites, 4Sprites22, 5Sprites, 5Sprites11, and 5Sprites22. Is something wrong with that?
[my RO5 under RPCEmu is older, !SparkFS is in $.ThirdParty]

Just out of interest, what was the IconSprites bug? I have a vague recollection that the !Run tried to IconSprites !Sprites, and RISC OS would first look for a version with a suffix appropriate to the screen mode being used (!Sprites22 for instance). Was there a ‘side effect’ to this?

The bug was a missing message to tell you that your Obey file was broken. The error was always there it’s just that no one got told and it didn’t (always) break things.

http://www.riscosopen.org/forum/forums/5/topics/1110

The point is that if you ignore the little errors then you need to start making value judgements about what constitutes little.

You mean this bit:

Yep – selecting different icon sets to match the OS version, which what I thought you said would be required…

FAIL: BootLoad <Boot$ToBeLoaded>.!!DeepKeys
—→: [ Module ‘DeepKeys’ is not 32-bit compatible ]

Which version of DeepKeys do you have? I thought it had been 32bit compatible for a very long time: http://twitpic.com/b03zja/full

Which version of DeepKeys do you have? I thought it had been 32bit compatible for a very long time: http://twitpic.com/b03zja/full

Interesting, considering this:
http://www.riscosopen.org/forum/forums/2/topics/49

Perhaps no one knew where to download a copy?

Perhaps no one knew where to download a copy?

After digging a little – the answer is http://zap.tartarus.org/downloads/ (any version 1.46-pre2 or later) tucked in the !Boot directory of the everything.zip

Which version of DeepKeys do you have? I thought it had been 32bit compatible for a very long time: http://twitpic.com/b03zja/full

DeepKeys, looking in the executable, is v2.02. I wonder if a failed (not fully 32bit) installation of Zap (before I found Tank’s version) put it in there?

Two questions for you: The module info thingy looks useful. What is it / where can I get a copy? And your backdrop – interesting. Looks (from the little that I can see) like a cross between Blade Runner and a Jean-Pierre Junet film.

Stephen:

Boot started :
ERR!: Initial module is not “UtilityModule”? Custom build of RISC OS?
: (detected OS version may be incorrect)
RISC OS version : 0.00
Memory available: 0 bytes (0KiB)
ERR!: !! Available memory is less than 240K, this may not work correctly… !!

Is this behaviour repeatable?

If so, something very strange is going on.

The Boot started line reads the OS time in string format (OS_Word, 14), like *Time.
The RISC OS version line examines the ROM for UtilityModule’s version. The proceeding statement is because it does a sanity check which is failing. See below.
Finally, the Memory available line simply reports R1 from OS_GetEnv. I don’t understand why this is coming back with zero.

Does anybody have a ROM image for RISC OS 3.5 that I can feed to RedSquirrel to see if I can replicate this? I do actually have a set of 3.50 ROMs around here (and 3.60; plus the 3.70 actually in my RPC), but taking that route would be an almighty pile of palaver (and thus, would never be done…).

Okay. The OS version check is to examine module zero of area -1 (first ROM). By rights, the first module in the chain should be UtilityModule (unless 3.50 is shonky and points to the hidden RISCOS module?!).

Can you try, from BASIC:

SYS "OS_Module", 20, 0, -1 TO ,,,r3,,,r6
PRINT ~r6
PRINT r3?0

The result of the first PRINT should be the version of RISC OS as a BCD value; so it’ll be something like 35000 (in hex).
The result of the second PRINT should be the character code for ‘U’, which should be 85.

If it is not, try:

PRINT ~r3
*Memory XXXXXXXX

(where the ‘XXXXXXXX’ is the address given by the PRINT ~r3 line)

You’ll see a load of junk, but it ought to begin with a string, and that string ought to read “UtilityModule”. (^_^)

Thanks.

Just tried the above and I get:-

*time
Tue,02 Oct 2012.14:27:11
*basic64
File ‘basic64’ not found
*system:modules.basic64
ARM BBC BASIC VI version 1.06 © Acorn 1989

Starting with 649468 bytes free

>SYS “OS_Module”,20,0,-1 TO ,,,r3,,,r6
>print ~r6

Mistake
>PRINT ~r6
35000
>PRINT r3?0
85
>

I might add, there is no pretty coloured text at boot up either. Just white on black as usual.

Two questions for you: The module info thingy looks useful. What is it / where can I get a copy?

I do find it useful, though I never released it. Follow me on Twitter and DM me an email address. http://twitter.com/nemo20000

And your backdrop – interesting. Looks (from the little that I can see) like a cross between Blade Runner and a Jean-Pierre Jeunet film.

Good guess. Got it from here: http://www.incrysis.com/index.php?option=com_content&task=view&id=793

Follow me on Twitter and DM me an email address.

Sorry, don’t have Twitter, never tweeted, only read a tweet once when another link took me there…
I am heyrick followed by 1973 at the domain yahoo at the co.uk tld.

Hoping to hear from you. (^_^)

I might add, there is no pretty coloured text at boot up either. Just white on black as usual.

How very bizarre. And 85 is U, from UtilityModule, with the 3.50 version number (in wonky BCD).

I’ll restate my request for a 3.5 ROM image to try on RedSquirrel; until then, I can only shrug…

I’ll restate my request for a 3.5 ROM image to try on RedSquirrel; until then, I can only shrug…

How might one go about acquiring one one of those if they had suitable hardware to hand? Maybe an old RISC PC for example!