Writing screen patches

OWL Patches
#1

As discussed in a different topic, we are making some changes to the online and offline compilers, specifically with regards to how screen support is handled.

Some devices (hello Magus) have an OLED screen which can be used by the patch. But up to now, to use the screen you had to compile your patch offline with OwlProgram, in order to supply the specific PLATFORM build parameter for your hardware (e.g. PLATFORM=Magus).

This was never a great solution, since ideally the patches (and therefore the compilation process) should be hardware agnostic as much as possible. So screen support has now been refactored into a new abstract base class.

An example usage is here, though admittedly it’s a bit of a weird patch: Lorenz FM

In summary, all you have to do now to use the Magus screen in your own patches is to inherit from MonochromeScreenPatch instead of Patch, and to overload this function:

  void processScreen(MonochromeScreenBuffer& screen)

Here is the API for ScreenBuffer.

Screen patches can be compiled online or offline. And they will even run on devices without screen.

Screen patch questions
#2

Getting rid of hardcoded hardware support in patches is great news. It created patch incompatibility and wasn’t even necessary to use it when screen rendering is defined in patch callback.

But I think we’ll still have to use PLATFORM to distinguish settings for different version of OWL. OWL2 has slightly more available RAM for patches now, so using the same linker script for OWL1 already can create a patch that won’t be loadable on device. And later we can have some future OWL platform revision(s) that would have much more RAM and different compiler settings.

So using PLATFORM for the actual platforms (OWL1, OWL2, OWL3000, etc) would be more reasonable than using it to store just hardware capabilities.