Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Some GP2x stuff pt. 2

Sign in to follow this  


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;
- no virtual addresses
- 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]
Sign in to follow this  


Recommended Comments



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.

Share this comment

Link to comment
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...


// Find the file information
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

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

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

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

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!