Home Page Forums MAME MAME The SNES WIP topic

r7679 /src/mame/machine/snes.c: [SNES]: Clear pending IRQ if the IRQ enable flag is disabled, fixes 3x3 Eyes - Seima Korin Den booting




Used the latter solution discussed with Arbee, since it's cleaner anyway.

Tested games a bit yesterday - here are some findings:

Graphic Issues:
Ardy Lightfoot (cave roof graphics)
Blues Brothers (pre-title)
Bugs Bunny - Rabbit Rampage (beginning of first level)
Super F1 Circus (J) (title Screen)
Tom and Jerry (in-game - "Tom and Jerry The Movie" sign - there are supposed to be round knobs, but there are twin halfs showing instead)
Super Genjin 2 (J) - (menu text at title is black)
Secret of Evermore - (@ title screen, repeating graphics) .. (mode 7 after first battle - when ship is crashing)

Not Working (black screen/hang):
Rendering Ranger R2 (J)
Rival Turf
Rushing Beat (J) [!]

Ho Ho Ho, spotted a g65816 core bug with F-1 Grand Prix Part 2:

C05940: LDA #$39
C05942: BMI c059a9 ($65)
C05944: ADC $858e65,X
C05948: STX $fea9
C0594B: SBC $950635,X
C0594F: ASL $8a
C05951: CLC
C05952: ADC #$40
C05954: BRK #$aa
00F04C: RTI



Do you need explainations? ;P

Looks like MESS is somehow reaching that code with the M flag in the wrong state.

Yeah, stack RAM pointer is somehow fucked up in current emu ... I see that BSNES register stack is equal to 0xe10 ... but in MESS is 0x5555, and that's obviously fucked up ...

Yeah, that's a classic "M=short, code is supposed to run with it long" disassembly.

Man, really sorry. I don't recall having bugs in any of the games you guys currently list as broken.


Sort of. class CPUcore is just the raw 65816. I actually do need to add some tiny things for some special SA-1 edge cases, though.

Both class sCPU and class SA1 inherit the 65816 core, and then add their own extra hardware units.


You're going to love some of the stuff you find in the future.

Here's a fun one ... game has the following:
-; bit $4211; bpl - //wait for IRQ acknowledgement

IRQroutine:
lda $4211 //clear IRQ acknowledgement flag
rti

Yes, the games can break out of that loop, and many will lock up if they do not. The Snes9X team gave up on trying to support this with an opcode-based core.

There is a 6-cycle hold time for the interrupt lines. If you read them at just the right time within them, you can:
- cancel the pending interrupt, or
- read the acknowledgement bit as set twice in a row

Ah, and the fun cli stuff that shows the two-stage pipeline nature of the 65xx chips. Since IRQs are tested on the bus opcode edge, that is one stage ahead of the work cycle to clear cli. Thus an IRQ can still trigger immediately after a cli instruction has executed. But rep/sep and rti are different, because their I flag is cleared sooner within the cycle.

I believe F-1 Grand Prix and Sink or Swim do something sick like trigger HIRQs more than one time on the same line or something. You guys should play those for a bit and see how they respond in MESS.


Sounds like it's reading from uninitialized WRAM. 0x55 is such a fun pattern, multiple titles break without it, despite the fact that SNES WRAM is DRAM-based, and is thus completely unpredictable upon power-up, with serious variations across each run.


Be sure to externalize the S-DSP gaussian interpolation table, and the S-DSP counter lookup table, and the S-PPU light table while you're at it
Pro tip: $2100 INIDISP display brightness of zero isn't absolute black. If you max out your TV settings, you can still see the image. And thus, the ramp is not linear in nature, nor does it operate in the RGB colorspace.


Indeed, I'm probably doing no good here.

There's lots of very edge-case games that require the most bizarre behavior you've ever seen. Like Speedy Gonzales and Wild Guns, for instance. But you guys are hitting some really simple things.

My discussion of these extreme edge cases is probably a mere distraction with the current state of things, and you'll probably just implement them incorrectly, possibly causing more bugs. The basics really need to be addressed first.

I guess what I'm hoping for in explaining the low-level stuff is that you guys will realize the futility of an opcode-based core, and move to cycle-based before you waste too much more time fixing up a dead end ...

By understanding the lowest level stuff now, you know exactly what your core will need to be able to handle, and can skip the 4-5 core rewrites I had to go through.

Also, one thing I will say, is that the VRAM write disable isn't hurting anything. Please don't even make that an option to bypass.

Regardless of whether or not it was ever their intention, the VRAM write issue has made ZSNES the IE6 of SNES emulators. It is the "extend" element of Microsoft's strategy. Why move to another emulator if it's going to break your (already broken) fan translations?

If your timing is really that awful, then adjust the range that you block writes. For instance, instead of blocking during V=0-224, change it to only block during V=8-216. Same effect, much more forgiving timing-wise.

We need every last emulator to counter this broken behavior and push for actual standards, so that we don't end up with more ZSNES-only software, perpetuating the negative feedback loop further.

don't worry. the only fact you wrote bsnes is a huge help. without it, we could only go back re-testing everything on the hardware; thanks to your help, we can currently simply fire up your emu and figure out what the expected behavior is.

Found, it's an open bus crapness:

C0516A: LDA $004212
C0516E: BIT #$01
C05170: BEQ c05178 ($6) <- it must jump here

It's weird though, in theory lda $4212 last open bus value should be 0x00, where it takes that needed 0x02?

Game works fine apart from this anyway:





EDIT:
Maybe ... LDA $4212 machine code is "0xaf 0x12 0x42 0x00"
So, the open bus for this specific opcode is either 0x42 / 0x12 and not 0x00?

EDIT2:
Actually, bit #$01 opcode indicates that is testing bit 0, not bit 1 like I've thought, yay for unclear dasm'ing ^^U

And the winner is ...

r7683 /src/mame/ (machine/snes.c includes/snes.h): [SNES]: Moved the i/o update status inside a timer, this fixes F-1 Grand Prix Part 2 booting

For whatever reason, the scanline timer was jumping from 240 to 257 (!), hence it wasn't updating the i/o status (that happens on line 242 in this case). I've forced that to happen on a separate timer.

Questions:
*Does I/O update happens when the NMI is disabled?

EDIT: notice that this update requires a clean recompile (or a forced driver/snes.c compile), otherwise inputs doesn't work at all.