Official Release - CMOS

I’ve been playing with the official release for about half an hour. It looks brilliant and the welcome guide is excellent. I’m a little confused though. Do I need to change a setting somewhere to make the ‘CMOS’ type settings persist betwween reboots. I’m finding that the mouse and screen need set up each time I boot the Pi.

Cheers.

It should ‘just work’. The CMOS settings are written into the ROM image by the SDCMOS module, so some things to keep in mind are:

1. make sure SDCMOS isn’t “unplugged”
2. when you change your ROM image, you should do something to cause CMOS to be saved or they will be lost

In addition to that, the mouse step is a CMOS setting, but the screen is stored in a file in the boot sequence (if you’re talking about which MDF you load and what resolution to use). I can’t think of a single cause that would make both cases fail to work (other than maybe problems writing to the SD card at all?).

BTW: thanks for the positive feedback on the welcome guide. I just hope I never have to redo those screenshots… ;)

Hi Steve. I knew that I would lose settings when I wrote the new image to the SD card. I was happy to have a clean start. Something seems wrong somewhere as both mouse settings and screen settings are consistently being lost between reboots. I haven’t messed around with anything in !Boot or ‘under the hood’ yet, but *modules does not show SDCMOS and *unplug states there are no modules unplugged.

I have just tried setting the CD drives to 1 and then rebooting but they are back to zero. Even if I selecct ‘SaveCMOS’ in the configuration window before rebooting, the settings are stll lost. I have even tried copying the file ‘CMOS’ (that is produced by ‘saveCMOS’) into !Boot.Loader.

*configure cdromdrives 1 works until the next boot and then *status shows it is set back to 0 again. It looks like a ‘delete-power on’ is being forced somehow.

RC2 worked OK in case that helps…

On RC2 ‘SDCMOS 0.08’ was shown as ‘Active’ when listed using *ROMMODULES

On RC5 ‘SDCMOS 0.09’ is shown as ‘Dormant’.

However, having CMOS settings fixed may be no bad thing for first-time users and an upgrade to allow settings to be altered will no doubt be ‘available soon’.

This sounds like an issue we saw in RC4 but we thought we’d fixed in RC5 (the final release candidate). I reckon something has gone awry (we tested the wrong image or something) which means the ROM in RC5 isn’t the one with the fix. We should be able to fix this via PackMan over the next couple of days. Failing that, drop the latest ROM from the ROOL site into your RC5 image and you should be OK (I hope!).

Hi Steve. I updated the image with ths mornings boot. Rebooted, configured stuff and then rebooted again. The settings have persisted now and all seems to be fine.

Cheers.

As regards the image, it doesn’t fit onto my 2Gb stick. When I dd’ed it onto my sd card it was too big. However everything checks out OK on using it.

Yes, same for me. It is just a little too big to fit on the card so I had to use a 4Gb card I had instead.

This is all good feedback, thanks. I reckon there’s going to be a MkII official release sometime fairly soon…

I’m not overly surprised to hear about 2GB cards not fitting the image – we bought a lot of SD cards of all different kinds and their actual size was quite variable. We sized the image to be slightly smaller than the smallest 2GB card we’d come across (so it’s 1876 MiB).

If those of you with SD card size problems could tell me exactly how big the cards actually are, that’d be a big help.

Steve, I think there’s been a regression on the image size in RC5:

-rw-r--r-- 1 atm26 atm26 1971322880 Oct 13 22:03 ro519-2gb-rc1.img
-rw-r--r-- 1 atm26 atm26 1967128576 Oct 15 21:45 ro519-rc2-1876M.img
-rw-r--r-- 1 root  root  1967128576 Oct 15 23:26 ro519-rc3-1876M.img
-rw-r--r-- 1 atm26 atm26 1967128576 Oct 16 21:09 ro519-rc4-1876M.img
-rwxr--r-- 1 atm26 atm26 1988100096 Oct 16 22:55 ro519-rc5-1876M.img

Thanks, Theo. This should be corrected in the RC6 release (official release part deux).

If you would like me to upload this to plingstore as an official ROOL upgrade, please let me know.

Hi Chris. What are you referring to? If you mean the RC6 image itself, it will be on the RPi site. If you mean the contents of it as a mechanism for users to update, then that will be handled, as I’ve said previously, using PackMan. If you take a look, there are already packages for the firmware and ROM image. We will up-version these and allow users to get the latest ‘official’ versions. Not everything is packaged yet, of course, because it’s all a work-in-progress, but we aren’t planning on pushing images or updates out via plingstore.

I want us all to move away from the old, chaotic RISC OS approach to software updates, where people manually move and copy and replace and edit stuff all over everything. That only ever multiplies the number of issues people hit and the support burden therein. In the worst case, you’ll end up with various different flavours of the distro which have been modified in various different (and no doubt incompatible) ways. I think we’ve all seen exactly what fragmentation of RISC OS leads to…

Of course, people want and expect flexibility – quite rightly so – and that’s why PackMan has now got the ability for you to re-locate installed apps into the place where you want them. More refinements of this type will inevitably follow.

I want us all to move away from the old, chaotic RISC OS approach to software updates, where people manually move and copy and replace and edit stuff all over everything.

I’m so pleased to hear that coming from the top.

I think it would be good if packman also offered a !store type fetching option. (i.e go and fetch it and let the user fiddle with what it downloads.) Not that I would use it, but it would deal with the objections to the way it works.

I would also like to see Store and packman combined. (At least from the user’s point of view. If there are two different delivery systems, fair enough.)

Also note that PackMan isn’t set in stone for ideological reasons, it is the way it is because nobody’s had the time to implement feature X or Y yet. So if you have an opinion on the way things should be, feel free to make some changes (code here ). If you’d like to, but haven’t a clue where to start, there’s help available.

Also note that PackMan isn’t set in stone for ideological reasons, it is the way it is because nobody’s had the time to implement feature X or Y yet. So if you have an opinion on the way things should be, feel free to make some changes (code here ). If you’d like to, but haven’t a clue where to start, there’s help available.

While I’d agree with you in principle, and have been advocating package management on RISC OS for a long time (I wrote about why it’s a good idea in Archive over eight years ago, for example), you have to remember that the RiscPkg platform (which includes PackMan, I’m afraid) has been receiving bad press for years. We’re now in the situation where a popular application recently switched to updates only being supplied via packages, and several users made it clear on the newsgroups (so not the least technical users out there by any means) that they wouldn’t bother to take any future upgrades.

I have no connection with !Store beyond writing about it a few weeks ago in a RISC OS publication and having a preliminary exchange of emails with Andrew before doing so which pretty much opened with “so why bother reinventing the wheel?” — although as a result of that exchange, some of my software is now included in the system. However, it seems clear that the concept is intended to get these kinds of users back on board with a distribution system which meets their requirements (whatever the ideological rights or wrongs of those might be).

While the changes to PackMan are definitely welcome, it’s baffling that no-one has mentioned them anywhere outside of this site. If it really has become flexible, that might improve its chances of being accepted by enough users to make it worth developers’ while to use it for distribution. Why has no-one shouted about it so that minds might get changed? At present, I’d prefer that people can use my stuff: if that means using both RiscPkg and !Store because many users won’t touch RiscPkg/PackMan with a bargepole, then so be it.

I’m not using the RiscPkg platform at present anyway, because unless I’ve missed something there’s a steep learning curve for developers wishing to package things up and little in the way of useful documentation to help.

Oh, and in this particular case I’d argue that saying to the users that “the source is here” isn’t helpful. It’s valid if they’re asking for new features or bug fixes to a piece of software, but if you’re trying to move them off downloading zip files on to a new delivery system that offers most benefits to the developer, then it’s up to the developer to do the legwork to get the new system looking attractive.

We’re now in the situation where a popular application recently switched to updates only being supplied via packages, and several users made it clear on the newsgroups (so not the least technical users out there by any means) that they wouldn’t bother to take any future upgrades.

I’m not sure what package that is, but those users must be pretty dumb, because the package file is just a zip file containing the app, and can be downloaded from a browser. So if they hate the packager, they can simply bypass it.

But it would be a good feature for packman to be able to offer just the files, like store.

But it would be a good feature for packman to be able to offer just the files, like store.

All the packages downloaded by PackMan can be found in their original form in !Packages.Cache.

So it should be an easy feature to add. (Because I suspect anyone who didn’t like the idea, would prefer to fetch the file with a browser, than go hunting.)

It’s simple enough to find the direct download URL with PackMan already. Just click on the ‘information on package icon’.

I’m not sure what package that is, but those users must be pretty dumb,

That’s always a good way to get users on board: call them “dumb”.

because the package file is just a zip file containing the app, and can be downloaded from a browser. So if they hate the packager, they can simply bypass it.

Unless things have improved, that’s far from obvious to the end user. Also, if more than a small handful of your target audience are bypassing the packaging system in favour of ripping the contents from the packages by hand, then there’s something very wrong indeed (and you might just as well avoid the hassle of packaging and go for vanilla zip files).

From what Theo said upthread, it sounds as if their main concern has been sorted; however !Store is another attempt to resolve that concern from a different angle, possibly because the improvements to PackMan appear to have been an extremely well-kept secret. Complaining that someone else has tried to fix a long-standing problem perceived by many users because you haven’t told anyone that you’ve finally done something about it yourself seems a bit like sour grapes.

As far as the presence of free software in !Store goes: until PackMan wins out, developers are entitled to want to use both systems so as to get the widest possible visibility for their software. And you can’t expect those developers to fix PackMan for you.

In the end, the PR (to both users and developers) matters just as much as the technical and ideological niceness of the solution. It matters not one bit how “nice” a system is if the users won’t use it because all they know of it is some acrimonious threads in the newsgroups where people were saying just how broken and “un-riscos” it was.