It turns out to not be too much of a performance issue to allocate
a new frame each time one is produced, so to reduce lock contention
I added a queue where frames are added to and taken from without
locking the frame for the whole update. I'm hoping this will give
more flexibility to frontend implementations, which can simply
skip or repeat frames if needed.
Mortal Kombat 2 was working but somewhere while getting the harte
tests to work, I fixed interrupts to change the flags before they're
pushed to the stack, in order to match the expected behaviour from
the tests when an address error occurs (sr is changed and the stack
push causes the error). I correctly saved the state of sr in the
function for group0 interrupts, to push to the stack later, but the
normal interrupts was saving sr *after* the flags were changed...
Now it saves sr beforehand
I also included some changes to the gfx interface to allow taking
frames, to fix a compile error introduced by the last commit.
I wanted to make this a bit more modular, so it's easier in theory to
write external crates that can reuse bits, and selectively compile in
bits, such as adding new systems or new cpu implementations
There are still some failures on the SBCD, but the logic is identical
to other emulator's calculations, but the test case doesn't seem to be
the way it should behave, so I'll leave it for now
The signed division overflow was incorrect, and I tried a few bit-wise
approaches, but using the signed 32-bit number to determine 16-bit
overflow using greater than/less than work perfectly
There was also a bug in exception handling where it would push values
to the stack before setting the supervisor flag, but the push funcs
use the supervisor flag to determine which stack pointer to use, so
when an exception happened in user mode, it was pushing to USP when
it should have pushed to SSP
The I/N bit in the special status word on the stack should be set
when returning from RTE results in a PC that isn't word aligned.
Every other case pretty much, it should be clear
Adjusted the PC value stored when an Address Error fault occurs to
use the size of the access operation.
I also flipped the IN bit in the word that's written to the top of
the stack on an AddressError, even though that's opposite of what
the docs say. It seems to pass the tests. I probably have something
else going wrong, but it shouldn't be an important bit either way.
Added support for RTR and RESET.
Fixed flags behavior for ASd
Added function to set PC, and fixed some instruction's handling of
an address fault a bit better
Some debug code was enabled that prevented illegal instructions
from being handled normally with a processor exception
The brief instruction word decoding could cause an illegal instruction
if it didn't match the docs, but the actual implementation would not
complain in those cases, so I modified it to not perform validation
for <=MC68010
Increment and Decrement addressing modes, when using the stack pointer,
will always inc/dec by at least 2 bytes, even if it's a byte operation,
to keep the stack aligned to the nearest word boundary
For instructions that use an operand twice, where it called
get_target_value and set_target_value, if the addressing mode was
one where it would increment or decrement a pointer, it was
causing a double inc/dec because of the two calls to get/set target.
I added an argument to let the functions know if they will be called
twice, in which case it assumes that get will be the first and set
will be the second, and inc/decs only once in the appropriate function
for whether it pre-incs or post-decs
