The NEC 781x series was released in 1982. The series is based on the earlier Zilog Z80 register set although featuring an incompatible instruction set.
The CPU shown above is a 7810 which is just like the 7811 series found in the RZ-1 except it lacks the 4KB of internal ROM present in the 7811. The 7811 series can have its 4K internal ROM disabled to turn it into a 7810. This is regularly done when the 7811 is cheaper, more plentiful, or more convenient to obtain.
Configuring the 7811’s ROM mode is achieved through setting two pins (MODE0 & MODE1) on the CPU to a combination of either high or low. If MODE0 is low and MODE1 is high then it’s operating in 7811 mode, otherwise it is behaving like a 7810 and totally reliant upon external ROM for its operating code.
0, 1 (low, high) = Internal 4K bytes used
0, 0 (low, low) = External 4K bytes used
1, 0 (high, low) = External 16K bytes used
1, 1 (high, high) = External 64K bytes used
According to the RZ-1 schematics, pin 29 on the CPU is MODE0 and pin 27 is MODE1. The schematics also tell us that pin 29 connects to ground (pulling the pin low) and pin 27 connects to a 47K resistor tied to voltage–a classic sign of a pull-up resistor. In other words, pin 27 is being pulled high. This low/high combination means the CPU is in true 7811 mode.
That’s rather unfortunate for all but the most intrepid hacker because it will be much, much harder to meaningfully alter or understand the firmware if part of it is being stored directly in the CPU.
Not all is lost however, as the Casio RZ-1 has a separate program chip, an NEC D23C128EC (part number µPD23C128E-031) which is a 128kbit (8bit x 16k) mask ROM. This contains the last 16KB of operating system firmware for the drum machine.
In order to modify or customize the CPU behavior of the Casio RZ-1, the firmware would need to be altered. Since Casio has not made its proprietary OS source code available to the public, the first necessary step is to read the firmware from the OS ROM so that it can be reverse engineered. An EPROM programmer and the pinouts for the firmware chip are a requirement for anyone seeking to actually implement any changes, but a mask ROM dump binary is available for exploration.
Note: Anyone looking to repair/replace a broken/erased/malfunctioning firmware ROM on the RZ-1 should be aware that the ROMs are not in sockets (at least not typically) and will likely need to be desoldered. The binary above can be written to a 27128 style EPROM and refitted once the original chip is replaced with a socket, however.
Although the last 990 (+/-) bytes of the ROM is easily readable text such as “CASIO RZ-1; PLAY SONG=**; TEMPO=***”, the majority of the OS is machine-code, so before it can be significantly altered it needs to be converted into human readable form. This is done through a disassembler which takes the machine-code and converts it into assembly language. This isn’t an exact science, unfortunately, but it’s the best that can be done without source code.
Here is a package which contains two disassemblers for the NEC 78(C)1x series, specifically the uPD78010 and uPD78011. Both programs can be run from the Command Prompt in Windows, and there is also a Linux binary available. A commercial disassembler worth looking into is Data Sync Engineering’s Universal Cross Disassembler (XDASM).
After the assembly code has been generated, consulting the instruction manual and datasheet for the NEC uPD7810 CPU will aid in understanding the functionality of the code. Section 12 of the instruction manual is particularly significant as it describes the uPD7810 & uPD7811 instruction set in detail.
At this point, a debugger would often be utilized to trace the code and to monitor CPU registers and ROM/RAM addresses. The debugger included with MAME would be worth investigating as 7810/7811 ROMs can be loaded into its debugger via support for Hartung Game Master. Renaming our RZ-1 firmware binary to “d78c11agf_e19.u1” and placing it in the “mame/roms/gmaster” folder will let MAME’s debugger load the RZ-1 firmware, however, the code isn’t functional since the first 4K of code is still locked in the RZ-1’s 7811 chip (among other complications, such as the Hartung Game Master BIOS being only 4K unlike the 16K RZ-1 ROM). In other words, MAME’s debugger isn’t likely to be particularly helpful in these circumstances.
Developing, compiling, and testing new source code or modification of the machine code is the end goal. This can be done either by altering the original assembly/machine code or by writing all new source using an IDE. If only small changes are made to the original code then changes to the assembly/machine code can be practical, but if an entirely new OS is being developed than an IDE is ideal.
Keeping in mind that the first 4K of code is unavailable for inspection and unable to be altered, making very minor patches is likely all that can be achieved. Examining the code to understand some of the algorithms (how the RZ-1 stores its pattern/song data, for instance) is probably of more benefit than actually modifying the firmware.
A destructive approach to gaining access to the on-chip 4K mask ROM would be decapping the CPU. This involves physically ablating the surface of the chip (ceramic layer, epoxy, etc.) to reveal the die. Traditionally this is done by grinding/filing away the surface with an abrasive and then applying a strong acid alternatively with acetone until the die is clearly revealed, at which point closeup photos are taken of the die with a microscope. The photos are used as reference to reconstruct the physical representation of binary data in its virtual form. While quite labor-intensive, this method is entirely feasible with mid-’80s vintage chip utilizing only 4K of mask ROM.
Although the 4K of mask ROM is detrimental to reversing the firmware, the 16K of external ROM opens up the possibility of retrieving the 4K of ROM non-destructively. The methodology to this is to write a trojan that asks the CPU to dump its internal ROM data over one of its outputs and then to burn the trojan to an EPROM which replaces the external ROM. When the RZ-1’s boot sequence inevitably calls the external ROM address, the trojan will be activated. All that’s left is to monitor the data output specified by the trojan.
This could conceivably be as simple as asking the RZ-1 to dump addresses $0000-$0FFF over the MT port instead of whatever is stored in sample/rhythm data memory.
If the 4K ROM was ever retrieved by such methods, one might be able to put the 7811 into 7810 64K external ROM mode by cutting the MODE0 trace to ground and then wiring it just like the MODE1 trace. Once the memory mode is changed, the 4K and 16K ROMs could be burned onto a 64K EPROM and booted just like the stock firmware, thereby bypassing the unalterable on-die mask ROM (ultimately making it alterable via the EPROM). If this method was successful than a 100% original firmware rewrite or significant extension (an extra 44K to work with!) would be feasible.
There are very few development environments available for this vintage CPU, but Macro Assembler AS V1.42 by Alfred Arnold is certainly an option worth exploring. A commercial option to consider is Data Sync Engineering’s Cross-32 Assembler. Supposedly Sophia Systems has (or at one time produced) a macro assembler (MASM7811) and an emulator (SA98-7810/11) but there appears to be no trace of this software existing in 2016.
Although this article is aimed specifically toward the Casio RZ-1, those looking for general info about the NEC 78K series will be helped by many of these tools and datasheets. Specifically, hackers of the Roland TR-909, Juno 106, PG-10, PG-1000, the Korg DW-6000 or DDD-1, the Akai AX80 or AX60, and the Casio CT-6500, HT-700, or CZ series may find this article of particular interest and utility.
The Roland D50 may also possibly be disassembled using one of the disassemblers in the package above, and possibly developed with IAR Embedded Workbench for NEC/Renesas 78K microprocessors, but your mileage may vary.