Update to bsnes v038r13? release.

<edit: removed outdated WIP>

**Delta queue support**

First up, I've added a binary min-heap delta queue. I converted all
events except IRQ/NMI test and hold. If we can convert these to use
the delta queue, there should be a speedup of 30-40% or so -- pretty
much the biggest low-hanging fruit there is. And the thing that has
plagued me for 12-18 months in the past before the major speed hit
v0.018 when I gave up and went with testing IRQ/NMI on every single
clock tick.

But it won't be easy: the delta queue works by adding an event when
you know its going to trigger. But we cannot _know_ if an IRQ or NMI
interrupt will trigger until we're at the current time. One can
literally disable or change these 2 clocks before they occur, which
would leave a bad trigger event in our queue.

IRQ/NMI hold also needs to be scheduled exactly four clocks after
IRQ/NMI trigger. Unless we queue these at least ~16 clocks in advance
of the trigger, then we may not be able to trip them exactly when
needed.

Since the test/hold are in the same inner loop, before or after the
delta queue time update, we can't just enqueue the hold and not the
test.

So, in the WIP I've included my insanely rigorous test ROMs for IRQ,
NMI and HDMA timing, and I'm asking for help. If anyone could please
help in merging sCPU::add_clocks() IRQ testing into the delta queue,
I'd be greatly in their debt.

Relevant code is at src/cpu/scpu/timing/[timing.cpp, irq.cpp] and
src/cpu/scpu/deltaqueue.cpp.

I'll be working on it as well, of course.

Note: removing events not at the top of the heap is not supported.
_If_ this is needed, it would probably be best to do an O(n) search
for the event, and overwrite the event code with 0 (meaning ignored)
than to try and pull out the event and renormalize the heap. IRQ/NMI
hold edge cases are very rare, so O(n) time shouldn't hurt speed.

**ALU delay**

Since there's no speed hit anymore, I added back hardware ALU (mul /
div) delays. While we still don't emulate the proper partial
calculation results, we should at least return 0 when reading too
soon.

The exact delay varies based upon the calculation, however. We ran
into problems with Taz-Mania in the past. So for this WIP only, I've
added settings to the advanced panel:
"temp.alu_mul_delay" + "temp.alu_div_delay"

The value has to be a _multiple of 2_ (2, 4, ... 32, 34, ...), and the
goal is to find the _highest_ possible value that will not cause any
bugs in games.

What I'm asking is for people to just set the value to something and
test a few games. If you spot a bug that's not in v038, try lowering
the value until it goes away. Then post the values here. We'll keep
lowering the current number until we find the best setting for future
releases.

Let's start with really high values that will definitely cause bugs:
ALU mul delay = 104
ALU div delay = 208

For example, pick any game ... say Zelda 3. Note how the triforces
won't render now. Lower the value until it works, post what numbers
you needed here plus the game name. Then everyone will use those
values and test other games. Rinse and repeat.

_Important note:_ you have to reset the game after changing these
values in the GUI for them to take effect.

**Fullscreen on startup**

I've added "video.start_in_fullscreen_mode". Because there's no way to
exit other than a keyboard shortcut, I've unhid the "Exit" option for
now. We can discuss the UI design stuff in the main v038 talk thread,
just stick to mentioning if you hit any bugs with it for this thread.

Thanks to all in advance for any help here!

[No archive available]
This commit is contained in:
byuu
2009-01-02 12:01:00 +00:00
parent de47a2c7de
commit 1a6de37454
Update to bsnes v038r13? release.

Diff Content Not Available
