Part 2 serial IO lesson

[quinnyo]

Don't get your hopes too high! This is an early draft PR for the lesson/features discussed in #42. Currently this PR includes only the "core" serial implementation (or what I'm calling SioCore), the code is not integrated with any existing code and there is no way to demo/test it.

The code here is a much refined version of my some experimental code and I'm relatively happy with it. (and to make sure I stay happy with it, I'm sticking it right here, as it is and I'm going to press the big green button). So please have a look, ask questions, etc. but I understand that in this state there's not necessarily a lot to respond to. To be clear: it is working code, but it doesn't do anything on its own.

A few questions and things I'm not sure of:

1. Is this totally the wrong thing to be working on?
2. Have I done something completely unexpected? I'm never sure!
3. I'm not sure about integrating this with the existing unbricked code. Other than the lack of actual score data, where does it go? How does the score sharing feature get started?
4. I've been using the timer interrupt to 'tick' the serial system. This is great for testing and going fast -- but it isn't a requirement for functionality, anything calling SioTick repeatedly will work. For the tutorial, it may be preferred to simply call the tick routine once per frame?
5. I think using the serial interrupt would be the first use/mention of interrupts (in reading order). Thoughts?

About the design/impl/code:

SioCore is kind of a multi-byte version of the underlying GB serial API. The core implements the clock provider's synchronisation delay and timeouts for the externally clocked device.
Configure a transfer by setting the data in/out locations (via the pointers wSioTxPtr, wSioRxPtr) and the number of bytes to transfer (wSioCount). Call the SioTick routine repeatedly until all the transfers are complete (wSioCount == 0).

Packet (not here yet) transfers a small chunk of data at a time. Builds directly on top of Core. Data transmission errors are managed here. A checksum is used to detect errors. Each packet can be retransmitted a limited number of time should an error be detected. The cost of retransmission is limited by the small packet size.

Bulk (not here yet) is more of a role/responsibility than a Thing. It's the thing responsible for splitting bulk data into packets and orchestrating their transfer. It's the interface between the high score code and the serial code.

Handshake (not here yet) establishes the connection -- as much as you can call it that. Establishes which device is the clock, provides initial detection of a connected device and a simple check to identify compatible software/protocol. This sounds like a lot (having written it down), but it amounts to sending a handful of magic numbers and expecting a specific sequence in return.

[avivace]

I love this!