When to update !Boot and other system files
Alan Robertson (52) 420 posts |
I really enjoy running the latest builds of RISC OS, and find them very stable, for my daily use. i.e. users current version & date > !Boot requires <no update||update>, ROM upgrade only |
David Pitt (102) 743 posts |
I simply use Fully understanding “recent changes in cvs” would take any guesswork out of the proceedings. However… |
George T. Greenfield (154) 716 posts |
I have a Pi2, and my OS version update procedure is to first make a discimage of the current SD card (I only use 4GB cards for this reason, and store working files on a memory stick in SCSI::0), save the discimage onto my PC over the network, to roll back to in case of problems, then copy the latest riscos/img file into !Boot.Loader, cross fingers and toes and reboot. To date this has worked fine (I’m currently running 5.23 [06-July-16]). I’ve not touched the !Boot directory at all – have I just been lucky? |
Jeffrey Lee (213) 6046 posts |
For both ROMs and the disc image we generally don’t advertise changes that we make, or when ROMs/disc image should be updated. So as David says, the best way of trying to work out what’s going on is to read through the recent CVS changes, or use something like DirSync to tell you which files have changed. That’s probably something we should look to improve at some point. It’s rare that we’ll make changes that require people to update their !Boot, so by not updating it’ll generally only be bug fixes and the occasional new feature that you’ll be missing out on. |
George T. Greenfield (154) 716 posts |
Thanks for clarifying, Jeffrey, and I’d like to add to the comments above regarding the stability and usability of recent builds, which is very good IME. Completely off-topic, I’ve noticed that !Thump’s slideshow consistently takes about 30% longer to cycle through a test directory of JPEGs when running under high-vector ROM versions, compared with a fairly recent low-vector ROM, using identical settings, and generally Thump seems to be less speedy rendering JPEGs. Is this something you’d expect to result from the zero-page changes? I’ve not noticed any other difference in responsiveness in general use, and ROmark and Firebench results are virtually identical (i.e. well within individual test variability). Otter on the other hand is /much/ more usable under a high-vector OS version, I find, as dynamic-area size largely ceases to be an issue. Keep up the good work! |
Jeffrey Lee (213) 6046 posts |
I have a feeling that the completion of the JPEG bounty has made rendering of JPEGs slower. This is just a gut feeling based on how long it takes my Pi 1 to render the splash screen. But if other people are noticing issues as well then it probably warrants some investigation. I’d be surprised if the performance impact was due to the zero page changes, but I guess that’s one of the things to look at in the investigation! The JPEG bounty page does list optimisations for ARMv7/NEON as being one of the goals, but unfortunately the page hasn’t been updated to show exactly what was agreed upon/implemented as part of the bounty. And of course the Pi 1 is ARMv6 so technically it isn’t covered by the optimisation goal. |
George T. Greenfield (154) 716 posts |
Just for clarity, I’m using a Pi 2. As to the specifics of the performance ‘hit’: 12 x c.5MB jpegs slideshowed in 26 secs under low-vector ROM, 34 secs under high-vector ditto, !Thump slideshow set to Render= Best dither, Image buffer from memory, scale= Fit screen, Step time= 0 secs, otherwise as defaults. |
Alan Robertson (52) 420 posts |
Thanks for all the replies and help on this matter. Sounds like !DirSync is an ideal solution to the problem. Think I’ll give that a go. Thanks again. |
David Pitt (102) 743 posts |
Today’s, 2016-07-10, beta builds do give an example of linked changes in both !Boot and the ROM. In this case it would make sense to upgrade both components to get the full benefit of the upgrade. There are three related commits in recent changes to cvs Update to Unicode 3.2.0 generates data for a new file, !Chars , in ROM, to be able to use this.
|
Rick Murray (539) 13400 posts |
Yay Chris! (^_^) |
Rick Murray (539) 13400 posts |
I’ve hacked mine, BTW. Simple – if holding Alt key while app starts, override and force UTF-8 support. Works with my modification to Ovation and hopefully anything else capable of supporting Unicode while the machine is still in Latin1 mode. |
Jeffrey Lee (213) 6046 posts |
Regarding JPEG performance, here are some timing results for rendering the Raspberry Pi splash screen via JPEG_PlotScaled:
So it looks like the new version of SpriteExtend is significantly slower, at least for that type of image. This was in a 16M colour mode (so no dithering) with no scaling (and for the superstitious, this was a high vectors build). The JPEG was rendered 5 times to take account of the fact that SpriteExtend does cache some values – so the first number is the time it took for the first render, the second is the average of the time it took for the others. |
Sprow (202) 1113 posts |
How does this variant compare under the same lab conditions? It’s the same image just resampled to the much more common 2×1 ratio. I also have various bits of profiling data I did last year somewhere for a load of specially brewed test images – drop me a line if you want me to remember which computer it’s saved on. |
Jeffrey Lee (213) 6046 posts |
It’s definitely a format that’s quicker to decode, but it’s done nothing to solve the large performance drop compared to old SpriteExtend.
And, since I’ve realised that the Pi build of SpriteExtend probably won’t be using any ARMv7 optimisations, here are some figures for a BB-xM:
|