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.
This combines my iso9660 parsing code, with all of the prior gdrom packet
interface / command code.
The example, on real Dreamcast hardware, displays the first 2048 bytes [1] of every
file in the root directory on the serial console.
[1] or the size of the file, whichever is smaller
From the GCC manual.
> GCC permits a C structure to have no members:
struct empty {
};
> The structure has size zero. In C++, empty structures are part of the
> language. G++ treats empty structures as if they had a single member of type
> char.
I was not aware of the different behavior in C++.
This fixes every maple example--most were broken for multiple reasons, including
this one.
This also enables SH4 caching. This includes linking code/data into the P1
area (previously this was not the case).
The maple examples (which indeed involve much use of DMA) require much work to
successfully work with the operand and copyback caches. The vibration example
currently is the most complete, though I should consider more on how I want to
structure maple response operand cache invalidation more generally.
Also adds the incomplete modifier_volume example.
This also adds vec2 for UV coordinates, and obj_to_cpp has been
modified to parse vertex texture coordinates from obj files.
This is very barebones, and uses the serial interface to communicate
the status of the "a" controller button being pressed.
I'd like to make this a more interactive/graphical demo.
There were two notable bugs:
- the maple transfer/data sizes were not being set correctly
- align_32byte always realigned the address of `_scene`, and not the
`mem` parameter as expected. This had the effect of the maple-DMA
send and receive buffers being the same buffer. On real hardware,
this causes unpredicable behavior.
On an emulator, the receive buffer is filled with the correct/expected
data for 'device status'.
I found this experiment useful:
- it revealed a bug in my register struct generator code (the
maple_if-related registers were not at the correct offsets)
- it validates my understanding about endianness-swapping between the
maple bus and the SH4
