The MSX2 VDP is fast enough to handle OTIR or consecutive OUTIs (slightly faster). There's usually no need to check for any of the bits norakomi is checking for in that loop. While it's definately not the proper way of doing things, a plain OTIR should work on most (all?) MSX2 computers.

(having said that, don't know if it would be a problem on 7MHz, but if not it should be easy enough to make a seperate routine for those computers without needlessly slowing down normal MSX2s.)

So, all VDP's on MSX2 are equally fast, but not all Z80's are. Officially there are only MSX2's with 3.58MHz Z80A, but quite some folks modified it to run at higher clock speeds, like 7 or 8 MHz, using a Z80H. Then there are some MSX2+ machines with a Z80B that can run on 5.something MHz. Etc.

> The MSX2 VDP is fast enough to handle OTIR or consecutive OUTIs (slightly faster).

In this case it seems, that transfering RAM to VRAM shouldn't be slower than transfering RAM to RAM? (when you don't count the initial overhead). If this is correct, well, what's the problem then? :-)

Quote:

This seems to be more or less slow

It's slow; but this is NOT an example of a standard RAM->VRAM transfer via OUTxx. It's the main execution loop of the VDP HMMC command used only for bitmap modes. You can find the flowchart of this command in the "MSX2 technical handbook", chapter 6.5.1.

www.konamiman.com/msx/th-4b.txt

This command is used for a high speed memory transfer between RAM and VRAM. I've never benchmarked an HMMC execution and an only OUTI (being the faster) based one; maybe without VDP "help" is even faster . The main advantage of HMMC is that VDP takes care automagically of the graphic area range where data is dumped; but you still need to OUT the data, byte per byte.

When working in 256x212x16 or 512x212x4 modes, if you only need to transfer a linear area (from RAM) to a rectangular data area (VRAM), the best approx for speed is to use the old way. Years ago, i've tested the two way and found better the old approach. This is because of two reasons:

1) when you out data to vram, vdp take care of autoincrement the address register ptr in VRAM, you do not need to respecify the address every time you write a data.
2) you work on a byte basis: when you send data to vdp with out (98h),a you are setting a byte at once, therefore you work on 2 or 4 pixels at once. Using the VDP HMMC way, you also work in byte unit, but you have to check the status byte before you can send the next byte to the port. This is done pratically by in a, (99) or similar, but means that you are "halfing" the transfer rate because for each byte transferred you need to do:

check_tr:
in a,(99h)
bit 0,a
jr nz,check_tr
out (9bh),a ; send byte
.. ; increment registers etc.
jr check_tr

3) VDP provide a logical transfer command LMMC from RAM TO VIDEORAM as well a LMCM for the reverse operation. however there is only a HMMC command to trasfer from ram to videoram not vice-versa.


VDP LMMC/LMCM commands are only useful only when you need to work on a pixel basis, because give you:
ability to execute a OR / XOR / IMP / AND operation between the pixel color you send and the existing pixel color
ability to use the color 0 to emulate transparency: when you send the color code 0 destination pixel is unaffected so
ability to get/set the color value directly from VDP, without needing to execute bit rotating/shifting/masking operations.

If you have question send me email, i will help you for the conversion of graphic part as i can.

P.S. = if i remember VRAM area on cPC is arranged in this way, counting pixels from left to right and from top to bottom:
(16 color mode)
byte 0 = two pixels color
byte 1 = right two pixels color .....
byte 80 = second line, two pixels color etc.

(4 color mode is analogue)

Hey, how is going this project? I've seen new CPC version (beta 1) and it simply rocks

There is a new beta version (Beta 2) for the CPC.

Is there some news about a MSX version?

Quote:

Is there some news about a MSX version?

I am sorry, but two hardware projects did interrupt me and unfortunatley delayed the MSX port. The good thing is, that one of the two projects (CPC TREX) already required somehow a porting of SymbOS two another environment., so I collected some experience with porting, and that was really very easy.
So I like to get familiar with the MSX hardware soon.

CU,
Prodatron

That is interesting. Keep up the good work!

Hmm... SymbOS is easily been mixed up with Symbian OS. ..But who cares.

Yes, you are right... When I started this project the first time end of 2000 I didn't know anything about Symbian. So I didn't thought, that there would be another OS with a similiar name. I just wanted to be far away from something like GEOS ;-)

CU,
Prodatron

Prodatron, you know that if you want help, here we are. Also, don't hesitate asking here at MRC, at forum.karoshicorp.com forums (development forums), msxposse.com or another MSX websites.

Yours,

Hum... the TREX board looks familiar, let's have a look:



Ok, it's not the very same as the 1CM, but I can't avoid the resemblance.

Prodatron, keep up the good work! As spl said, feel free to ask on any forum for help about MSX.

idd, was looking at it too. Pity the FPGA chip only has 6000 LE's tho...