Notes for building RISC OS on the A9Home

This is a brief description of the special steps needed in order to get the ROOL DDE and a build of the OMAP3 ROM working on an A9Home. It’s not intended as a full guide about how to build the ROM; just the salient points about doing it on an A9.

DDE

This was written based on experiences with DDE version 19, cc version 5.68. The only problem is that many of the tools (the Absolute files in the Lib32 directory inside !SetPaths, and the !RunImage executables inside most, if not all, of the desktop tools in the Tools directory) are squeezed and produce the following error when run:

Unable to start application
(decompression failed)

The solution is to get hold of a copy of the xpand tool that is itself not squeezed and use that to manually xpand all the offending files. ROOL may be able to supply one, and it looks like this app might contain the necessary binaries. (The app itself doesn’t appear to work on the A9Home — it reports Command line too long for task window module – possibly a DDEUtils problem? Anyway the xpand utility should probably work from the command line.)

Something to look out for: !ResEd has multiple squeezed !RunImage files inside the various sub-applications within its CSE directory. These all need xpand-ing.

UPDATE

ROOL has informed me that a new version of the DDE is/will be available with all the binaries decompressed from the start, so none of the above will be necessary for people using modern versions.

Note: The ‘squeeze’ binary can be replaced with an empty obey file of the same name, or an empty BASIC file with a REM statement in it. Refer to this forum post.

BBE

!UnTarBZ2

Setting up the BBE also requires some fiddling. Firstly, if the sources are coming from CVS via Linux (or Cygwin), they’ll probably need decompressing (untarring) on the A9. !UnTarBZ2 from the ROOL website is the tool to use, but again it won’t run until the executables inside its Tools directory are xpand-ed. Then, make sure Aemulor isn’t running and has been fully quit if it was (not just the front-end). It may cause a data abort inside the SharedCLibrary while decompression is taking place if left running…

Also, !UnTarBZ2 doesn’t appear to work from the command line, so use the front-end. (This looks to be a bug in the program for which I submitted a fix to ROOL. I’ve been assured that a new version will be available shortly.)

InstallTools

This is the script that’s supposed to copy the necessary tools from the DDE into the BBE for use when building the source. Once the sources are merged, it’ll be in RiscOS.Library. It refers to a system variable <SetPaths32$Dir> that looks like it’s supposed to be set by !SetPaths in the DDE, but it isn’t. I just added the following line to the !SetPaths !Run file to fix the problem:

Set SetPaths32$Dir <Obey$Dir>

Perl

Make sure the right version of Perl gets used during the build process. The right version is the one that comes as part of the BBE. Any other versions hanging around (for example in !Boot.Resources) could interfere. (I have a script called !UnPerl that unsets the following system variables: Alias$Perl, Perl$Dir, Perl$Heap, Alias$@RunType_102. I don’t know if it’s necessary to unset all of those, but it doesn’t hurt to be overcautious!)

Note that if !RiskPkg is installed, there may well be an application directory in !Boot.Resources called !Packages. Inside is a file called SetVars that sets Alias$Perl and Perl$Dir as well as a bunch of other system variables. This file is run by the !Boot, so just having !Packages in !Boot.Resources is enough to guarantee those variables aren’t set up the right way on system startup.

Build failures

During the build process (of the OMAP3 ROM at least), some special utilities get built from source which are subsequently used themselves in the build process. Unfortunately, they are built and then squeezed, which means the infamous decompression failed error will rear its ugly head again. The solution is to prevent these utilities being squeezed in the first place. To do that, comment out (by putting a ‘#’ at the start of the line) the following rule near the end of RiscOS.BuildSys.Makefiles.CApp:

       ${SQZ} ${SQZFLAGS} $@

DefMod

The build process needs a utility called DefMod for creating C headers for modules and other such munging tasks. This utility is in RiscOS.Library.Build (merged sources). Upon checking out the BBE from CVS however, there is a ’’’directory’’’ called DefMod, not an executable. The actual executable is within this directory, and is called !Run. In order for the build to succeed, it’s necessary to rename the DefMod directory to something else and copy the !Run file in its place, renaming it as “defmod”.

(This would affect anyone trying to build the source. If anyone can enlighten me as to why no one else has reported it, I’d like to hear from them!)

!Builder

!Builder sometimes refuses to load. Double clicking on it briefly makes a task called “Toolbox timers” appear in the Task Manager, but no icon appears on the iconbar, and no error is generated. It seems that loading !EraseCVS first rectifies the problem.

That’s it! Hopefully, with the above tweaks, a ROM should build happily on the A9Home.