There are some RISC OS *CONFIGURE settings that take effect immedately - which is unexpected when you realise what's happened. I think there should be a clear distinction that *CONFIGURE THING blah takes effect after the next restart, and *THING blah takes effect immediately. Eg *CONFIG. TV vs *TV, etc. That's the methodology I used in the USB ROM, *CONFIGURE USBPRINT takes effect after the next Reset, *USBPRINT takes effect now, etc. (Edit: quickly reads USB ROM documentation to check Image may be NSFW.The problem with *CONFIGURE TIMEZONE ±hh is that configures normally only take effect on a hard restart, whereas I would like a change of timezone to take effect immediately.
Clik here to view.
)And it makes sense that *commands call an underlying API, just as *TIME calls OSWORD 14,0 then prints out the result.
Thing is, *STATUS isn't "reading the...." it's "displaying the....". How would a program do timezone$=FNfoobar ?Also I read the timezone with OSWORD &E to calculate UTC for clock synchronisation, so it sort of makes sense to write the timezone using OSWORD &F. I suppose there could be a OSWORD &E call to return current time in UTC, and reading the timezone alone would be done with STATUS.
Haven't you pencilled in OSWORD 14,5 to return the current timezone. Then you'd just use BCD arithmetic and add/sub it to the local time returned by OSWORD 14,1. That would also be transparent if timezones are unsupported, do !X%=5:%=15:CALL OSWORD and if there's no timezone support, X%?1,2,3 are left as zero, and adding to the OSWORD 14,1 time is a null operation without having to do any special checking.
I think that makes sense. (though I've been awak sinxe 6am, Image may be NSFW.I prefer the syntax UTC±hh to ±hh for offsets because apparently a lot of places use MSK±hh, and it also allows things like CET+01 for daylight saving in places where DST-names are four letters.
My current inclination is to use *CONFIGURE TIMEZONE (or service call &29) to define timezone names, and *TIME (or OSWORD &F) to switch between them.
Clik here to view.
)The logical arrangement is *CONFIGURE TIMEZONE blah (which is passed via service call &29) and *TIMEZONE blah, ideally *TIMEZONE simply stacking the string and length calling OSWORD 15. That's what my *TIME=.... and *DATE=.... commands do.
In the USBROM I went to some effort to develop a general purpose command line parser that allows one bit of code and one table to be both Help, Command, Configure and Status match&dispatcher, semi-inspired by RISC OS module handling. It's one of those things that I want to get around to documenting properly.
I've been slogging through datasheets and ROMs sucking out internal implementations, and updating things like:
3002RTC, 6818RTC, OSWORD &0E, OSWORD &0F.
(In doing this I'm wishing I had a time machine to just back and kick somebody at Acorn for using coding OSWORD 14,3 in Arthur to read 5-byte centisecond time when a) the matching OSWORD 15 is the logical subcode 5, and b) more annoyingly, ANFS already implements OSWORD 14,3 and 4 to talk to the file server, so Arthur "broke" the API. OSWORD 14,5 was available as the next available subcall, and logically matches OSWORD 15,5. grrr.)
Statistics: Posted by jgharston — Mon Feb 03, 2025 10:57 pm