Home Page Forums MAME MAME The SNES WIP topic

Print Thread

Page 58 of 120

…

119

120

Re: The SNES WIP topic Just Desserts #55902 11/02/09 06:59 AM
Joined: Jul 2007 Posts: 4,625 A Anna Wu Very Senior Member
Anna Wu Very Senior Member A Joined: Jul 2007 Posts: 4,625	Originally Posted by Just Desserts byuu, can I use your source code to try implementing full SGB support in MESS? If we add to the snes driver, we need a second cartslot ? One for the SGB/SGB2 cart and the second for the GB cart ? Anna's Playground for QMC2

Re: The SNES WIP topic Anna Wu #55904 11/02/09 07:15 AM
Joined: Jan 2006 Posts: 3,691 Trondheim, Norway etabeta78 Very Senior Member
etabeta78 Very Senior Member Joined: Jan 2006 Posts: 3,691 Trondheim, Norway	no. at the moment, I think the only solution would be to have a separate driver with the sgb bios and the gameboy hardware and you only load .gb carts to it [dream=on] in a perfect world (i.e. once we have devices everywhere in the source), we would have a single cartslot with a "child" cartslot device so that you emulate mounting the cart inside the sgb expansion [dream=off]

Re: The SNES WIP topic etabeta78 #55905 11/02/09 07:20 AM
Joined: Jul 2007 Posts: 4,625 A Anna Wu Very Senior Member
Anna Wu Very Senior Member A Joined: Jul 2007 Posts: 4,625	Originally Posted by etabeta78 no. at the moment, I think the only solution would be to have a separate driver with the sgb bios and the gameboy hardware and you only load .gb carts to it [dream=on] in a perfect world (i.e. once we have devices everywhere in the source), we would have a single cartslot with a "child" cartslot device so that you emulate mounting the cart inside the sgb expansion [dream=off] This will be great. So we can use also other special carts like BS-X . Last edited by Anna Wu; 11/02/09 07:22 AM. Anna's Playground for QMC2

Re: The SNES WIP topic Anna Wu #55923 11/02/09 05:17 PM
Joined: Jun 2008 Posts: 205 B byuu Senior Member
byuu Senior Member B Joined: Jun 2008 Posts: 205	It's the Sufami Turbo that is going to ruin that approach: http://www.gamersgraveyard.com/repository/snes/peripherals/sufamiturbo.html It accepts two carts, and you can create custom games by combining certain ones. So it's required to have a mechanism for loading more than one. And then there's the BS-X non-Satellaview carts like Same Game. You can optionally insert a BS-X data pack to give the game custom graphics, such as one for Tengai Makyou. I figured I may as well treat all multi-carts the same for consistency, although to be honest I do find it tedious to load multi-carts as it stands now.

Re: The SNES WIP topic Anna Wu #55925 11/02/09 05:21 PM
Joined: Mar 2005 Posts: 503 Likes: 1 Bradford, UK incog Senior Member
incog Senior Member Joined: Mar 2005 Posts: 503 Likes: 1 Bradford, UK	Originally Posted by Anna Wu This will be great. So we can use also other special carts like BS-X . Or the even more bizarre Bandai Sufami Turbo Edit: Damn, beaten to it. Last edited by incog; 11/02/09 05:22 PM.

Re: The SNES WIP topic incog #55934 11/02/09 06:14 PM
Joined: Jun 2008 Posts: 205 B byuu Senior Member
byuu Senior Member B Joined: Jun 2008 Posts: 205	That's good, now I don't have to double post http://img202.imageshack.us/img202/2235/bomberman2.png Multi-player is pretty simple. Here's a trace log of writes to $ff00: Code read from 14 1,0 read from 14 read from 14 1,1 0,1 read from 15 read from 15 read from 15 read from 15 read from 15 read from 15 1,1 read from 15 1,0 read from 15 read from 15 1,1 0,1 read from 12 read from 12 read from 12 read from 12 read from 12 read from 12 1,1 read from 12 1,0 read from 12 read from 12 1,1 0,1 read from 13 read from 13 read from 13 read from 13 read from 13 read from 13 1,1 read from 13 1,0 read from 13 read from 13 1,1 0,1 read from 14 read from 14 read from 14 read from 14 read from 14 read from 14 1,1 The pattern is obvious enough. Write 1,1 to select and read out the ID (increment ID# here) Write 1,0 to read out D-pad Write 1,1 again for some reason (do not increment ID# here) Write 0,1 to read out buttons ... Write 1,1 to select and read out the NEXT ID (increment ID# here) etc. Still working on some fine details regarding initial values, what happens with MLT_REQs, etc.

Re: The SNES WIP topic byuu #56000 11/03/09 05:21 PM
Joined: Jun 2008 Posts: 205 B byuu Senior Member
byuu Senior Member B Joined: Jun 2008 Posts: 205	Quote now I don't have to double post Or maybe I do, meh. Had a lot of trouble getting all games to detect the SGB hardware when using $6003.d5,d4 to determine 1-player/2-player/4-player mode for masking the joypad ID. Games like Shin Megami Tensei Devil Children were writing out MLT_REQ and then immediately reading the joypad ID. This gives the BIOS no time to react and update $6003. So I'll keep being evil for now: Code if(packetlock) { if(p15 == 1 && p14 == 0) { if((joyp_packet[0] >> 3) == 0x11) { mmio.mlt_req = joyp_packet[1] & 3; if(mmio.mlt_req == 2) mmio.mlt_req = 3; } Pull the MLT_REQ state right out of the packet once it completes. Technically no reason the hardware can't do this, although it'd be quite odd for it to use $6003 at all in that case. I also set it to not increment until both the D-pad and buttons for each controller has been read out. I'm not entirely sure how that's supposed to work, but this works for all the games I'm aware of, so ... whatever. This also eliminates the need for the strange 0xf - (joyp_id ^ 3) trick I was using to get past the SMT: DC SGB test. Next, Zelda DX v1.0 and v1.1 had some sort of glitch. Compare v1.0: Code MASK_EN 1,1 1,0 0,1 1,1 0,0 <- this starts a new packet transfer 1,0 0,1 1,1 1,0 0,1 1,1 With v1.2: Code MASK_EN 1,1 1,0 0,1 1,1 1,0 <- and yet it's missing here 0,1 1,1 1,0 0,1 1,1 It's sending a packet start transfer of P15=0,P14=0 periodically. With my previous release, this would eventually spit out a PAL01 command that sets all colors to black, effectively "turning the screen off." Given that there was a revision to fix this, I expect this bug existed on real hardware as well; but it was most certainly affected by the line hold time requirements. pandocs states: Quote Data and reset pulses must be kept LOW for at least 5us. P14 and P15 must be kept both HIGH for at least 15us between any pulses. So probably it was getting all 1's (which is an invalid command, likely ignored) or 1's and 0's. The latter is easy, just disable the if(strobelock) return; line. Fixes Zelda DX. The proper fix, which I'll work on for a later release, is likely to take the time a value has been set into account before acknowledging it and performing bus contention ORing and such. One will also note the lack of 1,1 hold that pandocs requests between the 0,1 and 1,0; as that's obviously a joypad polling routine with an errant 0,0 write mixed in somewhere. Next, audio. With stock SGB audio volume, the SNES sound effects are so quiet you can't even hear them. By dividing the SGB samples by 3, the two blend much better together. To handle the downsample from 2147KHz to 32KHz, blargg provided a moving average downsampler, which is said to be superior to a 4-tap hermite filter for this kind of difference. Code void Audio::coprocessor_sample(int16 left, int16 right) { if(r_frac >= 1.0) { r_frac -= 1.0; r_sum_l += left; r_sum_r += right; return; } r_sum_l += left * r_frac; r_sum_r += right * r_frac; uint16 output_left = sclamp<16>(int(r_sum_l / r_step)); uint16 output_right = sclamp<16>(int(r_sum_r / r_step)); double first = 1.0 - r_frac; r_sum_l = left * first; r_sum_r = right * first; r_frac = r_step - first; //write to sound card / mixing buffer / whatever here //this is called @ 32KHz output_coprocessor_sample(output_left, output_right); } Lastly, I also added save state support. Stupid, but fun. It might be easier to hook up libsupergameboy with Gambatte into MESS, and then work on merging over MESS' DMG core.

Re: The SNES WIP topic byuu #56002 11/03/09 05:25 PM
Joined: May 2009 Posts: 2,214 Likes: 382 J Just Desserts Very Senior Member
Just Desserts Very Senior Member J Joined: May 2009 Posts: 2,214 Likes: 382	Originally Posted by byuu It might be easier to hook up libsupergameboy with Gambatte into MESS, and then work on merging over MESS' DMG core. Disagreement. I'd wager if I had an up-to-date copy of your source tree, I could just use MESS's DMG core right away.

Re: The SNES WIP topic byuu #56003 11/03/09 05:28 PM
Joined: Apr 2004 Posts: 1,563 Likes: 12 J judge Very Senior Member
judge Very Senior Member J Joined: Apr 2004 Posts: 1,563 Likes: 12	Originally Posted by byuu Had a lot of trouble getting all games to detect the SGB hardware when using $6003.d5,d4 to determine 1-player/2-player/4-player mode for masking the joypad ID. Games like Shin Megami Tensei Devil Children were writing out MLT_REQ and then immediately reading the joypad ID. This gives the BIOS no time to react and update $6003. So I'll keep being evil for now: Code if(packetlock) { if(p15 == 1 && p14 == 0) { if((joyp_packet[0] >> 3) == 0x11) { mmio.mlt_req = joyp_packet[1] & 3; if(mmio.mlt_req == 2) mmio.mlt_req = 3; } Pull the MLT_REQ state right out of the packet once it completes. Technically no reason the hardware can't do this, although it'd be quite odd for it to use $6003 at all in that case. Could it be that it simply halts the cpu in such a case?

Re: The SNES WIP topic

judge #56006 11/03/09 06:30 PM

Joined: Jun 2008

Posts: 205

byuu

Senior Member

byuu

Senior Member

Joined: Jun 2008

Posts: 205

Quote

I'd wager if I had an up-to-date copy of your source tree, I could just use MESS's DMG core right away.

You always do, you have WIP access on my forum :P
And the latest supergameboy is up on my page: http://byuu.org/bsnes/

Here's the fixed joyp_write() function, which is the only difference from what is already available:

Code

void SuperGameBoy::joyp_write(bool p15, bool p14) {
  //===============
  //joypad handling
  //===============

  if(p15 == 1 && p14 == 1) {
    if(joyp15lock == 0 && joyp14lock == 0) {
      joyp15lock = 1;
      joyp14lock = 1;
      joyp_id = (joyp_id + 1) & 3;
    }
  }

  if(p15 == 0 && p14 == 1) joyp15lock = 0;
  if(p15 == 1 && p14 == 0) joyp14lock = 0;

  //===============
  //packet handling
  //===============

  if(p15 == 0 && p14 == 0) {
    //pulse
    pulselock = false;
    packetoffset = 0;
    bitoffset = 0;
    strobelock = true;
    packetlock = false;
    return;
  }

  if(pulselock) return;

  if(p15 == 1 && p14 == 1) {
    strobelock = false;
    return;
  }

  if(strobelock && (p15 + p14 != 0)) {
    //this is a malformed packet
    packetlock = false;
    pulselock = true;
    bitoffset = 0;
    packetoffset = 0;
  }

  if(strobelock) return;

  //p15:1, p14:0 = 0
  //p15:0, p14:1 = 1
  bool bit = (p15 == 0);
  strobelock = true;

  if(packetlock) {
    if(p15 == 1 && p14 == 0) {
      if((joyp_packet[0] >> 3) == 0x11) {
        mmio.mlt_req = joyp_packet[1] & 3;
        if(mmio.mlt_req == 2) mmio.mlt_req = 3;
      }

      if(packetsize < 64) packet[packetsize++] = joyp_packet;
      packetlock = false;
      pulselock = true;
    }
    return;
  }

  bitdata = (bit << 7) | (bitdata >> 1);
  if(++bitoffset < 8) return;

  bitoffset = 0;
  joyp_packet[packetoffset] = bitdata;
  if(++packetoffset < 16) return;
  packetlock = true;
}

It rejects invalid packets, which seems to work great for both Dracula and Zelda DX; without breaking any other games that I know of.

Quote

Could it be that it simply halts the cpu in such a case?

I suppose that is technically possible. I don't see a command to restart the SGB after packets are transmitted, and if we restarted after a $700f read, it'd still probably be too late to change $6003. Plus if the SGB got stopped in the middle of gameplay while sending packets, the audio would most likely stall out for a couple MS, which would cause sharp popping. Thus, it probably doesn't halt.

Page 58 of 120

…

119

120

Moderated by Bletch, R. Belmont, Richard Bannister

Link Copied to Clipboard