Previous Thread
Next Thread
Print Thread
Page 32 of 120 1 2 30 31 32 33 34 119 120
Joined: May 2009
Posts: 1,879
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,879
Star Fox:






Stunt Race FX:




Vortex:






byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?

Joined: Oct 2006
Posts: 988
S
Senior Member
Offline
Senior Member
S
Joined: Oct 2006
Posts: 988
Originally Posted By Just Desserts
I have your S-DD1 and S-RTC implementations ported over, but neither of them currently work, and I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip? I'd be surprised if the cart didn't just use a stock RTC from some third-party manufacturer, for which datasheets exist.


I'd be willing to look, if I can get a decent PCB scan for SHVC-AE6J-JPN.

- Stiletto

Joined: May 2009
Posts: 1,879
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,879
Originally Posted By Just Desserts

byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?


Incidentally, do you think those issues could be caused by mirroring where no mirroring is present, or having no mirroring where mirroring is present?

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)?

Thanks in advance.

Joined: Jan 2006
Posts: 3,687
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release

Quote:
SuperFX support was the work of many people. [snip] (for reference, the implementation in bsnes is my own design)


?

we included the SFX core (uniquely based on your implementation) on the assumption it was original design and, hence, PD as most of bsnes

finally, is Nach missing in action? I tried to contact him with no luck about some code of his...

Joined: Sep 2009
Posts: 7
N
Member
Offline
Member
N
Joined: Sep 2009
Posts: 7
Just a question,
did you read http://byuu.org/bsnes/license/ ?
I don't understand English perfectly but reading this I think that bsnes is not Public Domain, not exactly... wink

netol #53235 09/02/09 10:24 AM
Joined: Jan 2006
Posts: 3,687
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,687
ok, I've definitely chosen the wrong wording and it's not public domain (even if, since he started working on his emu, byuu himself defined Public Domain bsnes source for quite some time wink )

however, as byuu has stated many times, bsnes can be used freely as a base for implementation in other emu (and he already kindly donated to MESS part of the cart recognition code) and this kind of free reference implementation is what we need for MESS in this particular case wink

Joined: May 2009
Posts: 1,879
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,879
Grah. I'm trying to do a side-by-side execution comparison between bsnes and MESS, so as to track down the remaining issues, but for the life of me I can't compile bsnes. Every time I try to configure QT, the configure process just runs for a while and then hangs up at some point during it. When I get home from work I'll see if I can find out exactly where.

Joined: Jun 2008
Posts: 205
B
Senior Member
Offline
Senior Member
B
Joined: Jun 2008
Posts: 205
Quote:
I'm kind of confused as to how the S-RTC is supposed to work. Does it keep track of how much time has occurred since the last delta, or does it behave like a normal RTC chip?


Yes. The registers just return the current time. Don't give it localtime() info, or the "round clock to the nearest minute" feature of games won't work, and the time setting screens will be pointless. Plus it'll break in 2014, as you can't set the clock higher than that in FEoEZ.

All the extra code in bsnes is to let you specify whatever time you want, and update it as real system time passes. Plus it has to work around libc localtime()/mktime() issues with dates outside the system epochs (the S-RTC chips have no such limitation.) And lastly, I store a 4-byte timestamp no matter what (so the same .rtc state file works on 32-bit and 64-bit systems), and use some trickiness to work even beyond Y2K38. Fun stuff.

If you could, please keep compatibility with my .rtc file format. SNESGT uses the same. Snes9X stupidly appends it to the end of .srm files (causing all other emulators to erase it), and ZSNES just uses the current system time.

Quote:
byuu, does anything leap out at you as being a possible cause for the missing polygon fills on Starfox, the wheels being rotated by 90 degrees on Stunt Race FX as well as the horrific crashing upon going in-game, and the missing polygons on Vortex?


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.

Quote:
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.

Quote:
while at it, byuu, can you confirm the statement you gave at bsnes 0.047 release


Yes, that is correct. I looked at the Snes9X and SNESGT implementations, but wrote it all myself. And had a dozen bug fixes provided by Jonas Quinn. As you no doubt know, integrating someone else's CPU core is very tough, as they tend to hook all kinds of external stuff: IRQ triggers, a custom memory mapping system, etc.

Quote:
finally, is Nach missing in action? I tried to contact him with no luck about some code of his...


I haven't heard from him either. Both Nach and pagefault tend to disappear for months on end sometimes, though. Hard to say if anything is wrong or not. I certainly hope not.

Quote:
ok, I've definitely chosen the wrong wording and it's not public domain (even if, since he started working on his emu, byuu himself defined Public Domain bsnes source for quite some time wink )


It's kind of complicated. I defined all the special chip stuff as PD (except the modules I didn't write myself), but that was prior to SFX/SA1 support.

I don't mind if MAME or MESS use those cores, at any rate. In fact, I encourage it. If you guys use it, and then spot a bug, please let me know and we both end up benefiting. No need to reinvent the wheel, we aren't competing after all.

Quote:
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.

Quote:
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.

byuu #53241 09/02/09 06:14 PM
Joined: May 2009
Posts: 1,879
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 1,879
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:

Code:
  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
Quote:
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
Quote:
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
Quote:
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:

Code:
 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

Joined: Oct 2006
Posts: 988
S
Senior Member
Offline
Senior Member
S
Joined: Oct 2006
Posts: 988
Originally Posted By Just Desserts
Are there no pre-compiled binaries of Qt 4.5.2 anywhere? frown


Eh? http://qt.nokia.com/downloads

Is byuu modifying Qt or something? I'm not familiar with his makefile...

Page 32 of 120 1 2 30 31 32 33 34 119 120

Link Copied to Clipboard
Who's Online Now
3 members (AJR, R. Belmont, Vas Crabb), 57 guests, and 1 robot.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,834
Posts116,214
Members4,921
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.5