Difference between revisions of "OSWORD &0F"
(Added detail to implementation.) |
m (Fixed heading.) |
||
| Line 91: | Line 91: | ||
Implements subcodes 5,8,15,24. The century is read from the system configuration. | Implements subcodes 5,8,15,24. The century is read from the system configuration. | ||
| − | + | ==Suitable possible extensions== | |
Calls to OSWORD &0F are simply '''length,string''', so additional calls can be | Calls to OSWORD &0F are simply '''length,string''', so additional calls can be | ||
implemented for suitable parameters. These are some possibilites. | implemented for suitable parameters. These are some possibilites. | ||
Revision as of 21:17, 7 February 2023
On entry: XY?0=length of data at XY+1 XY?0=3 Set alarm XY+1=3-byte BCD alarm block XY?0=5 Set from XY+1=5-byte centisecond time XY?0=7 Set from XY+1=7-byte BCD date block, year 1980-2079 XY?0=8 Set from XY+1=8-byte BCD date block with century XY?0=8 Set from XY+1="hh:mm:ss" XY?0=11 Set from XY+1="dd mmm yyyy" XY?0=15 Set from XY+1="DDD,dd mmm yyyy" XY?0=20 Set from XY+1="dd mmm yyyy.hh:mm:ss" XY?0=24 Set from XY+1="DDD,dd mmm yyyy.hh:mm:ss"
The caller should simply store the length of the passed data at XY?0 and store the passed data at XY+1. The caller must not put any interpretation on the data and length it passes, that is entirely the responsibility of the code that implements the call, not the caller.
On exit: The only defined exit state is that unsupported calls should leave the control block unchanged, and known implementations leave the control block unchanged after successful calls. Known implementations also leave the control block unchanged after unsuccessful calls. An appropriate extention would be for supported calls to modify the returned control block if passed invalid data, such as 8,"99:88:77" which is an invalid time.
Data format
The date string format is "DDD,dd mmm yyyy.hh:mm:ss". The punctuation is normally irrelevant, the position of the component values is fixed. 7-byte BCD date block format: +0 year &00-&99 year is 1980-2079 +1 month &01-&12 +2 date &01-&31 +3 day &01-&07 Sun-Sat or &00 for unsupported +4 hour &00-&59 +5 minute &00-&59 +6 second &00-&59 8-byte BCD date block format: +0 century &00-&99 +1 year &00-&99 +2 month &01-&12 +3 date &01-&31 +4 day &01-&07 Sun-Sat or &00 for unsupported +5 hour &00-&59 +6 minute &00-&59 +7 second &00-&59 3-byte BCD alarm block format: +0 hour &00-&59 or &C0-&FF for 'any' +1 minute &00-&59 or &C0-&FF for 'any' +2 second &00-&59 or &C0-&FF for 'any'
Calling from BASIC
REM X%=>control block, Y%=X%DIV256 REM T$=string : X%?0=LEN(T$):$(X%+1)=T$ A%=15:CALL OSWORD
Implementation
On a system without a Real Time Clock, the MOS passes OSWORD 15 to sideways ROMs for support. Implementations should ignore unsupported subcodes and pass them on. Writing invalid data should be silently swallowed, what the implementation does with invalid data is implementation specific.
Master MOS
The Master MOS 3 and MOS 4 implements subcalls 8,15,24. Unimplemented subcalls are swallowed and not passed on.
Master Compact
The Master MOS 5 passes all calls to sideways ROMs.
SoftRTC
The SoftRTC module stores the time and date with the system TIME timer. It implements subcalls 7,8,11,15,20,24. The SoftRTC module included in HADFS sets the date with *SETDATE. Unimplemented subcalls are passed on.
ANFS
I2C Control ROM
TicToc ROM
RISC OS
Implements subcodes 5,8,15,24. The century is read from the system configuration.
Suitable possible extensions
Calls to OSWORD &0F are simply length,string, so additional calls can be implemented for suitable parameters. These are some possibilites.
| 1,nn | ? |
| 2,nn,nn | ? |
| 4,"yyyy" | set year |
| 6,"xxxxxx" | ? |
| 9,"xxxxxxxxx" | ? |
| 10,"A=hh:mm:ss" | set alarm |
Notes
Have not yet found information to document implementations supporting turning alarm on/off, and reading alarm setting.
See Also
Jgharston 12:57, 26 May 2009 (UTC) Jgharston (talk) 00:16, 7 January 2023 (CET) Jgharston (talk) 21:04, 7 February 2023 (CET)
