Analysis of VIDCBandwidthLimit

As part of scraping the limpets off the bottom of the boot sequence I figure it’s probably worth doing something about VIDCBandwidthLimit, so here’s what I know

• It’s an internal command for system use (PRM 5a-143) so we’re free to do pretty much anything to it without fear of breaking application code
• It was originally added (from the comments in the ScreenModes module) because the initial VIDC20 performance was variable enough that a hardwired value couldn’t be used by the time the mask ROMs went to production
• It got extended with a 4th parameter to account for the A7000+ with its 2x faster memory bus, the first 3 parameters are for no VRAM, 1MB VRAM, 2MB VRAM respectively. The units also changed from bytes to 1000’s bytes
• The respective RO350Hook/360Hook/370Hook in the boot sequence do slightly different things to account for the above 4th parameter being there or not
• If no limit is set, the ScreenModes module stores 0, which it uses internally to mean “unset” and when a Service_ModeTranslation is passed round the (HAL) kernel suggests 100MB/s as a default. When unset the kernel’s suggestion is used; when set the kernel’s suggestion is ignored
• There’s a warning in the kernel to “Sort out GetBandwidthAndSize” so the 100MB/s looks like a dice roll
• The Iyonix boot sequence changed the limit to be 2000MB/s presumably to just make it big enough to not matter while not spilling into a top bit set number – so it’s essentially limitless, even if the hardware has no chance of supporting it

I can’t quite decide what to do, so here are some options

• Change the kernel to pick a much more conservative value such that its default mode of something like 800×600 8bpp 60Hz can be supported and thus becomes the failback value
• Remove VIDCBandwidthLimit completely and let GraphicsV_VetMode do any vetting of data rate, the boot hooks for pre HAL would still issue it as they do today
• Move VIDCBandwidthLimit out of ScreenModes into VIDC20Video module, so you can still set it on IOMD, but everything else uses the GraphicsV_VetMode scheme. Not sure this makes much sense since all the VIDC20s that were ever going to be made have been made now so their limits are well known
• Adapt VIDCBandwidthLimit to check for a GraphicsV implementation, and use that flag to remember that any clamp applied is outside its remit. Thus the ScreenModes module could still be softloaded on pre-HAL versions of RISC OS, tenuous if that’s useful
• Add a new kernel to HAL call to set the limit, then have the kernel send round the correct value instead of its 100MB/s guess. Not sure how this fits with unpluggable graphics cards, where the RAM bandwidth is not directly in the HAL’s sight
• Add a new GraphicsV subreason, have the kernel call it, then issue Service_ModeTranslation

Or something else?

I’d vote for removing it altogether, and letting GraphicsV_VetMode deal with any limits. I’d also vote for removing the vidc_type variable from ScreenModes and making the module assume/require GraphicsV to be in use.

I can’t think of any compelling reason for someone to want to softload our version of ScreenModes on a non-GraphicsV OS, and having pre-GraphicsV logic knocking around when I/we come to update the module to deal with multiple displays/drivers is only going to result in more headaches.

I concur. In the future we will want to teach RISC OS about different pixel formats (RGB vs BGR etc), I feel this would be more complicated than it should be if we have a lot of legacy code kicking around.
Therefore, it would be right to require GraphicsV now.

What’s the impact currently if VIDCBandwidthLimit is set “too high” for the machine? Video doesn’t display? Modes which can’t be displayed can be selected? Machine damage? Monitor damage? …?

Following on from Jeffrey’s point – is the revamped, tidied, sanitised !Boot going to be a replacement for the universal Boot; or the perfectly designed and optimised for RISC OS 5 boot sequence? If the former, the assumption about GraphicsV may be incorrect, although it has attractions for dual booting systems. The latter appeals from an architectural PoV, though (and comprehension of what exactly it’s trying to do).

What’s the impact currently if VIDCBandwidthLimit is set “too high” for the machine?

Too low, and there will be modes that can be displayed but are rejected.
Too high, and you quite easily end up with a garbled display (happens most reboots when testing on a Risc PC because 2000MB/s is used and with only 1MB of VRAM the default mode selected is outside VIDC’s range). It could well damage a CRT monitor (the line rate indirectly governs the drive to the line output transformer) but most sensible/recent monitors will blank when a duff line rate is given.

is the revamped, tidied, sanitised !Boot going to be a replacement for the universal Boot […] the assumption about GraphicsV may be incorrect

That’s the idea. However, the bandwidth limit is set inside ‘Choices:Boot’ which is copied from the respective hook directory, so lower numbered hook directories can still use the command but share the rest of the boot sequence. Likewise

X VIDCBandWidthLimit 1 2 3 4

At present, it should be universal for 3.50/3.60/3.71/4.01/4.02/4.04. You need to copy in the !System from the downloads page, and if using 4.xx you’ll need to copy the configure plugins into ‘RO400Hook.Res’ from the RO4 CD-ROM. The icons are probably a bit confused at present too.

Support for 3.10 is currently lacking, some of the central assembler macros output unconditional MSR/MRS sequences which wouldn’t work on crusty ARMs. Depending on mood I might stretch to 4.39 at some point too so at least all the ROM chip versions are covered, though 4.39 might have diverged too much to be worth the bother.

Too low, and there will be modes that can be displayed but are rejected.
Too high, and you quite easily end up with a garbled display (happens most reboots when testing on a Risc PC because 2000MB/s is used and with only 1MB of VRAM the default mode selected is outside VIDC’s range). It could well damage a CRT monitor (the line rate indirectly governs the drive to the line output transformer) but most sensible/recent monitors will blank when a duff line rate is given.

The reason I ask is cos it overlaps with the purposes of MDFs on RISC OS 3.7 and above. What that means in terms of sensible architecture, I’m not sure ;-)

probably worth doing something about VIDCBandwidthLimit

The command is now gone.

For reference, there is a faint echo of it in the boot sequence still. Basically, for RO350/360/370/400Hook it is left in place untouched, and for RO500/510Hook I’ve just prefixed it with an ‘X’ so it doesn’t halt the boot sequence where it is no longer available.

The reason it was ever needed in RISC OS 5 was because if unset the ScreenModes module uses the OS value, and the HAL based kernel sets an arbitrary value of 100MB/s.

It’s also worth noting that both !Configure (pre RISC OS 3.80) and the !ScrnSetup plugin will attempt to issue ‘VIDCBandLimit’ (note – this is an alias set in PreDesk) when a new instantiation of the ScreenModes module is made to temporarily test out the selected monitor. Since both check for the alias being set before issuing this can safely be left in Configure/ScrnSetup when RO520Hook is needed – so that they continue to run on previous OS’.

Just had a report from a user who was trying out a new ROM, and ran into some fairly major problems because this command caused an error, and stopped any more of Predesk executing.

I really think that for compatibility reasons, any removal of commands which might have previously been executed during boot (especially during predesk) should have dummy placeholders to prevent errors.

As it stands, if I issue a new ROM to our users without them having first modified their !Boot, they will get errors/crashes at Boot. In the case I saw, it resulted in Fat32FS not softloading, so subsequent references to the secondary drive failed resulting in more problems.

Basically, this problem is exasperated by the way errors early in PreDesk result in skipping execution of any remaining (alphabetically) entries in PreDesk.

exasperated

…Exacerbated?

I see where you’re coming from, but if this approach is taken too far, it can lead to things like the WindowUtils ROM module, which hasn’t contained any code since RISC OS 2 (it’s literally just a blanked-out header), but remains in place just in case anybody should ever want to RMEnsure it.

I agree with Andrew, removing it will be nightmare. Can we please have a dummy placeholder?

Basically, this problem is exasperated by the way errors early in PreDesk result in skipping execution of any remaining (alphabetically) entries in PreDesk.

I would be inclined to say that the part I have highlighted is the part that needs to be fixed. I think we’d need a shell command interpreter that can run through the stuff in PreDesk (etc) and log its status to a file. Nothing too complex, could just be a BASIC proggy to read the files and XOS_CLI the stuff.
By this method, failed stuff will be known to have failed ($.!Boot:BootLog) and the boot will hopefully complete upon fail rather than aborting in seemingly random places.

I really think that for compatibility reasons, any removal of commands which might have previously been executed during boot (especially during predesk) should have dummy placeholders to prevent errors.

In this instance the error is that the person in question has upgraded their ROM but failed to make the corresponding change to the boot sequence, the boot sequence is fully backwards compatible (tested back to RISC OS 3.50 currently). Remember, RISC OS is not just a ROM (that accounts for only 1/7 of the total bytes).

Basically, this problem is exasperated by the way errors early in PreDesk result in skipping execution of any remaining (alphabetically) entries in PreDesk.

Though not currently made use of, you can add a ‘-continue’ switch to the repeat command (as of boot commands 1.44) which will do as you suggest. It too carries risk, for example if a later part of the boot sequence relies on an earlier part having completed without error!

Although it’s a nuisance for people to have to update their boot sequences, I think I’m with Sprow & Martin when it comes to removing obsolete stuff from the ROM. If it was something which third party apps relied upon (like WindowUtils) then I could see the point of keeping it around. But VIDCBandwidthLimit is something that should only be used by the boot sequence. We control the boot sequence (or at least strongly suggest what users should use as their boot sequence), so there’s no reason why we can’t make ROM changes which require the user to update their boot as well, especially if the updated boot remains backwards-compatible with old ROMs.

I think part of the problem we’re facing is that there aren’t really any release notes supplied with the ROM images/disc build, so unless people constantly watch the forums or CVS they won’t know if there are any dependencies between the ROM & disc or if any special steps need taking when upgrading. This is a problem that affects anyone working with development images – regular users, budding alpha/beta testers, OS developers, etc. Likewise, there’s nowhere describing which new features are supported in a port, or which new/improved APIs have been added, etc. I’m tempted to say that the ROOL diary could fill this role, although it would also be nice to have an offline copy of the release notes within the ROM download archives (I guess the build script could just do a wget of the latest diary page?)

I don’t think it is particularly onerous to keep it as a NOP. We’re not quite that short of bytes, surely.

In an ideal world you are correct Sprow & Jeffrey. Andrew and I though, have to live with the unideal day to day!
Example: I’ve seen in the last couple of months a number of people admit in newsgroups or forums that they are using Iyonix PCs with pre 5.16 RISC OS. I expect that for everyone who has admitted it publicly there are 20-100 people out there…

I’d normally agree with what Jeffrey and Sprow say, and their point is extremely reasonable (I have no problem rolling updated !Boot sequences out to support new OS builds), but users don’t always follow our advice, or indeed logic at all. Recently I had people installing year-old versions on new machines, because they thought they had to install every update or none-at-all! Clearly you can’t legislate for such things, but this is an instance very similar to WindowUtils in that it directly affects something very critical (and to users, very scary) – the boot sequence, which has a fundamental knock-on effect to anything after it (ie. everything). If, for example, this problem just stopped an individal app from functioning until updated, I wouldn’t bat an eyelid. But in this case, it could royally mess up users, rendering them with an almost unusable machine.

There’s another scenario which may not be immediately obvious. Many users keep a “shipping backup” or “monthly backup” of !Boot in case it gets messed up, due to the importance of !Boot. Indeed, on dual-drive systems I routinely back up the whole system, just in case.

If a user messes up, and then rolls back, they’re left with an unbootable system, probably without internet access (I doubt !Internet would have been run) and hence without recourse for a fix, short of me supplying a new copy through the post. Granted, some phonecall tech-support should sort them in this instance, but nevertheless, I suspect you see the point!

(Tongue firmly in cheek) One wonders if the dreaded WindowUtils module could become a dummy store for such legacy commands! At least it’d then have a purpose!

But in this case, it could royally mess up users, rendering them with an almost unusable machine.

Hang on, are you talking about users who’ve installed (parts of) an odd-numbered ROM or the work-in-progress HardDisc4 image? Maybe we need to emphasise this more on our site but you get what you’re given if you use those things. You’re expected to know what you’re doing. If you don’t, you wait for an official software release from Castle, RComp, etc. I’m afraid I don’t have an enormous amount of sympathy for users who get themselves in a pickle by using beta-quality code. These are development releases for a very good reason; so the developers have access to the nightly builds.

There’s another scenario which may not be immediately obvious. Many users keep a “shipping backup” or “monthly backup” of !Boot in case it gets messed up, due to the importance of !Boot. Indeed, on dual-drive systems I routinely back up the whole system, just in case. If a user messes up, and then rolls back, they’re left with an unbootable system.

I always assumed it’s part of the job of the people building the commercial products who ‘ratify’ the even-numbered releases to think around the issues of user upgrades and reverting. As you quite rightly say, you can’t legislate for users getting themselves in a mess by installing stuff from the beta releases on the ROOL site. To that end, I’ve updated the downloads page to make it clear that the HardDisc4 images are works-in-progress.

I always assumed it’s part of the job of the people building the commercial products who ‘ratify’ the even-numbered releases to think around the issues of user upgrades and reverting.

Perhaps the maintainers of the commercial products should be encouraged to tell their users to beware of development releases, unless they have taken proper precautions etc.

As you quite rightly say, you can’t legislate for users getting themselves in a mess by installing stuff from the beta releases on the ROOL site. To that end, I’ve updated the downloads page to make it clear that the HardDisc4 images are works-in-progress.

My use of the development releases is to see what I can break and feed the information back via these forums.
I thought that was the purpose of the releases, and it seems I’m right.

My use of the development releases is to see what I can break and feed the information back via these forums. I thought that was the purpose of the releases, and it seems I’m right.

That’s exactly right.

Having got on my high horse last night, I have to admit, I do have sympathy for Chris, Andrew, et al. Customer support can often be the most demanding and least rewarding part of selling stuff. :(

Well the warnings aren’t exactly hidden (Oo, more bright red). I’m neither programmer nor developer (& the last thing I did write was in 6502 assembler) but then I don’t depend on my BB to run my pacemaker and I do make too many backups. Otherwise I wouldn’t play. Like to think the odd bug find helps.

I’m afraid I don’t have an enormous amount of sympathy for users who get themselves in a pickle by using beta-quality code.

Ouch! But quite true. The cutting edge stuff may go bang.

For what it is worth; is there a mechanism to download older revisions of the nightly builds? Is a rolling rotation (say, the builds of the last week + milestone builds) retained anywhere?

Customer support can often be the most demanding and least rewarding part of selling stuff. :(

Customer support is a pain.
Fortunately I do networks these days and even at 4am the switches don’t argue with me too often.

is there a mechanism to download older revisions of the nightly builds?

Nope, sorry. Once the new ones roll in, the old ones are deleted at present. We may revisit that idea when we’re less full of RPi-related work.

Whilst I completely agree it is up to the likes of ourselves to ensure our upgrades are smooth an painless, it is also our responsibility to alert developers to potential problems that users could experience, and discuss the risk/reward ratio (ie. what’s the risk of problems, vs what’s the benefit).

In this case, restoring a backup of their computer could potentially render the machine unbootable (or close to). I’m merely asking that developers have a think about how a safety net could be introduced in that scenario. Not in every scenario, but certainly ones that involve !boot (esp predesk). As others have stated, merely implementing the star-command with a NOOP would be perfectly sufficient. I honestly fail to see a downside to such a fix, except that purists could say “awww, but we don’t need that *command”. I may be missing something, but a *command in and of itself doesn’t take more than a few bytes does it (ie. it is just an entry in a lookup table followed by the NOOP behaviour)?

To those mentioning “running betas…” you’ve entirely missed the point – this won’t always be beta. If things remain as they are, and 5.20 rolls round without this being resolved, then anyone who inadvertently has to restore their backup of the original !Boot will have a problem. It is the role of beta-testers to report such problems so they don’t happen when 5.20 is ready.

Let’s give another example – your Iyonix ships with a CD containing a backup of !Boot. Your hard disc dies, so you replace it, and restore !Boot from the CD. Regardless of what OS build you’re running, you’d hope that the CD version of !Boot would still work to give a basic, bootable system which you could then update online. This is no longer the case as things stand. A 5.18 !Boot will error in Predesk (probably before !InetSetup is run) if run on 5.20 (as things stand). This is not a desirable situation if it can be avoided.