It will use CMD 0xa0 : Load Image (CPU -> VRAM). This is the normal method.
All that happens is the image data is upload to a part of VRAM, and then displayed using a Status Write of 0x05. The MDEC data may well be uploaded in chunks, the dimensions of which will vary from game to game.
MDECs can be in 24bit colour. This does't affect the VRAM uploading mechanism, just the displaying of the VRAM data.
Well right now I have added code to check for 24 bit mode so that it converts the information in the VRAM to whatever display there is. Unfortunately my MMX routines crash the thing at the moment (grin). However my problem is better solved now.
the RGB tooples are such a pain in 24 bit mode
[pix1] [pix2] [pix3]
G0 R0 R1 B0 B1 G1
However I noticed that if I swap the bytes it comes out.
R0 G0 B0 R1 G1 B1
the hard part is geting the 24 bit tooples loaded into the surface now.
This code seems to not work (grrr) but it basically does this
loads in 2 2/3 RGB 24 bit pixels and swaps the upper and lower bytes then encodes it to 16 bit RGB data
G0 R0 R1 B0 B1 G1 G2 R2
R0 G0 B0 R1 G1 B1 R2 G2
00 R0 G0 B0 R1 G1 B1 00
00 R0 G0 B0 00 R1 G1 B1
00 R0 00 00 00 R1 00 00
00 00 G0 00 00 00 G1 00
00 00 00 B0 00 00 00 B1
masking and shifting happen here
00 00 RGB0 00 00 RGB1
00 00 00 00 RGB0 RGB1
then the data gets stuffed into the screen.
Now if I can get it working that will be cool
I have been working on an MMX version of the soft GPU IE VRAM is 32 bits per pixel instead of 16 bits. However it's kind of slow work at the moment. I think I need to do some more changes to the display update code so it's clearer. I noticed the not so well documented scheme for doubling scanlines etc, this will need some work to clean up. Oh well
I have most of the MMX version implemented (including texturing etc.) it's getting it to display and not crash is the first challenge
1 - 4 of 4 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.