Harinezumi

@Rick, think I’ve got it. Check your email shortly.

Hi,

Does anybody reading have the sources to ANSILib (if not built from parts of the SharedCLib code?).
Specifically, the function _kernel_swi() ?

If so – can you spot anything that would cause it to trip up on a NON-booted RISC OS 3.50 machine?

Here is a spool of the harinezumi start text, with debugging messages added, as it appears on RISC OS 3.50 if run directly as the machine starts.

*!Boot.Utils.start_msg
harinezumi v0.01*alpha* (2012/09/29) initialised
================================================
by Rick Murray, <heyrick1973 at- yahoo -dot- co -dot uk>.

DEBG: Reading time from OS (OS_Word 14)
DEBG: Regs: R0=34609952, R1=94032, R2=0, R3=0; slen=1
DEBG: Mem: 0, 0, 0, 0, 0
Boot started    : 
DEBG: Determining version of RISC OS; OS_Module 20,0,-1
DEBG: Regs: R0=34610208, R1=0, R2=-1, R3=0 (&00000000), R6=0 (&00000000)
DEBG: Characters at title address: 28, 243, 159, 229, 28
ERR!: Initial module is not "UtilityModule"? Custom build of RISC OS?
    : (detected OS version may be incorrect)
RISC OS version : 0.00
DEBG: Reading environment
DEBG: Env: R0=34610464, R1=0, R2=-1
Memory available: 0 bytes (0KiB)
ERR!: !! Available memory is less than 240K, this may not work correctly... !!

It is worth pointing out here that going into *BASIC and typing the commands directly give the expected results. Subsequently running the start_msg program…fails.

Here is a spool of the exact same program (same build, everything) when run after the boot sequence has done its thing (though in my case, none of the PreDesk apps were started as it is a 3.70 boot running under a 3.50 ROM and choking slightly… ;) ). At any case, the results are obvious:

*!Boot.Utils.start_msg
harinezumi v0.01*alpha* (2012/09/29) initialised
================================================
by Rick Murray, <heyrick1973 at- yahoo -dot- co -dot uk>.

DEBG: Reading time from OS (OS_Word 14)
DEBG: Regs: R0=14, R1=94032, R2=0, R3=0; slen=25
DEBG: Mem: 84, 117, 101, 44, 48
Boot started    : Tue,02 Oct 2012.21:31:34
DEBG: Determining version of RISC OS; OS_Module 20,0,-1
DEBG: Regs: R0=20, R1=1, R2=-1, R3=58771427 (&0380C7E3), R6=217088 (&00035000)
DEBG: Characters at title address: 85, 116, 105, 108, 105
RISC OS version : 3.50
DEBG: Reading environment
DEBG: Env: R0=2792, R1=17567744, R2=2780
Memory available: 17567744 bytes (17156KiB)

Something happens in the boot sequence to ‘fix’ this. If you Shift-boot directly to the Desktop and then try running start_msg, it will fail.

As a result of this, I would not advise using Harinezumi on RISC OS 3.50. We can see garbage is being returned in the registers; and I since I also use _kernel_swi() for the calls to OS_GBPB to scan for files... that it "appears to work" may be luck rather than design.

A work-around (for me) would be to use custom assembler code snippets instead of _kernel_swi(), which is something I want to do in the long run to make the code more efficient, but it’ll take a bit of jiggling of the code to implement and I don’t have time right now.

Update: Stepped through the BootRun file bit by bit.

The magic that makes it all suddenly work is when CallASWI is loaded.

And… the docs say:
Note that this SWI calling mechanism is almost certainly faster than any other alternative implementation, including the original _kernel_swi and swix code contained in older versions of the SharedCLibrary. The new SharedCLibrary now simply uses OSCallASWIR12 for _kernel_swi and _swix.
plus:
The CallASWI module provides this functionality for versions of RISC OS 3.70 or earlier.

I think the sanest solution would be to instruct the user to pre-load this module on older versions of RISC OS.

Stephen – if/when you are reading, before the line that calls Harinezumi; add:
RMEnsure CallASWI 0.00 RMLoad <Boot$Dir>.Utils.CallASWI

You should (fingers crossed!) find Harinezumi now works.

I suspect the problem you’re facing is that StrongARM compatible versions of the Shared C Library/ANSILib (they’re both built from the same sources, available here) are reliant on OS_CallASWIR12 for calling SWIs. For RISC OS 3.7+ this SWI is in ROM, but for earlier versions CallASWI is needed. The stubs code will RMEnsure CallASWI and cause the program to fail to start if it’s not present – except it looks like that code is disabled for ANSILib for some unknown reason. I’m a bit surprised that you aren’t getting a “SWI not known” error back from _kernel_swi() (you are being a good boy and checking for errors, aren’t you?)

As long as you stay away from any functions that take SWI numbers as parameters you should be able to implement your own code to RMEnsure the module. Or as you mention you could replace the _kernel_swi() calls with your own veneers for the SWIs.

Hi,

Sorry – being a not-so-good boy. It never in my wildest imagination occurred to me that OS_Word (etc) would fail. Of course, being me, I’d probably freak out and be like “WTF d’you mean OS_Module is SWI not known!!?!??!”.
Gee. You learn summat new every day. (^_^)

Still, I’ve suggested to Stephen (above) to manually load CallASWI, and it’ll be the impetous to get me to write some assembler. No, I don’t write code that takes SWI numbers as parameters (that’s getting a little too close to deep magic for my liking). I hope (!) to write sufficient code that I can look to replacing all of the kernel.h stuff. Being stuck with ANSILib means the program is larger than I’d have liked, so the ability to shed some things wouldn’t go amiss. It looks like the kernel part of ANSILib is ~15K, that’s a lot when you don’t need most of it!

Thanks for the quick reply.

Where might I find CallASWI ?

Ah… interesting… <scratches chin>

I looked in the kernel init code and I saw this:

|_kernel_entrypoint|
        LDR     v6, =|StaticData|
        SWI     GetEnv                  ; to decide heap limit
        MOV     r4, r1
        LDR     r1, =|Image$$RW$$Limit|
        LDR     r3, =|__root_stack_size|
        CMP     r3, #0
        LDRNE   r3, [r3]
        MOVEQ   r3, #RootStackSize
        ADD     r2, r3, r1
        STR     r3, [r1, #SC_size]

Harinezumi is stuck with ANSILib as it, on >RO3.6 & <RO5, alters the memory allocation in situ and writes the new value where OS_GetEnv will pick it up. This can mean reducing a 20Mb application workspace down to 256Kb.
Under ANSILib, subsequent calls to _kernel_system() work fine; however under SharedCLib the same thing causes the machine to lock up, obviously the copy-out-of-the-way is not picking up the correct location for the end of workspace and is either trashing something or is being trashed.
I’m wondering if there might be a clue in Image$$RW$$Limit ?

[just reading the _kernel_system() code. whoo-eee]

Where might I find CallASWI ?

RMEnsure CallASWI 0.00 RMLoad <Boot$Dir>.Utils.CallASWI

At least, that’s where it is on my setup. Take a look there, tell me if it’s the same for you. If not, I’ll get a copy over to you.

Googled it.
Found something on Ionyx.com.
Installed and seems to work at first glance.
Got time, OS version and colour!

The ROOL version of CallASWI (which is newer than the iyonix.com one) is available from this page in the “System resources” (aka PlingSystem) download.

Hi,

Version 0.02alpha of Harinezumi is now available.
Look down for version 0.03alpha!

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

The changes are:

0.02  2012/10/07

      Fixed failure to report UtilityModule / memory on
      some versions of RISC OS. This was due to the newer
      library wanting to bounce its SWI calls via the
      OS_CallASWI entry point, which... did not exist on
      older versions of RISC OS (there's a CallASWI module
      to fake it).
      However, this is now a moot point, because...
      
      Removed all dependencies on _kernel_swi(), so now
      Harinezumi will work on RISC OS 3.60 and lower.
      [not sure about 3.1x, any testers for this? anybody
       still use such old hardware? ;-) ]
       
      Suppressed "Okay:"/"Fail:" (etc) prefixes for the
      on-screen messages. That was only supposed to be
      visible in the log file, with colours performing
      the same function on the display.
      
      Now uses "Load" and "Run" instead of "BootLoad"
      and "BootRun". Those were just aliases that also
      printed status, but there's no need as Harinezumi
      does this anyway. [result: display is tidier]

Stephen – this one ought to work without the CallASWI module. ;-)

[not sure about 3.1x, any testers for this? anybody still use such old hardware? ;-) ]

Use? No. Have in the back recesses¹ of “my room”² Yes.

¹ The piling system is totally out of control and the project for the next few months involves much work.
Should I find the older kit I can give things a try. The test room does need setting up anyway.

² Reasonable size house, 3 managerial cats with just us two support staff, but I get to have a room which I only have to share with the managers and the wife doing e-mail.

Stephen – this one ought to work without the CallASWI module. ;-)

Yes that seems to work now. I’ve removed the CallASWI module to make sure.

Looking at the BootLog, the Boot started time is wrong, but that’s my fault, I’ve not used the thing for a while and the system clock is slightly slow! :( Corrected that now!

But, I also notice that the Memory available is being reported in BootLog as 29360128 bytes (28672KiB)
When I boot up, RISC OS reports 49MB, which is true as I have 32Mb + 16Mb +1Mb Vram fitted.
Is there a reason for this?

The ROOL version of CallASWI (which is newer than the iyonix.com one) is available from this page in the “System resources” (aka PlingSystem) download.

I tried this and the !SysMerge file makes reference to !System.310.Modules.310Support directory that does not exist in the archive.
It also makes reference to !System.310.Modules.ABCLib module that is not there either.

Yes that seems to work now. I’ve removed the CallASWI module to make sure.

Phew! ;-)

But, I also notice that the Memory available is being reported in BootLog as 29360128 bytes (28672KiB)
When I boot up, RISC OS reports 49MB, which is true as I have 32Mb + 16Mb +1Mb Vram fitted.
Is there a reason for this?

Explanation is complicated, but in a nutshell while your computer (running in a 26 bit configuration) can have up to 256MiB (or is it 512MiB), but any one application can only have up to 28MiB [this, for a throwaway comment, is related to why application slots are limited to 28MiB when running Aemulor].

You know, you kinda oughta get yourself a RISC OS 3.70 ROM set off eBay or the like. It’s a nicer version of RISC OS. ;-)

You know, you kinda oughta get yourself a RISC OS 3.70 ROM set off eBay or the like. It’s a nicer version of RISC OS. ;-)

I have a set of 3.70 ROMS and 4.02 ROMS I could put in, but this is my second RISC PC I use occasionally for games. Some of the older games became less compatible the more I upgraded so I try to keep this one simple.

Besides, how would you test for backwards compatability? :)

Hi,

Version 0.03alpha of Harinezumi is now available.

Yup, two releases in one day! This is more a cosmetic look’n’feel version. But look on the bright side, I’ve not broken it as much as Google broke their YouTube app… You might even like it, it’s nicer than the “we’re not Linux really!” behaviour.

Essentially, I have added twothree command line options:

• -q switches to Quiet Mode. In this mode, you will see a single line saying “RISC OS booting – xx%” (this is slightly messed up by the toolbox unplugger, but it’s better looking than pages of coloured stuff). Note that in quiet mode, you will be notified of program errors, but not boot errors. [the boot log looks as it always has]
• -l <logfile> permits you to supply your own filename/path for the logfile to override the default of $.!Boot.BootLog
• -v (or -h) will report program build information and some other stuff; and will then exit (so may be used on an already-booted system).
• All other command line options/data are ignored.

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

The changes are:

0.03  2012/10/07

      Added "-q" parameter for quiet boot; will count %ge
      of predesk boot completed; and warn if there are
      *program* errors. It will *not* warn of boot
      errors nor will it use colours.

      Added "-l" parameter to provide alternative location
      of boot log (default is $.!Boot.BootLog).

      [undocumented] "-v" and "-h" give help message and
      then exit.

How does Harinezumi compare to Reporter?
Pros & Cons?

Reporter reports on stuff. It can be used to diagnose a broken boot, certainly, but it does not influence how the system boots.
Pros: Boot process is logged.
Cons: Boot process is as it always was.

Harinezumi is not primarily intended to report. That is a useful side effect. Actually, what Harinezumi does is replace the default boot process so that it is managed entirely by Harinezumi.
What this means, in effect, is that your boot is no longer handled by the “BootRun” file and commands such as “Repeat BootLoad”, but rather by a program that executes all of the commands in turn. The benefit to you is that if a command should fail, the entire boot sequence won’t be abandoned at that point. Harinezumi will continue.
Pros: Boot sequence more resiliant to errors.
Pros: Boot sequence is logged.
Pros: Boot sequence read from BootRun and PreDesk, so may be user-modified.
Cons: Not original boot sequence so may introduce its own quirks. No biggies that I am aware of ¹, but that doesn’t mean there aren’t any.
Cons: Installation on RISC OS 5 is a little more problematic (need to point to an Obey file that does some stuff before kick-starting Harinezumi).
Cons: Doesn’t one of Select/Adjust offer user profiles? May screw up with that as I don’t have such a version to test on.

Potential pros (not yet implemented):
Remember MS-DOS’s F5 to step through Config.Sys / AutoExec.Bat? Well, it wouldn’t be hard to add prompting. Could even key-scan for F5 at init to invoke this mode. ;-)
Likewise, it shouldn’t be too hard (with or without OS dev assistance) to offer multiple boots, either for different users or for different situations. I would give an example like “Games” or “Dev”, but we’re a long way from the days when nasty games would *Unplug everything in sight and *RMKill everything else just to get enough free RAM to load up a mass of data tables and graphics. Really, on a machine like the Pi or Beagle with 256KiB/512KiB available, we won’t exactly be lacking in memory!

tl:dr version: Reporter only reports on what the boot is doing. Harinezumi actively replaces it. While both offer reporting facilities, they are in fact very different things for tackling very different problems. The reporting is a point of similarity, that’s all.

¹ One thing I know is that the FreePool emulation (we must do this by necessity as shelling out to CLI to do a FreePool would trash our program!) does not perform the final step of releasing the memory into the free pool because it fails with “cannot move memory, application in use” because RISC OS’s memory allocation is a little… simplistic. I’m going to poke around the kernel and see if it is feasible to replicate the OS_ChangeDynamicArea code, and if not I might look to using HariKick in all cases to set up the memory prior to running the program (as is the case under RISC OS 5). In testing, this didn’t seem to make a lot of difference until RISC OS 5. I guess RISC OS errs on the side of caution, so if you zone off 256KiB for yourself and tell the OS it can release the rest, it’ll say “uh-uh, can’t”. Well, either that or RISC OS is a stroppy teenager and “can’t” means “won’t”. (^_^)

ISTR there was a “multiple boot” program on my A4000, never tried it though. Unfortunately I currently don’t have access to a computer capable of runnnig RISC OS. Will give harinezumi a try asap!

Next question: How does this compare to ROOL’s own BootFX, recently added to the RPi distro? How much of each other’s functionality do they duplicate? Do they conflict?

How does this compare to ROOL’s own BootFX, recently added to the RPi distro? How much of each other’s functionality do they duplicate? Do they conflict?

BootFX provides splash screens and progress bars and stuff like that. The progress bar part is intended to be of general use, once booting is finished – but hasn’t had much polish beyond the requirements of the boot sequence. In order to provide the progress bar in pre-desktop booting, it does rely on the Repeat command using new parameters which in turn call BootFX SWIs to update the progress bar.

If harinezumi replaces the Repeat command, it should call the BootFX_BarUpdate SWI (the x-form so if BootFX is present, it can fail silently) to update the progress bar. I’ve not done a spec for BootFX yet, but the info required is:

  SWI BootFX_BarUpdate (0x59140)

  In...
    R0 - %age to position bar at
  Out...
    All preserved

harinezumi will need to figure out how many things need to be executed so that it knows what the correct %age update needs to be as it iterates over them.

Ultimately, if it works out to be a worthwhile feature, I’d be a lot happier seeing the harinezumi stuff either being integrated into the BootCommands module, or made standard in the boot sequence. Because messing about with the boot sequence is pretty fundamental so it’d be nice to have things that end up with wide-spread adoption being part of the core distribution.

[post deleted – why can’t I delete my own posts!]

The forum was having a hiccup, and everytime I switched my phone’s browser back from TheRegister, it looked like it submitted the same thing (over and over). I’m justr glad it was a forum post and not “I agree to buy a car”. ;-)

If harinezumi replaces the Repeat command, it should call the BootFX_BarUpdate SWI (the x-form so if BootFX is present, it can fail silently) to update the progress bar.

Doable. I calc %ge off the amount of BootRun executed in quiet mode, so I can have a version that uses BootFX in no time.

Can you mail me a copy of BootFX? I want to see how it looks/feels with the rubbish-on-screen mode.

Because messing about with the boot sequence is pretty fundamental so it’d be nice to have things that end up with wide-spread adoption being part of the core distribution.

That’s doable too. If there is a place on the ROOL repo, I’d be happy to gift the code to you (it is mostly written in C). My standard licence is the EUPL, but if it is less hassle / going to be part of the core system in time, I’m happy to let it assume the standard ROOL licence.

Then, y’all can giggle at my code. (^_^)

Ultimately, if it works out to be a worthwhile feature, I’d be a lot happier seeing the harinezumi stuff either being integrated into the BootCommands module, or made standard in the boot sequence.

Speaking as someone who asked for this type of feature I, for one, would be rather happy to see it bundled in as part of the boot.
Probably the most asked about aspect of RISC OS use is getting a machine back up and running after a disc change, CMOS config loss, or these days a simple “I have just started using RISC OS, why does it do this?”
Harinezumi is designed to make the boot complete enough to give a working desktop and hand you logs of what happened on the way.
To answer Chris E’s question – Report reports in more detail.

Again this is something that might well be usefully integrated if the logging is transparent to the user and logs are aged out after a specified period.

I play with IT kit most of my waking time but most other users don’t and the Boot is a bit opaque at the moment so fixing it is a bit of a challenge.

Can you mail me a copy of BootFX?

I could, but it wouldn’t be too useful because it is designed to do the splash screen stuff when it’s part of a ROM build. I suppose you could fake it up by loading it right at the beginning of the boot sequence and then doing a “MODE MODE” in BASIC to cause a mode change (and get the splash screen/progress bar plotted). It also only has resources for the Raspberry Pi and assumes a 1920×1080 screen mode, although it will work in other modes, the text window and progress bar will be in an odd place. In fact, the text window will probably be off-screen so won’t have the desired effect at all; you will still have pre-desktop text printed full screen.