After all these years I'm actually quite proud of this SDL hack now, it has quite a few advanced features and a viable way to port software to 68K.
While you are at it.... could you please have a critical look at the HWSURFACE support, in particular for RTG graphics? A common problem (actually, a real problem in some current SDL ports) is proper handling of bitmap locking, in particular of the screen->pixels pointer.
The problem some ports face here is that both P96 and CGfx do not necessarily keep bitmaps in graphics card memory, but can also keep them off-loaded in regular CPU RAM. Both P96 and CGfx can also relocate bitmaps at any time, that is, copy them from the board to host memory, or back, depending on the memory load of the system. That has the consequence that if you allocate a bitmap, then get its bitmap pointer, it is not guaranteed that this bitmap pointer stays constant throughout the lifetime of the program. Unfortunately, SDL seems to keep such a pointer in its screen->pixels structure, which is then prone to fail.
Instead, before you can use this pointer, it is *necessary* and *important* that you lock the bitmap (e.g. by Cgfx/LockBitmapTags() or similar calls of the Picasso96API.library), then operate on the bitmap, and then release the lock again to give the system "some air to breath" as it requires the bitmap lock from time to time as well.
I have recently faced some problems with SDL-based ports due to the fact that some branches of SDL do not perform bitmap locking correctly, and for that reason do not show graphics in some situations, or crash the system on screen switches.
If you need further details, please let me know.