New S-DSP emulator progress

[blargg]

I'd like to get some general feedback about how integration of the new S-DSP emulator is going, problems encountered, etc. so I can address them. Here are some issues I've identified:

DSP interface: RE efforts show that DSP examines its registers at various times between output samples, so the interface will need to be changed at some point to accept the clock count (1.024 MHz) rather than sample count (32 kHz). Currently the DSP emulator does nothing for 32 clocks, then generates a sample, then does nothing for 32 more clocks, etc.

Save State Interface: I want to work out how the DSP state is saved and restored. I removed it from the most recent version since it needs more work before it's stable. I looked at zstate.c and its scheme makes sense. Would the following interface work?

Code: Select all

typedef void (*dsp_copy_func_t)( unsigned char**, void*, size_t );
void dsp_copy_state_data( unsigned char* buf, dsp_copy_func_t );

The copy_state_method doesn't seem necessary, since the DSP doesn't need to do anything special based on what's happening.

Emulation Changes: As more information is found, the DSP emulator's behavior will change. This might break some movies/save states that were made with earlier versions. What should be done about this?

Save State Format: RE efforts are uncovering more internal DSP state, so the format must allow future additions. It could either be variable sized or have several reserved bytes set to 0. I don't think we'll uncover too much new internal state.

Full SPC emulator module: If it is ever decided that my full SPC emulator (spc.h) will get used, I can add an SPC save function. Otherwise, it's not a priority for me.

[byuu]

I'd really like to work with you on subsample accurate emulation. Though very difficult, it should be a lot less painful than subscanline emulation for the S-PPU. I have a copier so with a little practice I can learn to start running my own tests.

If you want, I can easily add support for your S-DSP emulator into bsnes as well, though I'd still like to keep anomie's too. I already support runtime polymorphism for all core components. My S-DSP interface is as minimal as possible:

Code: Select all

class DSP {
public:
  virtual uint8  read (uint8 addr) = 0;
  virtual void   write(uint8 addr, uint8 data) = 0;

  virtual void   power() = 0;
  virtual void   reset() = 0;
  virtual uint32 run()   = 0;

  DSP() {}
  virtual ~DSP() {}
};

I can also trivially set the number of times run() is called per second to eg 1.024mhz, 32khz, etc. run() presently returns an audio sample, but that's trivial to change, eg bool run(uint32 &sample); return true when sample was generated.

[Nach]

Save State Interface: I want to work out how the DSP state is saved and restored. I removed it from the most recent version since it needs more work before it's stable. I looked at zstate.c and its scheme makes sense. Would the following interface work?

Code: Select all

typedef void (*dsp_copy_func_t)( unsigned char**, void*, size_t );
void dsp_copy_state_data( unsigned char* buf, dsp_copy_func_t );

The copy_state_method doesn't seem necessary, since the DSP doesn't need to do anything special based on what's happening.

Emulation Changes: As more information is found, the DSP emulator's behavior will change. This might break some movies/save states that were made with earlier versions. What should be done about this?

Save State Format: RE efforts are uncovering more internal DSP state, so the format must allow future additions. It could either be variable sized or have several reserved bytes set to 0. I don't think we'll uncover too much new internal state.

The interface you speak of with these issues is something we designed ~2 years ago to make life simple. Yet we find it has issues with future proofing.

We hope to in the near future to switch our entire state system over to PSR technology. While we can't guarantee movie sync between versions, state should be compatible. With PSR, we can have it that some vars don't exist in a state, but in that case it'll know to use the defaults, parse correctly, and continue from there with no need for any reserved bytes.

So ideally the entire state should be PSR based for the DSP, however I fully understand if that's not possible for you. In which case we'll need a simple function which allows us to copy bytes one way to another such as:

Code: Select all

void state_copy(buffer, (void *(*)(void *, void *, size_t))

And take memcpy() or memrcpy().