Experimental SP/DIF output on expansion pins of RP2040 boards

[saybur]

Enables audio playback on RP2040 boards via one of the expansion header pins. Core1 is used to translate 16-bit signed PCM samples to emulated biphase mark code, which is then sent over SPI1 (clocked at about 5.6448MHz) to generate a SP/DIF datastream. Functions are provided with an eye toward eventual CD-ROM integration, with audio_play() and audio_stop() calls allowing playback to proceed in the background, supported by the new platform_poll() call (thanks again for that!)

Hardware to get this going is pretty simple: for testing I've been using an Everlight PLT133 powered from the 3V at the expansion header, connected to various Toslink DACs. Audio playback is generally stable during light computer use, but dropouts do occur during extended disk I/O, particularly writes. As mentioned in the discussion this could probably be helped by additional sample buffering capacity (currently 2x8K).

There are some 'hacky' things to note:

• The board is overclocked the board to 135.428571MHz to get a better SPI divisor.
• Even with that divisor, the SP/DIF stream is still 0.03% slower than spec for 44.1KHz audio. Also, I don't have tools to check for jitter but I can't imagine it's as solid as real audio equipment. This is definitely not audiophile-grade! :)
• ADC voltage checks are stopped during audio playback due to an issue with missing DMA words.

Right now all code is behind an ENABLE_AUDIO_OUTPUT include guard, currently disabled. I've tested this on a pretty small set of computers and things are definitely on the 'unstable' side of experimental. I'm very open to suggestions for changes!

For testing, you'll need a 16-bit signed stereo PCM file in 'raw' format written to the memory card. I used Audacity to generate them. See lines removed in this commit for an example of setting up audio playback.

[PetteriAimonen]

Code looks clean.

With RP2040 specified to run up to 133 MHz, the tiny overclocking will work fine.
But it will change some timings, especially with SCSI synchronous mode.

For now it might be best to have this as separate image, "RP2040_Audio", to avoid risk of breaking anything in the main firmware but to make it easy to test and experiment.
Firmware images are configured in platformio.ini and the ENABLE_AUDIO_OUTPUT can be defined there.

Though maybe we'll need the CD-ROM playback before releasing it, to actually do something useful.
I guess that will need the #187 bin/cue support first, and then implementing some SCSI commands that start the playback?

[saybur]

That sounds like a good approach, I'll make the change for a separate firmware image.

Agreed, two steps are probably what's needed: #187 addresses the data backend, and for the bus interface, an implementation of the CD part of MMC (or the bare-bones SCSI-2 media commands). The first step likely leads into to the second depending on how you want to handle the CUE to TOC conversion.

[PetteriAimonen]

Yeah, I think I'll have the basics of #187 worked out in next few days.

[saybur]

I think I've got the separate board entry taken care of, I'm not super familiar with PlatformIO yet. Let me know if that looks incorrect.

[PetteriAimonen]

The fw image config looks fine.
Though it would be possible to use the extends = env:ZuluSCSI_RP2040 to reduce redundancy, like in ZuluSCSIv1_1 config. But apparently I haven't done that myself either on the BS2 config :)

I have experimental version of the bin/cue support here, but didn't have time to test it yet at all.
But at least it gives an idea of how it will look on code side, even if it doesn't work yet:
https://github.com/ZuluSCSI/ZuluSCSI-firmware/tree/dev_bin_cue

I moved cdrom handling to ZuluSCSI_cdrom.cpp and added stub functions for the playback.

[saybur]

That inheritance is a nice feature. Config cleaned up, thanks for the pointer.