blargg's SPC test ROMs

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
bklD
Posts: 12
Joined: Fri Sep 01, 2017 8:56 am

Re: blargg's SPC test ROMs

Post by bklD » Wed Oct 30, 2019 8:20 am

i'm sorry. i was just curious. thank you for the explanation.

Near
Founder of higan project
Posts: 1550
Joined: Mon Mar 27, 2006 5:23 pm

Re: blargg's SPC test ROMs

Post by Near » Wed Oct 30, 2019 9:38 pm

I don't mind, you did catch a valid regression earlier so that's appreciated.

In any case, a new finding:

smp_mem_access_times only works when the timers take the full wait cycle to match the cadence of writes, eg:

Code: Select all

auto SMP::read(uint16 address) -> uint8 {
  step(24);
  uint8 data = readRAM(address);
  if((address & 0xfff0) == 0x00f0) data = readIO(address);
  return data;
}
And Kishin Douji Zenki - Tenchi Meidou only works when the CPU port reads take less time than writes, eg:

Code: Select all

auto SMP::read(uint16 address) -> uint8 {
  step(12);
  uint8 data = readRAM(address);
  if((address & 0xfff0) == 0x00f0) data = readIO(address);
  step(12);
  return data;
}
Which is what I refer to as bus hold delays: the idea that reads tend to occur sooner within their opcode cycles than writes, eg $2137 reads vs $4201 writes for latching the PPU counters.

So a workable solution for both is thus the rather unlikely to be correct:

Code: Select all

auto SMP::read(uint16 address) -> uint8 {
  if((address & 0xfffc) == 0x00f4) {
    step(12);
    uint8 data = readRAM(address);
    if((address & 0xfff0) == 0x00f0) data = readIO(address);
    step(12);
    return data;
  } else {
    step(24);
    uint8 data = readRAM(address);
    if((address & 0xfff0) == 0x00f0) data = readIO(address);
    return data;
  }
}
There's multiple possibilities here, but it's probably just that there's some extra time required for reads and/or writes to certain registers to take effect, similar to the Game Boy APU registers (eg triggering the wave channel takes longer than modifying wave RAM.)

Unfortunately with the CPU and APU using separate oscillators, I don't know of a way we could even design a test ROM to narrow down exactly what's going on here. Help would be very much wanted, but for now we have something that's at least a little more accurate if not exactly correct.
Last edited by Near on Wed Oct 30, 2019 9:40 pm, edited 1 time in total.

User avatar
FitzRoy
Posts: 141
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: blargg's SPC test ROMs

Post by FitzRoy » Wed Oct 30, 2019 9:39 pm

byuu wrote:We're all good now, don't worry about blargg's SMP/DSP test ROMs anymore please unless there's a regression.
A regression in commercial games or the test roms themselves? Just making sure you're aware that spc_dsp6 still fails midway at "hidden env 0 at kon". On snes9x, it fails earlier at "edl 0 quirk".

Near
Founder of higan project
Posts: 1550
Joined: Mon Mar 27, 2006 5:23 pm

Re: blargg's SPC test ROMs

Post by Near » Wed Oct 30, 2019 9:41 pm

Disable the fast DSP setting and it passes just fine with the latest WIP. I just tested it right now.

User avatar
FitzRoy
Posts: 141
Joined: Wed Oct 22, 2008 9:27 pm
Contact:

Re: blargg's SPC test ROMs

Post by FitzRoy » Wed Oct 30, 2019 9:46 pm

Yep, my bad.

Post Reply