* Added github actions for PRs
* Added some rustfmt::skip attributes
* Applied formatting
* Added rustfmt component in action
* Configured to use rustfmt version 2 which fixes some comment formatting
* Removed ready_for_review condition for github actions
Since it has the synchronize condition, it will update after each
commit, whether in draft or not, so I think this should be alright
I'm trying to extract the memory/bus interface, and pass it in at
the start of each cycle instead of having the BusPort permanently
embedded, which will allow migrating to emulator-hal.
The functional way would be argument drilling; passing an extra argument
to each function in the entire execution core. The problem is that it's
messy, so a solution that is still functional is to implement all of the
execution logic on a newtype that contains a reference to the mutable
state and the owned cycle data, and at the end of the cycle, decompose
the M68kCycleGuard that holds the reference, and keep the cycle data for
debugging purposes.
The debug loop that reads a command and does something is part of the
frontend's main loop, so that it can potentially update, even though
it doesn't actually work for minifb because the command input is a
blocking call. It's also not implemented in the pixels frontend.
At some point I'll make a web frontend.
Special thanks to raddad772 https://github.com/raddad772
Also added some fixes to the Z80 for panicking math operations, but
it still won't complete due to an unimplemented instruction
It now sort of sounds like the main instrument, but the drums and bass
aren't there, and I'm not sure why. I'm pretty sure the envelope and
phase generators are working, and there is feedback although it might
not be correct. There's no LFO but that isn't used by Sonic 1 from
the register writes at least.
It was previously only updating the frequency if the A0 registers
were written last, but now it works the way the rate code does, using
the cached register values to set the frequency whenever a register
is written to. It also stores the fnumber and block in the operator
which I guess would be needed eventually if I want to save and restore
state.
- The envelope generator wasn't working as it should have, minor issues
with the limits and whether to use 10-bit or 12-bit values (more to come)
- fixed issues with sustain level where it was always set to 0
- fixed release rate and levels to make them 5-bit and 10-bit numbers
respectively, so they match the others
- switched from SineWave to SquareWave and this alone made it go from
terrible and muddy to not that far off. I probably need to completely
change the output
- also included an attempt at removing HostData, still needed for an
interrupt that is triggered by user input
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
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
