Date : Mon, 25 Aug 2008 20:48:51 +0100
From : jgh@... (Jonathan Graham Harston)
Subject: Master 128 century correction
"Raf" wrote:
> Jonathan, *maybe* I am in error but one thing about X that I have noticed
> in my research over time about OSWord &0E is that if you copy the default
> registers into main memory, X is zero ( XY= 0 ,1 or 2). Acorn returns the
No, how could that be? It would mean that you could only ever call
OSWORD with a control block at &xx00 in memory, which you isn't the
case? It would break every single program that did DIM ctrl%
31:X%=ctrl%:Y%=X%DIV256 as ctrl% could be *anywhere** in memory,
not just at &xx00. Even BASIC calls OSWORD with X=&36 and Y=&00
with a control block at &0036.
If you investigate the OSWORD handler, it starts off something
like:
.word
STA &EF:STX &F0:STY &F1
CMP #16:BCS not_a_mos_word
\ jump via MOS dispatch table
.not_a_mos_word
LDX #8:JSR issue_service_call :\ Send service call 8 - unknown
:\ OSWORD - to sideways ROMs, OSWORD
:\ number is in &EF, control block
:\ pointed to by &F0,&F1
> >> 250 STX &DB3 --> LDA &F4:STA &DB3
>
> Also, the third item in the extended vector situation is the ROM number.
> On checking the contents of &DB3, it always contained a zero when I ran
> your code. When I put ?~&F4 into it, it contained my ROM number, 7.
On entry to the service routine, A=service number, X=ROM number,
Y=any other parameter. If you try the following code:
10 REM > TEST/s
20 DIM mcode% &1000
30 FOR P=0 TO 1
40 P%=&8000:O%=mcode%
50 [OPT P*3+4
60 BRK:BRK:BRK
70 JMP Serv
80 EQUB &82:EQUB copy-&8000:BRK
90 EQUS "TEST"
100 .copy
110 BRK:EQUS "(C)":BRK
120 .Serv
130 PHA:TXA:JSR pr_hex:PLA:RTS
140 :
150 .pr_hex
160 PHA:LSR A:LSR A:LSR A:LSR A
170 JSR pr_nyb:PLA
180 .pr_nyb
190 AND #15:CMP #10:BCC pr_dig
200 ADC #6:.pr_dig
210 ADC #48:JMP &FFEE
220 :
230 ]NEXT
240 OSCLI"*SAVE TESTROM "+STR$~mcode%+" "+STR$~O%
(See also <http://mdfs.net/System/Rom/MCode/Testing/ServROM.s>.)
You will see that on every entry to the service handler, X is
holding the ROM number. If it isn't, there is something wrong with
your computer that is going to kill a huge number of ROMs that rely
on the service handler being entered with the registers set up
correctly.
"Raf" wrote:
> Hi John,
Who?
> 2. Would you please assist with full working programme listing(s), Jonathan,
What's wrong with "add the following lines to the previous
program"? It gives you:
10 REM > NewTime/s
20 REM Intercept RTC calls to force 21st century
30 :
40 DIM mcode% &800
50 FOR P=0 TO 1
60 P%=&8000:O%=mcode%
70 [OPT P*3+4
80 EQUB 0:EQUW 0
90 JMP Service
100 EQUB &82:EQUB Copyright-&8000:EQUB 1
110 EQUS "TIME":EQUB 0
120 EQUS "1.00"
130 .Copyright
140 EQUB 0:EQUS "(C)"
150 EQUB 0
160 :
170 .Service
180 CMP #&27:BEQ ServReset
190 RTS
200 .ServReset
210 LDA &20C:STA oldwordv+0
220 LDA &20D:STA oldwordv+1
230 LDA #newword AND 255:STA &DB1
240 LDA #newword DIV 256:STA &DB2
250 STX &DB3
260 LDA #&12:STA &20C
270 LDA #&FF:STA &20D
280 LDA #&27:RTS
290 :
300 .newword
310 CMP #14:BEQ newword14
320 .oldword
330 JMP (oldwordv)
340 :
350 .newword14
360 STX &F0:STY &F1
370 LDY #0:LDA (&F0),Y:PHA
380 LDY &F1:LDA #14:JSR oldword
390 PLA:BNE exit
400 LDY #11:LDA #ASC"2":STA (&F0),Y
410 INY:LDA #ASC"0":STA (&F0),Y
420 .exit
430 LDX &F0:LDY &F1:LDA #14
440 RTS
450 :
460 .oldwordv:EQUW 0
470 ]
480 P%=&865C:O%=P%-&8000+mcode%
490 [OPT P*3+4
500 EQUW &DC00:EQUB &F0:EQUB &20:EQUB &7E
510 ]
520 NEXT
530 A$="SAVE NEWTIME "+STR$~mcode%+" "+STR$~O%+" 8000 8000"
540 OSCLIA$
With the following results:
>T$=TIME$:P.T$
Sun,24 Aug 2008.13:33:43
>*BUILD FRED
1 HELLO
2
>*DUMP FRED
000000 48 45 4C 4C 4F 0D HELLO.
--
J.G.Harston - jgh@... - mdfs.net/User/JGH
05:10:36, 18-Nov-2008 - RISC OS time rolls over to &5000000000