bsnes v0.037a released

Archived bsnes development news, feature requests and bug reports. Forum is now located at http://board.byuu.org/
Locked
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

creaothceann wrote: The reason why internal recording options are so immensely great, why e.g. the TASers maintain their own emulator forks if necessary, is that nothing gets lost. You get frame-perfect results, no matter how long it takes to render a frame. External programs like Fraps are inherently flawed in that regard.
Are you talking about videos here, or the WAV option? Because I doubt there's any perceptible difference between bsnes output and some external program for WAVs. If there was a 1% loss of quality, you'd have to explain the applications demanding it because we already have archival quality SPCs for every game.

I understand the argument for emulator format videos, but I wasn't referring to that. I don't even know if such a thing is possible in bsnes or how often it would be used over an emulator that had savestates. Seems to me that TASers wouldn't use bsnes regardless, which makes FRAPS good enough.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

FitzRoy wrote:because we already have archival quality SPCs for every game.
for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
Fras
Hazed
Posts: 54
Joined: Tue Jan 16, 2007 5:32 pm

Post by Fras »

byuu wrote:Do they make you drink it there? o.O
Nah, christmas times is just all about julmust here(sweden). :P

/random stuff in serious discussions.
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

About TAS, why not give people the option to try and run recorded input? Sure, they can't create it since there are no savestates, but bsnes is hardware accurate as far as possible, right?
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

Panzer88 wrote:
FitzRoy wrote:because we already have archival quality SPCs for every game.
for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.
SPC ripping would be preferable to a wav recorder because of the filesize difference, track isolation, and lack of an external option. A wav just records the sound of gameplay. I'm not really sure why you'd want to do that or what you'd use it for. But it's a function that can be accomplished externally with ease. If one program can do it well for everything externally, there's no need to depend on each and every program adding some kind of custom internal support. Even if they did, just try and remember how to on all those different programs. You just can't avoid using an external program, it works and works the same way for everything.
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

FitzRoy wrote:
Panzer88 wrote:
FitzRoy wrote:because we already have archival quality SPCs for every game.
for the most part, but the archive is still expanding, no? it isn't really COMPLETE per se, I'm just saying.
SPC ripping would be preferable to a wav recorder because of the filesize difference, track isolation, and lack of an external option. A wav just records the sound of gameplay. I'm not really sure why you'd want to do that or what you'd use it for. But it's a function that can be accomplished externally with ease. If one program can do it well for everything externally, there's no need to depend on each and every program adding some kind of custom internal support. Even if they did, just try and remember how to on all those different programs. You just can't avoid using an external program, it works and works the same way for everything.
Oh I completely agree, you misunderstood, I mean we are still expanding our SPC database, they aren't all dumped yet.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

I should correct myself, SPC is not archival quality, it doesn't capture an infinitesimal amount at the beginning. And there are games that stream data and won't rip to it. It's the best we have though, a slightly better format might be possible, but a perfect one may not be.
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

I thought someone HAD spec'ed a better format, and people just ignored it.

http://snsf.caitsith2.net/

Star Ocean and Tales of Phantasia rips, among other things.




And I'm sure this trips some drama with SOMEONE.
Rashidi
Trooper
Posts: 515
Joined: Fri Aug 18, 2006 2:45 pm

Post by Rashidi »

FitzRoy wrote:because we already have archival quality SPCs for every game.
not quite.

since .SPCs was simply a snapshot or 'savestate' of SPC700,
with the way of sound being programmed, some game music just can't be SPC-ed properly *cough* FEDA *cough*

i would love if someone may managed to made the .SPC version of that game, from SPC700 activity logs...

i do prefer SPC over WAV or stuff..
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

FitzRoy wrote:Are you talking about videos here, or the WAV option? Because I doubt there's any perceptible difference between bsnes output and some external program for WAVs.
I'm referring to both (WAV recording is a part of video recording). With external programs you get what you hear which can include audible clicks, especially if the PC is not fast enough to do both emulation and recording (maybe with compression) at the same time.

The standard scenario for an emulator is "one user, emulation at realtime, synchronization to the video and audio devices". That's a very restricted model though, and removing these restrictions can be worthwhile.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

henke37 wrote:About TAS, why not give people the option to try and run recorded input? Sure, they can't create it since there are no savestates, but bsnes is hardware accurate as far as possible, right?
This idea has crossed my mind before, but there's really not much point without being able to record. (you could record without savestates, but that's not very useful for a good TASer) The reason being that all it would accomplish is casting into doubt the validity of current TASes - despite the fact that it may not even be impossible for such a TAS to work on a SNES simply due to timing fluctuations in its components. bsnes -is- a lot closer to the mean, of course.
creaothceann wrote:I'm referring to both (WAV recording is a part of video recording). With external programs you get what you hear which can include audible clicks, especially if the PC is not fast enough to do both emulation and recording (maybe with compression) at the same time.
This is a true advantage, though don't forget that bsnes is already forced to resample all sound due to the odd frequency of the SNES. Even if it didn't, I'm not sure you can make a 32040Hz/16-bit wave or play it back correctly, in which case bsnes' resampling is better anyway since it can tell the SMP to produce more samples.. oh, I don't know.
creaothceann
Seen it all
Posts: 2302
Joined: Mon Jan 03, 2005 5:04 pm
Location: Germany
Contact:

Post by creaothceann »

Verdauga Greeneyes wrote:I'm not sure you can make a 32040Hz/16-bit wave or play it back correctly
You can - the WAV standard specifies the frequency as a 32-bit unsigned number. Playback would be handled by the audio driver.
vSNES | Delphi 10 BPLs
bsnes launcher with recent files list
Verdauga Greeneyes
Regular
Posts: 347
Joined: Tue Mar 07, 2006 10:32 am
Location: The Netherlands

Post by Verdauga Greeneyes »

creaothceann wrote:You can - the WAV standard specifies the frequency as a 32-bit unsigned number. Playback would be handled by the audio driver.
Fair enough. I guess that just leaves the question whether bsnes' resampling or the audio driver's resampling is the preferred choice.
Fras
Hazed
Posts: 54
Joined: Tue Jan 16, 2007 5:32 pm

Post by Fras »

Gil_Hamilton wrote:I thought someone HAD spec'ed a better format, and people just ignored it.

http://snsf.caitsith2.net/
I have tried the snsf's for blackthorne and lost vikings before. I observed that the tempo is too fast on some tracks, and one instrument even misses a part in a lost vikings track. Is the snsf player unfinished?
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

Heck if I know.
You'd have to ask Cait Sith about that.
FitzRoy
Veteran
Posts: 861
Joined: Wed Aug 04, 2004 5:43 pm
Location: Sloop

Post by FitzRoy »

The problem with SNSF is it isn't easy to create. If the game didn't have a sound test, and most don't, you need to be able to hack the rom AND isolate the music from the sound. Conversely, my grandmother could capture an SPC. An archival quality format is interesting, but useless if it doesn't beget an archive. WAV can be recorded with ease, unlike SNSF, but you still have to hack the rom to isolate the music and the filesize is much larger. They all have their drawbacks, but SPC is clearly the best. If a perfect format was possible, it would have been done already.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

SNSF shouldn't be harder to rip than say, USF. But the main trouble is that SPC is a 'quick and dirty' alternative that's enough for most people, so the new superior format doesn't quite shine as much as it could.

Oh hey, I heard that kind of stuff on another topic some time ago... better stop there. ^^
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Panzer88
Inmate
Posts: 1485
Joined: Thu Jan 11, 2007 4:28 am
Location: Salem, Oregon
Contact:

Post by Panzer88 »

FitzRoy wrote:If a perfect format was possible, it would have been done already.
oh really? since when has that been true in application to anything.
[quote="byuu"]Seriously, what kind of asshole makes an old-school 2D emulator that requires a Core 2 to get full speed? [i]>:([/i] [/quote]
Gil_Hamilton
Buzzkill Gil
Posts: 4294
Joined: Wed Jan 12, 2005 7:14 pm

Post by Gil_Hamilton »

FitzRoy wrote:The problem with SNSF is it isn't easy to create. If the game didn't have a sound test, and most don't, you need to be able to hack the rom AND isolate the music from the sound. Conversely, my grandmother could capture an SPC. An archival quality format is interesting, but useless if it doesn't beget an archive.
There's huge archives of NSF, PSF, SID, SAP, and whatever other format that requires hacking capability.


On the other hand, the first out the door usually has the advantage.
byuu

Post by byuu »

My understanding of SNSF is that the files are basically hacked-up ROMs with as much data as possible trimmed off.

That makes the player emulate both the CPU and SMP, so that they can talk to each other.

I understand the advantage of the approach -- it's more fault-tolerant to timing when you have multiple players. But it adds a ridiculous level of complication to things.

I'd prefer if we perfect the last very minor issues with our current SMP / DSP cores, and move to have one standardized pure C89 library for playing back sound files.

At that point, the files would be SPC+logged read accesses to $f4-$f7. No need for cutting up ROM files, or emulating a 65816, to play back music. And anyone can dump them, just as they can now with SPC files.

But yes, we want it to be as close to perfect as possible before we go making a bunch of dumps that a future revision of the player may break. We're close, though. Cycle-perfect SMP core, mul/div/daa/das and all associated quirks fully supported, DSP that's 99.9% bit-perfect, etc.
kode54
Zealot
Posts: 1140
Joined: Wed Jul 28, 2004 3:31 am
Contact:

Post by kode54 »

Logged read accesses would still require hacking in the event of players that stream all of the music data in real-time, at least some way to handle a loop on the log data. That's assuming anything needs to loop the log data for constant music playback.
byuu

Post by byuu »

Files that need SPC logging could also provide fade-outs. Otherwise, yes, you'd have to hack the SPC file up.
henke37
Lurker
Posts: 152
Joined: Tue Apr 10, 2007 4:30 pm
Location: Sweden
Contact:

Post by henke37 »

I still think that there is a point in supporting prerecorded input.
byuu

Post by byuu »

I believe I've finally got a decent working model for CPU<>PPU sync, with only a minimal compromise.

PPU cannot run ahead of CPU:

We know that many registers can be written mid-scanline and have immediate effects, these include at least the screen and BG enable commands. One can also modify OAM and CGRAM on a per-cycle basis.

CPU cannot ordinarily run ahead of PPU:

The CPU polls the V/H pins of the PPU every clock tick. The states are fairly predictable, but the lengths can change based on interlace and overscan settings.

Extreme 1:

Forcefully sync both processors every single clock tick, causing ~20M context switches a second. Too slow, eats up ~50% of a second just syncing; let alone emulation overhead.

Extreme 2:

Give each core its own completely independent PPU latch counter, forcefully sync whenever interlace and overscan are changed.

Compromise:

Keep only one PPU counter system, a class inside of the PPU itself. Use a tick/tock system and a ring buffer history, like so:

Code: Select all

void CPU::tick() {
  ppu.counter.tick();
  uint16_t v = ppu.counter.vtime();
  uint16_t h = ppu.counter.htime();
}

void PPU::tick() {
  ppu.counter.tock();
  uint16_t v = ppu.counter.vhist();
  uint16_t h = ppu.counter.hhist();
}

//called by CPU
void PPU::Counter::tick() {
  //this will deplete the ring buffer completely ...
  if(ring_buffer.is_full()) scheduler.sync_ppu_up_to_cpu();

  //save current value for the PPU later on ...
  ring_buffer.push(current_vcounter, current_hcounter);

  //here, we use ppu.interlace(), ppu.overscan() and ppu.field()
  //as needed, to properly increment the counter positions by one cycle.
}

//called by PPU
void PPU::Counter::tock() {
  //this will add at least one new entry to the buffer ...
  if(ring_buffer.is_empty()) scheduler.sync_cpu_up_to_ppu();

  //slide our FILO buffer forward by one time position
  ring_buffer.pop();
}

uint16_t PPU::Counter::v,htime() {
  //or to get really hard-core, we could return their blanking states
  //as a boolean, instead. though I see no advantage in doing this ...
  return current_v,hcounter();
}

uint16_t PPU::Counter::v,hhist() {
  return ring_buffer.v,hcounter();
}
Whenever the CPU writes to $[00-3f]:[2100-213f], we call scheduler.sync_ppu_up_to_cpu() so that the PPU will use the new values just-in-time. This would work exactly the same as the current CPU<>SMP sync on writes to $[00-3f]:[2140-217f].

The only big difference is that the PPU cannot run ahead. But, that should not cause any noticeable speed penalty. For each time the PPU syncs to the CPU, the CPU should easily be able to execute at least one full scanline before needing to switch control back to the PPU.

That would drop ~20m context switches to ~(262*60*2) or ~32k switches a second (assuming of course the app doesn't hammer the $21xx registers non-stop. I know of no SNES games that do.)

The nicest part of this approach is that 100% of the PPU counter implementation resides inside of the PPU, rather than having the CPU try and emulate the PPU timing.

So, if in theory, we were to throw a different PPU core in that ran at 640x480, with 525 scanlines per frame, the CPU would need absolutely no adjustments ... even IRQs would work as expected. True modularity that allows eg the bsnes CPU core to be plugged directly into an Apple II GS emulator, if desired.

And there's only one counter. No need to spawn two instances. Since the PPU never goes ahead of the CPU, and the CPU syncs the PPU on writes to the interlace and overscan registers, it's 100% safe to use cached counter values. We never have to worry about an edge case causing the two counters to desync (which would permanently break IRQ timing if they did.)

If we're really lucky, the counter values won't even be needed for an unrolled cycle-based PPU loop, except for the V=240 and V=261->262 or 0. Like how the cycle-based DSP runs in a fixed 32-cycle loop.

I'm thinking it will be best to shoehorn the PPU1 and PPU2 chips into a single class, like I do now. Just instead of having struct regs {}, have struct ppu1 {} and struct ppu2 {}; and clearly denote which chip is doing what for each cycle.

Now to see if I can work out a model to do this same thing with the current scanline-renderer ...

I'd really like to make this the primary target for work in 2009. Enough talk, time to get started on this already.
grinvader
ZSNES Shake Shake Prinny
Posts: 5632
Joined: Wed Jul 28, 2004 4:15 pm
Location: PAL50, dood !

Post by grinvader »

Good approach.

What do you intend to do about the 2 ppus ?
皆黙って俺について来い!!

Code: Select all

<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Locked