My problem as well.
I vaguely remember the PE VDU as well. I never had that one. PE were quite strong supporters of the MK14 and published many software routines including a demo for the SOC VDU which showed an animation of four parachutists descending and landing. Not a bad achievement in 128 bytes of RAM.
When playing with retro kit, my mantra is, as far as possible 'never modify the original hardware' - so my scheme with the dual-port RAM would indeed have the DPR chip on an additional board acting as the bridge between the unmodified MK14 and the unmodified VDU card.
(That my MK14 no longer has its original keypad is not something I can really do anything about now: The original pad went the distance long before the machine ever came close to being 'retro').
But nowadays, I aim to disturb the original hardware and firmware as little as possible. For example, the recently built hex downloader / programmer works by 'typing' code into the machine via the keypad edge connector, and it takes that approach so that it:
1) - Requires no modification to the content of the monitor PROMs, which are the original SOC supplied parts.
2) - Requires no permanently installed support hardware such as a MAX232, which would be required for serial hex download directly through the SIO pin. Nor are any other hardware mods to the MK14 required.
3) - Uses no system RAM which is not already used by the standard monitor, therefore all user RAM remains available for user programs. (firmware based serial download routines would probably need to ring-fence some RAM as a buffer area).
Another decision I made was that the interface must be able to be connected or disconnected safely when the MK14 was powered and running, so that a demo program could be uploaded to it and the interface then disconnected to leave the MK14 in its clean standalone form, still running the demo.
For that, the interface connections to the keypad edge connector had to be completely isolated. 20 relays connected to the edge connector would have been one way to do this (it would have been interesting to hear that working!) but for higher speed, zero keybounce and less required power, I went for 20 optocouplers instead, with their outputs connected to the keypad edge connector in the same way as the 20 switches of an external keypad would be.
Another possibility, with the revised monitor fitted, is to read a prepared MK14 .bin program file into a modern computing device (Raspberry Pi?) and have it transmit that file to the MK14 in the form of the digital input stream that the MK14 expects to receive from the optional cassette interface. (The data format is described in the manual for the cassette interface, attached). The interface between the computer and the MK14 cassette data input could again, for isolation purposes, take the form of a single optocoupler which could be disconnected from the MK14 once the software has been loaded into it. The main reasons not to do it this way are (a) speed - only four characters per second - and (b) a 256 byte limitation on upload file size. (Plus, you have to set up the 'Load in' address manually every time).