R800

The R800 is the central processing unit used in the MSX Turbo-R home computer. The R800 was designed by the ASCII company of Japan, and the goals were to have the fastest CPU possible, while maintaining compatibility with old MSX Zilog Z80-based hardware and software.

In order to preserve software compatibility with old MSX software, the R800 uses a superset of the Z80 instruction set. In addition to all the Z80 opcodes, two multiplication instruction were added, MULUB (8-bit), and MULUW (16-bit). Also, many of the undocumented Z80 instructions were made official, these include all the opcodes dealing with IX and IY as 8-bit registers (IXh, IXl, IYh, IYl).

As the R800 is not based directly on the Z80, but stems from the Z800 family, it lacks some of the other undocumented Z80 features. For instance, the undocumented flags represented in bits 3 and 5 of the F register don't assume the same values as in Z80 (causing it to fail ZEXALL tests) and the undocumented opcode often called SLL is replaced by another undocumented opcode called TST.

On the hardware side, radical changes were made. The internal 8-bit ALU of the Z80 was replaced with a new 16-bit ALU. Opcodes like ADD HL, BC, that previously took 11 clock cycles, now can run as fast as only one cycle (in some conditions). The maximum clock speed was also increased to 7.16 MHz—twice as fast as the original 3.57 MHz Z80 used in the MSX. The data bus remained 8-bit to maintain compatibility with old hardware.

Additional changes were made in the way the CPU fetches opcodes. The original Z80 uses 4 cycles to fetch a simple instruction like OR A, and an additional waitstate is issued on the MSX architecture. A review of the Z80 fetch mechanism in a typical MSX environment is needed to understand the R800:

*Z80, cycle 1: set the higher 8-bits of address
*Z80, cycle 2: set the lower 8-bits of address
*Z80, cycle 3: waitstate
*Z80, cycle 4: refresh, part 1
*Z80, cycle 5: refresh, part 2

Since most implementations of MSX use RAM memory disposed in a 256×256 bytes block, two cycles are required to set the address for the fetch. The R800 avoids this by remembering the last known state of the higher 8-bits. If the next instruction is in the same 256-byte boundaries, the higher 8-bits are not set, and a cycle is saved. However, on the Z80, the refresh cycles destroy the information on the higher bits, so a workaround was needed.

The solution used in the R800 was to refresh entire blocks of RAM, instead of refreshing one line of RAM on each instruction issued. Each 30μs, the CPU is halted for 4μs, this time is used to refresh a block of the RAM. Since there's no refresh in between fetch instructions, and the waitstate is removed due to faster RAM chips, simple instructions can be issued using only one cycle. This cycle would be cycle 2 in the Z80 example above; cycle 1 becomes optional, and it's only issued when the program crosses a 256-byte boundary.

All of this only apply to the fast RAM used on the MSX turboR. External hardware, connected through cartridge slots, use timings similar to Z80. Not even the internal ROM of turboR is fast enough for this fetch scheme, so additional chips on the turboR can mirror the contents of ROM into RAM, in order to make it run faster.