After reading the Mitsubishi M50747 datasheet, I don't think the mask ROM can be read out. Sorry. internet archive 1989_Mitsubishi_Single-Chip_8-Bit_Microcomputers Page 196:
(1) Single-chip mode (00)
The microcomputer will automatically be in the singlechip
mode when started from reset, if CNVss is connected
to Vss. Ports P0-P3 will work as original I/O
Ports.
(2) Memory expanding mode (01)
The microcomputer will be placed in the memory expanding
mode when CNVss is connected to Vss and
the processor mode bits are set to "01". This mode is
used to add external memory when the internal memory
is not sufficient.
In this mode, Port P0 and Port P1 are as a system
address bus and the original I/O pin function is lost.
Port P2 becomes the data bus of D7 - D0 (including instruction
code) and loses its normal I/O functions. Pins
P31 and P30 output the SYNC and R/W control signals,
respectively when ɸ enters into the "H" state. Port P32
functions as an input Port during this same transition.
(3) Microprocessor mode (10)
After connecting CNVss to Vcc and initiating a reset,
the microcomputer will automatically default to this
mode.
In this mode, Port P0 and P1 are used as the system
address bus and the original function of the I/O pins is
lost. Port P2 becomes the data bus (07-00 ) and loses
its normal I/O functions. Port P3, and P30 become the
SYNC and R/W pins, respectively and the normal I/O
functions are lost.
(4) Eva-chip mode (11)
When 10V is supplied to CNVss pin, the microcomputer
is forced into the eva-chip mode. The main purpose of
this mode is to evaluate ROM programs prior to masking
them into the microcomputer's internal ROM.
In this mode, the internal ROM is inhibited so the external
memory is required.
The lower 8 bits of address data for Port P0 is output
when ɸ goes to "H" state. When ɸ goes to the "L"
state, P0 retains its original I/O functions.
Port P1's higher 8 bits of address data are output when
ɸ goes to "H" state and as it changes back to the "L"
state it retains its original I/O functions. Port P2 retains
its original output functions while ɸ is at the "W" state,
and works as a data bus of D7 - D0 (including instruction
code) while at the "L" state. Pins P3, and P30 output
the SYNC and R/W control signals, respectively
while ɸ is in the "H" state. When in the "L" state, P3,
and P30 retain their original I/O function.
The R/W output is used to read/write from/to the outside.
When this pin is in the "H" state, the CPU reads
data, and when in the "L" state, the CPU writes data.
The SYNC is a synchronous Signal which goes to the
"H" state when it fetches the OP CODE.
The relationship between the input level of CNVss and
the processor mode is shown in Table 2.
"Eva-chip mode (11)" inhibits the on-chip mask ROM, so unfortunately you can't directly retrieve the object code of the existing firmware. Eva-chip mode is essentially like "Microprocessor mode (10)", except that the address and data bus signals are time-multiplexed with the P0, P1, P2, and P3 Ports. The timing diagrams are on figure 15. They don't seem to give an application circuit, but you will need some rising-edge triggered latches and some falling-edge triggered latches. And some of the signals are bidirectional, controlled by the R/W bit that is time-multiplexed by P30 during phi=H state.
So the problem is, since it looks like the end equipment application circuit already uses Ports P0, P1, P2, P3; you have to disconnect all of them and insert latches to capture the "original" P0 P1 P2 output values, in addition to capturing the "eva mode" P0 P1 address outputs and managing the P2 bidirectional I/O data bus.
I think the original intent of eva-chip mode was to make the P0, P1, P2 Ports available to support firmware development. In microprocessor mode, those Ports are unavailable because they are dedicated to the external memory address and data bus. The only way to be able to test a piece of firmware that used those three Ports, and was targeted to execute from the internal ROM address space -- prior to actually fabricating the mask -- was to use eva-chip mode with a development board that had the Port replacement circuit (external edge-triggered latches). This would have been used on a blank chip, with the test firmware in an external EPROM memory.
I don't know whether there's any way to read out the contents of the internal mask ROM; maybe by accident but certainly not as a design feature. If the manufacturer thought about this use case at all, they would more likely have gone the direction of "code protection" to prevent customer's competitors from reverse-engineering or outright copying the customer's firmware. Memory expanding mode (01) might leak out the mask ROM opcode fetch cycles, but since this mode removes Port P0 P1 P2 the firmware might not function correctly.
I don't know, but maybe your best bet would be to use a logic analyzer (or something equivalent) to watch how the existing firmware interacts with the hardware.
