This fixes a problem I kept causing myself: the patched ROM files
were not per build directory, meaning that I'd build a wrong ROM
and wonder why nothing was working.
it only works at all with 128k or 256k non-psram builds
you can hear the beep when you adjust the slider in control panel, but
there's other audio overlaid on it that is kind of a weird descending tone,
very regular in nature.
The sample rate is set to 20k not 22.255k because of my i2s dac not
liking random sample rates.
Instead of using the i2s dac on the fruit jam, this uses A0 (data),
A1 (lrck), A2 (bclk). It's not super convenient, and it's hard coded.
this is a _workaround_ for the fact that the mac framebuffer is inverted.
we'll probably ditch it again once we copy the (512x342) framebuffer
from PSRAM to SRAM....
Adds a new build option, -DVIDEO_PIN=<n>, which sets the base GPIO
of Video (followed by syncs).
The video pins (for PIO reasons) need to be contiguous, numbered upward
from the DATA pin. This has caught a couple of people out, so to make
it easier just define them this way. That then gives a single
configuration option, the first GPIO, setting it all up.
Uses the no-OS-FatFS-SD-SPI-RPi-Pico library, and on startup opens
the fs to search for 'umac0.img' or 'umac0ro.img'. If the former
is found, it's used as a RW image; the latter is RO. If no images
are found, the code falls back to an in-flash disc image; you can
set up a default that's used if no SD card is inserted, for example.
The wiring defaults to GPIOs 2/3/4/5 for SCK/TX/RX/CS respectively,
which matches the upper-left SPI0 on the Pico board. The wiring
can be overridden by defining SD_TX, SD_RX, SD_SCK, SD_CS on the
`cmake` build commandline.
The SPI speed defaults to a very conservative 5MHz (at least one of
my cards will only cope with this). Again, this can be overridden
by defining SD_MHZ on the commandline (to an integer in units of MHz).
Note this also disables the RTC portion of FatFS when building
for RP2350 (which doesn't have an RTC, or APIs for it).
