PlayLoud!! Annex

■元記事
2011-03-10

---

MAMEのドライバでvblankを確認。toaplan2.c

1486      AM_RANGE(0x21c03c, 0x21c03d) AM_READ(video_count_r)

この辺が画面表示のタイミングを計るところなのかな、とアタリをつけておく。
併せて、MAMEでガレッガ基板のvideo_count_rの辺りを読みます。

  552  static READ16_HANDLER( video_count_r )
  553  {
  554      /* +---------+---------+--------+---------------------------+ */
  555      /* | /H-Sync | /V-Sync | /Blank |       Scanline Count      | */
  556      /* | Bit 15  | Bit 14  | Bit 8  |  Bit 7-0 (count from #EF) | */
  557      /* +---------+---------+--------+---------------------------+ */
  558      /*************** Control Signals are active low ***************/
  559  
  560      toaplan2_state *state = space->machine->driver_data<toaplan2_state>();
  561      int hpos = space->machine->primary_screen->hpos();
  562      int vpos = space->machine->primary_screen->vpos();
  563  
  564      state->video_status = 0xff00;                       /* Set signals inactive */
  565  
  566      vpos = (vpos + 15) % 262;
  567  
  568      bool hblank, vblank;
  569  
  570      hblank = (hpos > 325) && (hpos < 380); 画面に表示されない部分＋α？
  571      vblank = (vpos >= 247) && (vpos <= 250);
  572  
  573      if (hblank)
  574          state->video_status &= ~0x8000
  575      if (vblank)
  576          state->video_status &= ~0x4000
  577      if (vblank || hblank) // ?? Dogyuun is too slow if this is wrong
  578          state->video_status &= ~0x0100
  579      if (vpos < 256)
  580          state->video_status |= (vpos & 0xff);
  581      else
  582          state->video_status |= 0xff;
  583  
  584  //  logerror("VC: vpos=%04x hpos=%04x VBL=%04x\n",vpos,hpos,space->machine->primary_screen->vblank());
  585  
  586      return state->video_status;
  587  }

ガレッガの垂直方向は240ラインですが、このソースではvposというのが247〜250までのときVBlankらしいです。
21C03Chから2バイトには、上位にblank状態、下位にvposの位置が入るんですね。
　
で、上の21C03Chというアドレスにアクセスしている部分をガレッガのソースから探し出してみます。

;source1
00178E: 47F9 0021 C03C             lea     $21c03c.l, A3
001794: 163C 0098                  move.b  #$98, D3
001798: 3239 0010 0526             move.w  $100526.l, D1
00179E: 3413                       move.w  (A3), D2
0017A0: 6B00 0004                  bmi     $17a6
0017A4: 3413                       move.w  (A3), D2
0017A6: B403                       cmp.b   D3, D2
0017A8: 64F4                       bcc     $179e

;source2
0021E4: 3F07                       move.w  D7, -(A7)
0021E6: 3E39 0021 C03C             move.w  $21c03c.l, D7
0021EC: 6B00 0008                  bmi     $21f6
0021F0: 3E39 0021 C03C             move.w  $21c03c.l, D7
0021F6: 0C07 00F1                  cmpi.b  #-$f, D7
0021FA: 65EA                       bcs     $21e6
0021FC: 0C07 00FC                  cmpi.b  #-$4, D7
002200: 64E4                       bcc     $21e6
002202: 3E1F                       move.w  (A7)+, D7
002204: 4E75                       rts

;source3
002206: 3F07                       move.w  D7, -(A7)
002208: 3E39 0021 C03C             move.w  $21c03c.l, D7
00220E: 6B00 0008                  bmi     $2218
002212: 3E39 0021 C03C             move.w  $21c03c.l, D7
002218: 5307                       subq.b  #1, D7
00221A: 0C07 00EE                  cmpi.b  #-$12, D7
00221E: 64E8                       bcc     $2208
002220: 3E1F                       move.w  (A7)+, D7
002222: 4E75                       rts

21C03Chが登場するのは上の3ヶ所です。
デバッガで追ってみて、source1はvdpにアクセスする前、source2はテキストを描画する前、source3はBGを描画する前に通るルーチンのようです。たぶんw
source2では「F1h=241」〜「FCh=252」までの間を待っているので、これは順当にVBlankということなのでしょうか。
VBlankを待つというより、タイミングを見計らって書き込みに行ってる感じ？これだと結構シビアにタイミングを計算しないと破綻する気がするんですが……アーケードゲームだからその辺シビアなんでしょうか。