Software testing help wanted for Raspberry Pi

Are all your files in !Boot.Loader in capitals? It does fall over if they’re not.

No. I have renamed them (under RISC OS) to be capitalised and – they work! Many thanks.

RISC OS now starts up with 448Mbytes (using gpu_mem=64).

FYI Theo (and everyone else): There’s a new version of ArcEm which will run properly on the Pi (I’ve added support for running in 32bpp modes). This version also lets you specify which keys are used to open the tweak menu (—menukeys command line option).

Now perhaps someone can explain what is happening here:

On RISC OS I have created an 8:3 file called ‘lowcase.txt’ by copying the ‘config.txt’ file

Then I look at the FAT partition under Windoze and see:

Suddenly it has appeared as ‘lowcas~1.txt’ it can’t be the case that is the problem because I can create both ‘lowc.txt’ and ‘LOWCA.TXT’ OK under windoze. So is it a bug in the RISC OS image filing system?

I found this when trying to upgrade the RISCOS.IMG from within RO, presumably because it was clashing with me renaming the previous image. There’s a bug loaded #313 that might relate https://www.riscosopen.org/tracker/tickets/313

I can’t test anything on my Pi at the moment but I’ve been looking through the package list.
The UnixLib package description says it is “currently just the module SharedULib, at version 1.10”. However the SharedUnixLibrary package is version 1.12. This sort of thing is bound to happen when you have two packages for the same thing.

Windoze

This was funny back in the 1990s when I was a teenager and when Windows was actually rubbish. Now it’s rather tiresome and immature.

and when Windows was actually rubbish

This aspect of winows is actually still rubbish!

Well spotted Edward – it comes from merging two package repositories that have different ideas about package naming. I should be able to fix it.

I should also point out that the changes to start.elf have broken my testing firmware autobuilt package. Probably worth waiting for us to be happy about the new firmware arrangements before reinstating it. Testing ROM builds are still fine, and don’t require a particular firmware build.

The DOSFS bug is indeed one I reported by upgrading firmware and discovering the Pi wouldn’t boot. If everything’s uppercase and in 8.3 format you should be safe.

Just found a discrepancy in !PackMan.

Fresh Boot. Run Apps.Admin.!Packman
Having selected “Update Lists” from the menu on the box on the iconbar, my only available update is RPi-ROM, which is fine.
However, “Packages to remove”, I get “xjig” listed. Little game I downloaded using !PackMan at the weekend.
Select “Cancel” and Select on box icon brings up the list of packages.
Menu in the list window, Select “Upgrade all” and there is nothing to remove.

Now just discovered, Menu in the list window, “Upgrade All” repeatedly, actually toggles whether “xjig” is there to be removed or not.
The same applies to the Menu on the box on the iconbar.

xjig appears to be working fine by the way!

xjig appears to be working fine by the way!

Ooh, I’ve just remembered – I made a graphical front-end for xjig with AppBasic which enabled you to configure all its command-line options in a friendlier way and launch it from the icon bar. (It also automatically corrected the filename extension problem that that program inherited from some inferior non-RISC OS filing system.) I sent it to Peter Naulls, but AFAICT he ignored it. Theo, would you be willing/want/be able to have it integrated into the main distribution now?

Martin, I have no objection. Is this something to drop around the xjig executable? Does it need extra bits (eg the AppBasic linker) to build it? The current xjig build requires netpbm, whose build is currently broken. So might be good to fix this at the same time…

Yes, it’s just a simple drop-around, and once compiled, it shouldn’t require AppBasic.

Still testing! RPi, 24/11/12 ROM and latest firmware. 224Mb RAM.

MadPlay. Listening to Iron Maiden. Pause response seems a bit slow and there is no tag info displayed. Will try again at a later date with MP3s from other sources or edited tags.

xu4. Seems to work, but haven’t a clue what is going on! :)

xpilot-ng. Get welcome screen, but closes when “Local” Selected. Click “Internet” and I get a list of servers. Not made much progress from here and certainly no gameplay yet.

xjig. Still works. Will investigate the “Remove” issue when the next ROM update is available, but not installed.

xflame. No spritefile found error on opening directory. Seems to work, but if I set size options in !Run file to 1920×1080 it is a little slow, and it does take 6.8Mb acording to Taskmanager.

wesnoth. A little slow on startup. Sound stuttery, but tutorial working.

I am also trying the:- run a program, reduce screen size, quit game, restore to maximum screen size thing. It seems to black screen and crash on most programs with sound, but only sourced through !Packman. !MineHunt doesn’t have the same effect. I don’t have many other sound programs that are 32 compatible to test this.

wargus. Don’t have Warcraft2 CD

tuxmath. Game works ok, but get black screen crash on exit. As game changes resolution, it may be related to the bug above.

tutris. Works, even after resize thing, but maybe that’s because there is no sound. Just a thought.

rocksndiamonds. Works ok.

mazeofgalious. Slightly alarmed at the beginning. Looks like Ali Gs’ goat! Seems to work, changed to 640×480 to fill screen. Quit game and back to full HD. Get the black screen bug again.

Are all your files in !Boot.Loader in capitals? It does fall over if they’re not.

I was happily updating files in !Boot.Loader by copying files like ‘riscos/img’ over the top of what was there before (RISCOS/IMG) not realising that I was relying on a quirk of RISC OS. If you copy or save a file ‘OdDcAsE’ over the top of an existing file ‘oDdCaSe’ then the capitalisation of the original file survives. When saving, the filetype of the original file also survives. If you rename a file ‘AAA’ to ‘aaa’ then this effect also applies, preventing the renaming in one step.

Theo, what is the procedure to add packaged software to the packages.riscosopen.org location please?

There isn’t one, yet. I had hoped to integrate something with the ROOL website, but it looks like Andrew has enough to worry about for the moment.

Probably the easiest thing is to put it on a website (if you are able) and send me a link and I’ll pull it in manually. It makes life easier if the URL is one that doesn’t change if you update the package (ie it’s myapp.zip not myapp123beta.zip). If you don’t have a website you can email it to me (theo at markettos dot org dot uk).

Probably the easiest thing is to put it on a website (if you are able) and send me a link and I’ll pull it in manually.

Yes please. I’ve read the guide to packaging and it looks rather complicated. Here’s some software then:
!Store/Cat, /CountDown, /MakeDraw, /MultiTask, /SignalBox

(as Cat and CountDown are dependent on MakeDraw [and !Store cannot handle dependencies] I have just included it inside the application and changed the Run file to set MD$Dir to suit).

The last mentioned is an update to the version shipped with RC6 (as provided with RC6 but with some extra data files that make it 98Mbytes rather than ‘just’ 20Mbytes)

Yes, it needs describing more simply when I get a moment. If it’s a simple app, use PackMan to install PackIt. Run PackIt, drop the app onto the iconbar icon, and fill in the boxes. See the PackIt help if you don’t understand what a box means, or in the worst case read the policy manual . There’s a little reminder at the bottom about things that need attention. You can then save out the package from PackIt.

Modules for !System need to go in a dummy !System directory inside the zip, but (annoyingly) called System (not !System). I don’t think PackIt handles these yet. All you need in addition is a RiscPkg.Copyright file (your licence conditions for them) and a RiscPkg.Control file (open another package in !Boot. Resources.!Packages.Cache and look at the Control file for examples).

Modules for !System need to go in a dummy !System directory inside the zip, but (annoyingly) called System (not !System)

Wouldn’t it make more sense for these to be separate packages? Then they could be used for other programs without downloading the original program.

Unless the module is something incredibly specific to the program.

(But, yes, modules should be separate packages that are called as dependencies by the original program.)

Indeed… things which are useful to other programs ought to be in their own packages. Better to have lots of small packages than one large one. It also means it’s more efficient to upgrade the one module than the whole lump of a big app. Same goes for datafiles – if SignalBox (for example) will run with a minimal dataset ship it with that and add the full one as other package(s). That means you don’t have to download 100MB of stuff every time the program is updated, and people who are short on disc space can just have the basic version.

Sometimes you might want to install odds and ends that don’t fit in the existing structures (app, !System, !Boot.Resources, etc) – the RiscPkg model is to put these in an application directory so other things can find them by system variable (an example would be !ZapFonts). If there’s things that don’t fit this idea very well, do let me know.

!Scumm seems to work well. Better than the original games I have struggled or failed to run on various PCs!
Been through my CDs/floppies and all the following seem OK.

1. Discworld
2. Simon the sorceror I+II
3. Day of the Tentacle/Manic Mansion
4. Sam ‘n’ Max
5. Curse of Monkey Island
6. Broken Sword for PSX
7. Beneath a Steel Sky
8. Space Quest IV
9. Broken Sword II

Minor issue with config file stuck in root SDFS directory even though I’ve managed to store and link everything else on a separate USB drive.

Blimey (edited for language! :) ) Fills about 5Gb, more than the harddrive on my RISC PC!

Using RPi.

“Indiana Jones and the fate of Atlantis” and “Monkey Island 2” start as well, didn’t found time to acutally play it yet.

!ScummVM puts the config files in root when !UnixHome wasn’t seen by RISC OS. Just put !UnixHome in !Boot.Resources. and RISC OS will have seen it after booting.