It does something, but doesn't work as it should. It could be a few
things including the on/off signal being too slow due to how time
works in the sample generation, but I wanted to at least commit what
I have. It seems to work roughly right according to the forum post
that describes the chip's operation in detail, but there could still
be some glaring bugs
The hope was that this would reduce the amount of copying and bit
shifting required by the frontend to get the data on screen, but
it doesn't seem to offer much advantage, surprisingly. I'll leave
it in though. There are a few other minor tweaks included here to
try to improve the performance a bit
It was using the DAC value as a positive offset, which makes a slight
click at the start and end of the SEGA voice at the start of a game.
now subtracts half the value and amplifies it a bit so that it
crosses the 0 value
It wasn't copying the frame data from the sources to the output frame
correctly, and there was a small period of zeros at the start of the
frame.
I also converted to using a vec of tuples for the two channels to
make it easier to reason about, since some of the issues were related
to the differences sizes calculated from the clock based on the sample
rate
If the sim is running slower than 60Hz, it was using the frame limiter
to not apply because no frame was drawn, and so it would end up running
at full speed. Minifb can save the last frame without cloning it, and
redraw the same frame if no new frame is ready, which allows the limiter
to still delay the next frame, so slower speeds work. This was also
preventing things that didn't update the screen from allowing inputs
including escape to have any effect
AddressRepeater now takes the range it should repeat over, which only
really affects its reported size.
AddressAdapter is now AddressRightShifter, which is literally the operation
it performs, where the input is still the bits to shift the address right by
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
