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
Previously it was going line by line, but that makes it hard to
properly parse multiline comments, so I modified it to include line
terminators in the token stream. I also added parsing of /* */
and | \n comment types. There is still a problem with line numbers
in the post-parsing phases, but they seem correct in the parser/lexer
stage. It's still not able to parse the syscall.s file from Computie
but it's mostly just issues with named constants preceeded by a
"#" or "-" character. As for the encoding stage, it has a problem
with a move instruction that uses a label.
It can encode some basic instructions but not the more complicated
addressing modes or special instructions. It can keep track of
labels and patch the displacement addresses after assembling the
output data, but it doesn't check for duplicates or that a label
has been declared before it appears. It also doesn't take into
account the origin yet. To run it, there is an m68kas command
that will take a file and print the data:
```
cargo run -p moa --bin m68kas <filename>
```
It's not yet tied into the rest of the system, but could be used in
the debugger to allow insertion of new code into a running system.
In order to more accurately emulate the VDP, the main draw loop is
now going through each pixel on the screen and calculates the various
cells that should be displayed, gets the exact pixel data, and then
draws lines them all up in priority-order, and whichever is the first
non-mask pixel colour gets put into the frame buffer. It's rather
verbose and duplicative, but I'll fix it up now that I have something
working
It's a bit weirdly implemented because the Addressable trait doesn't
have access to System, so it has to set a flag on the Bus which is
then checked during the step function in System to activate the
breakpoint if a watched memory location was written to
