HINTS & TIPS

Rounded up by Lee Calcraft

CLOSING FILES

by Sheridan Williams

In routines such as error handlers it is often important to close particular data files which have been left open. The command *CLOSE or CLOSE# 0 may be used for this purpose, but these blanket commands close all open files, including obey files, and others which may need to be kept open.

The alternative is to close files specifically, but the problem here is that if you attempt to close a file that is not open, errors can occur. The solution is to use the procedure PROCclosefile below. This takes as a parameter the file handle of the file to be closed, and only attempts to close the file if it is open. When it has closed the file, it resets the file handle to zero to indicate that it is closed.
DEFPROCclosefile(RETURN handle%)
IF handle%>0 THEN CLOSE# handle%:handle%=0
ENDPROC

RISC OS MODULE HELP

by Dennis Weaver

Although the Arthur operating system and accompanying modules give useful syntax information when you type:
*HELP
the machine is less communicative when you request help on the module name itself. RISC OS is decidedly more helpful. Issuing:
*HELP
now gives information on commands and configuration options provided by the module.

SCREEN MODE AND THE RISC OS DESKTOP

by Lee Calcraft

RISC OS allows programs to be booted using Shift-Break whether the Desktop is active or not. All you need to do is to set *OPT4,3. But you may have problems with screen RAM when booting from the Desktop. Even if you have configured 160K of screen RAM, the Desktop will dynamically alter the total RAM available for the screen on the basis of the configuration of a new parameter: WimpMode. To permit a program which boots from the Desktop to use up to 160K of screen RAM, use:
*Configure WimpMode 15
followed by Ctrl-Break. This will work regardless of the amount of screen RAM configured. In other words, you can have a 160K screen when the screen size is configured to only 80K - all thanks to RISC OS dynamic RAM allocation.

PASSING PARAMETERS

by David Graham

The SYS call "OS_GetEnv" can be used to read any parameters supplied when a program is run. For example, the following short program stores in name$ the full command supplied to the operating system when the program is run using *filename:
10 SYS "OS_GetEnv" TO name$20 PRINT name$
If the program is saved under the name test, then typing:
*test fred
will set the variable name$ to:
BASIC -quit "test" fred
The parameter fred at the tail end of the string can be picked up and used in whatever way the programmer wishes. For example, as a data filename. Since the call works by picking up the last issued star command, you must ensure that no star commands are issued between running the program using *filename, and issuing the SYS call.

CARE WITH SHIFT

by Lee Calcraft

The use of Basic's shift and rotate operators ("<<", ">>" and ">>>") can give rise to syntax errors in certain circumstances because the expression evaluator appears to confuse them with the "greater than" or "less than" operators (">" or "<"). The following statement, for example, fails:
IF x>>>2=4 THEN VDU7
To resolve the problem, just bracket the expression, thus:
IF (x>>>2)=4 THEN VDU7

WHICH FILING SYSTEM?

by David Graham

It is sometimes useful in a program to be able to check which is the currently active filing system. This is easily achieved with the following SYS call:
SYS "OS_Args" TO fsyst

After making the call, the variable fsyst holds the number of the current filing system. The three most commonly encountered filing system numbers are:
Econet5
ADFS8
RAM23

NO MORE LINE NUMBERS

by Roger Wilson (Acorn)

When Basic is called on exit from Twin, either when Twin is used without line numbers, or when line numbers have been put out of sequence in Twin, Basic automatically renumbers the incoming program with the equivalent of:
RENUMBER 10,10

A problem arises with Basic programs of longer than 6527 lines, because when numbered by tens, they will exceed the highest line number that Basic can cope with (65279).

The solution is to make a patch in RAM Basic so that it renumbers in steps of one rather than 10. To do this, find the code right at the start of Basic where the message "Program renumbered" resides, and alter the two instructions:
MOV R4,#10
MOV R5,#10

to
MOV R4,#1
MOV R5,#1

WIMP GET ICON ERROR

by David Spencer

The Programmer's Reference Manual (page 472) erroneously gives the name of the SWI call "Wimp_GetIconState" as "WimpGetIconInfo".

UTILITY BUG

by Michael Spalding

There appears to be a major bug in Arthur 1.20 (but not RISC OS) which affects the writing of utility commands - that is machine code routines with a filetype of &FFC. When a utility is invoked, the operating system allocates 1K of workspace to it, setting register R12 to point to the bottom of this block, and R13 to the top. If you use R13 as a stack pointer, then the stack grows down from the top of the workspace. However, opening a file using SWI "OS_Find" corrupts the top few bytes of the workspace, overwriting the stack and causing havoc. This was found by chance, and similar nasty behaviour might happen with other SWI calls. The cure is to move the stack lower down (using perhaps SUB R!3,R13,#256) at the start of the utility. See the Basic program lister elsewhere in this RISC User for an example of this.

UP AND DOWN BY THE PAGE

James Lovejoy

The Page Up and Page Down keys on the Archimedes are the same as the Cursor Up and Down keys, but with the effect of shift reversed. For example, if the commands:
*FX 4 2
*FX 225 &80
*FX 226 &90

were issued, then the Up and Down Cursor keys would produce ASCII codes &8F and &8E respectively, while Page Up and Page Down would generate codes &9F and &9E. However, if the Shift key was pressed, the codes would be reversed - the cursor keys producing &9E and &9F, and the Page Up and Down keys &8E and &8F. One effect of this is that almost all software that uses Shift in conjunction with Cursor Up and Down will also accept Page Up and Down as an alternative.

DELAYED SYS

David Spencer

The Archimedes Sound Scheduler module provides a call to execute a SYS command after a given delay. It takes the form:
SYS "Sound_QSchedule",delay,&F000000+sys,R0,R1
Where sys is the number of the SYS call to make (found from the Programmer's Reference Manual), and R0 and R1 are the parameters to pass to it. For example: $&9000="Your Time Is Up!!"+CHR$0
SYS "Sound_QSchedule",1000,&F000002,&9000,0

This uses SYS call 2 which prints a text string from a given address in memory. The length of the time delay depends on the value given in the command and the TEMPO setting. For the default value of TEMPO (4096) the delay is in 1/100s of a second, so the above text is printed after 10 seconds. It is possible to queue several calls simultaneously, and this is a simple alternative to using events or interrupts.