Handling multiple interrupts dsPIC
The dsPIC33EP provides a DMA interface to the UART (see chapter 8 of the datasheet). If you configure a buffer large enough for 20ms of data, you can configure the DMA to write into that buffer and then read the results between screen updates. Note that:
$$
57,600~bps \cdot 0.02~sec = 1152~bits = 144~bytes
$$
If you are using SPI to write to the SD card, DMA can also be used there to limit the CPU load during the larger writes (the driver might already have built-in DMA support).

Alternatively, you could perform the actual buffer read in the interrupt (instead of polling for a flag). This is a bad idea in most cases, however, for multiple reasons:


As little code as possible should be placed in interrupts, to reduce system latency;
It depends on the method being used to drive the display, but it is likely that read interrupts received during a screen refresh will result in visual glitches;
Function calls from within interrupts are rarely a good idea--they typically increase the pre- and post-interrupt code written by the compiler (to save off registers, etc.), and introduce opportunities for deadlock that would be more obvious with inline code.


In short, DMA is made for the situation you describe. It is usually a painful process to set up and debug multiple DMA transfers, but it will allow clean display refreshes due to the longer reads and writes without CPU intervention.