* 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.
It now actually checks the clock and tries to mix the audio in sync
relative to the clock, but the cpal output doesn't yet try to sync
to the StreamInstant time. Sound seems a lot better on chrome in
wasm, but and kind of better on firefox despite frame skipping not
being supported yet, but it's way slower for some reason (12fps)
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 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
