Friday, June 18, 2010

Famous last words (Updated)

"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.

Tuesday, June 08, 2010

A non-graphical OSCLI

(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.