Re: BGMODE or parameter changes during scanline
Posted: Fri Aug 07, 2015 5:02 pm
> It works on a Super NES, which is what matters.
You would think that, but experience shows me otherwise.
We found a bug that caused Der Langrisser to freeze in ZSNES, especially when you hit the fast forward key. We reported it to them in 1998, pagefault said he'd fix it soon, and it's still broken in 2015. It also apparently happens periodically in Snes9X v1.43 and earlier.
When we released the game, we warned people about the emulator bugs, and recommended real hardware or bsnes.
On the first day of release, we had two people accuse us of making the fan translation "bsnes-only", even though the original Japanese game had the same issue.
TL;DR: people are really, really stupid.
> This is a wake-up call to nocash and the 9x team to get their behinds in gear.
I think the 9x team is pretty much dead. They're all still around, but we're over four years out from the last release now, with no signs of project life.
I do know of one other emulator that has pixel-based PPU timing, but it's not public. Also have not heard anything on that in over a year, so it may be dormant/dead, not sure.
> Perhaps that's why it's 5 slow cycles, not 4: to let the previous cycle finish.
It certainly could be.
(H)DMA has a really bizarre and complex clock sync system for its DMAs (it first syncs the CPU clock tick count to a multiple of 8, then does the DMA, then syncs it back to a multiple of the last CPU cycle's clock count, then resumes.) But that causes a variable length of extra clock cycles, which DRAM refresh doesn't exhibit, so that's not what DRAM refresh is doing.
> Might NES timing details (the 513/514 cycle OAM DMA thing and the DMC DMA waiting a few cycles for an interrupt's triple-write to finish) inspire something?
It doesn't for me.
You would think that, but experience shows me otherwise.
We found a bug that caused Der Langrisser to freeze in ZSNES, especially when you hit the fast forward key. We reported it to them in 1998, pagefault said he'd fix it soon, and it's still broken in 2015. It also apparently happens periodically in Snes9X v1.43 and earlier.
When we released the game, we warned people about the emulator bugs, and recommended real hardware or bsnes.
On the first day of release, we had two people accuse us of making the fan translation "bsnes-only", even though the original Japanese game had the same issue.
TL;DR: people are really, really stupid.
> This is a wake-up call to nocash and the 9x team to get their behinds in gear.
I think the 9x team is pretty much dead. They're all still around, but we're over four years out from the last release now, with no signs of project life.
I do know of one other emulator that has pixel-based PPU timing, but it's not public. Also have not heard anything on that in over a year, so it may be dormant/dead, not sure.
> Perhaps that's why it's 5 slow cycles, not 4: to let the previous cycle finish.
It certainly could be.
(H)DMA has a really bizarre and complex clock sync system for its DMAs (it first syncs the CPU clock tick count to a multiple of 8, then does the DMA, then syncs it back to a multiple of the last CPU cycle's clock count, then resumes.) But that causes a variable length of extra clock cycles, which DRAM refresh doesn't exhibit, so that's not what DRAM refresh is doing.
> Might NES timing details (the 513/514 cycle OAM DMA thing and the DMC DMA waiting a few cycles for an interrupt's triple-write to finish) inspire something?
It doesn't for me.