Msx is something a bit of good ideas and missed chanches
MSX 1 had sprites which is a good idea not so common in 8bit. Even the so overestimated C64 had by they copied them from the tms. What s the problem? They were underpowered. The tms had pattern modes, another good idea but lacked smooth scrolling.....
Later they tryed to fix with V9938 but again good ideas missed chances :
They realized sprites was underpowered, but not enough effort to fix them
They realized no smooth scroll but they added (incredible) only vertical.
They realized that the way to go was hw blitter... Great idea sw sprites are flexible than hw ones...... But they missed a chance by giving a blitter that has comparable power to z80 running at 3 mhz.....
Cpu wise a 7nhz upgrade should be used even on msx2.
Another problem were the z80 descendants.
Z80 was a huge success but in order to move on 16 bit, successors were not so popular. They should had started to think to another Cpu arch like the 68000 already used in others competitors and used the z80 as a sound processor (Sega?)
I am back in OCM development.
I can read Japanese 
scan-005.tif
5.2 Pin function description
5.2.1. Memory I/O Access Interface
D7-0 (I/O, 3state) 8bit Bidirectional data bus.
A15-0 (I/O, 3state) 16bit address bus.
A15-14 is read when RESET rises from LOW to HIGH as a value indicating the type of DRAM connected to R800.
-------------------
A15: LOW, A14: LOW ===> 64k x 4bit DRAM
A15: LOW, A14: HIGH ===> 256k x 4bit DRAM
A15: HIGH, A14: LOW ===> 1M x 4bit DRAM
A15: HIGH, A14: HIGH ===> 4M x 4bit DRAM
The DMA in the R800 is very flexible it could be used for video, memory copies, disk IO, etc. I do not believe it was there just for video. No need to have two of it if this was the case. And also the memory mapping and interrupts do not help video as much.
I didn't say DMA was there only for video, I meant to say video was the only thing compelling enough to justify adding it and risking serious problems with compatibility and expenses with extra research/development.
The Mega Drive has a DMA which is meant mostly to be used for video related data transfers, it is inside the VDP chip.
They realized no smooth scroll but they added (incredible) only vertical.
MSX was a computer first and video games machine second. The idea why they had vertical scroll on the VDP was for text (on graphical screens, like Kanji text or ASCII text with embedded pictures) on the MSX and other V9938 applications (Captain/Teletext terminals).
So these features were added or omitted with cost reduction in mind obviously.
...the talking wire...
...the thread below... 
say the secret DMA has 4 megs per second. then with those 16 megs ram of the 24bit MMU you get max 4 seconds of video as an architecture limit - it is a joke.
say the secret DMA has 4 megs per second. then with those 16 megs ram of the 24bit MMU you get max 4 seconds of video as an architecture limit - it is a joke.
He is not saying video in the sense of playing video. This would be challenging for any machine that was not a SGI at the time.
He is saying video in the sense of accelerating copy of VDP stuff from RAM to VRAM. Small bitmaps, small animations, sprite data, emulating more sprites, text, etc.
Even in the case someone decides to use it to play a video cutscene blasting 4MB/s into the framebuffer is a little silly. It just means you can copy an entire 27k frame in a much shorter period, for example.
In any case I can't imagine a machine like that with 16MB at the time. It would cost several times the price of the machine. And for a computer that barely reaches 0.7 DMIPS it would be wasteful.
Copying data to VDP was always a limitation (coming from the VDP simplistic design). If you have a new chip that can take 4MB/s or more, the DMA makes a lot of sense. But once the new chip was dropped, the DMAs, extra memory and Ints could still be used to accelerate other functions. It is kind of lame that they were not even thinking of an HD for example. 20-40MB HDs were common at the time. It was already scoped as a last attempt.
I went to the library and read the "R800 User's Manual Interim Version" on Datum magazine 1990 Oct issue. The magazine was not something you imagine as a "magazine" but more like a huge hardbound encyclopedia.
I compared page 140 (first body text of the R800 Manual after TOC) of the Aug 28 1990 on the Datum magazine (say ver 1) and that of Jan 27 1991 ver (say ver 2) mentioned in the twitter link in this thread and noticed beside cosmetic text style changes, "9. Supports the I/O command fast transfer mode (command fetch is only once)" was deleted from ver 2.
I read ver 1 again and realized "Fast mode (I/O data block transfer is executed by only one command fetch) is supported", which is the preceding line and the final line of 8., is saying the same thing and speculated line 9. was determined redundant and was deleted from ver 2 thereof.
Since I don't think R800 itself was upgraded between 1990 and 1991, ver 2 probably had corrections/additions/deletions since ver 1 and some of them MIGHT had reflected A1GT implementation. But I don't have access to ver 2 therefore nothing can be said for sure.
Note ver 2 still has the "Interim Version" subtitle. I don't know if "proper version" was released later.
Regarding the A1STs with two or three ROMs, a 10K resistor on the board setup how the S1990 behaves regarding that. Models with three chips will have it and models with two chips will have not (or the opposite, not sure. Last time I dealt with that was at least two years ago)
Early models have three chips and later models two. Very likely other density/mapping configurations are possible. The setup is done in a similar way to how the R800 is configured at reset time for DRAM banking (chip latches voltages at these lines on power up while /RESET is held low).