Henrik Gilvad, 00-00-00
(Overgenomen van Quasar 26) V9990 evaluation board. The first impression. Written by Henrik Gilvad. It have been a while since I last wrote for the Quasar and the reason is not difficult to explain. I got a V9990 evaluation board from MSX Handler Gemeinshaft with an interface for MSX. From now on there will be 2 kinds of MSX people, those who hate the V9990 and those who love it. After this article you should have no doubts about what group I belong to. The first rumours: I first heard about the V9990 several years ago, it was mentioned together with a new MSX computer which had a 16 bit 28 MHz Risc CPU. The new videochip had up to 2048 dots in the X direction and 2048 in the Y direction, with 32k colours the quality would beat all existing hobby systems. Quite a mouthfull of words so we didnt really believed it then, only hoped. The facts of both the 28 MHz and the 2048/1024 dots was not precisely correct but misunderstandings from people who could not read and understand the technical information. The machine was naturally the Turbo R, all though not as fast as the rumour. The V9990 DOES have up to 2048 in the X direction and up to 2048 in the Y dir. but that is in the vram and NOT on the screen. The V9990 is a very complex chip but it is incredible simple to program and therefore the 'thru-put' is much faster than on the know MSX VDP's. Furthermore the V9990 is ALWAYS ready for the Turbo R, therefore it is possible to transfer up to 520kbyte or so from the Turbo R internal RAM to the VRAM with OUT's. This is nice but the REAL power is internally of the V9990, the hardwarecommands and other features are much more valuable than even 2 or 4 higher CPU to VRAM access. (My personal oppinion.) I will not write about the things that you can read in the Application Manual, get that one from Arjan. I will bring you here the test results and other things that I found out. To see the strength of the V9990 I did some first tests. The following tests have been made in a screen 7 compatible mode. Optimized machinecode. LMMV LINE BOXFILL Fill's about 3.183 Mbyte /sek in B1 mode CMMK KANJI to (X,Y) Writes about 3.076 Mbyte /sek --!!-- LMMM COPY (X,Y) Transfers 2.248 Mbyte /sek (Faster if sprites/cursor is disabled) in P2 mode with the same commands: LMMV 1.267 Mbyte CMMK 1.047 Mbyte LMMM 756 Kbyte (Also faster with disabled sprites.) I have also tried to see how many Lines and Copy's the Turbo R can give in M-Code with different size. (All in B1 mode) LINE -STEP(3,3) 26087 lines in 1 sek. LINE -STEP(16,16) 20689 lines in 1 sek. LINE -STEP(31,31) 15384 lines in 1 sek. LINE (0,0)-(255,211) 4054 lines in 1 sek. and COPY: COPY step(15,15) 8696 times in 1 sek. COPY step(31,31) 3141 times in 1 sek. The B1 mode is with only 2 sprites (called Cursors) with 32x32 pixels and multicolour. The P2 and P1 modes have up to 125 sprites with 16x16 pixels in multicolour. 16 per line. Compared to the V9958 then the V9990 is MUCH faster in all concepts. The V9958 have 2 kinds of COPY. One with logical operations (in DOT units) and one without log.ops. (In BYTE units) The Byte copy is never faster than 350 K/sek and the Dot Copy is only pumping out about 100kbyte/sek. The V9990 only have 1 COPY and that is always with Logical operations between the Source and the Destination. If the V9990 COPY is compared with the V9958 Dot COPY then it is 23 times faster ! But compared with the V9958 Byte COPY it is 'only' 9 times faster in this command type. So was the V9958 so bad ?? The answer is no, the VRAM was bad. The V9990 can only use what is known as REAL video-ram, that is also called DUAL PORT RAM. The problem has been that 1 ram had to deliver data to both the picture (Which can not wait for its information.) and the 'blitter', that is not possible in very high resolutions. Actually the V9958 can only show SCREEN 5 with one VRAM bank, it have to have 2 banks to go up to resolutions as the Screen 7 and 8. On the IBM-PC VGA cards they have NO 'blitter' and NO sprites. With these 2 things VGA would never existed, with normal RAM. Most VGA cards have to split up the VRAM in 4 or 8 banks to get enough 'access time' just to show the screen resolution * number of colours. With the new DUAL PORT ram then V9990 have 1 port for the Picture and 1 port for 'blitter', sprites and CPU access. This gives the possibility of the high speeds and higher screen resolutions in both dots and colours. So, does V9990 have ANY MSX future ? The first 3 days or so I did not get much sleep, I was busy converting XBASIC and Turbo R BASIC from V9958 to V9990. After about 1 week I had most routines rewritten and they were both faster and smaller ! I didnt belived it myself but this chip is so damn brilliant. Take a basic command like the "COPY file to (X,Y)" it is hopeless in screen 8 and even worse in screen 6. Each dot have to be read from the diskfile, masked out and written to the VDP, but before each dot the SUBROM first have to set and examine some status registers. ALL the work is done by the CPU and not by the videoprocessor as it should be. There are 4 different COPY routines in the SUBROM, one for each screen mode. The V9990 have a hardware command that is much simpler to use. Just read the data from the disk and write them directly to a VDP port, it does the rest. The new routine is really much faster. The V9990 will distribute the data to the correct dots, no masking to be done ! The V9990 command even IGNORES the last bits in the right side of the rectangle you are copying to, for those who dont know it then this is a MSX speciallity. The V9990 fits the MSX to a fault not only in this point but it also contains other commands fit for MSX BASIC and BIOS. Other basic commands that was getting much faster and smaller was : PUT SPRITE, PAINT, PRINT #1, PUT KANJI. Commands like LINE, PSET, POINT was not different in size. The V9990 can simulate all MSX 2 and 2+ screen modes in matter of the DOTS. The incompatibility starts with SPRITES and with VDP registers. The old sprite system was really bad, take a look on the PUT SPRITE function in the SUBROM and you will understand what I mean. To make 1 PUT SPRITE command takes about 200 VPEEKS and VPOKES and lots of calculations. Sprites on the V9990 is very simple and more powerfull at the same time. Sprites are now defined just as normal bitmapped graphics, actually you can use normal graphic as spritedata. This makes sprites much more usefull. Sprites can have 1 of 4 palettes (1 palette have 16 colours) so with sprites there can be up to 64 colours on the screen in the 'GAME MODES'. Sprites can move BEHIND the picture or between the 2 planes in P1 mode, so the 2 planes can be huge sprites themselves. Sprites on the V9990 are NOT vram compatible with the V9958, that would be imposible. VDP registers are not compatible either, this was not possible as there have been so many improvements. If programmers are using BASIC, XBASIC, C or Assembler with BIOS based routines then there should be no problems. But Assembler programs which writes to VDP registers and VRAM and not using the BIOS will not work correctly. The MSX standard does not permit anyone to access the vdp registers directly. The only legal and fast way to access the VRAM, bitmap graphics area, is by setting up the VRAM ADR. with a BIOS routine and then writing vram data directly to the I/O port which is stored in ROM adr. 6-7. It is not allowed to use the VDP regs to set up the adr. If this is done correctly then the V9990 is compatible. Now 2 examples. Ex1 is the wrong one, Ex2 is the right one. Ex1: Write 255 bytes from RAM to VRAM LD HL,#0000 LD A,L OUT (#99),A LD A,H OR #40 OUT (#99),A LD HL,#A000 LD B,255 LD C,#98 OTIR RET This ex. will not work on the V9990, it should have read like this: LD HL,#0000 CALL SetWr LD HL,#A000 LD B,255 LD A,(#0006) LD C,A OTIR RET This is smaller in memory and much nicer to look at. The speed should not be a problem as the BLOCK transfer is the same. The VRAM problem is the SPRITE control since the bytes used in VRAM are located differently and 2 of the 4 bytes are swapped and 1 have different meaning. Not an easy one to solve. The last problem is that the V9990 does not have SCREEN 0-3. In the V9990 BASIC that I now have made there is a 64 char textmode, it also works in DOS. Program written in BASIC with no 'dirty' commands like 'VDP', 'BASE' and VPOKE to the sprite area would all work. Programs written in XBASIC with the same limits will also work in my V9990 XBASIC version, when its complete. With a few rules for software devellopers then future programs can work both on V9990 and on V9958. But as long as there is no MSX with ONLY a V9990 then this should perhaps not be nessesary. The V9990 have some modes not mentioned in the manual. They are: Normal monitor: 192 x 240 with 2-32k colours 1024 x 212 with 16 colours (not sharp picture) VGA monitor: 320 x 480 with 2 - 32k colours. 160 x 480 --!!-- Some people asked me to write about the Interlace on the V9990. The interlace is different from the one on the V9958. 1 page non-interlaced will be the upper half of the picture in interlace mode. So it is a more logically and usefull interlace. (No converting needed !) My conclusion is that the V9990 is a very powerfull chip for both Games and more Serious programs. Personally I dont think that there will be a MSX with just the V9990 as too many programmers have not been, and will not be, desciplined enough to write programs that will work on it. The ideal solution would be both V9958 and V9990 superimposed. However I think that the V9990 are having too huge a potential to be ignored, even a 3.5 MHz MSX will be able to gain from it. To the people who are 100% against V9990 I just want to ask: When did You last use screen 1-4 ? MSX should not be standing at the 1985 level for 10 more years.