10REM >Y2KFixS
20REM by Steven Flintham
30REM
40REM Version 0.01
50REM
60REM Friday 25th July 1997
70REM Thursday 21st August 1997
80:
90REM This is a bit of a bodge, but s
hould suffice. The Master Reference
100REM Manual implies that the RTC its
elf contains a century number and
110REM correctly handles the 21st cent
ury. Whether or not this is actually
120REM the case, I don't want to get i
nvolved in talking directly to the
130REM RTC - I'd probably have to disa
ssemble the OS to find out how to
140REM do it and there's always a slig
ht risk of doing something nasty to
150REM the chip.
160REM
170REM All I do is provide a "front en
d" to the OSWORD calls, changing the
180REM "19" in the date string to "20"
for years from 0 to 69 inclusive -
190REM this adjusts the range of years
which is displayed correctly to
200REM 1970-2069. This works because t
he RTC doesn't know 1900 wasn't a
210REM leap year. The OSWORD call to r
ead the CMOS clock in BCD format is
220REM unmodified as it doesn't return
a year; anything using it for
230REM display purposes probably assum
es a 19XX year, but there's nothing
240REM I can do about that.
250REM
260REM There's no need to do anything
about setting the RTC; the OS treats
270REM a 20XX year as a 19XX year for
this purpose, which is just what's
280REM wanted with this fix.
290:
300PROCinit
310PROCassemble
320OSCLI "Save Y2KFix "+STR$÷code%+" "
+STR$÷(save`to`here-dest%+code%)+" "+STR
$÷redirect`wordv+" "+STR$÷dest%
330END
340:
350DEF PROCinit
360DIM code% 1024
370dest%=&A80
380:
390wordv=&20C
400osword=&FFF1
410:
420REM I can't see why I shouldn't use
these locations for this purpose
430REM although in theory it might cau
se problems.
440osword`x=&F0
450osword`y=&F1
460ENDPROC
470:
480DEF PROCassemble
490FOR opt%=4 TO 7 STEP 3
500P%=dest%:O%=code%
510[OPT opt%
520½ This isn't needed once it's been
executed the first time, so it can
530½ be overwritten after loading. Dep
ending on where the fix code is
540½ placed in memory, it might be mor
e useful to have this once-only
550½ code at the end instead of the be
ginning. (It would then be necessary
560½ to save the uninitialised data th
ough.)
570.redirect`wordv
580LDA wordv:CMP #my`osword MOD 256:BN
E redirect`vector`do`it
590LDA wordv+1:CMP #my`osword DIV 256:
BEQ rts ½ Already redirected
600.redirect`vector`do`it ½ Actually r
edirect the vector
610LDA wordv:STA old`vector
620LDA wordv+1:STA old`vector+1
630LDA #my`osword MOD 256:STA wordv
640LDA #my`osword DIV 256:STA wordv+1
650.rts
660RTS
670:
680½ TODO?; I don't preserve the proce
ssor flags at all; is this a flaw?
690.my`osword
700CMP #14:BNE pass`on ½ Only process
calls to read the clock
710STX osword`x:STY osword`y
720LDY #0:LDA (osword`x),Y
730CMP #1:BEQ restore`pass`on ½ nothin
g to change for BCD read
740½ Handle the string operations by l
etting the OS deal with it, then
750½ modifying the century in the stri
ng if appropriate
760TXA:PHA:LDA osword`y:PHA
770TAY:LDA #14:JSR old`osword ½ X hasn
't been modified
780PLA:STA osword`y:PLA:STA osword`x
790½ Year within century is at offsets
13 and 14
800LDY #13:LDA (osword`x),Y
810SEC:SBC #ASC"0"
820ASL A:STA year`within`century
830ASL A:ASL A
840½ The carry should be clear anyway,
but it seems silly to risk problems.
850CLC:ADC year`within`century:STA yea
r`within`century
860½ year`within`century now contains
C*10, where the year is ABCD
870INY:LDA (osword`x),Y:SEC:SBC #ASC"0
"
880CLC:ADC year`within`century
890½ A now contains CD, where the year
is ABCD
900CMP #70:BCS claim ½ If CD>=70, do n
othing
910LDY #11:LDA #ASC"2":STA (osword`x),
Y
920INY:LDA #ASC"0":STA (osword`x),Y
930.claim
940½ Y has been corrupted, but OS 3.2
(at least) doesn't preserve either
950½ X or Y (it will have corrupted X
itself on the earlier OSWORD call
960½ but this code hasn't corrupted it
). It does preserve A, however.
970LDA #14
980RTS
990.restore`pass`on
1000LDA #14:LDY osword`y ½ X hasn't bee
n modified
1010.old`osword
1020.pass`on
1030JMP (old`vector)
1040:
1050.save`to`here
1060½ Uninitialised data
1070.old`vector EQUW 0
1080.year`within`century EQUB 0
1090]
1100NEXT
1110ENDPROC