This adds a new texture memory allocation header,
texture_memory_alloc2.hpp, with two of each memory area.
This also adds two new examples, "cube_textured" and "cube_vq" that
demonstrate using the new texture_memory_alloc2 to perform CORE
rendering, geometry transformation, and tile acceleration
concurrently.
For a lack of a better idea, bind board and piece rotation to X/Y
chess::do_move no longer advances the turn--prior to this change,
castle moves incorrectly double-negated turn.
This adopts a "writer" concept, vaguely inspired by the ta parameter
writer. This might turn out to be not a great idea if the
response/offsets for heterogenous commands are too inconvenient to
keep track of.
This breaks every example that uses maple--only
example/maple_controller is updated to use the new interface.
The previous texture_memory_alloc.hpp was written based on an
incorrect understanding of the "32-bit" and "64-bit" texture memory
address mapping.
The primary motivation is to rearrange the texture memory address map
so that "textures" (64-bit access) do not overlap with 32-bit
accesses, such as REGION_BASE or PARAM_BASE.
It is unclear why this reordering is useful--it should be the case
that the previous content of the cache is invalidated on write
regardless of when cache::init is called.
This makes it possible to change the serial baud rate without
uploading a new serial transfer program. I'm not sure how useful this
will be, but it is simple enough to add.
The client program is also substantially improved. Sincerely I do not
understand how/why this works. Experimentally, I found that feeding
the ft232h data in chunks of up to roughly 384 bytes works reliably,
both for reads and writes. Larger chunk sizes are (as expected)
faster, but the tranfers do not appear to be consistently correct in
this case.
I have no logical explanation for this. The size of the ft232h FIFO is
1K each for the transmit and receive buffer respectively.
This also enables RTS/CTS hardware flow control. Surprisingly, this
doesn't appear to affect reliability significantly.
