Re: Decoding RamFactor's memory detection

[Hot Rod <hotrod.apple2@gmail.com>]

On Thursday, August 16, 2012 8:32:58 AM UTC-5, BLuRry wrote:
> Or rather I'm attempting to decode it anyway so I can get the bugs out of my RamFactor emulation code.  I've traced the screen write portion of the diagnostic routine and found where it starts writing "256" to the screen.  The question is, how is it getting the value for "2" to display?
> 
> 
> 
> A0 03 00 01F2 ..R...Z.  cbcc : DEX 
> 
> A0 02 00 01F2 ..R.....  cbcd : BPL $cb9f
> 
> A0 02 00 01F2 ..R.....  cb9f : LDA #$00
> 
> 00 02 00 01F2 ..R...Z.  cba1 : PHA 
> 
> 00 02 00 01F1 ..R...Z.  cba2 : SEC 
> 
> 00 02 00 01F1 ..R...ZC  cba3 : LDA $3e
> 
> 00 02 00 01F1 ..R...ZC  cba5 : SBC $cbde,X
> 
> 70 02 00 01F1 ..R.....  cba8 : PHA 
> 
> 70 02 00 01F0 ..R.....  cba9 : LDA $3f
> 
> 04 02 00 01F0 ..R.....  cbab : SBC $cbe3,X
> 
> 02 02 00 01F0 ..R....C  cbae : BCC $cbba
> 
> 02 02 00 01F0 ..R....C  cbb0 : STA $3f
> 
> 02 02 00 01F0 ..R....C  cbb2 : PLA 
> 
> 70 02 00 01F1 ..R....C  cbb3 : STA $3e
> 
> 70 02 00 01F1 ..R....C  cbb5 : PLA 
> 
> 00 02 00 01F2 ..R...ZC  cbb6 : ADC #$00
> 
> 01 02 00 01F2 ..R.....  cbb8 : BNE $cba1
> 
> 01 02 00 01F2 ..R.....  cba1 : PHA 
> 
> 01 02 00 01F1 ..R.....  cba2 : SEC 
> 
> 01 02 00 01F1 ..R....C  cba3 : LDA $3e
> 
> 70 02 00 01F1 ..R....C  cba5 : SBC $cbde,X
> 
> E0 02 00 01F1 NVR.....  cba8 : PHA 
> 
> E0 02 00 01F0 NVR.....  cba9 : LDA $3f
> 
> 02 02 00 01F0 .VR.....  cbab : SBC $cbe3,X
> 
> 00 02 00 01F0 ..R...ZC  cbae : BCC $cbba
> 
> 00 02 00 01F0 ..R...ZC  cbb0 : STA $3f
> 
> 00 02 00 01F0 ..R...ZC  cbb2 : PLA 
> 
> E0 02 00 01F1 N.R....C  cbb3 : STA $3e
> 
> E0 02 00 01F1 N.R....C  cbb5 : PLA 
> 
> 01 02 00 01F2 ..R....C  cbb6 : ADC #$00
> 
> 02 02 00 01F2 ..R.....  cbb8 : BNE $cba1
> 
> 02 02 00 01F2 ..R.....  cba1 : PHA 
> 
> 02 02 00 01F1 ..R.....  cba2 : SEC 
> 
> 02 02 00 01F1 ..R....C  cba3 : LDA $3e
> 
> E0 02 00 01F1 N.R....C  cba5 : SBC $cbde,X
> 
> 50 02 00 01F1 ..R....C  cba8 : PHA 
> 
> 50 02 00 01F0 ..R....C  cba9 : LDA $3f
> 
> 00 02 00 01F0 ..R...ZC  cbab : SBC $cbe3,X
> 
> FF 02 00 01F0 N.R.....  cbae : BCC $cbba
> 
> FF 02 00 01F0 N.R.....  cbba : PLA 
> 
> 50 02 00 01F1 ..R.....  cbbb : PLA 
> 
> 02 02 00 01F2 ..R.....  cbbc : BNE $cbc6
> 
> 02 02 00 01F2 ..R.....  cbc6 : INY 
> 
> 02 02 01 01F2 ..R.....  cbc7 : EOR #$b0
> 
> B2 02 01 01F2 N.R.....  cbc9 : JSR $fded
> 
> //------------------------------------------ WRITES 256k where A is '2'

So that last JSR is to the ROM routine for a charout (I think), and to get a '2', it is being called with #$B2 in the accumulator.

The #$B2 is a result of the EOR of #$B0 with the value in A (which was a #$02 at the time).

The accumulator ends up with a #$02 in it, because of the two ADC #$00 ops on it, each time having the carry bit set from the ops that precede those.  The accumulator was init'd with #$00, and on each 'second' PLA (when it's pulled off the stack) and the ADC #$00 is performed, the carry bit is evidently set, resulting in first #$01, and then #$02.  Then this is EOR'd with #$B0, and you get #$B2 sent to the $FDED routine (and a '2' on the screen).

(I'm still pretty rusty on this!)

]HR