Open bus findings

[byuu]

So I'm toying around with open bus... I'm going to update this post/thread as I work on it to make sure I don't miss anything.

I'm going with info from here:
http://www.snes9x.com/forum/topic.asp?TOPIC_ID=7293

STAT78 (Version 2.0)
Bit 5 ------ Complement Bit 5 of last value read from $2138,$213c,$213d.

Yet below it states that reading $213b,$213c,$213d update the PPU2 latch.

I tested the latches by a ton of random $213b,$213c,$213d reads with random values in CGRAM.
I noticed that the top 7 bits of reads from $213c/$213d (when reading the top bit of the latch counters) do in fact get updated from any reads from $213b-$213d.

Ok, great. I tried getting STAT78 right next. First thing I noticed is that $213b reads modify bit 5 of STAT78. Second, it doesn't appear to be the complement, but the direct value, at least on my SNES (2/1/3 NTSC region 0).

lda $213b ;A=#$FF
lda $213f ;A=#$23
lda $213b ;A=#$00
lda $213f ;A=#$03

---

$2138 reads do not affect $213c/$213d/$213f reads in any way I can see. Default PPU2 latch value at reset seems to be #$ff. Hard to tell, I can only notice this by reading $213f immediately at reset (giving me only bit 5). Could be that the latch value isn't updated at reset and the copier did something that made bit 5 get set.

$2137 reads always give me #$00. This could be because my copier screws up the CPU open bus. Should this just return the CPU MDR like $43xc-$43xe? I'd think all the PPU regs would be special cased.

...back to testing...

[Overload]

So I'm toying around with open bus... I'm going to update this post/thread as I work on it to make sure I don't miss anything.

I'm going with info from here:
http://www.snes9x.com/forum/topic.asp?TOPIC_ID=7293

STAT78 (Version 2.0)
Bit 5 ------ Complement Bit 5 of last value read from $2138,$213c,$213d.

Yet below it states that reading $213b,$213c,$213d update the PPU2 latch.

Must be a typo, PPU1 handles OAM, should be $213b. I'm not sure why i got those results. It might be a PAL thing?

I tested the latches by a ton of random $213b,$213c,$213d reads with random values in CGRAM.
I noticed that the top 7 bits of reads from $213c/$213d (when reading the top bit of the latch counters) do in fact get updated from any reads from $213b-$213d.

Also, on the second read of $213b only 7 bits are updated.

$2137 reads always give me #$00. This could be because my copier screws up the CPU open bus. Should this just return the CPU MDR like $43xc-$43xe? I'd think all the PPU regs would be special cased.

Yep. The register doesn't return any data so the MDR is not updated.

[byuu]

Also, on the second read of $213b only 7 bits are updated.

Whoa, nice catch! Thanks.

New findings:

Ok, everything else appears to be correct.

I also verify $21[0-2][4-6,8-a] are PPU1 open bus, the rest being unmapped -> CPU MDR (up to $2133 of course).

I still don't understand STAT77 bits 4 and 5... bit 4 appears to be set upon first read when the SNES is reset. I dunno why.
I read the explanations for them but they still don't make sense.

Now for the weird part... reading $213e updates the PPU1 latch, but reading $213f does NOT update the PPU2 latch. Why in the hell not? >_<

[Overload]

I still don't understand STAT77 bits 4 and 5... bit 4 appears to be set upon first read when the SNES is reset. I dunno why.
I read the explanations for them but they still don't make sense.

I don't know what these bits are. Bit 4 is wierd.

Now for the weird part... reading $213e updates the PPU1 latch, but reading $213f does NOT update the PPU2 latch. Why in the hell not? >_<

I don't know.

[Edit]

Did you try reading $213b, $213f, then $213b again and check bit 7?

[byuu]

Did you try reading $213b, $213f, then $213b again and check bit 7?

Yeah, TRAC pointed out my flawed logic :/
Reading $213f set the $213c/$213d read positions back to zero, so of course I didn't see any of $213f in the next $213c/$213d read.

Code:

Code: Select all

  stz $2121
  lda #$ff : sta $2122
  lda #$7f : sta $2122

;we start out on interlace field 0
  stz $2121
  lda $213b
  lda $213f ;bit 7 should be clear
  lda $213b : sta $700000

- lda $4212 : bpl -
- lda $4212 : bmi -

;now we're on interlace field 1
  stz $2121
  lda $213b
  lda $213f ;bit 7 should be set
  lda $213b : sta $700001

That returns 0x7f, 0xff. So $213f does update the PPU2 latch/MDR value. Sorry about that :/

Ok, I got all the CPU ones in now, too.
JOYSER1 is weird that it has always 1 values, but I get the same thing.
No qualms with RDNMI/TIMEUP/HVBJOY.
Lastly, JOYnH. Bits 7-4 don't go anywhere on the controller, but I guess it is a 16-bit value since auto joypad read accesses $4016 sixteen times each frame...

Hurray, that turned out to be a lot easier than I thought. Anyone know of a really good example game I can try that would fail without open bus support? :D

[creaothceann]

Anyone know of a really good example game I can try that would fail without open bus support? :D

Well, from the thread you linked to:

Also I believe Mortal Combat uses the bit 7 latching of $4201 if you wanted a real world example of it in use.

The Electronics Test in the SNES Test Cart does too.

[byuu]

That has nothing to do with open bus.

[Overload]

A few games have problems without Open Bus

Accele Brid, Equinox, Captain America and the Avengers (E), Shien's Revenge, Rock & Roll Racing, Super Play Action Football, DKC2