Difference between revisions of "OSWORD"
(→Specification) |
(Added some bugs to be aware of.) |
||
| Line 49: | Line 49: | ||
''Application note 004: Tube application note'', p.5.</ref> | ''Application note 004: Tube application note'', p.5.</ref> | ||
This makes them easier to implement as only USERV needs to be hooked into | This makes them easier to implement as only USERV needs to be hooked into | ||
| − | instead of WORDV. | + | instead of WORDV, and &F0/&F1 is already prepared pointing at the control |
| + | block. | ||
==Calling from BBC BASIC== | ==Calling from BBC BASIC== | ||
| Line 70: | Line 71: | ||
* PDP-11 Entry Address: EMT 3, vector &03 | * PDP-11 Entry Address: EMT 3, vector &03 | ||
* ARM Entry Address: SWI &07 "OS_Word", vector &07 | * ARM Entry Address: SWI &07 "OS_Word", vector &07 | ||
| + | |||
| + | ==Bugs in implementations== | ||
| + | Some ROMs OSWORD handlers have flaws that either cause their OSWORDs | ||
| + | to not work properly, or cause other OSWORDs to not work properly. | ||
| + | Of note are the following. | ||
| + | |||
| + | ===DFS 0.90=== | ||
| + | DFS 0.90 traps ''all' OSWORDs above &7F and treat them as OSWORD &7D due to | ||
| + | the omission of a ''BMI exit'' instruction. This means that any high | ||
| + | numbered OSWORD in any other ROM will fail to execute if it is in a lower | ||
| + | ROM than DFS, and instead it attempts to read the disk. | ||
| + | |||
| + | ===DumpOut=== | ||
| + | DumpOut 3's teletext pixel reading OSWORDs use high numbered calls but | ||
| + | without the correct header, meaning they fail on any second processor system | ||
| + | or similar. | ||
| + | |||
| + | ===Morley RAMdisk=== | ||
| + | Uses a high numbered OSWORD without the correct header, so cannot be used | ||
| + | from a second processor. The call is a data-transfer call and also only uses | ||
| + | a 16-bit address, so cannot transfer across the Tube. | ||
==See Also== | ==See Also== | ||
| Line 80: | Line 102: | ||
[[User:Jgharston|Jgharston]] 17:03, 6 November 2009 (UTC) | [[User:Jgharston|Jgharston]] 17:03, 6 November 2009 (UTC) | ||
| + | [[User:Jgharston|Jgharston]] ([[User talk:Jgharston|talk]]) 00:10, 13 May 2020 (CEST) | ||
Revision as of 23:10, 12 May 2020
Miscellaneous actions with a control block
Contents
Specification
| 6502 | Z80 | 6809 | PDP11 | 80x86 | 32016 | ARM | On entry: | On exit: |
| A | A | A | R0 | AL | R1 | R0 | = function code | undefined |
| XY | HL | X | R1 | BX | R2 | R1 | =>control block | undefined, control block updated |
| Control block for calls>&7F | ||||||||
| &00 | Length of sent control block | |||||||
| &01 | Length of received control block | |||||||
| &02... | Any other parameters | |||||||
OSWORD &00 is the only call that is allowed to return data in registers. All other calls return data in the control block.
OSWORD calls with numbers &15-&7F must only have a maximum of 16 bytes in the control block. OSWORD calls with numbers greater than &7F must contain the number of parameters to send in the first byte of the parameter block, and the number of parameters to receive in the second byte of the parameter block, inclusive of the first two bytes. There are some calls that break this and will not work in all cases.
While it is not enforced by the API, the convention for high-numbered OSWORDs is for the control block contents to be:
- XY?0: length of sent block (required)
- XY?1: length of received block (required)
- XY?2: action
- XY?3: result, set to zero when calling
- XY!4 onwards: parameter data
Then calls are made with code along the lines of:
-
!XY%=&2008:XY%?2=6:XY%!4=data:CALL OSWORD:result=XY%?3
OSWORD calls with numbers &E0 to &FF are "available for use by the user" and are passed directly to USERV on the 6502 I/O processor.[1] [2] This makes them easier to implement as only USERV needs to be hooked into instead of WORDV, and &F0/&F1 is already prepared pointing at the control block.
Calling from BBC BASIC
-
INPUTcalls OSWORD &00 -
=TIMEcalls OSWORD &01 -
TIME=calls OSWORD &02 -
SOUNDcalls OSWORD &07 -
ENVELOPEcalls OSWORD &08 -
=POINTcalls OSWORD &09 -
=TIME$calls OSWORD &0E -
TIME$=calls OSWORD &0F
Entry points
- BBC BASIC Entry Address: &FFF1
- 6502 Entry Address: &FFF1, vectors via &020C
- Z80 Entry Address: &FFF1, vectors via &FFF2
- 6809 Entry Address: &FFF1, vectors via &FFF2
- 80x86 Entry Address: INT &4A, vectors via &0000:0128
- 32000 Entry Address: SVC &07
- PDP-11 Entry Address: EMT 3, vector &03
- ARM Entry Address: SWI &07 "OS_Word", vector &07
Bugs in implementations
Some ROMs OSWORD handlers have flaws that either cause their OSWORDs to not work properly, or cause other OSWORDs to not work properly. Of note are the following.
DFS 0.90
DFS 0.90 traps all' OSWORDs above &7F and treat them as OSWORD &7D due to the omission of a BMI exit instruction. This means that any high numbered OSWORD in any other ROM will fail to execute if it is in a lower ROM than DFS, and instead it attempts to read the disk.
DumpOut
DumpOut 3's teletext pixel reading OSWORDs use high numbered calls but without the correct header, meaning they fail on any second processor system or similar.
Morley RAMdisk
Uses a high numbered OSWORD without the correct header, so cannot be used from a second processor. The call is a data-transfer call and also only uses a 16-bit address, so cannot transfer across the Tube.
See Also
References
Jgharston 17:03, 6 November 2009 (UTC) Jgharston (talk) 00:10, 13 May 2020 (CEST)
