Talk:OSWORD &7F
From BeebWiki
Contents |
Calling from Tube processor
- If the start of the data block lies within 16 bytes of the parameter block,
- it will be overwritten when the Tube client copies the parameter block back
- from the host.
Yes, overwritten with whatever was there anyway. As you can't modify that memory yourself bewteen calling OSWORD and OSWORD returning, there is no change, viz:
Call OSWORD sends 11-byte control block and 5 extra bytes:
aa bb cc dd ee ff gg hh ii jj kk LL MM NN OO PP
on return the block will be filled with:
rr rr rr rr rr rr rr rr rr rr rr rr MM NN OO PP
the control block bytes rr and whatever was after them.
True in most cases...
- but consider what happens during command &53. Supposing
- one allocates exactly the memory needed by the I/O processor:
DIM osword_block% 10, data_block% 255 ...
- The coprocessor sends these bytes:
dd aa aa aa aa nn cc pp pp pp rr MM NN OO PP QQ
- then during the command the capital bytes are replaced with the start of the
- read sector, only to be overwritten by their previous contents.
- Same thing if there was some timer or event driven counter in those bytes,
- hence 'volatile'. -- beardo 10:31, 22 December 2007 (UTC)
data_block% further on
In that example, the capital letters will be the variable header for 'data_block%':
dd aa aa aa aa nn cc pp pp pp rr LL LL 'a' 't' 'a' where LL is LINK address
The contents of data_block% which will be overwitten will be about five bytes past the end of the control block. You would only get that occurance if you did something like
DIM mem%:ctrl%=mem%:data%=mem%+10
A note on the OSWORD page is appropriate. Jgharston 14:57, 24 December 2007 (UTC)
Or...
DIM X% 10, T% 255 X%!1 = T%
However as you point out, the problem is not specific to OSWORD &7F. -- beardo 21:05, 24 December 2007 (UTC)
