Alpha testing on Pi

Although I haven’t had a chance to try it myself, I think that update should fix the DigitalCD issue (Chris’s image from the 25th just missed out on my sound fix from the 26th)

I’m using the lastest firmware and ROM/Image and there are no issues with sound for me, so looks like it is fixed.
I am finding random freezes though. At the moment I suspect firmware, so I’ve updated to the latest.
My guess is that it’s either SD card or USB I/O related, I’ve a usb dvd rom coming tomorrow – if it works I’ll use that and hammer my USB ports and SD card and see what happens.
Using !TTF2f seems to increase the problem (when It’s finishing off the font at the end when bar goes red)
Also crashing with the PS to riscos font converter, so maybe it’s a generic font issue?

Just installed it on my Pi and DCD is now happilly streaming internet radio again.

What has changed from 1Oct2012 to 8Oct 2012 in the HardDisc4 image? No files have been added or removed but the following files have a different datestamp and/or size AND on examination their contents have changed:

HardDisc4.!Boot.!Run  
HardDisc4.!Boot.Resources.!System.500.Modules.CLib  
HardDisc4.!Boot.Resources.Configure.Monitors.Other.Generic  
HardDisc4.!Boot.RO500Hook.Boot.PreDesk.SoftSCSI.SCSIFiler  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootApps.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootBoot.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootRun.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!MousSetup.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!PinSetup.Messages  
HardDisc4.!Boot.RO500Hook.Res.Configure.!PinSetup.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!ScrnSetup.Messages  
HardDisc4.!Boot.RO500Hook.Res.Configure.!ScrnSetup.Res  
HardDisc4.!Boot.RO510Hook.Boot.PreDesk.SoftSCSI.SCSIFiler  
HardDisc4.!Boot.Utils.BootRun  

Hope this is helpful. It looks like the 10Oct HardDisc4 build failed as there should have been more changes than this judging from the CVS commitments…

What has changed from 1Oct2012 to 8Oct 2012 in the HardDisc4 image?

Well, you can read the CVS checkin comments, can’t you? ;)

The changes to the configure plugins will have been where I fixed them all to work properly in low res modes (i.e. 640×480). Monitors.Other.Generic is where I added a 800×480 mode definition for the Pandora. !Boot.Utils.BootRun would have been this change, !Boot.!Run would have been changed simply because the date/version number gets built into the file. I’m not sure about the CLib and SCSIFiler changes – maybe some tweaks to another library or a header caused slightly different code to be produced, or maybe there’s a build date string being inserted somewhere.

Well, you can read the CVS checkin comments, can’t you? ;)

Sometimes have to look carefully to see what’s ROM/disc for the inexperienced.

I’m not sure about the CLib and SCSIFiler changes

I compared them a few times. Changes are to datestamp & r/w permissions only.

I compared them a few times. Changes are to datestamp & r/w permissions only.

No. Where the datestamp/file size differed, I examined the contents of the file byte by byte and only where the contents were different have I included them in this list.

I examined the contents of the file byte by byte and only where the contents were different have I included them in this list.

What differences did you find in the byte by byte comparison? Visual checks show nothing significant

As a first check I looked at a simple text file: HardDisc4.PinSetup.Messages

There are changes in the content of that file:
The current file has “_Version:0.19 (06-Oct-12)” and the matching line in an older version has “_Version:0.12 (03-Feb-03)”

I make that nine bytes of different content.

HardDisc4.ScrnSetup.Messages
“_Version:0.20 (27-Jun-12)” vs. _Version:0.24 (06-Oct-12) seven bytes of different content.

I think the changes to the res files will be the fixes Jeffrey mentioned, although in the 1 Oct to 8 Oct period I think other files in the Res.configure tree changed at least in date stamp. But you didn’t list those

What differences did you find in the byte by byte comparison?

I used a programme to do it so I don’t know (or care). It’s quicker to copy over the new file than to agonise over why.

What has changed from 1Oct2012 to 11Oct 2012 in the HardDisc4 image? No files have been added or removed but the following files have a different datestamp and/or size AND on examination their contents have changed:

HardDisc4.!Boot.!Run  
HardDisc4.!Boot.Resources.!System.310.Modules.BasicEdit  
HardDisc4.!Boot.Resources.!System.500.Modules.CLib  
HardDisc4.!Boot.Resources.Configure.Monitors.Other.Generic  
HardDisc4.!Boot.RO500Hook.Boot.PreDesk.SoftSCSI.SCSIFiler  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootApps.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootBoot.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!BootSetup.!BootRun.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!MousSetup.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!PinSetup.Messages  
HardDisc4.!Boot.RO500Hook.Res.Configure.!PinSetup.Res  
HardDisc4.!Boot.RO500Hook.Res.Configure.!ScrnSetup.Messages  
HardDisc4.!Boot.RO500Hook.Res.Configure.!ScrnSetup.Res  
HardDisc4.!Boot.RO510Hook.Boot.PreDesk.SoftSCSI.SCSIFiler  
HardDisc4.!Boot.Utils.BootRun  
HardDisc4.Apps.!Maestro.!RunImage  
HardDisc4.Apps.!Maestro.Messages

Hope this is helpful.

What has changed from 1Oct2012 to 11Oct 2012 in the HardDisc4 image?

Most likely the same as what was changed from the 1st to the 8th, plus this (which looks like it would have merely resulted in the version number/date changing) and this

The only reason I’m doing this is so that I can keep my disc image up to date without having to start each time from an empty set up. I am directly comparing the unpacked HardDisc4 image rather than reading the CVS.

Please note that I have disabled further downloads of the alpha distribution – the next step is an official distribution by ROOL.

How platform specific will the official distro be?

(I have tried your Alpha, on both a Risc PC and A7000, and it worked fine on the RPC, but the A7000 had issues because of the restrictions on filenames and directory size.)

“Please note that I have disabled further downloads of the alpha distribution – the next step is an official distribution by ROOL.”

Fantastic news. Well done and thank you to everyone involved. Looking forward to the official distro.

How platform specific will the official distro be?

It’s only been tested on the RPi.

Below is my understanding (in plain English) of how things are legally – but I’m not actually clear on the agreement between Castle and the Raspberry Pi Foundation so some of this may not be entirely correct…

Further to that, we’ve only obtained permission from third parties to distribute the software as a part of the RPi distro. And the ROM and firmware (plus the disc image, partitions, etc) all count as a part of the distro – they are mostly RPi-specific. If you were to want to re-distribute (or even sell) our distro, you’d be fine – as long as it’s for the RPi. If it’s for something else, I’m not sure where you’d stand legally with respect to some of the bundled software. Also, the Castle-licenced bits, such as the ROM and boot sequence, would require you to buy commercial licences from Castle if you wanted to sell for anything other than the RPi (or in any other form than as we ship it).

Having said all that, the SDFS (Filecore) part of it doesn’t include anything that is RPi-specific, as far as I’m aware. And it’s build around the HardDisc4 build which is once more an Universal boot structure – that means it should support legacy hardware such as the RiscPC. One thing you do need to be aware of is it won’t work correctly on ARMv7 platforms (e.g. Beagleboard) because we’ve included some software which isn’t ARMv7 safe (and some that is untested).

The executive summary that I’m waffling my way towards is: if you want to redistribute the RPi distro (free or for a price) then that’s fine, as long as you target the RPi. If you target something else, you probably need to speak to the authors of the third party software to obtain permission. If you want to sell it for something else, you need to buy licences from Castle.

We knew the moment was coming, it was just a matter of time. Well done to everyone involved in achieving this.

Christmas has come early this year :-)

I am assuming there is GPLed software in the distribution; have ROOL prepared what is required to make sure they are not breaking the source redistribution elements of the licence? Almost nobody ever gets this right, and it’d be nice to see RISC OS for RPi get it right.

if you want to redistribute the RPi distro (free or for a price) then that’s fine, as long as you target the RPi.

Interesting. The current RO licence is pretty much a home brewer’s charter. Build it for yourself (or presumably help friends to do it.) and it’s free, otherwise (if you want to sell a system) you have to make arrangements (presumably involving money).

This gives more away, but only for the Pi, premium systems still remain the same.

Excellent thinking.

Does the final distro still have the same partition/image arrangement?

Is it still for a 2GB card?

Is it still for a 2GB card?

Whatever size of card is intended, someone will say that there is not enough storage for RISC OS. But it is easy to add a pen drive for more storage.

Use a bigger card than the image and you can add another partition – for example for Linux. Then you can, in principle, multi-boot.

There seems no case for making the distro bigger than 2Gbytes.

I managed to repartition the SD card so that I have 8 GB for RISC OS. Was a bit tricky… (perhaps I was not using the quickest way):

1. Boot Pi with RO
2. Copy RO stuff to my IYONIX pc with ShareFS (except for !Boot.Loader PC partition file); you can copy it to an USB stick or whatever too.
3. Remove card from PI (but leave it on)
4. Save contents of boot partition (the small 128 MB one) with Windows, Linux or whatever
5. Partition so that one 128 MB partition at end and a big one for the rest – used Linux since Windows does not like to create partitions on removeable media and the commeon tools to help fail on Windows 7 x64.
6. Format the small partition as FAT and active.
7. Note the number of sectors of the big partiion.
8. Copy backthe saved ontents of the boot partition (see step 4).
9. Put card back in Pi
10. Run HForm (from the copied stuff through ShareFS – see 2.)
11. It suggested heads, sectors per track and cylinders … divide the number of secors (see 7.) by heads and sectors per track and subtract 1 (or a bit more) to get the number of cylinders to use for the new partition we want to format now.
12. Copy back the file saved in step 2.
13. Reboot
14. If boot works fine you’re done… if not well you can restart from the beginning after refilling the SD card with the distro image.

I wanted a bit more than 2 GB so that I can put all apps on the SD card so that for the data I can either use a network drive or a USB key.

I just ordered a 4GB class 10 / UHS-1 panasonic card for about £6 from amazon.

The other 2GB won’t be wasted, because of the wear levelling.

The next version of Fat32Fs has support for SDFS so when it’s released the remaining space can be partitioned and mounted without affecting what’s there already.

That sounds great. I shall have to start looking for a big SD card.

That should mean that there should be no longer be a reason to do the image file thing.

However a new formatter would be needed.

The next version of Fat32Fs has support for SDFS so when it’s released the remaining space can be partitioned and mounted without affecting what’s there already.

Surely, now that the filecore partition is marked as type &AD (filecore) with a partition table in the area which RISC OS ignores, and the FAT partition has its own partition table (which between them protect the part of the card used by SDFS) it is already possible to add further partitions without affecting SDFS? Not yet under RISC OS but on Linux, for example.