The serial_transfer loader, as long as the target program voluntarily
terminates itself at some point, is able to load multiple programs
consecutively without requiring a physical power cycle to reload the
transfer program from CD.
The current example.mk juggles between two different "memory layouts",
one for "burn to a physical CD" and another for "load via serial
cable". Because the serial_transfer program now relocates itself to
the end of system memory, this means the 0x8c010000 area is now usable
by programs that are loaded by serial_transfer.
Though I did spend much time thinking about this, my idea was not correct.
The "tearing" and "previous frame is being shown while it is being drawn" is
simply because that's exactly what the logic in holly/core.cpp did.
This is no longer the case--by the time the newly-created core_flip function is
called, the core render is complete, and we should switch the FB_R_SOF1 to the
current framebuffer, not the one that is going to be written on next frame.
This also modifies alt.lds so that (non-startup) code now runs in the P1 area,
with operand/instruction/copyback caches enabled. This caused a 10x speed
increase in my testing.
Previously, due to the ordering of .text.p2ram and .bss, the linker
was forced to allocate .bss in the output file, increasing the size
of the final binary unnecessarily.
The linker scripts now preserve debugging symbols during linking.
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.
