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 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
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
Also fixed a bug where MOVEA needs to behave differently than MOVE,
such that the data is sign extended to a long and the condition flags
are not changed. I also modifed how Addressable returns data because
I need to return owned data from MC68681, so that the stored data can
be updated (ie. the status flag must be modified after a read)
