Harinezumi

Version 0.05 of Harinezumi is now available.

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

This is a more ‘cosmetic’ release. If you have “BootFX” present, it will call the SWI described above during boot-up. Untested; haven’t had time (sorry Steve! I’ll let you know soon if that version of BootFX you sent me works on the emulator).

However, what about for those who don’t have BootFX (those who are legion)? Well, for you Harinezumi will draw a slightly shaded red-with-green-bar slidey thing. For a few screenfuls of assembler code, it looks pretty good and doesn’t require any resources except RISC OS itself! ;-)

You’ll notice I’ve put effort in to making it work on a variety of different screen modes and colours. It will work in MODE 0 as MODE 12 as MODE 28; the only limitation is those inherent in the display (i.e. monochrome, etc).

I did this work while listening to this – http://www.youtube.com/watch?v=6OOl0yA2v2g … it is ~40 minutes of the same song in various different forms; I like “Dear You – Feel” (starts at +11:52) but I might say the orchastral version “Dear You – Hope” (starts at +25:32) is all kinds of awesome. It starts a little strangely and then lets rip. If you want to try something a little different, at least listen to the orchestral one – direct link
[it is based upon variations of a character song for “Higurashi no Naku Koro Ni” which is somewhat infamous for a whole different set of reasons (!)]

Anyway, here’s the official list of changes:

0.04  2012/10/08 [not released; waiting on v0.05 changes]

      No functional changes; just added a call to the
      BootFX module to (hopefully) modify the slidey-bar
      on the RaspberryPi.

      

0.05  2012/10/15

      And as a fallback, if BootFX does not exist, we
      will draw our own slidey-bar when running in Quiet
      mode. It isn't as sexy-looking as BootFX, but on
      the other hand it renders from code (not a massive
      resource file clogging up memory) and has been
      designed specifically to provide useful results in
      *any* screen mode (yes, even two-colour modes!).
      
      Slidey test notes:
        MODE 0   - Looks okay (as much as mono can!).
        MODE 1   - Looks okay.
        MODE 2/5 - Looks crap (text wider than screen!).
        MODE 3/4 - Not a graphics mode!
        MODE 6   - Slider is yellow, but looks good.
        MODE 7   - You're kidding, right?
        MODE 12  - Looks okay.
        MODE 15  - Looks okay.
        MODE 20  - Perfect.
        MODE 21  - Perfect.
        MODE 27  - Perfect.
        MODE 28  - Perfect.
        32K SVGA - Perfect.
        16M SVGA - Perfect.
      Yes, there is fudging in the code so it looks okay
      from MODE 0 upwards; even though chances are that
      few people will boot with something other than MODE
      27 or 28 these days; or even higher resolution if
      the hardware requires it; but for those with simpler
      or older setups, it is hoped that these will work
      just as well.
      
      Minor alteration to help to "Obey -c" the HariKick
      file due to weird behaviour in some people's boot
      sequences where RISC OS failed to '/' (Run) it.

Here’s a version of “Dear You – Hope” (the orchestral one) with lyrics (Rōmaji and English translation). Naff video quality, but you’ll get the gist of it. ☺ http://www.youtube.com/watch?v=t8XXpcxcJZk

Version 0.05 only works with me when I unplug BootFX. Last rom and disc image on a Pi.

Version 0.05 only works with me when I unplug BootFX.

Um… Steve?

Here’s the code I use, based upon the SWI you mentioned (earlier in the thread).

   ; we assume the module does its own sanity check,
   ; but be paranoid anyway
   CMP     R0, #0
   MOVLT   R0, #0
   CMP     R0, #100
   MOVGT   R0, #100
   SWI     &79140              ; XBootFX_BarUpdate
   MOVVS   R0, #255
   MOV     PC, R14

Does BootFX need to be configured to know where its resources are? [given that it holds its own resources internally, why doesn’t it default to using those?]

Wouter – what happens with BootFX loaded? Does Harinezumi crash or stall or…?

It looks like crash, no mousecursor, last text “Running HariKick…”, garbage in the BootLog file if you removed it before the reboot.

Happy to report it still works on RISC PC, ARM610 and 3.5
However! I had a similar result to Wouter on RPi.
Get the graphic boot screen and lower centre window, stalls with text"Running HariKick…"
I inserted line at begining of HariKick to unplug BootFX as Wouter refered to.
I need to check up on this, as I am not so sure now, but thought it started up with splash screen, lower centre window, lots of green text and good boot.
Tried a reboot to see if progress bar working and don’t get the splash screen, just fullscreen black background and hedgehog coloured text. (Sorry, I can spell hedgehog without having to look it up!)
If I unplug said module, is it possible to plug it back in again?
Reflashing distro again to make sure it’s nothing I’ve done!

Update. Re RPi. Using 22nd(24th) Distro. Nothing else, it seems to work.
Will now try to update everything and see what falls over.

Update. Only used latest ROM image. Stalls again with green “RISC OS – RaspberryPi” Splash screen and lower centre window

No keyboard present – autobooting
“Running HariKick…”

If I unplug said module, is it possible to plug it back in again?

*RMReInit <moduletitle>

*RMReInit

Thanks Chris, I’ll try that next time. I thought a reboot might bring it back, but had no success.

Update. Latest Firmware direct from GitHub, revert back to 24th ROM. Seems to run OK. Minor issue with progress bar, at minor delay while “contacting DHSS”, bar at 80%ish and green blob on bar at 40%ish.

Update. Latest ROM image,(15th Oct) Stalls again.

Version 0.06 of Harinezumi is now available. This is functionally identical except support for BootFX has been dropped¹ until such time as more extensive development/testing can be conducted.

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

¹ Which meant commenting out five lines of code and rebuilding. Whoo. ;-)

What advantages does Harinezumi have over Reporter?

What advantages does Harinezumi have over Reporter?

Reporter reports only.

Harinezumi takes each of the BootRun commands and runs it, with a graceful move to the next if a failure occurs so that the boot completes, and logs the progress.Without it a failure can halt the boot and leave a non-functional machine at the desktop or worse.
In some respects they complement each other.

Harinezumi is in essence a test of a more robust boot sequence. If it was in the ROM it could check ALL of the startup including the first attempts at disc access.

One question I have – what’s stopping this functionality from being added to the Repeat command in BootCommands? That way, the existing boot sequence would gain the functionality without change (or just a minor change, as per progress bar stuff).

what’s stopping this functionality from being added to the Repeat command in BootCommands?

That would work for Repeat. But anything altered/failing outside of scanning through the PreDesk for files/directories wouldn’t be “looked after”.

Is that adequate?

That would work for Repeat. But anything altered/failing outside of scanning through the PreDesk for files/directories wouldn’t be “looked after”.

Say again? Repeat is used for each stage of the boot, including Tasks.

Regardless of the admirable qualities of boot alternatives, I fully support adding a “keep going” (and/or log failures) flag to Repeat, and perhaps to Obey too.

Say again? Repeat is used for each stage of the boot, including Tasks.

Repeat is used here:

Repeat BootLoad <Boot$ToBeLoaded> -files
Repeat BootRun  <Boot$ToBeLoaded> -directories

It is not used here:

BootObey Choices:Boot.PreDesktop

or any other part of the before-Desktop-started part of the boot (ie “BootRun”). Therefore, making Repeat more resiliant will only affect faulty stuff put into the <Boot$ToBeLoaded>. While this is “most things”, it doesn’t offer any service if the fault lies elsewhere.

Now, you may have a point when it comes to making tweaks to Obey.

I wrote Harinezumi to address a certain specific point; so people can either carry on with it, or make similar modifications to RISC OS itself. Or, if people’s attentions are better served elsewhere (there’s a lot of more important stuff to do to RISC OS!), I have also stated that I’m happy for Harinezumi itself to become a part of RISC OS, if only a stop-gap measure until there is time to address the issue.