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.
Successfully tested on real hardware on multiple optimization levels.
I knew in the previous commit that __attribute__((aligned(32))) did
not actually align to 32-bytes. However, at -Os specifically, and only
with that exact code, GCC was coincidentally generating a 32-byte
alignment. When the code or optimization level changed, this changed
the alignment of the "scene" buffer, which caused CH2-DMA to perform
incomplete copies of the TA parameters, which in turn variously caused
the TA to generate incomplete/nonsensical/nonexistent object lists.
This also fixes an unrelated issue with the background ISP/TSP
parameters. This "worked" in flycast but not on real hardware by
complete accident (a coincidence of the specific timing that the
ISP/TSP parameters are read in each Dreamcast implementation). The
issue is that the TSP parameters are 60 bytes long, which is greater
than the 32 bytes were previously being allocated. After changing the
allocation to 64 bytes, the background color is now drawn on real
hardware as expected.
In addition, though this did not cause issues yet, I corrected the
length of p1ram/p2ram in the linker script, to prevent future issues
where GCC's memory allocations wrap around past the end of the system
memory address space.
