Autor
| v9990 Transfer Speed - Update
|
GhostwriterP
msx addict
Posts: 313 |  Postado em: 24 Setembro 2008, 21:02 |
Here is the new table, with an accuracy of ± 256 bytes, all values in kb (x 1024 => bytes).
----------------------------------------------------
| COMMAND
MODE |--------------------------------------------
| LMMM | BMLL | BMXL | BMLX | LMMV
----------------------------------------------------
B 4bit | 44.125 | 44.250 | 44.500 | 44.125 | 62.625
MCKIN | 26.875 | 26.750 | 27.000 | 26.875 | 39.375
----------------------------------------------------
B 8bit | 44.125 | 44.125 | 44.500 | 44.125 | 93.000
MCKIN | 27.000 | 27.250 | 27.000 | 27.000 | 58.000
----------------------------------------------------
P1 sON | 6.125 | 6.125 | - | - | 12.875
sOFF| 9.125 | 9.125 | - | - | 19.250
----------------------------------------------------
I share this for all of you to enjoy  |
|
PingPong
msx professional
Posts: 1023 | Postado em: 24 Setembro 2008, 21:16 |
@GhostWriterP: thx, but you missed a little thing: the table show the amount of bytes moved, but not the period. What are KB/sec?  |
|
Edwin
msx professional
Posts: 626 | Postado em: 24 Setembro 2008, 21:41 |
Going by the numbers, I'm guessing bytes per int at 50 Hz. 44125*50 = 2.1MB. Which is approximately what a g9k should be capable of.
|
|
GhostwriterP
msx addict
Posts: 313 | Postado em: 24 Setembro 2008, 22:08 |
I meant to post this one:
----------------------------------------------------
| COMMAND (kb / frame)
MODE |--------------------------------------------
60Hz | LMMM | BMLL | BMXL | BMLX | LMMV
----------------------------------------------------
B 4bit | 36.250 | 36.250 | 36.500 | 36.250 | 51.750
MCKIN | 22.500 | 22.750 | 22.500 | 22.500 | 33.000
----------------------------------------------------
B 8bit | 36.250 | 36.250 | 36.500 | 36.250 | 76.750
MCKIN | 22.500 | 22.750 | 22.500 | 22.500 | 48.750
----------------------------------------------------
P1 sON | 6.125 | 6.125 | - | - | 12.875
sOFF| 9.125 | 9.125 | - | - | 19.250
----------------------------------------------------
The other table contained 50Hz values for B modes... quite useless
|
|
manuel
msx guru
Posts: 3528 | Postado em: 25 Setembro 2008, 12:39 |
Weird, between 4 and 8 bpp, only LMMV makes a diff. (In the first table, that's different, btw!)
|
|
GhostwriterP
msx addict
Posts: 313 | Postado em: 25 Setembro 2008, 18:21 |
You are right, verry strange. Anyway manuel, are you still interested in the test programs?
|
|
AuroraMSX
msx master
Posts: 1260 | Postado em: 26 Setembro 2008, 11:59 |
Quote:
| You are right, verry strange. Anyway manuel, are you still interested in the test programs?
|
Although I'm not manuel (thank ghodd!  ), I'll say "Definitely YES!", the test programs and the results can be very helpful in perfecting the v9990 emulation! |
|
manuel
msx guru
Posts: 3528 | Postado em: 26 Setembro 2008, 21:40 |
GhostWriterP: I'm always interested in such programs! (As AuroraMSX says!) Anything we can run on real MSX and on emulation, especially benchmark/measurement programs are extremely helpful!
|
|
GhostwriterP
msx addict
Posts: 313 | Postado em: 27 Setembro 2008, 13:28 |
----------------------------------------------------
| COMMAND (kb / frame)
MODE |--------------------------------------------
60Hz | LMMM | BMLL | BMXL | BMLX | LMMV
----------------------------------------------------
B 4bit | 36.250 | 36.250 | 36.500 | 36.250 | 51.750
MCKIN | 22.500 | 22.750 | 22.500 | 22.500 | 33.000
----------------------------------------------------
B 8bit | 36.250 | 36.250 | 36.500 | 36.250 | 76.750
MCKIN | 22.500 | 22.750 | 22.500 | 22.500 | 48.750
----------------------------------------------------
B 16bit| 37.000 | 36.750 | 37.000 | 37.000 | 77.500
MCKIN | 22.500 | 22.500 | 22.500 | 22.500 | 48.500
----------------------------------------------------
P1 sON | 6.125 | 6.125 | - | - | 12.875
sOFF| 9.125 | 9.125 | - | - | 19.250
----------------------------------------------------
|
|
Leo
msx freak
Posts: 238 | Postado em: 27 Setembro 2008, 20:50 |
|
|
manuel
msx guru
Posts: 3528 | Postado em: 05 Outubro 2008, 23:25 |
GhostWriterP: can you please send us the test programs, so we can use this stuff and verify if it works in openMSX?
|
|
manuel
msx guru
Posts: 3528 | Postado em: 14 Outubro 2008, 00:00 |
Thanks for sending the test programs. Wouter disassembled them and rewrote them into a single program to test all modes. The results can be found here.
What else can we learn from these numbers?? Discussion please! |
|
GhostwriterP
msx addict
Posts: 313 | Postado em: 14 Outubro 2008, 19:48 |
You guys really did a great job.
Never thought the cursor would have such impact, it seems faster to do it manually with copies.
And I like to add that BMXL and BMLX do not work as expected in P1, that is why I did not put them in the table.
|
|
Edwin
msx professional
Posts: 626 | Postado em: 15 Outubro 2008, 00:34 |
While it's better than nothing, I don't think tests like these will help in getting things really accurate. The system is basically the same as with the v99x8 chips. Speed is determined by two things: the processing speed of the vdp and the vram bandwidth. It will take the chips a number of cycles to read and write bytes. Extra cycles are needed when it has to calculate the address to a new line. This makes copies of 128x16 faster than copies of 16x128. It's those times you'd really need to figure out for various operations.
On top of that is the fact that the vdp has only one memory interface. This means that command engine operations will get delayed if the VDP is reading VRAM for display. Having sprites turned on means that more memory access is needed for display. With the display turned off, the command engine has the entire vram bandwidth to itself. Also, vram access is not needed for lines during vblank, leaving more bandwidth to the command engine.
You can use the difference in values for the above cases to start estimating values for delays and command engine performance. But to really get closer a lot more specific testing will be needed. I think this will be easier on the v9990 because it has an interrupt for when the command engine finishes it's work. So you can do some reasonably accurate timing of commands during various stages of the refresh, which in turn helps figuring out when the vdp does it's vram access.
|
|
mth
msx freak
Posts: 193 | Postado em: 15 Outubro 2008, 10:21 |
The V9990 uses dual ported RAM, page 2 of the data book says so. Also, recently Manuel mentioned that he heard the GFX9000 is relatively expensive to produce because of the need for dual ported RAM.
Perhaps in bitmap modes, one VRAM port is used for commands and the cursor and the other for display? That would explain why display on/off makes almost no difference if the cursor is off. The small difference might be explained by the V9990 having less freedom in scheduling refresh cycles if both ports are in use.
Page 96 and onwards of the data book specify RAM access timings. It doesn't tell us what the VRAM access is used for, but it does show for example that the V9990 is capable of omitting RAS when doing sequential reads (see "page mode" diagram), like the turbo R does. If this optimization is used for command engine access as well, row-aligned transfers would be slightly faster than non-aligned ones.
Anyway, to get back to your point: indeed for high accuracy we would need a model of how the V9990 accesses RAM. However, an approximation based on the average timing measurements would already be a big improvement over the current situation.
|
|
|
|
|
