JMP [ABS+X] ($1F) で ABS+X の値が 0xFFFF の場合、ARAM $0000 の値が 0x00 として処理される。 about spcplay HOT 8 CLOSED

@GodGnilda さん
不具合をご報告いただき、ありがとうございます。

調査しましたところ、不具合を確認できました。
なお、ご指摘の JMP [labs+X] (opcode $1F) だけでなく、labs を引数として使用している各種命令、および、16bit 演算命令において影響があることが判明いたしました。

まとめますと、以下命令において、動作が変わります。

1. ご指摘のとおり、labs+X = $FFFF となった場合、正しい移動先の 16bit アドレスが取得できません。
   原因： 16bit アドレス参照時、下位 $FFFF、上位 $10000 が参照されるため

   JMP  [labs+X]     1F
   

2. 下記命令につきましては、オペコードの位置が $FFFE にある場合、labs (16bit 値) を正しく取得できません。
   原因： 16bit の引数値を参照時、下位 $FFFF、上位 $10000 が参照されるため

   MOV  A,labs       E5
   MOV  A,labs+X     F5
   MOV  A,labs+Y     F6
   MOV  X,labs       E9
   MOV  Y,labs       EC
   MOV  labs,A       C5
   MOV  labs+X,A     D5
   MOV  labs+Y,A     D6
   MOV  labs,X       C9
   ADC  A,labs       85
   ADC  A,labs+X     95
   ADC  A,labs+Y     96
   SBC  A,labs       A5
   SBC  A,labs+X     B5
   SBC  A,labs+Y     B6
   CMP  A,labs       65
   CMP  A,labs+X     75
   CMP  A,labs+Y     76
   CMP  X,labs       1E
   CMP  Y,labs       5E
   AND  A,labs       25
   AND  A,labs+X     35
   AND  A,labs+Y     36
   OR   A,labs       05
   OR   A,labs+X     15
   OR   A,labs+Y     16
   EOR  A,labs       45
   EOR  A,labs+X     55
   EOR  A,labs+Y     56
   INC  labs         AC
   DEC  labs         8C
   ASL  labs         0C
   LSR  labs         4C
   ROL  labs         2C
   ROR  labs         6C
   JMP  labs         5F
   JMP  [labs+X]     1F
   CALL  labs        3F
   TEST1 labs        OE
   TCLR1 labs        4E
   

3. 下記命令につきましては、引数の値が $FF の場合、ダイレクトページを超えてメモリ参照が行われます。
   原因： 例えばダイレクトページが 0 の場合、下位 $00FF、上位 $0100 が参照されるため

   MOVW YA,dp        BA
   MOVW dp,YA        DA
   INCW dp           3A
   DECW dp           1A
   ADDW YA,dp        7A
   SUBW YA,dp        9A
   CMPW YA,dp        5A
   

上記不具合につきまして、下記リリースで修正しております。
お手数をおかけし申し訳ありませんが、お試しください。
https://github.com/dgrfactory/spcplay/releases/tag/2.18.4.7352

from spcplay.

@GodGnilda さん
早速ご確認いただき、ありがとうございます。

1. SNESAPU.DLL が pAPURAM + 0x10000 の値を参照しないのであれば、処理速度が低下してしまうだけである。
2. SPC ファイル読み込み直後など、pAPURAM + 0x10000 の値が pAPURAM + 0x0000 の値と異なることがある (SNESAPU.DLL のメンテナンスが困難になる可能性がある)。

先日の返信におきまして、説明が不足しておりました。 申し訳ありません。
上記についてですが、改善版では pAPURAM + 0x10000 の値を参照するようにしております。
（ご要望通り、RAM 参照時の命令において、値取得の直前に pAPURAM + 0x0000 の値を 0x10000 にコピーし、word サイズでの取得時は、L:0xFFFF H:0x0000 に見えるよう対処しております。）

メモリコピーのオーバーヘッドは確かに出ますが、速度低下につきましてはほとんど影響がないものとの認識です。
そのため、エミュレーションの正確性向上にもなりますので、修正を採用させていただきたく存じます。

7. Mov PC,[ESI-2] 使用するオペコードが $FFFD または $FFFE にある場合、ESI-2 が pAPURAM - 1 または pAPURAM - 2 となるため正しい移動先の 16bit アドレスを取得できないことを確認いたしました。

新たな不具合のご報告、ありがとうございます。
確認させていただきますので、お待ちください。

【追記】
CALL labs の不具合を、以下リリースにて対応いたしました。
（[ESI-2] を使用せず、Sub SI,2 で下位16bit のみ減算されるよう修正）
確認が不足しており、お手数をおかけし、申し訳ありませんでした。
https://github.com/dgrfactory/spcplay/releases/tag/2.18.4.7354

from spcplay.

@dgrfactory 様

早々にご回答いただき大変恐れ入ります。

エミュレーションの正確性向上にもなりますので、修正を採用させていただきたく存じます。

承知いたしました。

ご要望通り、RAM 参照時の命令において、値取得の直前に pAPURAM + 0x0000 の値を 0x10000 にコピーし、word サイズでの取得時は、L:0xFFFF H:0x0000 に見えるよう対処しております。

値取得の直前にですので、SNESAPUCallbackProc (effect = CBE_S700FCH) 実行時は pData の 下位 16bit の値が 0xFFFE または 0xFFFF の場合、addr の値には画像のように pAPURAM + 0x0000 は最後にコピーが実行されたときの値、pAPURAM + 0x0001 (と pAPURAM + 0x0002) は 0 が指定されることを確認いたしました。

3 下記命令につきましては、引数の値が $FF の場合、ダイレクトページを超えてメモリ参照が行われます。

すべてのオペコードでダイレクトページを超えないメモリ参照が行われることを確認いたしました。

CALL labs の不具合を、以下リリースにて対応いたしました。
（[ESI-2] を使用せず、Sub SI,2 で下位16bit のみ減算されるよう修正）

オペコードが $FFFD または $FFFE にある場合も正しい移動先の 16bit アドレスを取得できることを確認いたしました。

from spcplay.

@GodGnilda さん
早速、ご確認いただきまして、ありがとうございます。
また、SNESAPUCallbackProc についても、挙動のご確認・ご報告、感謝いたします。

CBE_S700FCH のコールバックについて、マニュアルでは下記通り記載されていることから、
コールバック直前において、$0000～$0003 の内容を $10000～$10003 にコピーする対応を行います。

Script700 にも同様の問題がございますが、こちらは用途がかなり限定されておりますので、
こちらは制限事項とし、マニュアルに注意書きを追記いたします。
https://dgrfactory.jp/spcplay/script700.html#script_param_list

【追記】
CBE_S700FCH の問題につきまして、下記で修正しております。
お手数おかけして申し訳ありませんが、ご確認いただきますよう、よろしくお願い申し上げます。
https://github.com/dgrfactory/spcplay/releases/tag/2.18.4.7356

from spcplay.

@dgrfactory 様

1. #27 (comment) のオペコードが正しく動作することを再確認いたしました。

2. CBE_S700FCH のコールバックで正しい addr の値が指定されることを確認いたしました。

3. LadpX マクロを使用するオペコードは v2.18.4.7350 と同じ動作であることを確認いたしました。

   $E7  MOV      A,[dp+X]
   

4. LadpY マクロを使用するオペコードは v2.18.4.7350 と同じ動作であることを確認いたしました。

   $F7  MOV      A,[dp]+Y
   

ご修正いただきありがとうございます。

from spcplay.

@dgrfactory 様

早速に、ご返信恐れ入ります。

もし動作変更なさる場合は、他の命令と同じように PC への設定が 16 ビットアクセスのみで実現できるように、メモリへのデータ転送命令実行時に [pAPURAM + 0x10000] へ [pAPURAM + 0x00000] の値をコピーする処理を追加してくださいますか。

この件ですが、

• Visual Studio 2019 がうまく最適化できるようなコードを書けないので、コールバック相当の処理をインラインアセンブリを使用して書き換える予定である (アセンブリであれば下位 8・16 ビットだけ変化させるのは容易であるし、マクロを用意すればインライン関数の実体が残ることもない)。
  
• SNESAPU.DLL が pAPURAM + 0x10000 の値を参照しないのであれば、処理速度が低下してしまうだけである。
• SPC ファイル読み込み直後など、pAPURAM + 0x10000 の値が pAPURAM + 0x0000 の値と異なることがある (SNESAPU.DLL のメンテナンスが困難になる可能性がある)。
  

以上の理由で、誠に勝手ながら取り下げさせていただきたく存じます。

1 ご指摘のとおり、labs+X = $FFFF となった場合、正しい移動先の 16bit アドレスが取得できません。

2 下記命令につきましては、オペコードの位置が $FFFE にある場合、labs (16bit 値) を正しく取得できません。

本日は上記の件についてご報告いたします。以下のオペコードで確認いたしました。

1. Mov PC,[OP1] を使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $5F  JMP      labs
   

2. Labs マクロを使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $E5  MOV      A,labs
   $C5  MOV      labs,A
   $0E  TEST1    labs
   $4E  TCLR1    labs
   

3. LaabsX マクロを使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $1F  JMP      [labs+X]
   

4. LabsX マクロを使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $F5  MOV      A,labs+X
   $D5  MOV      labs+X,A
   

5. LabsY マクロを使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $F6  MOV      A,labs+Y
   $D6  MOV      labs+Y,A
   

6. Lmbit (Labs) マクロを使用するオペコードが $FFFE にある場合、正しい移動先の 16bit アドレスを取得できることを確認いたしました。

   $EA  NOT1      mem.bit
   

7. Mov PC,[ESI-2] 使用するオペコードが $FFFD または $FFFE にある場合、ESI-2 が pAPURAM - 1 または pAPURAM - 2 となるため正しい移動先の 16bit アドレスを取得できないことを確認いたしました。

   $3F  CALL      labs
   

   
   

from spcplay.

@GodGnilda さん
今回もご協力いただきまして、誠にありがとうございます。
また何か動作でおかしい点がございましたら、お気軽にお問合せください。

from spcplay.

修正版がリリースされました。 クローズします。
https://github.com/dgrfactory/spcplay/releases/tag/2.18.4.7379

from spcplay.