Date   : Wed, 29 May 1996 23:43:00 PDT
From   : Peter Vince <Peter.Vince@...>
Subject: OSWORD 14 parameter block allocation on 2nd processor

This may be a known problem, but may I issue a warning to allocate a large 
enough parameter block for OSWORD 14 (read CMOS clock) when running in the 
second processor.

This, of course, only affects the Master, as the Beeb doesn't have a CMOS 
clock, so doesn't support this OSWORD call.

The Master Reference Manual Part 1, page D.3-22, describes how OSWORD 14 
provides three different read functions for the CMOS clock.  If the first 
byte of the parameter block is zero, a 24-byte string is returned with the 
date and time spelt out, and this is terminated with a carriage-return in 
the 25th byte.

If the first byte of the parameter block is 1, then the date and time is 
returned in BCD format,  and the manual says the parameter block need only 
be 7 bytes long.

If the first byte of the block is 2, then a BCD format date/time will be 
converterd to the 24-byte string format, and hence a 25-byte block is again 
needed.

In the native Master, all appears to agree with the manual.  However, when 
running a 6502 second processor (I was using the Master internal version, 
but I presume the external version will be the same) the Tube Operating 
System (?) seems always to expect a 25 byte parameter block to be allocated, 
even for the 7 byte BCD result.  This produced some very strange results in 
a program I had written, but a quick test program to do a hex dump of the 
area of memory before and after the call revealed all.  Initially, when 
using the second option to get a BCD result, an extra 17 bytes were nulled 
by the call.  However, after using the third call to convert a BCD time to a 
string, on calling for the second option again, these extra 17 bytes 
contained the end of the string which had previously been returned by the 
convert option.

Moral of the story?  Always allocate the maximum size parameter block a 
routine may ever need.

Hope this saves someone else a bit of time,

     TTFN,

          Peter Vince.

Peter.Vince@...