How to dump M50747 (6502 derivative) ROM

hackingrom;

I've recently picked up a Canon ES 3 Personal Typewriter, and have of-course popped the cover to reveal this PCB (bottom). On board I find a chip marked as "Canon NH4-0338 D52 039100", not very helpful, but the silkscreen right next to it is marked "M50747" [datasheet]. This is an 8-bit 8 MHz 6502 derivative chip with an 8 Kb ROM and 256 bytes of RAM.

I wish to gain access to the firmware, a seemingly impossible task until reading through the datasheet and stumbling across the "Eva-chip mode". This mode seems to configure the chip to use an external ROM to run code for the purpose of evaluating a mask ROM. Is there any information on this being done for other devices that might prove useful (a blog post with a how-to or details from another chip)? (I've seen this is how the Tamagotchi firmware was dumped, as well as a printer for the Atari and the keyboard in the AppleII)

The purpose of dumping this ROM would be for hacking the typewriter, namely interfacing some other micro-controller and use it as a teletype. There is a much simpler option for interfacing through the keyboard port, which seems to be a scanned and multiplexed column affair, but working out which key combinations correspond to what is proving difficult (21 lines with 4 modifier keys and no data-sheet for the keyboard).

Any ideas as to how I should best go about modifying this typewriter?

Best Answer

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.

figure 15 processor mode and functions of Ports P0-P3

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.

Related Topic