Harinezumi versions =================== 0.01 2012/09/29 First working version. Initial release. 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] 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. 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. 0.06 2012/10/16 It seems BootFX calls on an RPi are not a winning combination, so BootFX disabled until more info is available and testing can be done. 0.07 2017/07/10 Half a decade later. OMFG. Removed serious screw up in system detection where if the first module was NOT "UtilityModule" (thus can't be a known incarnation of RISC OS), it would drop out of the check by STACKING instead of UNstacking. It's nerdy and technical, so let me just say that a weird sort-of-but-not RISC OS would have likely frozen solid as soon as Harinezumi was started. I guess half a decade of ZERO reports is useful to show that it's just a bit of paranoia on my part instead of anything likely to be encountered. Fixed Harinezumi so it works once again on RISC OS 5. Somewhere along the way, the "Repeat BootLoad" and "Repeat BootRun" commands ended up having "Do" prefixed. Why? "Do" claims to pass its argument to the command interpreter, rather like just... not using "Do" at all. Is this like the "LET" keyword in BASIC? Pointless syntactic sugar? At any rate, it broke Harinezumi, so now it's fixed. FOR THE ABOVE REASON, YOU *MUST* UPDATE YOUR COPY OF HARINEZUMI! An interesting use case turned up recently on the ROOL forums. Harinezumi can help diagnose boot problems, but THIS machine was running headless (that means no monitor or the like, but we'll happily go with screaming chicken analogies if you prefer) which gets to the interesting problem that if a problem *was* uncovered by Harinezumi, rebooting with a monitor attached would lead to the *new* boot being logged, not the one that failed. Why is this important? Because it was the lack of a monitor that was triggering the problem. Ding! Interesting! So what Harinezumi does now is that if the boot should fail, then the boot log (either the default $.!Boot.BootLog or a custom filename) will be copied with the date and time suffixed, for instance BootLog -> BootLog_20170710-213017 [ yyyymmdd hhmmss ] In this way, you can always refer back to see what went wrong. No copying will be done if everything went okay, so if your !Boot folder is filling up with loads of log files, take it as a warning that something's not right. 0.08 2020/05/01 Rebuild with later library to not mess with bit 5 of the processor mode flags; ARv8 *really* doesn't like it. No functional change (other than to bump the version number, 'cos Harinezumi ain't AcornSSL!). 0.09 2020/05/03 Realised that Harinezumi was actually being built with ansilib instead of CLib Stubs due to not knowing if a 26/32 bit CLib is present on the system. However, since the OFFICIAL !Boot system checks for, and loads if necessary, a recent CLib before we are invoked, I have decided that it is probably acceptable to simply rely upon the presence of CLib. Those with wonky versions of Select, those with issues with the 32 bit world, and those who never got over the blight that is StubsG... you're on your own. Took the opportunity to update the URLs and email address to all point to heyrick.eu.