Difference between revisions of "Talk:OSBYTE &97"

From BeebWiki
Jump to: navigation, search
m (no assembling across pages)
(Bug in indexed addressing: ~)
 
(One intermediate revision by the same user not shown)
Line 6: Line 6:
  
 
However, the indexed addressing mode bug only manifests if the calculated address crosses a page boundary from the base address. For instance, STA &FCF0,X where X=16 crosses from page &FC to page &FD to read the byte at &FCF0+16=&FD00. (What happens in this case is that &FC00 is erroneously read and then &FD00 is written.) As all the 'read/write I/O' OSBYTEs index from &xx00 they will never cross a page boundary, so the bug will not manifest.
 
However, the indexed addressing mode bug only manifests if the calculated address crosses a page boundary from the base address. For instance, STA &FCF0,X where X=16 crosses from page &FC to page &FD to read the byte at &FCF0+16=&FD00. (What happens in this case is that &FC00 is erroneously read and then &FD00 is written.) As all the 'read/write I/O' OSBYTEs index from &xx00 they will never cross a page boundary, so the bug will not manifest.
:Sonninen ''et al.'' document <tt>STA abs,x</tt> as always taking 5 cycles in [http://rk.nvg.ntnu.no/bbc/doc/6502.txt 64doc] – three instruction reads, the dummy read (as the address is not yet known to be correct), then the write.  This is confirmed in the [http://www.visual6502.org/JSSim/expert.html?graphics=f&loglevel=2&steps=50&a=0000&d=9d0000 Javascript 6502 simulator].  For proof, time the following program running under MOS 1.20:
+
:Sonninen ''et al.'' document <tt>STA abs,X</tt> as always taking 5 cycles in [http://rk.nvg.ntnu.no/bbc/doc/6502.txt 64doc] – three instruction reads, the dummy read (as the address is not yet known to be correct), then the write.  This is confirmed in the [http://www.visual6502.org/JSSim/expert.html?graphics=f&loglevel=2&steps=50&a=0000&d=9d0000 Javascript 6502 simulator].  For proof, time the following program running under MOS 1.20:
 
<pre>  10 MODE 2
 
<pre>  10 MODE 2
   20 clsvec=&35D:cls=&CC02:oswrch=&FFEE
+
   20 clsvec=&35D:cls=&amp;CC02:oswrch=&amp;FFEE
 
   30 DIM code 511
 
   30 DIM code 511
 
   40 P%=code+255 AND NOT 255
 
   40 P%=code+255 AND NOT 255
Line 22: Line 22:
 
   140 CLC:ADC #1:BCC loop
 
   140 CLC:ADC #1:BCC loop
 
   150 .done
 
   150 .done
   160 PLP:LDA #7:JSR oswrch
+
   160 JSR cls
   170 LDA #0:JMP cls
+
   170 LDA #7:PLP:JMP oswrch
 
   180 ]
 
   180 ]
 
   190 CALL test
 
   190 CALL test
 
</pre>
 
</pre>
:There are 65538 × 20480 <tt>STA abs,x</tt> instructions, none crossing a page boundary, plus approx. 76 seconds' worth of overhead (at 2 MHz); each cycle of the <tt>STA</tt> instructions adds 11m11s to the running time.  The program completes in 57 minutes rather than 46, showing that each <tt>STA</tt> instruction takes 5 cycles. [[User:Regregex|Regregex]] ([[User talk:Regregex|talk]]) 16:38, 18 April 2016 (UTC)
+
:There are 65538 × 20480 <tt>STA abs,X</tt> instructions, none crossing a page boundary, plus approx. 76 seconds' worth of overhead (<tt>cls=&amp;CCF2</tt>); each cycle of the <tt>STA</tt> instructions adds 11m11s to the running time.  The program completes in 57 minutes rather than 46, showing that each <tt>STA</tt> instruction takes 5 cycles. [[User:Regregex|Regregex]] ([[User talk:Regregex|talk]]) 16:38, 18 April 2016 (UTC)

Latest revision as of 10:40, 4 May 2016

Bug in indexed addressing

This article originally had the following warning:

Acorn MOS 1.20 writes the byte using STA &FE00,X. As it is an indexed-addressing instruction, the 6502 CPU performs a dummy read immediately before the write. Some hardware, though not all, may operate inappropriately due to the dummy read: outputs could momentarily be set to the wrong level, or an interrupt condition could be cleared and lost. Review the datasheet for the hardware being accessed to see whether it will be adversely affected.

However, the indexed addressing mode bug only manifests if the calculated address crosses a page boundary from the base address. For instance, STA &FCF0,X where X=16 crosses from page &FC to page &FD to read the byte at &FCF0+16=&FD00. (What happens in this case is that &FC00 is erroneously read and then &FD00 is written.) As all the 'read/write I/O' OSBYTEs index from &xx00 they will never cross a page boundary, so the bug will not manifest.

Sonninen et al. document STA abs,X as always taking 5 cycles in 64doc – three instruction reads, the dummy read (as the address is not yet known to be correct), then the write. This is confirmed in the Javascript 6502 simulator. For proof, time the following program running under MOS 1.20:
   10 MODE 2
   20 clsvec=&35D:cls=&CC02:oswrch=&FFEE
   30 DIM code 511
   40 P%=code+255 AND NOT 255
   50 [OPT 0
   60 .test
   70 PHP:SEI
   80 LDA #cls MOD 256:STA clsvec
   90 LDA #cls DIV 256:STA clsvec+1
  100 LDA #0:TAX:TAY
  110 .loop
  120 JSR cls
  130 INY:BNE loop
  140 CLC:ADC #1:BCC loop
  150 .done
  160 JSR cls
  170 LDA #7:PLP:JMP oswrch
  180 ]
  190 CALL test
There are 65538 × 20480 STA abs,X instructions, none crossing a page boundary, plus approx. 76 seconds' worth of overhead (cls=&CCF2); each cycle of the STA instructions adds 11m11s to the running time. The program completes in 57 minutes rather than 46, showing that each STA instruction takes 5 cycles. Regregex (talk) 16:38, 18 April 2016 (UTC)