Reorganize the and optimize the code to avoid redundant code and thus
reduce code size, while making sure to zero-initialize the used areas
on the SD card. These are the "clean" part of this change.
The "dirty" part:
Optimize the FAT16 export code further by introducing small deviations
from the FAT16 specification. These deviations should not be harmful
at all, unless the SD card is used for something requiring the jump
instruction and/or boot code in the boot sector to be valid. This is
typically only required when booting off the filesystem.
After these changes, a considerable reduction in code size can be
observed for sys_controller.elf and sys_onchip_memory2_0.bin:
sys_controller.elf:
text data bss dec hex filename
32392 2936 2652 37980 945c sys_controller.elf
sys_onchip_memory2_0.bin:
size: 35328 bytes
This reduces the cost of the FAT16 export feature to 446 bytes.
Replace an array of const char* literals with a single const char*
literal containing all the messages in the rotating prompt and an
array of alt_u8 containing the offsets of each message within the
literal.
This ends up yielding a larger size reduction than expected, a
healthy 20 bytes, despite a meager 8-byte difference in the size
of local variables and slightly more complex pointer math in
calculating the address of the current message within the string
literal.
The behavior of the menu option was all over the place, and would
easily leave the OSD in a weird state, requiring the user to blindly
do something that completely redraws the OSD.
Fix this by making the behavior similar to that of the userdata import
feature, with the difference of giving a more specific error message
when something goes wrong.
A very simple implementation, as we are very short on remaining
block RAM. Simply blindly copies the entire userdata area to the
SD card. This may subject the SD card to some extra wear, as well
as potentially read-disturb some Flash memory pages, but this would
require more code.
In the Flash info structure, the field containing the end address of
the Flash storage is documented to be non-inclusive.
However, when this field is compared to the end address of a read or
write, which is also non-inclusive, it is considered an error that
these two values match, which is incorrect, as this would error out
on an attempt to fully read/write the last page.
Fix this by simply changing the >= comparison into a > one.
There were a few things wrong with the SD card write implementation:
1. The protocol change regarding the interpretation of offsets
introduced with SDHC cards was not taken into account in the write
path, unlike in the read path.
2. All SPI writes involved in the process were actually issued as reads
due to the use of the SPI_RW() function, the implementation of which
seems to have gone through some churn. Likely just an instance of
bit-rot.
From the Cyclone IV device handbook:
> When you use the VREF pin as a regular input or output, you can expect
> a reduced performance of toggle rate and tCO because of higher pin
> capacitance.
Previously, we had set all HDMI_TX pins to fast output, but doing so
produces some worrying timing violations which were masked over by
relaxation of the SDC constraints. With fast output enabled, actually
fixing the timing constraints would require substantial RTL
optimization.
Instead, by only setting fast output on the VREF pins, I'm able to avoid
the glitching that would occur without any fast output pins when
displaying high clock rate line3x output, while also allowing fitter
enough flexibility to avoid timing violations.
In addition, this commit restores the previously relaxed HDMI_TX timing
constraints to those documented in the IT6613 datasheet.
This commit adds both a 480p input sampling mode and line2x optimized
mode for the PSP's 480x272 picture. The line2x optimized mode is enabled
automatically when the sampling mode is selected.
When in-game, the PSP outputs a letterboxed 480p picture. The active
portion of the screen is 480x272, but is treated as 480p (480x720).
In addition, a line2x optimized mode is added which produces a 960x544
output picture, which if desired the top + bottom pixels can be dropped
producing a 960x540 (qHD) picture.
To generate a qHD picture, use the following settings:
V. Active: 270
V. Backporch: 135
marqs
Ari Sundholm
Russell Harmon
Russell Harmon
marqs85