|Home||Software developers||News and documentation||Emulators||New MSX|
This is the first part of a series of articles discussing the MSX turbo R.
The MSX turbo R is the latest generation MSX computers from Japan. Up to now, only two different models have been produced. Both by Panasonic. They are officially identified as the FSA1ST and FSA1GT. Though in the remainder of this series, we will call them ST and GT as far as the difference between the two models is relevant.
Minimum hardware requirements
The MSX turbo R contains two micro processors, a Z80 and a R800. The latter one is a Z80 compatible micro processor with a few additional instructions. Furthermore, the MSX turbo R contains a bus controller, the S1990, which connects the Z80, the R800 and the internal RAM memory with the other parts of the computer. The S1990 contains a PCM controller to play and record sound samples. To finish up the machine, it also contains a FM-PAC, a 2+ video chip, a MSX DOS 2 kernel and a minimum of 256 kB main memory. Furthermore contains the MSX turbo R the JIS 1 and JIS 2 kanji ROMS and a whole bunch of firmware. Though, this firmware is not part of the MSX standard and will not be discussed in this series. The firmware uses a 16 kB sized battery backed up SRAM chip, to store some data. This SRAM can also be used by the kanji processor to store customized kanji combinations.
MSX standard weakened
When defining the MSX turbo R standard, ASCII corporation has taken the liberty to weaken the MSX standard. They have decided that the cassette port is not any longer a part of the MSX standard. Furthermore, ASCII has decided that the MSX AUDIO is not any longer an optional part of the MSX standard. This decision has most probably been taken because you always have to wait a short time when sending bytes consecutive to the AUDIO processor. As the R800 is much faster then the Z80, the R800 will not wait long enough and mess up the entire sound. So, ASCII either had to find a solution for that problem, like rewriting the AUDIO BIOS or making a hardware solution, or they had to drop the MSX AUDIO from the standard. ASCII choose for the second option. Although the MSX AUDIO is not any longer part of the MSX standard, programs can still use the AUDIO processor on the MSX turbo R. The only prerequisite is that the programs either switch back to the Z80 before addressing the audio processor or have been adapted to wait long enough on the R800.
Apart from the minimum required hardware, a MSX turbo R can also have some optional hardware. ASCII corporation has defined a standard for MIDI usage on the MSX. This standard is called MSX MIDI and is only defined for the MSX turbo R and anything newer. You need at least an MSX turbo R because the Z80 is way too slow for a real good effective MIDI control on the background. You really need a R800 for that. Controlling a MIDI device from BASIC is rather simple. You must first initialize the MIDI BASIC with the command
CALL MUSIC. After
the initialization you can play music with
PLAY #1,M$, where
M$ stands for the music string. So, it is almost exactly the
same as controlling the FM-PAC from BASIC. The MIDI BASIC has some other
possibilities as well, but we won't discuss these in this article.
Differences between the ST and the GT
The GT is a little bit more extended then the ST. First of all contains the GT 512 kB main memory, while the ST only contains 256 kB of main memory. Furthermore does the GT contain the MSX MIDI extensions and it contains a build-in ROM disk with MSX DOS 2 and MSX VIEW. The latter one is a Japanese graphical shell for MSX DOS 2. This shell has been translated into English by MSX club West Friesland (from the Netherlands). Thanks to the ROM disk, you can boot MSX DOS on the GT without having a floppy disk in the disk drive; MSX DOS will simply be booted from the ROM disk. The last but not least GT specific feature is a 16 kB sized SRAM disk with a battery backup. This 16 kB SRAM comes in addition to the 16 kB SRAM used by the Panasonic firmware and the kanji processor.
ROM and DRAM mode
The MSX turbo R contains two types of main memory. The internal RAM of 256 kB or 512 kB and the ROMs with the BASIC interpreter, DISK BASIC version 1 and 2, MSX MUSIC/MIDI BASIC and many other things. The internal RAM memory is made of so-called DRAM chips. DRAM chips can be addressed faster then ROM chips. The ROM chips are even that slow that they can not keep up with the R800. As a consequence, the R800 must wait very short for each and every byte fetched from the ROM memory.
When the MSX is operating under BASIC, all instructions processed by the processor must be fetched from the BASIC ROM. To prevent that the R800 gets slowed down too much under BASIC, a very smart trick has been used. The MSX turbo R reset routine copies the entire BASIC ROM into the four highest pages of the internal RAM memory and switches to the so-called DRAM mode after doing so. In this DRAM mode, the four highest pages of the internal memory are not any more visible in the RAM slot. Instead, they are visible at the locations where you would expect to find the BASIC ROM. Because of this, all BASIC interpreter instructions will be fetched from fast DRAM memory in stead of slow ROM memory. Consequently, the BASIC interpreter will run faster.
Still too slow
Unfortunately, even the DRAM memory can not keep up with the R800. When addressing DRAM memory, the address has to be set-up in two steps. The address is split-up in a so-called row address and a column address, which must be set-up consecutive. This takes two clockcycles. Since the R800 wants to read from the memory within one clockcycle, the R800 still has to wait. To work around this problem, a second trick has been used; the R800 checks if a new instruction is fetched from the same row of memory as the previous instruction. If so, only the column address changes. Hence, the row address does not need to be set-up again and one clockcycle is saved. If the new instruction has to be fetched from a different row, the both the row and column address will be set-up again.
One row in the DRAM memory chips has a size of 256 bytes. This implies that
a routine within a 256 byte block can be executed at full speed. Though, there
is one big issue to take into account: The R800 only checks if the row address
is still the same when fetching an instruction! As soon as the R800 has to
fetch a variable (for example
ld hl,(nn) or has to operate on
the stack (
ret, the R800 always assumes that the row address has changed
and sets-up both the
row and column address. So there is not any use to put the stack and
all variables in the same 256 bytes block as the instructions. The R800 ignores
the location of the variables and the stack anyway.
This whole problem of setting up the row and column address separately could most probably have been avoided if the DRAM chips had been faster or if the memory interface had been designed slightly different. If the MSX turbo R had been designed a little bit smarter, it would have been approximately 8 times as fast as a standard MSX 2(+) in stead of only 5 times as fast on the average.
The VDP interface
The MSX turbo R contains yet another chip that is too slow for the R800; the VDP. When addressing the VDP you sometimes have to wait a while; when sending two bytes to the VDP consecutive, you have to wait somewhere between 2 and 8 microseconds between these two bytes. How long exactly depends on the circumstances. For example whether sprites are on or off, whether you are in text mode or in graphical mode. To which area of VRAM that you are writing, etc. Practice has learned that in most cases 3 micro seconds is sufficient. As soon as you wait too short, the VDP will miss some data and therefore simply ignore those data.
This wait time is that short that most programs on Z80 do not have to wait explicitly. For example, when you program a loop to transfer data from RAM to VRAM, going through the loop takes much longer then the wait time required for the VDP. Hence, most MSX programs do not have any waitloops when addressing the VDP. However, at the moment that you run such a program on the R800, you will get a problem; the R800 executes the loop much faster. As a result, the time between two consecutive executions of the loop will be too short for the VDP and the whole data transfer will be completely messed up. To solve this problem, the S1990 monitors everything that the R800 is doing. As soon as the R800 addresses the VDP several times, the S1990 will sent a so-called wait signal to the R800, which causes the R800 to wait until the wait signal is over. The S1990 is designed in such way that controlling the VDP will work correctly in all cases. Therefore, the S1990 makes the R800 wait for 8 microseconds between two consecutive VDP accesses. This is a very long time for the R800. It is 57 clockcycles. The R800 can execute an entire 16 bit multiply instruction in that time!
Fortunately this wait time can be used effectively, by smart programming.
The S1990 starts the counter for the wait time as soon as the R800 accesses
the VDP. However, the wait signal is only generated when the R800 accessed
the VDP for a second time, before the counter has reached zero. So, if the
program access the VDP only once, does some calculations that take long enough
and accesses the VDP for the second time, then the R800 does not have
to wait at all. An example can be found in listing setreg.
The routines in
setreg2 both set a VDP register
and update the corresponding variable in the MSX system area. The first routine
does not use the information above; the routine first sets the VDP register and
after that it updates the system area. The second routine handles it more
effecient; it first sends the value to the VDP, then it updates the system area
and then it sends the register number to the VDP. So, in the second routine the
MSX system area is updated during the timeframe that the first routine is waiting
for the VDP.
This article did not discuss all topics about the MSX turbo R. For example, we did not discuss the additional MSX turbo R I/O ports, addressing the PCM controller to record or play samples, programming the GT MIDI controller and the memory layout under DOS 1, DOS 2 and when using external memory extensions. Furthermore, the article did not say anything about the actual speed of the R800, over which still much confusion exists. These topics, and any other topic that I can make up, will be discussed in coming parts of the series. If you have any other questions about the MSX turbo R, you can always contact me. I will either answer them to you personally or add an additional part to this series, once I'm done with the translation of the original Dutch series.