• entries
455
639
• views
424750

# Some GP2x stuff pt. 2

130 views

So, it turned out I was being a bit slow, however before I go into how and what I did to fix it I'd like to setup my excuse [grin]

In the past when I have done hardware related stuff its been under some of the following conditions;
- non-paged memory map
- specific IO functions to send data to ports/hardware
- no OS between me and the hardware.

The first 2 and the last one applied to my Atari days, when you had a 32bit memory map which you could access at will, everything was physical addresses as the device had no virtual ram as standard and you had no OS between you and the hardware.

The first, third and final ones apply to the small amount of time I spent with x86 assembly at Uni many many years ago.

As such, the GP2x is a whole new world for me as you've got to remember about virtual addresses != physical addresses, you have an OS behind you and because of this you need to map memory addresses into virtual address space to access them.

Now, when it came to playing with the blitter chip (as I will continue to refer to it even if it isnt technically correct) there is a specific range of address you have to send your data to in order for you to make use of it. This data has a base physical address of 0xE0020000.
By default the library I'm using sets up some memory mapping BUT it doesnt extend far enuff, only 1Meg from 0xC0000000.
This would explain why attempts to access addresses such as 0xE0020000 would cause the program to crash out [grin]

So, I fixed that by adding an extra memory mapping into the equation, tada, crash goes away [smile]

However, this leaves problem 2 : It doesnt appear todo anything [sad]
Now, it dawns on me at this point that in my setup code I'm sending bloody virtual addresses (screen and source image), which the blitter cant work with, so a bit of hackery later and they have been changed to physical addresses, good good.

However, it still just displays a black screen [sad]
At this point I'm puzzled, so I go looking to see if someone else has solved the problem and I stumble apon the allegro source code diff which enables hardware acceleration of 2D ops, so I take a shifty at that and try to duplicate the code it uses for a surface blit.

I also noticed in the setup it turns on a couple of extra clock lines, persumably to the 2D chips, so I've added that as well.

Now, while I'm pretty sure all the code I have is the same as they have it still displays just a blank screen, which is a tad annoying to say the least. However, at this point it was getting late and I had to be up at 11am for college so I called it a day.

Tonight I'm going to look around to see if I can find more examples and fix this damned code so it works, probably via more looking at the pdf and maybe the source to a few games. Getting this right is probably the biggest learning experiance I've got right now, once I've got one piece of hardware down the rest should fall into place, I'm still learning about how it all fits together.

Now, the GTL image issue, Jack suggested that I do some DX wizzardry to convert the image, which is a nice idea but for one issue : I know sod and all about DX.
The easier way will be to debug GTL so it works properly when presented with this perticular texture format, mostly because its just a matter of checking flags and ensuring the correct output is setup.

But thats secondary to me getting the chip working first, I can copy rubbish around, no problem [grin]

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHh

Hi.

Where did you find the info about the blitter? The only thing that's really stopping me right now with the hardcore dev is the constant rebooting to test shit. SDL for the win, for now - at least.

Quote:
 Jack suggested that I do some DX wizzardry to convert the image, which is a nice idea but for one issue : I know sod and all about DX.
hmm, lets see...

LPDIRECT3DSURFACE9 pSurf = NULL;

// Find the file information
D3DXIMAGE_INFO info;
if( FAILED( D3DXGetImageInfoFromFile( "24bit Bitmap.bmp", &info ) ) )
{
// Handle error
}

// Create the surface
if( FAILED( pD3DDevice->CreateOffScreenPlainSurface( info.Width, info.Height, D3DFMT_R5G6B5, D3DPOOL_SCRATCH, &pSurf, NULL ) ) )
{
// Handle error
}

if( FAILED( D3DXLoadSurfaceFromFile( pSurf, NULL, NULL, L"24bit Bitmap.bmp", NULL, D3DX_DEFAULT, 0, NULL ) ) )
{
// Handle error here - probably a file I/O problem
}

//Lock
D3DLOCKED_RECT r;
if( SUCCEEDED( pSurf->LockRect( &r, NULL, 0 ) ) )
{
// We locked the surface, so we now have the binary:
UINT16 *p565Data = reinterpret_cast< UINT16* >( r.pBits );

int y = 0;
for( int x = 0; x < info.Width; x++ )
{
// Access this pixel:
UINT16 pixel = p565Data[ x + y * r.pitch ];

// Save out 'pixel' here...

// Move to the next row
y += (r.pitch / sizeof( UINT16 ));
}

// Play nice and unlock the surface
pSurf->Unlock( );
}

// Clean up the resources
SAFE_RELEASE( pSurf );


No guarantees, all off the top of my head....

## Create an account

Register a new account