Btw, does someone know, if there is a way to copy large files on a harddisc image? Usually I first copy the files on a disk image with Arnold's wrdsk and then copy them in the emulator on the harddisc. But in this case I am limited to 720KB.
Now I would like to test the speed of the SymPlay video player, and 720KB is mostly not enough for a movie.
As blueMSX IDE support is not yet public, I don't know how to move big files on this environment. There are tips and instructions for OpenMSX here:
http://www.msx.org/forumtopic6184.html
The VDP speed is lower on R800 because of there is horribly too much delayed VDP access. To get maximum speed I think, that you should change to Z80 when drawing the screen. If you are interested about this kind of MSX tR support, I think, that I can write you needed CPU change routines. Another way is to try to do as much as possible between VDP I/O commands, CPU will stop to wait only when VDP is accessed again. If I remember correctly the delay between possible VDP I/O commands is 56 t-states.
Does it mean:
- the VDP itself is slower?
- the delay, before you can send the next VDP command, is longer?
- the general I/O (writing/reading) to/from VDP ports is slower?
How long does it take to switch from/to the Z80?
I'll post a link to a blueMSX beta with IDE support here for people that want to try SymbOS in blueMSX (and not have the energy to download the source from sourceforge and compile it themselves
)
Btw, does someone know, if there is a way to copy large files on a harddisc image? Usually I first copy the files on a disk image with Arnold's wrdsk and then copy them in the emulator on the harddisc. But in this case I am limited to 720KB.
Now I would like to test the speed of the SymPlay video player, and 720KB is mostly not enough for a movie.
You can use DiskManager that you can find on the RuMSX site.
To create an formatted harddisk image : select the MSX-DOS 2 and Custom options, then define the size of the harddisk image by changing the number of sectors per disk.
Then you can drag and drop the files on the harddisk image.
Don't try though to change later these files, as for this part the DiskManager is not fully developed and seems to hang.
Also the harddisk image created when using openMSX or blueMSX beta is not recognized by DiskManager, what's strange, but maybe can be explained by an uncomplete development of this tool for the harddisk images.
prodatron> The IO is slower. IO to the VDP is kept track of and if needed delayed. Unfortunately, the delay is a bit excessive and the result is slower than plain z80. But that's just for the writing to the IO ports!
also, openmsx allows you to write files to a HD image from the console using the "diskmanipulator" commands.
Awaiting the test release with interest. I'll give it a try on my tR.
- the general I/O (writing/reading) to/from VDP ports is slower?
This is correct, fortunately this delay is only for VDP I/O
How long does it take to switch from/to the Z80?
I think this is very interesting question... I don't think that anyone has ever measured this. I don't think that the actual change takes much time, but as these CPU's are both individuals (they don't share even PC register) there are quite a many things to take care of...
Indeed, I checked the bios code for that. Basically a switch pushes/stores *all* registers changes cpu and restores it again. A pretty slow operation if done completely.
I don't think that the actual change takes much time, but as these CPU's are both individuals (they don't share even PC register) there are quite a many things to take care of...
Ah, I see. So I think it only makes sense for CPU->VRAM commands and VRAM reading.
@Dvik: Is this I/O R800 delay implemented in BlueMSX? I couldn't see a difference in the speed of the graphic output (where I have many OTIRs).
Sorry, that I have to go now, but the delay should be easy to test. If you download the Dragon's Lair demo and run it with "/H" (High speed) parameter you should see the demo slow down a lot.
Look here:
http://www.msx.org/Dragons-Lair-introdemo-for-MSX2-update.newspost3694.html
