Home Page Forums MAME MAME The SNES WIP topic

blargg cracked it.

http://board.byuu.org/viewtopic.php?f=16&t=562&p=12138#p12138

That passes all of the adc+sbc tests. It's calculating overflow prior to the last ADC/SBC decimal-mode adjustment.

Adapting to 16-bit mode should be easy enough.

Cool, so once again nintendo doing things slightly different from what you'd normally expect.

Awesome I'll test on the real non-SCPU 65816 after work today. Would be interesting to get a test on a real 6502 also, but I don't have any of those.

My real Apple IIgs gives A=00, P=7B in both 8-bit native mode and emulation mode, and "mess apple2gs" gives A=00, P=3B so overflow is definitely wrong. And it's not something Nintendo broke even.

I've implemented blargg's 8-bit versions in both 8-bit and 16-bit, by extending his algorithm appropriately. Source code is here:

http://board.byuu.org/viewtopic.php?p=12151#p12151

Given lda #$0123; adc #$4567: regs.a.w = 0x0123, rd.w = 0x4567

It's definitely correct for all 8-bit x 8-bit combinations.

I'd certainly appreciate it if anyone could confirm the new BCD code is correct, as I can't exactly test 16-bit x 16-bit full combinations on a 3MHz SNES with 32KB SRAM

I suppose we should add the new ADC/SBC versions to both the Apple II GS and SNES cores in MESS, too.

Isn't that amazing, though? 15 years of SNES research and we never got add or subtract right, heh ...

Actually MESS only has one 65816 core that both drivers use for the moment, so it's easier

Decimal mode is rarely used, and using it outside the "obvious" bounds even less so so I'm not surprised it went forever without getting hit.

Arbee is right. This is at least the fifth investigation into SNES BCD in the last 12 years.

And every time the result is "oops. Bugs!"

byuu, one way to counter the 32 KB limit is "don't store results from the SNES in SRAM, store the emulated results in the ROM". Of course, you'd need to CRC-16 or checksum the results to get a full scan in, and then you'd need to actually check the failed pages later, but it gives you almost 4 MB to play with instead of 32K. It takes you a step further from the hard numbers because you can only get down to "these 8K results add up correctly" or so. But it's a different approach than is usual.

Creating the same 16-bit x 16-bit test set that I used for the 8-bit version would require 16GB of storage. Each of the 16 tests would take approximately three full days to complete. And that's just running the tests.

Getting it to a PC, my fastest method would be blargg's serial controller, so I would have to add a 16GB transfer over a dial-up modem connection to the 48 days already needed.

I'm sorry, but not even I am that dedicated to accuracy.


Well at least we know with 100% certainty now that the 8-bit versions are correct, once and for all.

-----

EDIT: and the latest results:
http://board.byuu.org/viewtopic.php?f=16&t=562&p=12168#p12168

I've confirmed with 100% certainty that my (blargg's) 8-bit implementations are perfect. I've also confirmed that my adaptations to extend blargg's 6502 implementation to 16-bit 65816 is correct for ADC BCD accumulator results. I am unable to test ADC BCD flag results, or SBC BCD accumulator or flag results. Again only in 16-bit mode.

But flags are substantially easier than math to extend from 8-bits to 16-bits. And the extension to ADC is the same as the extension to SBC.

Thus, I am 99.9% sure my implementations are bit-perfect, both in 8-bit and 16-bit mode. I would be very surprised if not.

So if you guys want to implement it to your core, the final versions are listed in this post:
http://board.byuu.org/viewtopic.php?p=12151#p12151

Can you port the theoretical code for adc/sbc TO the snes (without actually using decimal mode on the snes) and then have the snes sequentially do actual adc/sbc ops, then do software emulation, and compare the two (and throw an error to screen if they don't match)? I know MooglyGuy had something similar for testing mess's n64 rsp core vs the real one on the n64 itself, though I don't know what happened to it...

LN

It would take several days to execute the adds directly. To emulate the adds in 65816 would make it days weeks or months to complete.

Here is an 8-bit ADC/SBC BCD + flag test from blargg:

http://rapidshare.com/files/362042163/test_adc_sbc.zip.html

Passes in bsnes v061r02 with the updated algorithms.

Fails in bsnes v061, Snes9X v1.52, Super Slueth v1.04f, SNESGT v0.230b6, MESS v0.136, and ZSNES v1.51.