ROLF - An alternative GUI for Linux

Beagle Board booting moving to another blog

2011-12-07T10:16:00.000+01:00

It seems what I'm doing now mirrors the goings on back in July at this site this site, which is written in a much better style.

I'm intending to continue working on this until I have a complete OS on the BeagleBoard. I'll be talking about that on my Something Like Eiffel blog, since it's going to be designed around the same language features that I've been thinking about there.

Booting Beagleboard by BBC BASIC

2011-11-24T21:40:00.000+01:00

The RPC is the only machine I have left with a serial port (well, except the BBC Micro that's coming up to its 30th birthday next year, and it can't quite manage 115200 baud).

Below is a very short BBC BASIC program that assembles some code and uploads it to the BB internal memory. You have to hold down the USR button on powerup/reset to get it to talk. (The slowest part in development was noticing out that the initial boot sequence uses 8E1 protocol, and not the 8N1 that the x-loader and u-boot and linux do.)

I wanted to get into the boot process as early as possible without continuously re-flashing the NAND ROM, and also avoiding plugging an SD card into the somewhat worn out socket.

Brunel OS is an idea I've been thinking about for years, with a concept based on an Eiffel inspired language that handles multi-threading by simply only alowing one thread at a time access to any object and allowing threads to pass through multiple memory maps (somewhat different to the process model of other operating systems I've had experience of).

So, an example of loading a very small program into internal RAM of the BeagleBoard from a Risc PC:

SYS"OS_SerialOp", 0, &106, &fffffe00
SYS"OS_SerialOp", 1, %011000
SYS"OS_SerialOp", 5, 18
SYS"OS_SerialOp", 6, 18

PROCassemble

REM Receive ASIC ID (and ignore it, for the time being)
FOR R%=1 TO 58
  REPEAT
    SYS"OS_SerialOp", 4 TO ,J%;F%
  UNTIL (F% AND 2) = 0

  PRINT RIGHT$( "0"+STR$~J%, 2 );
NEXT

PRINT "Sending boot command"
PROCput( 2 )
PROCput( 0 )
PROCput( 3 )
PROCput( &f0 )
PRINT "Boot command sent"
DIM B% 4
!B%=P%-code%
PROCput( B%?0 )
PROCput( B%?1 )
PROCput( B%?2 )
PROCput( B%?3 )
PRINT "Length sent ";!B%
T%=0
FOR Q%=code% TO P%
  SYS"OS_SerialOp", 4 TO ,J%;F%
  IF (F% AND 2) = 0 THEN
    PROCshow( J% )
  ENDIF
  PROCput( ?Q% )
  T%+=1
NEXT
PRINT "Transmission finished "; T%; " bytes"

REM Kind of terminal (one way, at the moment)
REPEAT
  REPEAT
    SYS"OS_SerialOp", 4 TO ,J%;F%
  UNTIL (F% AND 2) = 0
  PROCshow( J% )
UNTIL 0

END


DEF PROCput( C% )
REPEAT
SYS"OS_SerialOp", 3, C% TO ; F%
UNTIL (F% AND 2) = 0
ENDPROC

DEF PROCshow( C% )
    R%+=1
    IF C%>31 OR C%=10 OR C%=13 THEN
      VDU C%
    ELSE
      PRINT "<";~C%;">"
    ENDIF
ENDPROC


DEF PROCassemble
DIM code% 1000
FOR I%=0 TO 1
P%=code%
[OPT 3*I%
  MOV r9, #&49000000
  ORR r9, r9, #&00020000
  ADR r1, welcome
.write_loop
  LDRB r2, [r1], #1
  CMP r2, #0
  STRNEB r2, [r9]  ;This can overflow the buffer, but it's not important yet
  BNE write_loop

.loop
  B loop
.welcome
  EQUS "Welcome to Brunel OS 0.0.0-1"+CHR$10+CHR$13
  EQUB 0
  ALIGN
]
NEXT
ENDPROC

Output:

04010501343007561302010012150100000000000000000000000000000000000000001415010000000000000000000000000000000000000000Sending boot command
Boot command sent
Length sent 64
Transmission finished 65 bytes
Welcome to Brunel OS 0.0.0-1

Alignment and modern ARM processors

2011-11-04T19:33:00.001+01:00

Back when RISC OS was in its heyday, and the ARM processor was new, reading or writing a word at a non-word aligned address didn't cause an exception or cause two memory words to be read (and half discarded); instead it would read the word at (address & ~3) (i.e. the word containing the byte addressed) and load it into the register, rotated so that the addressed byte was the least significant byte in the register (IIRC).

ARM Architecture Reference Manual:

load single word ARM instructions are architecturally defined to rotate right the word-aligned data transferred by a non word-aligned address one, two or three bytes depending on the value of the two least significant address bits.

Modern ARM processors, when faced with this case, can trigger an alignment exception, allowing the OS to fixup the instruction to behave in the (admittedly more high-level-language-friendly) way of reading the four bytes starting at the address and treating them as a single word); some hardware can even perform the fixup automatically.

Unfortunately, that means that some RISC OS (read: old) code breaks.

There are two Linux features that appear to have a bearing on the problem:

/proc/cpu/alignment (allows you to set whether an alignment exception should be fixed up or a SIGBUS sent to the process). Unfortunately, that has at least two problems; firstly, it's system-wide, and so may cause other programs to break, secondly, it doesn't register unaligned LDRs (probably because the hardware performs the fixup).
The prctl has the following values defined in linux/prctl.h: PR_SET_UNALIGN and PR_GET_UNALIGN, and the possible values: PR_UNALIGN_NOPRINT (for silent fixup) and PR_UNALIGN_SIGBUS (to signal the exception to the process for fixing up). This is a per-process feature but, unfortunately, these values are not implemented in the ARM kernel.

Ideally, I think I'd like to use the prctl approach and have a third value to set the system to, PR_UNALIGN_ARM_TRADITIONAL, which would simply work the way ARM processors used to. How practical that is remains to be seen (especially in the presence of multi-core processors; the behaviour has to be settable on a per-core basis).

ARM Emulation on ARM - progress

2011-11-02T19:15:00.004+01:00

The emulation approach I talked about in my last post is working well enough that most BASIC seems to work well (and the missing parts are probably due to omissions in the ROLF libraries, not down to the emulator code). !Edit (from a RISC OS 4.02 ROM image) starts up, brings up an IconBar icon and opens a window (whose text can be read, provided it's not in system font), but for some reason the characters typed each get put on a new line!

There are still some bugs to be ironed out, and the (unoptimised) speed is less than I'd hoped. Actually it's about 100 times slower than my 200MHz RiscPC!

Still, I have several features that still need implementing, such as a hash table for cache searching, fixing up jumps to non-local code so that the second and subsequent jumps make no search, compiling the library with gcc optimisation on (which made a surprisingly large difference on the x86 ARM emulator) and, if all else fails, reorganising the instruction identification mechanism to be more efficient.

Update 19:39. Implemented a simple three instruction hash, for a better than 10x speedup. Now only 10 times slower than the 15 year old machine!

Update 19:55. -O4 optimisation gives a 30% speedup (a test that used to take 167cs, now takes 115cs), although that's probably more about turning off some debug than anything else.

Update 00:21. One fixup approach takes the time down to 78cs (for 1 million times around a FOR...NEXT loop).
Initially, I thought I'd have to clear the cache (which involves a system call, plus whatever the OS does) for each fixup, but I realised that I could use LDR pc, [pc,...] to load the destination address using the data cache, (where the destination address would initially be the fixup routine and later the actual code address). I might try some other approaches in the morning. (I just noticed some debug output still in there, so I deleted it and... the time went UP to 106cs. I'm going to bed.)

ARM Emulation on ARM

2011-10-06T15:23:00.000+02:00

ROLF has a compatibility layer intended to allow execution of RISC OS applications. On x86 platforms, this includes an emulator for the ARM instruction set. Recent experience with trying to simply use the ARM processor on ARM platforms ended in failure. I'm trying a different approach to work around that problem, which should also remove the need for Linux kernel changes and allowing the execution of both 32-bit and 26-bit programs.

The emulator interface will be the same as the emulator on the emulator that generates x86 code, but takes a different approach to code generation due to the similarity of emulated and host processors.

Basically, code generated by the emulator is isolated from the Linux code by a code fragment that stores and replaces Linux register values with the emulator's register values on entry and does the opposite on exit. Most instructions can then simply be copied verbatim from the emulated code to the generated code. Since the emulator generated code needs some workspace to deal with, four registers have been reserved and instructions that use the reserved registers will be modified and supplemented with code to load and/or store the stored register's values into reserved registers.

For example:

ADD r1, r4, #17

Would be copied, but

ADD r8, r9, r10 LSL#2

needs to be replaced with something like

LDR r8, [r11, #40]    ; Load arm_emulator_regs[10] into r8
LDR r9, [r11, #36]    ; Load arm_emulator_regs[9] into r9
ADD r8, r9, r8 LSL#2  ; The original instruction with the register fields replaced
STR r8, [r11, #32]    ; Store r8 into arm_emulator_regs[8]

Use of r15, the program counter, will also be recognised by the emulator and code generated to emulate either the 26-bit or 32-bit PC, depending on the current mode.

The reserved registers chosen are r8-r11, since:

They appear to be the least used registers in the RISC OS 4.02 ROM
They are in a block of four, aligned on a four register boundary, which allows instructions using them to be identified by checking the top two bits of the register number (0b10xx)
Four is the smallest number of registers that this can work with, considering instructions like ADD r11, r10, r9, LSL r8 need three registers to hold the "input" values (we can re-use one of them as the destination register) and one more register (r11) to store a pointer to the emulator's registers in memory (plus the stored caller's registers and the emulator's PSR).

Condition flags are also a breeze compared with emulating them in x86 machine code, and conditional execution of instructions pretty much takes care of itself, except when the instruction sets the flags and the emulator still has to emit code to store the value of a reserved register.

For example:

ADDEQ r8, #1

Can't simply do this:

LDREQ  r8, [r11, #32]
ADDEQS r8, #1
STREQ  r8, [r11, #32]

because the final instruction will execute on the conditions set by the preceeding instruction.

So, in cases where the instruction condition is not AL, and a reserved register may be modified by the instruction, the generated code will have to be more like this:

ADDNE  pc, pc, #offset
LDR    r8, [r11, #32]
ADDS   r8, #1
STR    r8, [r11, #32]

I'll have to experiment to see if it's more efficient to implement all conditional instructions with a opposite-condition hop over unconditional instructions or copying the emulated instruction's condition to each of the generated instructions. I suspect that the hop approach will be easier to implement and also faster at generating code, so that's what I'll try initially.

Two details that have cropped up in the implementation so far are that:

The generated code needs to be written to a writable, executable area of memory, so not a global variable but an anonymous mmap'd area (or possibly a global variable declared specially, perhaps in an assembler file?)
The ARM instruction cache needs clearing after generating code. Linux provides a call: __clear_cache( void *begin, void *end ) - begin is inclusive, end is exclusive.

What now?

2011-09-04T18:55:00.002+02:00

I've been having a look at what's working and what's not (on x86 systems).

The basic ROLF functionality is largely there, with some minor bugs (buttons appearing pressed when they aren't any more, etc.) It's largely unchanged, although it's easier to produce different Wimps for different display types (currently xlib, vnc and the original frame buffer are supported, I expect others, like SDL, would be fairly simple to implement). XLib needs to be able to support mouse movement outside the screen area (probably by including an offset to the X mouse position to ensure the mouse limit is always within the window area). Framebuffer needs autorepeat of keypresses to be implemented; the Terminal application is a bit of a pain to use without that. The only adjustment to the Wimp protocol still to be made is to allow an application to request the current state of the modifier keys, specifically for shift-activating application directories in the Filer.

From the point of view of RISC OS programs, support is patchy. For example, the ArtWorks renderer seems to work quite well, both using the AWRender module from the ROLF-native Viewer application as well as !AWViewer, a complete RISC OS application (given a RO4 ROM image to provide various modules).

On the other hand, of the ROM applications from RO4, none of them show their proper application icons [fixed] and only Edit gets to the point where it does anything useful. Draw drops out after adding an icon to the iconbar. Help requires the toolbox, which I've not included in the list of modules loaded by default. None of the others bother the scorer at all.

NetSurf needs tidying up and possibly merging with the NetSurf sources. It would be nice if ArtWorks files could be displayed, using AWRender, and even videos using mplayer. At the moment, none of the menu items work, you can't type in a URL, etc.

The MPlayer application hasn't changed in a long time, some videos appear in diagonal stripes, like the horizontal hold is broken; perhaps they have an unusual width or height? The one I just looked at has a width of 930, which isn't divisible by eight... [fixed - the stride passed in to the draw_slice routine was greater than needed for the width, my mistake]

I have no idea if GTK still compiles, let alone does anything useful.

Brandy 1.0.19 has a patch that may still work, but I tend to use the RO BASIC interpreter, because it's got an assembler built in (needed for AWViewer to run). I seem to recall that 1.0.20 needed quite a different patch approach, but I can't remember the details.

I think I'll have a go at the Filer, first, it's been a long time since I looked at it.

A minor hitch running RISC OS code on ARMLinux

2011-07-09T16:56:00.000+02:00

Update to an earlier post about running RISC OS applications on ARMLinux.

Here's the thing: RISC OS modules, libraries and, occasionally, even applications switch merrily between USR and SVC mode at will. There's even a system call, OS_EnterOS, which exits with your application running in SVC mode, no questions asked.

The problem is that at least one instruction to return to user mode (MSR CPSR_c, r1) is still a legal instruction in user mode (i.e. its execution isn't flagged as an exception), so ROLF can't detect that it should switch the "banked" registers it emulates.

One solution might be to jump to the code while in SVC mode but, even if that works, there would be a hole in the Linux security model big enough to fly a fleet of A380s through.

Bother.

Why does the language version being used affect standard semantics?

2011-06-15T09:47:00.003+02:00

knoppix@Microknoppix:/tmp$ cat x.c
#include <signal.h>

siginfo_t info;

knoppix@Microknoppix:/tmp$ gcc x.c -c
knoppix@Microknoppix:/tmp$ gcc x.c -c -std=c99
x.c:3: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'info'
knoppix@Microknoppix:/tmp$

Hmpf.

Root filesystem for Beagleboard on MMC card

2011-06-11T17:14:00.002+02:00

Update: There is of course the rootwait kernel parameter, which is better. (I'll leave the rest in case someone else searches for the same symtoms.)

Just in case someone else has the same problem, I've had a frustrating few days trying to get my own kernel to start up with the root filesystem on /dev/mmcblk0p2.

I based my kernel on the config found here, and based my boot.scr file on the one supplied with the Debian Net Install generates with "mk_mmc.sh --uboot beagle_bx".

No matter which kernel I tried, or boot.scr options I could find, I kept getting a kernel panic whenever I tried to use root=/dev/mmcblk0p2 (rather than an initfd):

[    4.075317] regulator_init_complete: VDAC: incomplete constraints, leaving on
[    4.083404] md: Waiting for all devices to be available before autodetect
[    4.090637] md: If you don't use raid, use raid=noautodetect
[    4.097534] md: Autodetecting RAID arrays.
[    4.101928] md: Scanned 0 and added 0 devices.
[    4.106628] md: autorun ...
[    4.109558] md: ... autorun DONE.
[    4.113159] Root-NFS: no NFS server address
[    4.117614] VFS: Unable to mount root fs via NFS, trying floppy.
[    4.124816] VFS: Cannot open root device "mmcblk0p2" or unknown-block(2,0)
[    4.132141] Please append a correct "root=" boot option; here are the available partitions:
[    4.140991] 1f00             512 mtdblock0 (driver?)
[    4.146362] 1f01            1920 mtdblock1 (driver?)
[    4.151672] 1f02             128 mtdblock2 (driver?)
[    4.157012] 1f03            4096 mtdblock3 (driver?)
[    4.162384] 1f04          255488 mtdblock4 (driver?)
[    4.167724] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
[    4.176483] [] (unwind_backtrace+0x0/0xf8) from [] (panic+0x5c/0x190)
[    4.185150] [] (panic+0x5c/0x190) from [] (mount_block_root+0x160/0x214)
[    4.194061] [] (mount_block_root+0x160/0x214) from [] (mount_root+0xa8/0xc4)
[    4.203338] [] (mount_root+0xa8/0xc4) from [] (prepare_namespace+0x15c/0x1c0)
[    4.212707] [] (prepare_namespace+0x15c/0x1c0) from [] (kernel_init+0x150/0x194)
[    4.222381] [] (kernel_init+0x150/0x194) from [] (kernel_thread_exit+0x0/0x8)

The solution turns out to be dead simple (but I couldn't find a reference to it on the web): the rootdelay kernel parameter gives the kernel time to detect the MMC card before trying to mount it.

Now, if I can just work out how to stop Debian's "Detecting Network Hardware" stopping the installation process in its tracks, I'll be a happy man...

Why did Linux use a RISC OS SWI number, when they had 24 million to choose from?

2011-06-03T19:55:00.000+02:00

The EABI syscall interface for Linux on ARM processors uses the SWI (SoftWare Interrupt instruction) number zero as its way into supervisor mode and the kernel. Unfortunately, that instruction has been in use for more than twenty years by the operating system used by the originators of the ARM, Acorn's RISC OS.

Now, Acorn weren't against looking ahead (I like to think of their software interfaces as forward-compatible, with support for likely developments looking forward many years, or even decades). One example of this was when they defined the new ARM SWI instruction, they included these bits:

Bits 20 - 23
These are used to identify the particular operating system that the SWI expects to be in the machine. All SWIs used under RISC OS have these bits set to zero. Under RISC iX, bit 23 is set to 1 and all other bits are set to zero.

Now, Linux used to stick to this definition, using the number 9 for the OABI, but when they moved to EABI, the operating system bits were quietly dropped and SWI 0 (RISC OS's OS_WriteC - "Writes a character to all of the active output streams") was used.

Now, this has become a bit of a headache for me, because I'm trying to get Linux to run RISC OS programs using the ROLF compatibility library, which provides native Linux implementations for many RISC OS system calls. What I want is for the kernel to signal the application when a SWI is encountered in RISC OS code so that the ROLF routines can be executed in user space and the application (or module) can continue on its merry way.

There are a few ways to approach this:

Check the personality of the process for each SWI executed
Redefine the EABI to insist on SWI 0x009fxxxx as the kernel entry SWI (and treat all other SWIs as an illegal instruction or use a special signal code)
Make OABI the standard interface
Use a similar mechanism to the x86 emulator to generate Linux code from the RISC OS code, which won't execute any RISC OS SWIs
Make the personality implementation more object-oriented and allow each process to determine how it should handle SWIs, Unknown instructions, data aborts, etc.

Option 1 will work, but will slow down all system calls even more than just moving back to OABI.

Option 2 will make some existing programs incompatible with the kernel, although not if they just use libc to make system calls, or are recompiled against a new unistd.h.

Option 3 would be a step backward for Linux (and support will probably be phased out over time). Also, it suffers from the same incompatibilities as option 2.

Option 4 will be fully compatible and would allow running of old 26-bit applications but would be much more work and probably quite a lot slower.

Option 5 would be cool, but probably too high impact.

Jan Rinze likes 1, I prefer 2, but I'll probably go with whichever produces a working solution first!

Building on Angstrom on a BeagleBoard

2011-05-22T00:37:00.002+02:00

Update: Anonymous says all I needed to do was: opkg install task-native-sdk, thanks!

These are some quick notes that I intend to update when I have (a) time, and/or (b) a working build.

Tha Angstrom distribution doesn't include a native toolchain (it's meant to be light-weight, so that's OK). It does, however, mean you need to use the opkg package manager a lot.

First try:
"opkg install gcc"... This works.
"gcc x.c"... command not found - what?

"opkg install gcc-symlinks"... Ah! gcc now exists!

Here's part of today's bash history:

87 opkg install gcc

88 opkg install gcc

93 opkg install binutils binutils-symlinks cpp cpp-symlinks

95 opkg install libc-6

96 opkg install libc6-dev

107 opkg install libmagic

109 opkg install libmagic-dev

110 opkg install file

111 opkg install file-dev

115 opkg install ccache

117 opkg install install

118 opkg install libtool-symlink

119 opkg install libtool-symlinks

121 opkg install coreutils

128 opkg install freetype2-dev

129 opkg install freetype-dbg

131 opkg install freetype-dbg

147 opkg install libjpeg-dev

148 opkg install libpng-dev

152 opkg install pkg-config

154 opkg install pkg-config

174 opkg install eval

195 opkg install bash

215 opkg install stl

218 opkg install c++

221 opkg install g++ g++-symlinks

223 opkg install libstdc++-dev

Some worked, some didn't. But I think the combination of all of them has given me enough programs and libraries to build ROLF without RISC OS compatibility.

I also had to set up these symbolic links for libraries:

ln -s libfreetype.so.6 /usr/lib/libfreetype.so

ln -s /lib/libgcc_s.so.1 /lib/libgcc_s.so

As the applications were supposed to be linked, there was a problem with libtool; the generated static libraries contained only the text "! < a r c h >" (without the spaces), which turned out to be because the /bin/sh link was to /bin/busybox, not /bin/bash (which was already installed). For search engines: there were several lines like: "eval: 1: libtool_args+=: not found".

ln -sf bash /bin/sh

I've noticed you can get a tarball of rolf code using the following URL (which means you don't have to install SVN to build it):

http://ro-lf.svn.sourceforge.net/viewvc/ro-lf/ROLF/rolf/?view=tar

The code needs modifying to get it to build, including removing the agp specific code and also the compatibility library, for the time being. The signal handlers in the compatibiity code need modifying to cope with ARM registers, rather than x86. Also, run_arm_code, and similar routines should be replacable with a simple jump to the code - a kernel patch by Jan Rinze will provide a signal on non-Linux system calls, allowing the compatibilty library to handle RISC OS system calls in-process.

I'm really hoping we can get this to work!

Building on and for Knoppix II

2011-01-27T19:08:00.000+01:00

Updated with some corrections from last time.

The Knoppix Live CD (http://knopper.net/knoppix/) is an excellent way to try out Linux on any PC with a CD-ROM drive. It won't store anything on your PC (unless you ask it to) and doesn't mess up any existing installations of Linux or Windows.

In this article, I'm going to describe how to build ROLF to run on Linux assuming a PC booted from an unmodified Knoppix 6.2 CD.

When done, you should have a working ROLF desktop being displayed in a window, able to run a few native ROLF programs and even some RISC OS programs, in a limited way. Simply by copying the directory into which you've installed ROLF to some permanent storage (a hard disc or a memory stick, for example), you can use the build again without having to go through the steps I describe.

Set up a build environment

Knoppix, unfortunately, doesn't include all the tools needed to build ROLF, so we have to get them from Debian first. (If your Linux system already includes these tools, you can obviously skip this step.)

First, get the full list of packages that are available:

sudo apt-get update

Then update the compiler to include the C++ compiler, needed to build the Server part of ROLF (the libraries are all plain C, but to build them, you need libtool).

sudo apt-get install build-essentials
sudo apt-get install subversion
sudo apt-get install libtool
sudo apt-get install pkg-config

After that has been done, the compiler will still refuse to compile C++ programs because it can't find cc1plus, for some reason. The simplest way to fix that is to add the path to the (just installed) cc1plus file installed to the PATH environment variable.

export PATH=$PATH:$(dirname $(find /usr/ -name cc1plus 2>/dev/null | head -n 1))

Now, to get the source code:

svn co https://ro-lf.svn.sourceforge.net/svnroot/ro-lf/ROLF/rolf

(If you don't expect to make any changes to the code, you can instead use:
svn export https://ro-lf.svn.sourceforge.net/svnroot/ro-lf/ROLF/rolf)

Change directory into the downloaded code and run configure (not as complicated as a normal configure script):

cd rolf
./configure --appsdir=$(pwd)/Apps --prefix=$(pwd) --tarballs=$(pwd)/tarballs/

Knoppix (or Debian) have all their shared libraries taged by their version number; to make the files linkable, we need to do this:

mkdir lib
ln -s /usr/lib/libz.so.1 lib/libz.so
ln -s /usr/lib/libjpeg.so.62 lib/libjpeg.so
ln -s /usr/lib/libpng12.so.0 lib/libpng.so
ln -s /usr/lib/libfreetype.so.6 lib/libfreetype.so
ln -s /usr/lib/libstdc++.so.6 lib/libstdc++.so
ln -s /usr/lib/libmagic.so.1 lib/libmagic.so

Similarly, the build requires a set of include files [This bit needs an update!]

Specifically, the files needed are:

From zlib:
zlib.h, zconf.h

From libpng:
png.h, pngconf.h

From file:
magic.h

From libjpeg
jpeglib.h, jmorecfg.h, jconfig.h

From freetype 2:
./ft2build.h
./freetype/internal/internal.h
./freetype/fttypes.h
./freetype/ftsystem.h
./freetype/ftmoderr.h
./freetype/ftimage.h
./freetype/fterrors.h
./freetype/fterrdef.h
./freetype/freetype.h
./freetype/config
./freetype/config/ftheader.h
./freetype/config/ftconfig.h
./freetype/config/ftstdlib.h
./freetype/config/ftoption.h

Update the config.mak file created by configure to point at the libraries and includes:

sed -i 's/CFLAGS.*$/& -L$(CFGDIR)\/lib/' config.mak
sed -i 's/CFLAGS.*$/& -I$(CFGDIR)\/my_includes/' config.mak

Now you should be able to build ROLF:

make

Assuming all goes well with the build, the next step is to collect the resources needed in one place.

You will need:

Fonts (at least FreeSerif.ttf; the default font)
Tool and Icon sprites (I use Chris Wraight's Steel theme, from here: http://www.lym.iconbar.com/downloads/steel.zip)
A mimemap.txt file (if you're going to use RISC OS software)
and a !Boot file, to load them all (like the one below)

Create a resources directory with subdirectories:
mkdir -p Resources/fonts/{FreeSerif,FreeSans,FreeMono}
ln -s /usr/share/file/ Resources/
cd Resources/fonts
for i in *; do for f in $( find /KNOPPIX/ -name $i*.ttf ); do ln -s $f $i/ ; done ; done 2>/dev/null
# This one is needed for the Terminal application:
cp `find /KNOPPIX/ -name default8x16.psf* 2> /dev/null` .
cd .. # Resources
unzip steel.zip
cd ..
cat > \!Boot <<"EOF"
IconSprites $ROLF_RESOURCES/Steel/Tools
IconSprites $ROLF_RESOURCES/Steel/Icons
LoadPointer $ROLF_RESOURCES/Steel/Icons ptr_default 0 21
LoadPointer $ROLF_RESOURCES/Steel/Icons ptr_double 0 21
# Match up icons with the appropriate mime types
if [ -f $ROLF_RESOURCES/mimemap.txt ] ; then ( grep -v ^# $ROLF_RESOURCES/mimemap.txt | tr -s '\t' | cut -f 1,3 | sort -k 2 | sed 's/$.*$\t$.*$$/IconSprite file_\2 "file_\1"/' | sh ) ; fi
# Load applications
IconBar
Filer Icon $(dirname $0)/Apps 50 romapps Apps
Filer Icon /tmp 40 ramfs ramfs
Filer Icon $HOME 45 homedisc Home
EOF

Now, we just have to run it!

export LD_LIBRARY_PATH=`pwd`/lib
export PATH=$PATH:`pwd`/bin
#Uncomment the next line if you need a log of what's happened (useful for debugging)
# ROLF_WIMP_LOG=/tmp/rolf_wimp_log \
ROLF_RESOURCES=`pwd`/Resources \
ROLF_VNC=800x600:2008 \
Wimp

That should have the effect of printing:
VNC Server waiting for connections on port 2008.
New file descriptor 3
New Opaque bitmap VNCFrameBuffer, 800x600

In another terminal window, type:

vncviewer localhost:2008

... and a colourful window with an icon bar and a couple of drive icons should appear!

Progress, with a Video!

2011-01-26T18:27:00.002+01:00

A couple of bugs have been chased down, so, just for fun, I thought I'd try and make a screen capture video of the state of the emulator.

At first I tried to use recordmydesktop, but that doesn't seem to play nice with the compiz window manager. So, I found a nice, uncomplicated, picture format (TGA) and modified the user interface to write a screenshot to a file ten times a second (albeit upside down). The user interface, incidentally, is a separate process from the emulator and accesses the files that contain the memory of the emulated RPC directly, much like a real VIDC chip.

Using mencoder, I produced the following video; it's probably best to watch it in fast-forward since it takes 40 seconds to get to the desktop and I'm not the fastest typer, either!

The upload to Blogger seems to have scaled it down 50% and reduced the quality considerably, though. The screen looks a lot better than that in use.

The command line I used to generate the movie was this:
mencoder mf://*.tga -mf w=640:h=480:fps=10:type=tga -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell -o /tmp/screen_cap.mpg -flip

I don't much like C++

2011-01-24T19:45:00.001+01:00

I came across this statement today which neatly sums up my experience:

"After 15 years programming in C++, I was surprised to discover today that..."

Programs are running, for a while at least.

2011-01-18T12:10:00.004+01:00

The stand-alone RPC emulator has taken a couple of steps forward in the last few days.


Still some problems!

The TEQP implementation was wrongly checking the future processor mode rather than the current one, to see which flags should be affected.

Once that was fixed, the next problem was dealing with pre-fetch aborts, where the ARM code scanner caused a segmentation violation reading the memory where code would be mapped in by the OS's lazy address decoding.

There are still problems with caching (see picture); I've missed something that should be clearing the instruction cache between task swaps...

In addition to stability, I need to:

Write a module to handle the mouse input (I've done a hack to intercept OS_Mouse calls, but the RO pointer doesn't move with it, just changes shape while staying motionless). The X interface passes on absolute coordinates, like a tablet, rather than relative movement, like a mouse.
Sort out keyboard input (it's a bit hit and miss if a keypress appears when you're typing quickly); I think RISC OS is debouncing the input, so modifying the timing of keyboard events might sort that out.
Intercept more SWIs; networking ones might be a good start.
More graphics modes (limited currently to 640x480x256), maybe change the RISC OS mode when resizing the X window.

What ROLF gets from all this

When it works, ROLF should gain:

a bit of publicity
a test platform for running RISC OS programs under ROLF (I'll be able to examine the behaviour of SWIs under RISC OS when implementing them in the compatibility layer
an X windows front end for a variation on the ROLF Wimp server which will make use of the work done on graphic card acceleration to display the frame buffer (while still remaining compatible with simple frame buffer implementations)

Stalled for months!

2010-12-11T12:58:00.004+01:00

[Updated below; some progress!]
[Updated again, lots more progress!]

I've been struggling with the RPC emulator over the last few weeks.

The main problem is accessing a hard disc image. Initially, I intercepted the calls from FileCore to ADFS in order to read (what I thought were) the appropriate areas of the disc image file, but what I returned wasn't accepted by FileCore. Then I tried another track; I integrated the files ide.c, fdc.c and superio.c from RPCEmu to provide the emulation of the fdc37c665 component. This is the result when using the hd4.hdf and cmos.ram from http://b-em.bbcmicro.com/arculator/hdboot.zip (the emulator now has a VNC based front-end that provides keyboard entry):

The output I get from the ide.c file (with the addition of the data read from the file) is as follows:

IDE: First check - spt 63 hpc 16
IDE: Write IDE 000003F6 00 039C0A2C 02107CF4
IDE: Read IDE 000003F6 039C2028 00000000
IDE: Write IDE 000001F6 A0 039C1FEC 02107CF4
IDE: Read IDE 000003F6 039C1FF8 00000000
Callback IDE = 200
IDE: Read IDE 000003F6 039C1B88 00000200
IDE: Write IDE 000001F6 A0 039C1BA0 02107CF4
IDE: Read IDE 000003F6 039C1BB4 00000200
IDE: Write IDE 000001F1 00 039C1BD0 02107CF4
IDE: Write IDE 000001F2 01 039C1BD8 02107CF4
IDE: Write IDE 000001F3 07 039C1BE0 02107CF4
IDE: Write IDE 000001F4 00 039C1BE8 02107CF4
IDE: Write IDE 000001F5 00 039C1BF0 02107CF4
IDE: Write IDE 000001F6 A0 039C1BF8 02107CF4
IDE: Write IDE 000001F7 20 039C1BFC 02107CF4
IDE: New IDE command - 20 0 0 039C1BFC
IDE: Read 1 sectors from sector 7 cylinder 0 head 0
IDE: Read 0 0 7 00000E00
IDE: Read sector callback 7 0 0 offset 00000E00 0 left 1
IDE: Read data:  00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 01 00 80 13 03    ................
IDE: Read data:  09 3f 10 00 0d 09 00 00 01 1a 68 00 35 02 00 00    .?........h.5...
IDE: Read data:  00 60 1b 03 00 00 00 00 00 00 00 00 00 00 00 00    .`..............
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
IDE: Read data:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 5f    ..............._
IDE: Read IDE 000001F7 039C17B8 00000002
IDE: Over! packlen 0 512
IDE: Read IDE 000003F6 039C1B88 00000002
IDE: Write IDE 000001F6 AF 039C1BA0 02107CF4
IDE: Read IDE 000003F6 039C1BB4 00000002
IDE: Write IDE 000001F1 00 039C1BD0 02107CF4
IDE: Write IDE 000001F2 3F 039C1BD8 02107CF4
IDE: Write IDE 000001F3 07 039C1BE0 02107CF4
IDE: Write IDE 000001F4 00 039C1BE8 02107CF4
IDE: Write IDE 000001F5 00 039C1BF0 02107CF4
IDE: Write IDE 000001F6 AF 039C1BF8 02107CF4
IDE: Write IDE 000001F7 91 039C1BFC 02107CF4
IDE: New IDE command - 91 0 0 039C1BFC
IDE: Read IDE 000001F7 039C1F84 00000002
c2107f08 00000041 00000006 01c07a90 000001f4 021086ac Callback IDE = 200
IDE: -1338894612 sectors per track, -1338894596 heads per cylinder
IDE: Read IDE 000003F6 039C1B88 00000002
IDE: Write IDE 000001F6 AF 039C1BA0 02107CF4
IDE: Read IDE 000003F6 039C1BB4 00000002
IDE: Write IDE 000001F1 00 039C1BD0 02107CF4
IDE: Write IDE 000001F2 3F 039C1BD8 02107CF4
IDE: Write IDE 000001F3 07 039C1BE0 02107CF4
IDE: Write IDE 000001F4 00 039C1BE8 02107CF4
IDE: Write IDE 000001F5 00 039C1BF0 02107CF4
IDE: Write IDE 000001F6 AF 039C1BF8 02107CF4
IDE: Write IDE 000001F7 91 039C1BFC 02107CF4
IDE: New IDE command - 91 0 0 039C1BFC
IDE: Read IDE 000001F7 039C1F84 00000002
Callback IDE = 200
IDE: -1338894612 sectors per track, -1338894596 heads per cylinder

Some differences in my use of the RPCEmu code are:

callbackide is called on the next tick event, ignoring the value of (non-zero) idecallback.
No DMA implemented

Any bright ideas?

Update:

Thanks to Tom Walker pointing out (on stardot) that the error reported by RISC OS is a floppy disc error, not a hard disc one, I noticed that I wasn't making callbacks required by the fdc.c floppy disc emulation. Now, I have a nice new error to worry about!

Update 2: Not so much to worry about, after all. That one turns out to be because my emulation of post-increment LDR wasn't storing the calculated base+offset value into the base register. That's the first bug I've found in the basic emulate-ARM-instructions part of the emulator for a long time, but at least it's just a two line fix.

Emulator progress on RO 4.02

2010-10-15T22:01:00.000+02:00

Using the ROLF Emulator to run RISC OS

2010-09-28T18:40:00.006+02:00

Updated below.

I've been working on getting RISC OS 4.02 running using the ARM emulator from ROLF.

This was initially prompted by a near death experience of my Risc PC, and also a desire to see how well it would do.

Also, many years ago, I suggested an approach to getting RO available on (then-current and 26-bit mode supporting) ARM based computers.

It was quite simple:
1. Identify what the OS absolutely needed from the hardware to be able to run (I guessed memory, one or two timers and some form of static memory, as provided by the CMOS RAM in the RPC)

2. Get the hardware manufacturers to provide some startup code to get that hardware running and enter the OS with information about where the RAM/ROM is and a set of pointers to routines to provide each of the required functions.

3. At a certain point in the boot process, the hardware manufacturers could start modules to handle other aspects of their computer.

It looks, so far, like that approach would have worked. (And, of course, getting the hardware manufacturers to work on the low level aspects would have had the advantage of hugely increasing the number of engineers working on getting the OS to market, at no cost to ROL.)

The speed of running the ArtWorks Renderer module on some complex images under the emulator show a speed of approximately 3-4 times that of a 200MHz StrongARM Risc PC. (i.e. celtic_knot3 renders in about 14s, as opposed to nearly a minute on the RPC). There's still some considerable scope for improvements in the code generated by the emulator.

As far as I can tell from reading about RPCEmu (I've had difficulties installing it, and not yet suceeded), the speed compares quite well.

The main difference, I think, is that ROLF uses the Linux process' memory to provide the emulated RISC OS task with no address translation required. With a single RISC OS Task (process) that is very easy, since memory doesn't have to be switched in and out, as is the case with the whole OS.

The approach I've taken is to use some special link parameters to keep the Linux process's memory in an area of the memory map which RISC OS doesn't use. Then, a set of files for ROM, RAM and VRAM are mapped in and out of memory as required by the OS using mmap (this is the part that could turn out to be horrendously slow).

Also, I've avoided emulating hardware outside the processor (so it's not really a RiscPC emulator) and chosen to patch some sections of RISC OS with native code. This is an ugly approach, but it has the advantage of being quick and easy as well as identifying those essential hardware elements I was talking about. Longer term it should be possible to integrate RPCEmu's hardware emulation routines (both products are GPL licenced).

Update:
It seems I've found a problem with Linux. The emulator, when it's producing a lot of debug output, tends to hang in a futex system call. This happens with the shared C library, the static equivalent that came with Knoppix and a specially compiled static glibc-2.5.1. Kernel 2.6.32.6.

The other problem is with RISC OS; the routine TranslateMonitorLeadType (which I will be replacing with native code, but that's not the point) makes an XOS_ServiceCall, which causes a jump to zero. I'll look into that before I try to work out the Linux Kernel.

Update 2: It seems the ROM files were corrupted somehow.

Update 3: Yes, there really is a problem with Linux. The following program will hang, sooner or later, on my system. It's easiest to see if you pipe the output into "grep -n Tick". It is probably related to this.


#include <signal.h>
#include <stdio.h>
#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/time.h>

#include <stdint.h>

static void alrm_action( int code, siginfo_t *info, void *p )
{
    fprintf( stderr, "Tick" );
}

int main()
{
    struct sigaction action = { .sa_sigaction = alrm_action, .sa_flags = SA_SIGINFO };
    sigaction( SIGALRM, &action, 0 );

    int microseconds = 10000; // 1cs

    struct itimerval timer_val = { 
        .it_interval = { .tv_sec = microseconds / 1000000, .tv_usec = microseconds % 1000000 },
        .it_value = { .tv_sec = microseconds / 1000000, .tv_usec = microseconds % 1000000 },
    };
    struct itimerval old_val;

    setitimer( ITIMER_REAL, &timer_val, &old_val );

    int x = 0;
    while (1) {
        fprintf( stderr, "+" );
        if (x-- == 0)
        {
            fprintf( stderr, "\n" );
            x = 100;
        }
    }

    return 0;
}

Update 3: It's not a problem with Linux, fortunately. This document lists 118 functions "that shall be either reentrant or non-interruptible by signals and shall be async-signal-safe"; printf variations are not included.

Famous last words (Updated)

2010-06-18T09:46:00.005+02:00

"I could probably build you a standalone program to execute non-WIMP programs; it wouldn't even need to run the ROLF server."

Well, it worked to an extent, but as always when you think something won't take long, something always crops up.

I've successfully got to the point where I can get squeeze ("squeeze vsn 5.00 [Jan 11 1995] - compress an executable ARM-code program", plus SharedCLibrary and Messages modules from RO4) to compress a NetSurf !RunImage file, resulting in a identical file to one generated by the same utility on RO4. But, the RMA has to be located low in memory, for it to work! It has to be under the 16MB boundary, which is considerably below where it is in a real RISC OS system.

The possibilities I see at the moment are:
On real RISC OS, the shared C library mallocs from the WimpSlot rather than RMA.
I've got a problem with my implementation of the ARM emulator when it comes to shifts or overflows (the crash seems to appear when the most significant bytes of the malloc'd address is non-zero).

Update: It seems (http://www.iconbar.com/forums/viewthread.php?threadid=11447&page=1#114647) that the former is correct, and, on examining the emulator debug output, I notice that the library checks if it was called from SVC or USR mode and behaves appropriately. Unfortunately, the program never drops back into USR mode after a OS_EnterOS SWI, which is probably the problem.

Update 2: The culprit was that I hadn't emulated TEQP correctly for 26-bit mode. Since TEQ is a data processing operation with no destination, I'd simply ignored the destination part of the opcode; unfortunately it has a special meaning in 26-bit mode when the destination is 15 (the PC), and changes the processor mode. It's working much better now.

A non-graphical OSCLI

2010-06-08T20:58:00.006+02:00

(Updated because the previous version wouldn't run without a running ROLF server.)
(Updated again, Wed 9 June 2010, because of a bug in the interpreter, now built from revision 81.)

I've just put a Linux x86 executable to run command line RISC OS programs here (48785 bytes, md5sum 72db2104a71d0f2c5527dae1b0597fe3 ~~48843 bytes, md5sum 5deb778bdbb5e7e1eef06fbc358f8bf8~~).

command_line_oscli is released under the GPL version 2.

To get it to run usefully, you will need a file called mimemap.txt containing at least the following three lines, in a directory whose name is stored in the environment variable
ROLF_RESOURCES:

application/x-riscos-absolute           Absolute        ff8     .ff8    .abs
application/x-riscos-module             RelocatableModule       ffa     .ffa
application/x-riscosobey                Obey            feb     .oby    .feb

RISC OS applications and modules will have to be "filetyped" appropriately by creating a hidden symbolic link to the mime type for the file named .filename,type

e.g.

ln -s application/x-riscos-module .SharedCLibrary,type

The source is available as revision 80 81 of the ro-lf project on
http://sourceforge.net/projects/ro-lf/develop.

The build command was:

gcc -DNO_DISASSEMBLE -DNO_GRAPHICS -DNO_FPE Libs/Compatibility/arm_emulator.c \
Libs/Compatibility/compatibility_switch.c External/Compatibility/oscli.c \
Libs/Environment/*.c -I Libs/Environment/includes/ -I Libs/Compatibility/includes/ \
-o command_line_oscli -std=gnu99 -lmagic

If Floating Point Emulation is needed, try not defining NO_FPE and including some more of the files from the Libs/Compatibility directory.

All the testing I've done was to run unmodsqz from !SqzUnSqz/Abs on CLib from the ROOL website and look to see that the file size had changed.

ln -s application/x-riscos-module .CLib,type
ln -s application/x-riscos-absolute .unmodsqz,type
( echo rmload .home.knoppix.Apps.\!Compatibility.SharedCLibrary
  echo run unmodsqz CLib ) | ./command_line_oscli

There's quite a lot of debug output to stderr (try 2> /dev/null) and the test ends with "Should do a handler function here", which means an unexpected SEGV trap was caught, but that's after the program has run.

ArtWorks Renderer

2010-05-31T20:05:00.003+02:00

The ARM emulator is now working with 26-bit code as well as 32-bit (although it would be a bad idea to mix them in the same process) and is capable of executing the free renderer for ArtWorks files. Unfortunately, it seems to be a little slower than the pure 32-bit version was but there's plenty of room for optimisation.

The Viewer window title bar shows the time taken to render the file (actually, the whole ArtWorks file is rendered and copied into a bitmap that is displayed by the Viewer application). The computer is a dual core with about 5000 BogoMIPs per core (the emulator only uses one core, of course). No modules from RISC OS are needed to run Viewer with AWRender.

Building on and for Knoppix

2010-05-29T14:50:00.003+02:00

The Knoppix Live CD (http://knopper.net/knoppix/) is an excellent way to try out Linux on any PC with a CD-ROM drive. It won't store anything on your PC (unless you ask it to) and doesn't mess up any existing installations of Linux or Windows.

In this article, I'm going to describe how to build ROLF to run on Linux assuming a PC booted from an unmodified Knoppix 6.2 CD.

When done, you should have a working ROLF desktop being displayed in a window, able to run a few native ROLF programs and even some RISC OS programs, in a limited way. Simply by copying the directory into which you've installed ROLF to some permanent storage (a hard disc or a memory stick, for example), you can use the build again without having to go through the steps I describe.

Set up a build environment

Knoppix, unfortunately, doesn't include all the tools needed to build ROLF, so we have to get them from Debian first. (If your Linux system already includes these tools, you can obviously skip this step.)

First, get the full list of packages that are available:

sudo apt-get update

Then update the compiler to include the C++ compiler, needed to build the Server part of ROLF (the libraries are all plain C, but to build them, you need libtool).

sudo apt-get install build-essentials
sudo apt-get install subversion
sudo apt-get install libtool
sudo apt-get install pkg-config

After that has been done, the compiler will still refuse to compile C++ programs because it can't find cc1plus, for some reason. The simplest way to fix that is to add the path to the (just installed) cc1plus file installed to the PATH environment variable.

export PATH=$PATH:$(dirname $(find /ramdisk/ -name cc1plus 2>/dev/null | head -n 1))

Now, to get the source code:

svn co https://ro-lf.svn.sourceforge.net/svnroot/ro-lf ro-lf

(If you don't expect to make any changes to the code, you can instead use:
svn export https://ro-lf.svn.sourceforge.net/svnroot/ro-lf)

Knoppix (or Debian) have all their shared libraries taged by their version number; to make the files linkable, we need to do this:

mkdir lib
ln -s /usr/lib/libz.so.1 lib/libz.so
ln -s /usr/lib/libjpeg.so.62 lib/libjpeg.so
ln -s /usr/lib/libpng12.so.0 lib/libpng.so
ln -s /usr/lib/libfreetype.so.6 lib/libfreetype.so
ln -s /usr/lib/libstdc++.so.6 lib/libstdc++.so
ln -s /usr/lib/libmagic.so.1 lib/libmagic.so
sed -i 's/CFLAGS.*$/& -L$(CFGDIR)/lib' config.mak

Similarly, the build requires a set of include files [This bit needs an update!]

Specifically, the files needed are:

From zlib:
zlib.h, zconf.h

From libpng:
png.h, pngconf.h

From file:
magic.h

From libjpeg
jpeglib.h, jmorecfg.h, jconfig.h

From freetype 2:
./ft2build.h
./freetype/internal/internal.h
./freetype/fttypes.h
./freetype/ftsystem.h
./freetype/ftmoderr.h
./freetype/ftimage.h
./freetype/fterrors.h
./freetype/fterrdef.h
./freetype/freetype.h
./freetype/config
./freetype/config/ftheader.h
./freetype/config/ftconfig.h
./freetype/config/ftstdlib.h
./freetype/config/ftoption.h

sed -i 's/CFLAGS.*$/& -I$(CFGDIR)/my_includes' config.mak

Change directory into the downloaded code and run configure (not as complicated as a normal configure script) and build ROLF:

cd ro-lf/ROLF/rolf
./configure --appsdir=$HOME/Apps --prefix=$HOME --tarballs=`pwd`/tarballs/
make

Assuming all goes well with the build, the next step is to collect the resources needed in one place.

You will need:

Fonts (at least FreeSerif.ttf; the default font)
Tool and Icon sprites (I use Chris Wraight's Steel theme, from here: http://www.lym.iconbar.com/downloads/steel.zip)
A mimemap.txt file (if you're going to use RISC OS software)
and a !Boot file, to load them all (like the one below)

Create a resources directory with subdirectories:

mkdir -p Resources/fonts/{FreeSerif,FreeSans,FreeMono}
ln -s /usr/share/file/ Resources/
cd Resources/fonts
for i in *; do for f in $( find /KNOPPIX/ -name $i*.ttf ); do ln -s $f $i/ ; done ; done 2>/dev/null
# This one is needed for the Terminal application:
cp `find /KNOPPIX/ -name default8x16.psf* 2> /dev/null` .
cd ..
unzip Steel.zip
cd ..
cat > \!Boot <<"EOF"
IconSprites $ROLF_RESOURCES/Steel/Tools
IconSprites $ROLF_RESOURCES/Steel/Icons

LoadPointer $ROLF_RESOURCES/Steel/Icons ptr_default 0 21
LoadPointer $ROLF_RESOURCES/Steel/Icons ptr_double 0 21

# Match up icons with the appropriate mime types
if [ -f $ROLF_RESOURCES/mimemap.txt ] ; then ( grep -v ^# $ROLF_RESOURCES/mimemap.txt | tr -s '\t' | cut -f 1,3 | sort -k 2 | sed 's/$.*$\t$.*$$/IconSprite file_\2 "file_\1"/' | sh ) ; fi

# Load applications
IconBar
Filer Icon $HOME/Apps 50 romapps Apps
Filer Icon /tmp 40 ramfs ramfs
Filer Icon $HOME 45 homedisc Home
EOF

Now, we just have to run it!

export LD_LIBRARY_PATH=`pwd`/lib
export PATH=$PATH:`pwd`/bin

#Uncomment the next line if you need a log of what's happened (useful for debugging)
# ROLF_WIMP_LOG=/tmp/rolf_wimp_log \
ROLF_RESOURCES=`pwd`/Resources \
ROLF_VNC=1 \
Wimp

That should have the effect of printing:
VNC Server waiting for connections on port 2008.
New file descriptor 3
New Opaque bitmap VNCFrameBuffer, 1024x768

In another terminal window, type:

vncviewer localhost:2008

... and a colourful window with an icon bar and a couple of drive icons should appear!

I will follow this up with some more postings about running RISC OS software on ROLF, as well as implementations of NetSurf and MPlayer.

Emulator speedups

2010-05-22T22:03:00.004+02:00

The other day I noticed that it took AWRender nearly fifty seconds to render the file celtic_knot3 from here, and I thought that was too long, so I decided to get around to speeding up the emulator. (Had I first tried it on my SARPC, I'd have found that it took 55 seconds on there, so it wasn't really too slow.)

The first step was to disable all the debug output from the compatibility library; that halved the rendering time to a shade over 24s. I found that rather disappointing; I was expecting the debug output to take up at least two-thirds of the time.

I turned on optimisation in the library compilation, -O4 reduced the render time to under 18s.

Two optimisation suggestions from Jake Waskett were to ensure that jump targets were on 16-byte boundaries and to fix up calls to scan from a fixed location and jump to the returned call so that on the second attempt, there wouldn't be a relatively expensive scan call. The former shaved about 0.1s off the render time, but the latter gave a significant improvement, taking the render time down to just over 15s.

During all this, I noticed the SETcc operations and realised that I could use SETO %al ; LAHF to get all the necessary x86 flags into %ax (previously, I'd been using pushf/popf). Of course, when I googled for that combination I found a description of someone writing an ARM JIT compiler using pushf, with a comment recommending the seto/lahf combination; it's all about knowing what to look for! Anyway, once the flags are in %ax, it's fairly easy to get the four flags we want into the bottom nibble of %al by rotating %ah, masking and or'ing with %al: ( ror $3, %ah ; and $0xe, %ah ; or %ah, %al ). The flags aren't in the same order used by ARM, but a 16-byte lookup table can translate between the two in one instruction.

Obviously, there are more flag reads than flag writes (there's no point in setting the flags if they aren't going to be read at least once), so I added a new global variable to be set at the same time the flags were which contains a 16 entry bitmap, one for each condition code (EQ, NE, GT, etc.), so that a conditional instruction just has to test a known bit in a known variable and use the ZF to behave appropriately.

That change was fairly major (but only affected three files), and takes the render time down to 13 seconds.

Next thing to try was to eliminate the extra code for each load or store that checks for non-aligned accesses. The idea is to set the x86 flag that causes a SIGBUS signal to be generated for unaligned accesses and load the registers as necessary before moving on to the next instruction. Unaligned accesses in ARM code will probably be relatively rare and the speedup in the normal memory accesses should more than make up for the slower signal handling. Since the only routines called from emulated ARM code are scan_arm_code and (when debugging is enabled) dump_regs), those routines would reset the flag on entry and restore its state on exit.

That "optimisation" slowed the render time down to 15s again.

Since the only unaligned access from scan_arm_code is likely to be when setting a 32-bit constant in an instruction, I stopped manipulating the flag in scan_arm_code and tried modifying cache_32bit to write its four bytes one at a time, instead, and the time improved again to a little over 12s. However, the code I was testing didn't include any unaligned accesses, and since I hadn't written the signal handler anyway, I've decided to call it a day for the time being and leave that optimisation out.

Future optimisation possibilities:
finish the SIGBUS solution
Improve the hash table lookup
Use mov $constant,arm_emulator_regs[n] for constant loads into registers
Combine consecutive ARM instructions that load a constant into a register
Remember if the flags (or a register's contents) are stored in a register from last time.

All of these things have a chance of making the scan_arm_code routine slower and negating their speed improvements, but they're probably worth a try.

The other thing to do is to profile the ARM code somewhat by generating code to increment counters when, for example, flags are set, flags are read, scan_arm_code and get_hash_entry are called, etc. At the moment, I notice that a sequence of ARM instructions leading up to a decision point (conditional jump, swi, etc.) is rarely much more than ten instructions.

The instruction emulator file stands at 1761 lines (55158 bytes).

Edit partially working

2010-02-22T14:43:00.002+01:00

The compatibility layer is coming on nicely, to the extent that the !Edit application binary from ROOL will run, load a file and allow its editing (but not saving).

Before I go any further on that, I intend to start dropping all use of the original window api (in furniture.h) in favour of the newer and much more flexible composite_window interface.

I'd spent a lot of time trying to think of a good way to describe complex windows with multiple panes, toolbars, combined status and scroll bars, etc. In the end, I decided to avoid any descriptive mechanism in favour of providing a toolbox of useful widgets to be combined programmatically. The idea is that, as long as they are flexible enough, a descriptive system (textual, or data structure based) can be added later by simply writing an interpreter layer.

I'm not likely to get very much done in the next month (just like most months, unfortunately), but that's where I plan to focus when I get a chance. Once the compatibility library starts using that mechanism, I can go back to implementing more RO system calls until I can get some proper applications running.

I'll try to add a screenshot in the next day or so.

RISC OS Compatibility Revisited

2010-01-05T20:01:00.002+01:00

Today, I managed to get a Public Domain RISC OS program that uses the shared C library to run.

The application is unmodsqz from !SqzUnSqz (www.martinkd.freeuk.com/unsqueeze.html), which unsqueezes relocatable modules.

Unfortunately, it was a rather circular problem, because the shared C library is squeezed and thus not directly supported by the compatibility library (which can be thought of as being a bit like WINE, but for RISC OS). The solution I used was to unsqueeze the CLib module on an existing RO computer, a better one is probably to use the Graham Shaw's open source (GPL) library from RiscPkg.

Anyway, the biggest problem was with the library accessing zero page (the bottom 4k of RAM), because it appears that it can't be mmap'd into memory on x86 Linux. The solution I've used is just to catch SEGV events and interpret the x86 instruction accessing the memory. That was a lot easier than I thought (especially as I only had to deal with x86 instructions generated by the ARM emulator code), and gave me some experience of recovering from signals. A similar approach could be fairly easily used for non-word-aligned memory accesses and reduce the code generated by the emulator and, no doubt, speed up emulated code significantly.

I've tried to get a few of the applications from the ROOL site to run, but without success; a lot more SWIs need to be implemented. One thing I noticed was that Edit uses UpCall 6 (no UpCalls are supported at the moment, the SWI just pretends to work), and that could be something like ROLF's Detatch mechanism - needs looking into.

Problems with a new PC

2009-09-08T12:46:00.002+02:00

I got myself a new PC today, an Acer Aspire L5100 with 4GB RAM and 640GB SATA hard disc.

Unfortunately, neither my Live CD nor some (relatively old) knoppix or SUSE discs that I tried could see either disc drive.

I'm sure I can rectify the situation, but I thought I'd mention it in case anyone tries the ISO image on a similar machine.

What now?

2009-08-14T17:24:00.002+02:00

I've not done anything on ROLF for a few weeks; I've been on holiday. Just before I left, I put the source up on SourceForge, but I didn't advertise it because I didn't have a chance to help anyone crazy enough to try to get it to work. I should have some time now, though.

The code can be accessed by the following command:

svn checkout https://ro-lf.svn.sourceforge.net/svnroot/ro-lf/ROLF/rolf

There are quite a few areas I'd like to tidy up and debug, but I wondered if anyone had a preference for where I should focus. Some possibilities are:

Create and upload a 25-30MB iso image for people to try out.

Continue working on getting an ARM kernel and build to run on a BeagleBoard.

Speed up the ARM emulator.

Improve the ROLF frontend to NetSurf.

Improve the ROLF frontend to MPlayer.

Get a VNC-based version of ROLF to run on a Nokia 770 (not really a practical platform, in general).

Comments/requests?

What's working

2009-07-01T13:22:00.003+02:00

In the screenshot below, you can see the following:

Two NetSurf windows (without any toolbar and with the status in the title bar).

A terminal window running a modified Brandy, the BASIC interpreter, with SYS calls available. The ROOL BASIC will also run, once decompressed, on the ARM emulator, which has the advantage of an inline assembler but the disadvantage of not being released under a free licence.

A native image viewer application, displaying an ArtWorks image rendered using the AWRender module.

A movie running on MPlayer.

And, of course, the Icon Bar and Filer windows.

All of the applications need a good deal of polishing up, but I'm quite happy with the state of the ARM emulation, which is good enough to run two quite demanding pieces of software (AWRender and BASIC105), and the SWI support is easily extendable. The emulator could be faster (it takes about 10 seconds to render the ArtWorks StartUp file, where my RPC takes 3-4s), but there are several ways to achieve that.

Some progress on the emulator

2009-06-01T01:50:00.004+02:00

I've been working on the emulator, trying to get the ArtWorks file viewer AWViewer running on an x86 computer. I finally have some progress to report!

ROLF is being viewed via VNC, and the ArtWorks StartUp file is being displayed entirely using the AWRender module, called from AWViewer.!RunImage running on ROOL's BASIC105.

The blue border is due to some debug code (clearing the area to be redrawn to blue), the title of the window is not taken from the CreateWindow request, and the green text is because the font code needs some more work. There's still a long way to go, but it's a significant step forward.

Update:
The size of the text is due to the font manager being told that the screen is 90dpi, but ArtWorks expects 180dpi (because that's what my software tells it).

There's no transparency in the image (the droplets of water should be transparent), which, I'm told, was due to the renderer not being able to get dynamic areas properly. I've fixed the dynamic areas, but now I have to work on allowing the code to redirect output to sprites.

Getting BBC BASIC to run on ROLF

2009-04-16T18:28:00.007+02:00

I'm trying to get the BASIC105 module from ROOL to run using the compatibility library and ARM emulator.

Downloaded the module from:
http://www.riscosopen.org/content/downloads/module-zipfiles

Next, a program to load a single Relocatable Module:


#include <stdlib.h>

#include "rolf/compatibility/compatibility.h"
#include "rolf/compatibility/arm_emulator.h"

int main( int argc, const char *argv[] )
{
    uint32_t regs[16];
    uint32_t flags;

    setenv( "RISCOS_MODULES", "BASIC105", 0 );

    // Any old SWI, the first call to riscos_swi loads and
    // initialises all the modules in RISCOS_MODULES (a
    // colon-separated list of filenames)

    riscos_swi( 0x0, regs, &flags );

    return 0;
}

First problems:

1. I haven't implemented arguments to be passed to the module on initialisation (in r10). I can fake that in gdb, for the time being.

2. The module expects to be decompressed by the operating system (the init code has bit 31 set). What algorithm does it use?

[Update]
The decompression algorithm appears to be private, so I've ripped a decompressed version from my Risc PC.

The start code assumes it has memory to use at 0x8000, so I've given it some to be going on with.

The code makes use of multiple load and store instructions which load or store the base register, which I hadn't implemented.

I believe I've fixed that, now, and with the (quick and dirty) implementation of a few OS_ SWIs (WriteS, Write0, WriteI+... and ReadLine) I've got to the point where it prompts for input, but segfaults at a strange address that's exactly 0x20000000 lower than the return address in r14. I suspect that the module requires loading in the lowest 512MB, or even lower.

[Update 2]
Yes, allocating memory around the 64MB mark means that the code runs a lot longer.

A whole lot longer; it's time to disable logging the register contents on each ARM instruction!

[Update 3]
OK, the underlying problem is that the BASIC I have is 26-bit, and I'm not implementing that (yet). The 0x20000000 offset was due to the code clearing the C flag.

On the plus side, I found a bug in the emulator where loading a byte didn't clear the top 24 bits of the register. I'll go back to trying to get AWRender to work, now that's fixed.

Beagle board

2009-02-24T12:35:00.003+01:00

A week or so ago, I got a Beagle board. So far, I've proved that it is unbrickable (by corrupting the NAND ROM and practically bricking it, then spending a couple of days and using a wide selection of computers and software to nurse it back to health).

Today I just got a self-built linux kernel to boot on it (not doing anything useful yet, though).

Once I'd got a set of working binutils and gcc (built for the arm-elf target), I got a long way, until the kernel was generating the uImage file. There were two problems.

The second, mkimage not found, was simple to fix - it comes with the u-boot code, also available here:
ftp://ftp.koansoftware.com/public/linux/mkimage

The first was heralded by the following error message:

"arm-elf-ld: ERROR: arch/arm/boot/compressed/misc.o uses VFP instructions, whereas arch/arm/boot/compressed/vmlinux does not"

It turned out the problem wasn't with arch/arm/boot/compressed/vmlinux at all (which is not surprising, since it's actually the output file), but with the head.o and piggy.o in the same directory.

The output of this command:

readelf -a arch/arm/boot/compressed/*.o | grep Flags:

included the lines:
Flags: 0x200, GNU EABI, software FP
Flags: 0x600, GNU EABI, software FP, VFP
Flags: 0x200, GNU EABI, software FP

What was needed was to re-assemble the head.S and piggy.S files with the -mfpu=vfp flag. Now, I doubt I've run any floating point code in the kernel since it's only booted up and hasn't really done anything, so it could be that I've compiled everything else wrong and it shouldn't use VFP, but that can wait for now.

Oh, I also edited drivers/video/omap/Makefile, to add the following line:

objs-y$(CONFIG_ARCH_OMAP3) += dispc.o

(I won't be able to work on anything for the next week and a half, but I'm looking forward to getting ROLF working on my TV, it's already worked with OMAP on the Nokia N800, and the VNC code points to a better solution.)

ARM emulation

2009-02-06T21:38:00.005+01:00

Yesterday, I decided to implement my own ARM code emulator.

I think my problems with getting AWRender to work have been to do with self modifying ARM code in the AWRender module. I had a half-hearted go at finding a way to implement OS_SynchroniseCodeAreas with QEMU, then I decided to just implement my own.

The interface is very simple: global storage for the registers, and a routine that returns a pointer to some x86 code that implements whatever ARM code is pointed to by r15 on entry. The x86 code will return when it comes to an instruction it can't deal with by itself, such as a SWI or a floating point operation.

The idea is to keep the emulator as the core of an ARM system, and anything else that needs emulating (like an Operating System, or a co-processor) will be taken care of outside the core. That way, I think, I can create something that can be finished!

I'm moving away from QEMU for a couple of reasons. Firstly, because it does much more than I need and it's heading off in a direction of increased complexity. For example, when I found a bug in the (latest release) version I was using, I discovered that later versions (with that bug long since fixed) don't work the same way as the one I had been working with, and I was told that, surprisingly, I didn't really want to use it that way!

Another reason is that a stripped version of the QEMU library is a little under half a megabyte in size (478568 bytes, to be specific), whereas my replacement is about 8k, at the moment, with maybe half the instruction set dealt with (bearing in mind that floating point is a co-processor feature). Perhaps I could strip QEMU down, but not that far, and not that quickly.

QEMU has given me some good ideas about how to approach the problem, but it's too bloated for my liking, now.

Update: It's going quite well.

It took me a while to work out that the x86 uses the carry flag in the opposite way to the ARM when subtracting, that jb isn't quite the same as BHI, and a day and a half to realise that I'd implemented BIC as AND instead of AND NOT.

Anyway, I'm now at the point where I have to start looking at which SWIs to emulate in order to get AWRender to, well, render something. I've chosen to attempt to get the freely available ArtWorks renderer working as a proof of concept for the compatibility layer (the whole thing isn't free, but apparently very good). Unfortunately, the application doesn't work out of the box, because the BASIC uses inline assembler and Brandy (http://sourceforge.net/projects/brandy) doesn't include that. I'll ask on comp.sys.acorn.programmer if there's an alternative that does.

Update

2008-12-10T09:12:00.002+01:00

I'm moving my code into an SVN repository, something I should have done a while ago.

I've sorted out the rather horrible looking text problem by ignoring FT2's 1/64th pixel resolution in favour of absolute millipoints. If text should fit in an inch at 12pt size, it should fit in a half inch at 6pt (and the dpi of the display should not be allowed to affect that).

NetSurf is coming along, in a horrible, hacked way!

In general, nothing to release, but still working on it.

RISC OS Compatibility

2008-10-30T10:08:00.007+01:00

The primary goal of ROLF was always to produce an operating system that provided a programming and user experience as similar to RISC OS as possible. It was never about running particular RO programs, although I had given the concept some thought.

In response to some postings on Drobe, I thought I'd have another look at the compatibility library that is intended to be used by Brandy and QEMU.

I've implemented a very few SWIs in the library and sucessfully integrated (hacked) it into Brandy (although any programs using TIME= will get out of sync with OS_ReadMonotonicClock).

I've since started looking at QEMU, and it looks promising.

The emulator code is released under the LGPL and so I should be able to integrate it into the compatibility library. That should mean that I can provide SWI decoder code that can search both native i386 routines and also Relocatable Modules from RO, which can then call i386 SWIs.

Some outstanding questions:

Should the RMA be a shared memory area? (This would allow RMs to provide inter-process communication, but opens up a whole can of worms with locking the code/memory areas.)

Can restricting RM SWI calls to when the application has a lock on the Wimp (i.e. has received a non-redraw event from the Wimp) work? (Not really, Artworks, for example would need it's RMs' routines when redrawing.)

Update: [3 Nov] After a little more work, I've got various relocatable modules initialising and executing SWIs. For simplicity, I've gone for loading all the modules in each application, no shared memory; that means that only utility-style modules will work (task modules won't at all). ARM SWIs may call native (i386) code SWIs, but they can't call ARM module provided SWIs. (Also, I haven't looked at returning flags properly, including setting the V flag on a failed exit.) For each SWI a module needs, I either have to soft-load another module or implement the SWIs natively; of course the RISC OS modules aren't freely distributable.

Update 2: [4th Nov] I made the mistake of softloading Font Manager 3.40 (17 Aug 1998), which got some distance, but then failed for what I finally worked out was a non-32bit compatible instruction (of course, it's from 1998). So, now I'll have a look at the 41 Font_ SWIs.

Update 3: [10 Nov] I've been trying to get the ArtWorks renderer module to work, with permission and documentation from Martin Wuerthner. It's an interesting interface, in that it gives you a pointer to a routine within the relocatable module for the application to call and you have to pass the address of a callback routine to the renderer, so it can request more memory (among other things). That seems to be working, in that the ARM code runs and, with the addition of two special SWIs ROLF_RunARMCode and ROLF_CallOut, native code can call the ARM routines and ARM code can call native code (i.e. C, written and compiled under x86 Linux). Unfortunately, I seem to have done something wrong and the simple AWRender_DocBounds SWI fails. I'm working on that, and on making RO applications transparently executable on Linux.

Update 4: It seems to be a bug in QEMU, and Justin Fletcher's already been there! Unfortunately, it doesn't look like his quick fix is sufficient, so it looks like I'll have to have a look at the qemu internals.

Update 5: [12 Nov] OK, I've made a patch for QEMU which seems to work, but I should test it a bit more before sending it in. I'm trying to get the ArtWorks renderer module, http://www.mw-software.com/software/awmodules/awrender.html (and its dependencies) to work; it's a utility module that stresses the compatibility library (so similar modules should be easier to get to work), and Martin Wuerthner is supportive of my attempts. The framework appears to be working OK, so now its back to adding support for more low-level SWIs.

The comments are appreciated, I'll try to keep posting updates.

Remote Frame Buffer

2008-10-17T11:52:00.002+02:00

I've taken a few days off trying to get NetSurf to work in order to add basic Remote Frame Buffer protocol support to the Wimp.

That's the protocol used by VNC, so now the Wimp can be used from a VNC client, either with or without displaying to an actual display. (Keyboard support is not yet included, but the mouse works.)

To use it, set the environment variable ROLF_VNC to anything (at the moment, later it will be used to define the port to listen at and, possibly, the frame buffer resolution). If ROLF_VNC is not defined, or FRAME_BUFFER is, the proper frame buffer device will be used (rather than a shared memory bitmap).

In use, it's much faster than running the system under qemu, and I can use the host system to debug code. I'll now go back to working out the coordinate system for netsurf.

An apology

2007-12-10T08:18:00.000+01:00

I have to make an apology. When I was getting a distribution together to release ROLF, I dutifully asked Chris Wraight if I could use his sprites, and he was kind enough to say yes.

Unfortunately, the sprites I used (in a9sprite and tools) were designed by Detlef Thielsch. He pointed this out to me in a friendly e-mail last week, and has kindly said that I can continue to use the sprites for private use.

So, my apologies to Detlef for using his sprites without permission. (While I'm at it, I also apologise to Chris, for not using his.)

Thanks to both of them for providing the chance to make ROLF look half way decent and not like a bad copy of Arthur, which is how it would have looked with my attempts at icon drawing.

Progress on palmtop version

2007-11-16T12:20:00.001+01:00

While I'm waiting for a new CD-ROM image to build, I thought I'd take another look at getting ROLF to run on my Nokia N800.

The display is now working; it turns out the frame buffer access isn't so clear-cut as on a PC, in that the display needs to be told when you've just updated a rectangle, it's a simple enough modification, though.

Initially, I thought I'd (have to) replace the existing interface with ROLF, but now I think I'll try to have them running simultaneously on separate virtual terminals. This means the server will have to configure and react to VT change signals (rather than the simplistic approach of waiting to be sent another keypress when changed to another VT). Then, I just need a simple program on each one to perform a chvt to the other.

The touchscreen delivers events through an input event device (see Documentation/input/input.txt in the Linux kernel); this is a much nicer interface than the /dev/psaux one I was using and handles keyboards as well, so I'm moving over to that for all platforms. I need to calibrate the touchscreen, though, the reported return values from the device cover a larger area than are actually returned, so with my initial code, the cursor wouldn't move out of a smaller rectangle in the middle of the screen.

To get anything working at all, I've installed dropbear (a ssh server), so that I can login remotely via the network. Executable files don't work from the memory cards, so I'm installing to a directory under the root.

Finally, new core code

2007-11-05T11:35:00.000+01:00

I've just uploaded a new version of the core code to http://stoppers.drobe.co.uk/downloads/rolf.200711031911.tgz

This version supports more frame buffer formats, including the packed 24-bit RGB used by QEMU.

There is a very simple configure script, now, that you can use to configure the code to compile on X86 or ARM, and enable debug symbols, etc. (IIRC, the GTK+2 configure script is actually more lines of code than ROLF contains.)

The terminal program has been modified to keep reading from the application producing output even when waiting for a response from the Wimp (this means that you can run ROLF applications from the terminal command line without it hanging because it's filled up the buffer while it's got the lock on the Wimp).

As it stands, it's not very much, but if anyone gets it working, they'll be in a position to use the patches for Brandy, GTK and MPlayer that I intend to put up soon (meaning when they're finished, or I get prodded again). Also, I should look into patching ARM QEMU....

Update: Once you've built the code, you will need a fonts directory (included in the ISO image, or from here. Then change directory into Resources and run:

ROLF_FONT_DIR=$HOME/.fonts Wimp
Assuming you unpacked the fonts tarball into your home directory.

Update II:
If nothing appears to happen, try Ctrl-Shift-F12 to exit and look in /tmp/boot.
If the mouse pointer doesn't move, you probably don't have read-write access to /dev/psaux.

What I'm working on at the moment

2007-10-17T08:35:00.000+02:00

Image library
I've optimised the image library in several important cases (all the optimisations are within a single routine, DefaultRenderTo, where information hiding is allowed to go out the window to improve speed of rendering images).
I've added support for more frame buffer pixel formats, although they have yet to be tested.
Specifically, I've taken some code from MPlayer to do copying to the frame buffer (mem2agpcpy), this will be an optimisation for almost all applications, but mplayer was the only one really suffering.
I will also add a generic image colour inverter that can be used by the filer for selected files, instead of the ugly red square overlay.

Live CD
The stax scripts weren't quite what I was after, but they have helped me to understand squashfs and build it into my kernel and scripts; unionfs (or aufs) will come later. At the moment, the kernel doesn't boot under QEMU for some reason that I will be looking into.

MPlayer
The ROLF Mplayer output library can play DVDs at full speed (and about 50% processor loading). The only example HD trailer I have (The Bourne Supremacy) plays pretty well, too.
I'm not sure about licensing issues to do with including it on the Live CD, though.

Launcher
This is a new program that will allow simple applications to be built which have an icon bar icon and run programs on any files dropped on the icon (this will initially be used for mplayer). It could be extended to something scriptable, perhaps.

Compatibility Library
This library has been added recently, with partial support for a few simple RO SWIs. It is easy to integrate with Brandy, although there is an issue with running a Wimp program; Brandy doesn't seem to like being turned into a daemon (which ROLF_Initialise usually does). I haven't tried integrating it with (ARM) QEMU yet, but it shouldn't be much harder.
I think it should be possible to support ARM code relocatable modules fairly easily, by having a shared memory block containing the RMA. It would be nice to get something like the ArtWorks viewer running.

Priorities
I'll be working on getting the live cd to run under QEMU and, in the mean time making minor additions to the image library and filer.

Back to Blogger

2007-10-17T08:32:00.000+02:00

I think this might be a quicker way to publish my thoughts about what's being updated in ROLF.

Progress

2006-10-20T10:32:00.000+02:00

I've been on holidays for a couple of weeks, but since then, I've added support for reading Sprite files and modified my Iconsprites utility to accept sprite files. This means that I can use the Chrome tools by Chris Wraight downloaded from drobe. I haven't asked for permission to distribute them, but I can presumably just include a script to download and decompress them (or similar ones), when the time comes.

The release of the Select documentation will allow me to add alpha sprite capability later, too, also a good thing.

At the moment, I've lowered my sights somewhat from Firefox, to the example programs that come with GTK+. Specifically, I'm trying to get the helloworld program to work. The good news is that it seems that I can shoehorn ROLF into the structure of GTK without any modifications to the ROLF API.

Getting Firefox to build

2006-09-15T08:34:00.000+02:00

Well, I've got a GTK2 library to build without any X source (and without any functionality, the ROLF backend consists of placeholders for the time being), and I want to get Firefox to build on top of that. It's not as easy as I'd like, the X library headers seem to get pulled in whether or not it's using X. It's been a decade since I had anything to do with COM, and there seems to be about 2000 COM interfaces in the tree. When I've had a look through them, hopefully I'll be able to identify which libraries need to be patched.

Still here

2006-09-07T12:44:00.000+02:00

I'm not posting more often because (a) nobody's looking and (b) I have to reboot into Knoppix and use Mozilla Firefox to post. My base system is Linux From Scratch, this time built using ALFS, which doesn't do a lot, but I want to ensure that there are as few dependencies as possible for the basic system.

The mplayer patch seems to work quite well with moderate sized videos (but needs DVD movies scaled down to a half original to be watchable).

Next (after hunting down the show-stopper that meant I had to do this re-boot), I plan to install GDK in a special user's home directory and see what I can achieve with SVG and, possibly, some simple Gnome applications.

If anyone is interested in having a copy of the source code, I can provide it via e-mail, if anyone wants to request it from simon dot willcocks at t-online dot de. The code will be released as (L)GPL. The whole lot is 12k lines of code, 360K uncompressed (78K compressed), plus a 528 line patch to MPlayer-1.0pre8.

MPlayer

2006-09-01T22:23:00.000+02:00

Well, I gave up on SVG for the time being and decided to patch MPlayer to display movies using ROLF instead.

It's simply a matter of adding a new Video Out driver that opens a window and displays each frame as it comes, detatching from the WIMP while the next frame is built so that other windows can do stuff. The MPlayer software even takes care of the YUV to RGB translation transparently. That took a couple of days, the last two days have been spent updating my LFS system to get proper audio (and a 2.6 kernel). I've got to do that more often, so I don't forget how it works!

Alpha version available soon

2006-08-27T14:49:00.000+02:00

I've been working on ROLF for some time, off and on, and I've got to the point where I'm almost willing to let other people have a look.

The applications include the Iconbar and Filer, plus a simple image viewer for JPEG and PNG files (try some PNGs with transparency) and a terminal application (supporting ONE font and ONE screen size).

Everything is very slow and flickery, even on a 2GHz machine, but fairly functional. You don't want to have anything important running or edit important documents at the moment, though!

Currently, I'm working on supporting SVG in the bitmap library (OK, the name's bad, I'll probably change it), but librsvg seems to want me to install an entire X windows system to get it to compile!

Architecture (in brief)

2006-08-27T11:31:00.000+02:00

The basic ROLF software consists of three applications and two libraries:

Wimp : the central process that all ROLF applications communicate with. It manages the window stack and the on-screen pointer, handles inter-process messaging, and communicates with the input devices (keyboard and mouse). Access to the Wimp is managed in a co-operative multi-tasking manner (as with RISC OS), with a couple of differences: firstly, applications can continue processing independently of the Wimp and, secondly, multiple applications may be asked to (re)draw non-overlapping rectangles of the screen simultaneously.

Iconbar : this ROLF application must be run first by the Wimp (to be ready to provide its services to other applications, including the Filer) and provides the backdrop and iconbar functionality.

Filer : this ROLF application provides a GUI representing the files on the system and handles loading or running of files and applications. Filetypes will be stored in the Linux directory structure (initially as hidden files including the file type in their names) so that the types of all the files in a directory can be read in almost the same time as simply reading their names.

Furniture library : a library linked with each ROLF application that handles window furniture (title bar, size icon, etc.) using the facilities provided by the Wimp. Having a separate library should avoid feature creep in the Wimp, so that modifications to the Wimp should consist only of optimisations and support for additional hardware.

Bitmap library: a library for handling images in an abstract way, so that the internal format of a bitmap need not be known by external software. Source Images can be rendered to Destination Images, without having to know anything about the internal representations of either. Pixels are nominally 16 bits each of Red, Green, Blue and Alpha, although most major operations will be optimised to use the minimum required. Scalable images (SVG, DrawFiles and Fonts) are also handled by this mechanism.

What ROLF is

2006-08-27T08:55:00.000+02:00

ROLF is a GUI framework using the framebuffer device on Linux to provide a look and feel similar to that of the RISC OS operating system.

The RISC OS GUI is largely unchanged in concept since the late 1980's, not because of any lack of development, but because it just worked, better in many people's opinion than any of its competitors, then and now.

ROLF is not intended to take over from RISC OS, or even to run RISC OS native applications (although that may become possible with the use of Brandy, QEMU and a command line interpreter, among other things), but to allow Linux applications to be written or modified to work in the manner of the RISC OS GUI (with some newer twists, like translucent windows and preemptive scheduling, not to mention multi-gigahertz processors).

Another aspect of RISC OS I would like to emulate is to keep the system lightweight and modular, so that it will work on devices with limited resources as well as highly powerful and resource-rich desktop machines.