Process N64 commands with interrupt

The original design of Cube64 is base around the polling done
by the host system. The adaptor will block waiting for a command
from the N64. Once a command is received and answer then the adaptor
does its business hoping to get back blocking for commands in time.

This change make polling the GC controller the first thing done right after
we finish processing an N64 command. That means the button status we
sent to the N64 is always almost 1 frame old (@ 60 Hz it's 16.6 ms).

This change move N64 commands processing in an interrupt context.
When the adaptor detects activity on the N64 system pin it interrupts
current work and go reply.

While no commands are receive the adaptor simply poll in loops the
GC controller. Polling GC data takes around 500 us so our maximum
delay between GC pool and N64 pool will be around 500 us and 1 ms
based on when the GC pooling gets interrupted. We alternate between
two buffers to make sure one is always good for transmission.

Once we get an interrupt, we got little interest in the current context.
The stack is clear and we start polling GC controller again once out
of the interrupt.

The N64 system pin had to be moved to PORTB to isolate it from the
controllers pin. PIC interrupt on change feature will miss change
on monitored pin if an unmonitored pin change simultaneously!

Also system flags that control the states of the adaptor had to
be updated as atomic operations and interstate data had to be preserved.
This allows the adaptor to simply restart the last state from scratch
following an interrupt.

A side effect of this is that the adaptor menu can be used now without
any polling from N64. Like while holding reset.

firmware/Makefile

@@ -2,7 +2,7 @@
 all: cube64-dx_18f14k22.hex
 
 cube64-dx_18f14k22.hex: cube64.asm *.inc
-	gpasm -p PIC18F14K22 -o $@ $<
+	gpasm -y -S 2 -p PIC18F14K22 -o $@ $<
 
 install: cube64-dx_18f14k22.hex
 	pk2cmd -PPIC18F14K22 -M -F $<