REU Suport

[Kroc]

Whilst REUs are not that common for hardware users, they are widely implemented in emulators. The extra space is not so critical as is the DMA channel which would allow us drastically speed up data moving operations. Some possible uses:

• Use the DMA to wipe the bitmap screen, doing away with the need to erase the lines for the next frame (speed up) helps with Remove Flickering #1
• Implement double-buffering? (solves Remove Flickering #1)
• Load additional code modules from disk into the REU so that the disk is no longer needed

[dyme6510]

REU transfer blocks all interrupts. Clearing the offscreen buffer in one go means that the neccessary raster interrupts for switching banks or colors may be delayed by thousands of cycles. Either the clearing is done in 8-byte babysteps (longest regular instruction duration), or the distance to the next raster interrupt has to be factored in somehow. Maybe we can add a table containing safe cycles per raster line, or a flag that signals "256 bytes can now be transferred"

[Kroc]

GeoRAM should also be supported, but that doesn't have DMA, so DMA-support should be considered a separate feature from RAM-expansion as far as build-options are concerned.