Originally Posted by byuu
Not at all, sorry. For me, horrible crashing was usually due to opcode bugs, and I haven't had any of the other issues.

Are you handling IRQ communications between chips properly? Eg the GSU STOP command and such.

I think so:

  775              case 0x00: // STOP
  776                  if(!(cpustate->cfgr & SUPERFX_CFGR_IRQ))
  777                  {
  778                      cpustate->sfr |= SUPERFX_SFR_IRQ;
  779                      cpustate->irq = 1;
  780                  }
  781                  cpustate->sfr &= ~SUPERFX_SFR_G;
  782                  cpustate->pipeline = 0x01;
  783                  superfx_regs_reset(cpustate);
  784                  break;

It makes perfect sense for the IRQ flag to be set in SFR, but I wasn't able to track down where exactly the "irq" class member variable is used. It doesn't appear to have a purpose inside your Super FX core, and I didn't find anything referring to it in the rest of the emulator. Is this true?

Originally Posted by byuu
Basically, what I want to know is: if the SuperFX reads from a SuperFX memory address of 0x712345, does it actually read from index 0x2345 in the FX RAM buffer? If the S-CPU reads from 0x356789, is this the same as a read from 0x306789, which itself is a read from index 0x789 in the FX RAM buffer (due to mirroring)?

I would strongly advise you to handle the mirroring properly (per my map on the previous page.) But I couldn't say for sure, mirroring was one of the first things I did.

No offense intended, but that was the entire reason why I asked those two questions. smile

I'm still having some trouble wrapping my head around where, exactly, a given byte write to a given address by the S-CPU goes in relation to what the SuperFX chip then gets back. Those two questions were carefully designed such that, when answered correctly, will give me most of the info I need to do that.

I'd hazard a guess that I probably have the mirroring correct now, though, or there would be far worse problems, since SRFX and Vortex are at least drawing most of their triangles, and SF is now drawing line "primitives" (but not triangles).

Originally Posted by byuu
Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it.

Ironically, the Windows port is the worst version of Qt. The OS X version is pre-compiled, and the Linux version is even easier: a single apt-get command.

Are there no pre-compiled binaries of Qt 4.5.2 anywhere? frown

Originally Posted by byuu
I'm trying to do a side-by-side execution comparison between bsnes and MESS

The timing differences will make it very hard to compare line-by-line, but be aware of the disasm modules for all of my cores. You will have to hook calls to it yourself in the ::enter() routines, and put the data in files yourself. v048 may be better, it had part of a tracing interface. I'm in the process of redoing that for a debugger as of v049+, so it will be harder to work with there.

The timing differences are immaterial, as I would only be logging the opcodes executed by the Super FX chip. Also, I'm not interested in a diassembly, I'm interested in actually printf-ing the full register state after every single opcode, using some format like:

 R0=0000  R1=1111  R2=2222  R3=333
 R4=4444  R5=5555  R6=6666  R7=7777
 R8=8888  R9=9999 R10=aaaa R11=bbbb
R12=cccc R13=dddd R14=eeee R15=ffff
 DR=0     SR=0    SFR=0000

...and then make MESS output exactly the same thing. It'll produce a gigantic log file, probably a number of gigs in size, but that's not an intractible problem, I'd just use a binary diff program rather than visually diffing.

Trust me, this is how we tend to do things with MAME and MESS. smile