blargg's SPC test ROMs
Moderator: Moderators
Forum rules
- For making cartridges of your Super NES games, see Reproduction.
-
- Posts: 32
- Joined: Thu Jan 24, 2019 1:35 am
Re: blargg's SPC test ROMs
Great, thank you. So what you sent me is what I should be outputting. Let's have a look at DAS.
-
- Posts: 32
- Joined: Thu Jan 24, 2019 1:35 am
Re: blargg's SPC test ROMs
Hi Kingizor,
How did you get this output. Is it via an emulator?
I can now get a pass but then it then freezes. Is it possible to get hold of the assembler code to see what the rom does.
How did you get this output. Is it via an emulator?
I can now get a pass but then it then freezes. Is it possible to get hold of the assembler code to see what the rom does.
Re: blargg's SPC test ROMs
It seems to run one pass with the running hash, then checks the final result against what it expects. If the two hashes don't match it runs a second pass but logs each interim result along the way. Therefore, one can make it produce that list by damaging the running hash as the first pass is being run. By doing that in an emulator that would otherwise pass, it willl produce the list of "correct" hashes for each step.
Your output (in particular the "Passed 01" message at the bottom), indicates all the listed opcodes are fine so the issue seems to lie somewhere else. This is where things get tricky because there are a lot of reasons things might go wrong. It looks as though it completes the first pass successfully but doesn't manage to convey that back to the CPU, so it ends up running the second pass anyway and uploads the results.
I'd check that writes to $F1 are only clearing the ports on the SMP side, and that the 4-in, 4-out behaviour is correct on both sides.
If it's neither of those, then I'm not really sure. Whatever it is, it's probably not something that would affect most games, so I'd be happy to ignore it for the time being.
Your output (in particular the "Passed 01" message at the bottom), indicates all the listed opcodes are fine so the issue seems to lie somewhere else. This is where things get tricky because there are a lot of reasons things might go wrong. It looks as though it completes the first pass successfully but doesn't manage to convey that back to the CPU, so it ends up running the second pass anyway and uploads the results.
I'd check that writes to $F1 are only clearing the ports on the SMP side, and that the 4-in, 4-out behaviour is correct on both sides.
If it's neither of those, then I'm not really sure. Whatever it is, it's probably not something that would affect most games, so I'd be happy to ignore it for the time being.
-
- Posts: 32
- Joined: Thu Jan 24, 2019 1:35 am
Re: blargg's SPC test ROMs
Thank you again Kingizor. I have checked the APU IOs and they work fine. There must be something else wrong and I suspect it comes from my CPU code. I need to to test/simulate each opcode with a fine tooth comb.
Re: blargg's SPC test ROMs
Really aggressive CPU instruction validation is a large missing component in the entire emulation scene.
The test suites all rely on the CPU core to be mostly functional, and some of the video circuitry implemented, in order to even run them.
But if you have a bug in a critical CPU instruction, you're in for a world of pain. The best I've found is to find another emulator and generate an instruction trace log from it, and then go line by line looking for bad flag / accumulator calculations.
A testing framework needs to be able to evaluate each instruction, without any other part of the CPU being present. That's not an easy problem, and one I'm not up for trying to solve right now, but at least you can be ~95% sure that someone evaluating a CPU interpreter is going to be using C or C++, so C would be the language of choice for the evaluation framework.
The test suites all rely on the CPU core to be mostly functional, and some of the video circuitry implemented, in order to even run them.
But if you have a bug in a critical CPU instruction, you're in for a world of pain. The best I've found is to find another emulator and generate an instruction trace log from it, and then go line by line looking for bad flag / accumulator calculations.
A testing framework needs to be able to evaluate each instruction, without any other part of the CPU being present. That's not an easy problem, and one I'm not up for trying to solve right now, but at least you can be ~95% sure that someone evaluating a CPU interpreter is going to be using C or C++, so C would be the language of choice for the evaluation framework.
Re: blargg's SPC test ROMs
Then perhaps the answer is to start with a direct port of "nestest" (a basic 6502 test suite by kevtris) to SPC700, so that an emulator developer can detect where PC/AXY diverge from a known good trace. This should help shake out the most obvious problems with "critical" instructions.
Re: blargg's SPC test ROMs
- spc_dsp6.sfc
- spc_mem_access_times.sfc
- spc_spc.sfc
- spc_timer.sfc
---
did byuu change something? mesen s is the only emulator who passed all tests.
- spc_mem_access_times.sfc
- spc_spc.sfc
- spc_timer.sfc
---
did byuu change something? mesen s is the only emulator who passed all tests.
Re: blargg's SPC test ROMs
I pass them.
Re: blargg's SPC test ROMs
you did. now i know what's going on. spc_dsp6 and spc_timer failed since bsnes 110.1. https://github.com/byuu/bsnes/commit/6e ... f7fc06a969
but spc_mem_access_times and spc_spc... i have no idea. even a pretty old version failed.
edit
they work now with bsnes.
but spc_mem_access_times and spc_spc... i have no idea. even a pretty old version failed.
edit
they work now with bsnes.
Last edited by bklD on Wed Oct 30, 2019 12:03 pm, edited 1 time in total.
Re: blargg's SPC test ROMs
Oh, it's recent. Needed more details.
It's this issue:
https://github.com/SourMesen/Mesen-S/issues/40
https://github.com/byuu/bsnes/issues/124
Change in question:
Well, hopefully Sour has some ideas because I sure don't.
It's this issue:
https://github.com/SourMesen/Mesen-S/issues/40
https://github.com/byuu/bsnes/issues/124
Change in question:
Code: Select all
auto SMP::read(uint16 address) -> uint8 {
//wait(address); //if the wait is here, blargg's tests pass
uint8 data = readRAM(address);
if((address & 0xfff0) == 0x00f0) data = readIO(address);
wait(address); //if the wait is here, Kishin Douji Senki boots
return data;
}
Re: blargg's SPC test ROMs
oh, so mesen s doesn't emulate this game yet and that's why spc_dsp6 is working.
Re: blargg's SPC test ROMs
I haven't had the chance to look into this just yet. Was mostly busy trying to finish up the features I wanted to add before releasing 0.3.0 the past couple of weeks (just released 0.3.0 an hour ago or so.) With most of the basic emulation features finally out of the way, I'll probably get back to trying to fix the last few games that don't work properly because of small IRQ/NMI/DMA/SPC timing issues (presumably)byuu wrote:Well, hopefully Sour has some ideas because I sure don't.
Though given that your original fix causes blargg's test to fail, I'm not looking forward to tackling this particular bug :p
I'll let you know if I find something.
Re: blargg's SPC test ROMs
Yeah. Writing an SNES emulator is playing Whack-a-Mole with 3000 active moles.oh, so mesen s doesn't emulate this game yet and that's why spc_dsp6 is working. :)
Awesome, that would be much appreciated! I'm intensely burned out right now ^-^;;I'll let you know if I find something.
I think between these test ROMs and Kishin Douji Zenki, I'll leave the latter broken for now.
Re: blargg's SPC test ROMs
what exactly does blragg's speed_2_freezes2? startup routines? that's the only rom that failed with bsnes now
https://snescentral.com/article.php?id=1115
https://snescentral.com/article.php?id=1115
- Attachments
-
- speed_2_freezes2.smc
- (64 KiB) Downloaded 233 times
Re: blargg's SPC test ROMs
That tests the SMP TEST register. It was based on older, incorrect assumptions about the test register.
With me, AWJ, and a few others, we figured out the rest of the bits of the TEST register: they controlled internal and external wait states.
Different SNES models have different lock-up percentages with the wait state settings, and some real SNESes fail that test from blargg as well.
We're all good now, don't worry about blargg's SMP/DSP test ROMs anymore please unless there's a regression.
With me, AWJ, and a few others, we figured out the rest of the bits of the TEST register: they controlled internal and external wait states.
Different SNES models have different lock-up percentages with the wait state settings, and some real SNESes fail that test from blargg as well.
We're all good now, don't worry about blargg's SMP/DSP test ROMs anymore please unless there's a regression.