One of the goals listed for the project is to port STM32-based firmware to the existing Geoff's PIC32-based board. Since PIC32 version uses singe SPI channel to generate monochrome video signal the #ifdef shims had to be made to have common codebase for both.
To keep the compatibility with ANSI SGR attributes for color I decided to use two strategies to transform color to monochrome. First strategy--I call it "simple"--is chose normal or inverted rendering by checking background color. When background color is 0, use normal, otherwise use inverted. Second strategy uses pre-computed luminance value for each of 256 colors in the ANSI palette. When foreground luminance is greater than background luminance, use normal rendering, otherwise use inverted. The transformation strategy was made to be selectable in the terminal SETUP because one would work better than the other with certain terminal programs.
A rather big portability issue appeared to be related to the fact that the old PIC32 firmware uses 32-bit packets in SPI transfers for pixel data. It turns out that the PIC32 SPI controller sends bytes in the order that is different from how they are stored in memory. This required PIC32 frame buffer code to implement tricky re-ordering when it comes to writing pixel values. The new common codebase uses fast memcpy/memset operations for shifting and clearing pixels and assumes pixel bits are stored sequentially.
When simply changing SPI packet size from 32 to 8 bits the order was correct, but now the SPI could not keep up with 25MHz pixel clock and started skipping transfers. You can see the picture jumping randomly off by multiples of 8-bits. Bummer!
After hours of playing with SPI configuration I was able to solve this issue by enabling enhanced buffer mode:
SpiChnOpenEx(SPI_CHANNEL2, SPI_OPEN_ENHBUF | SPI_OPEN_TBE_HALF_EMPTY | SPI_OPEN_MODE8 | SPI_OPEN_ON | SPI_OPEN_MSTEN | SPICON_FRMEN | SPI_OPEN_FSP_HIGH | SPI_OPEN_FSP_IN | SPI_OPEN_DISSDI, SPI_OPEN2_IGNROV | SPI_OPEN2_IGNTUR, 2);
Geoff's PIC32-based board uses PS/2 keyboard. This required writing a portability layer to translate PS/2 scan codes to USB HID key codes that the common code base is built with. With this change common code base was abstracted out from the keyboard hardware and just use #define'd key codes and SHIFT, ALT and CTRL flags.
Other smaller changes revolved around differences in the UART hardware between STM32 and PIC32. PIC32 board supports inverting signals to approximate RS232 signal levels. STM32 has support for various word lengths in addition to the parity.
After many weekends--at last--PIC32 board fired up with the new 3.0 firmware!