GP32 Mirko-sdk Questions


unit3

Member
Joined
Aug 8, 2003
Messages
151
Location
Canada
Website
demoni.ca
Hey all,

Well, the shakeups in my life seem to have calmed down, so I'm trying to get back on track with all the GP32 development I had planned. *sigh*

Anyway, I'm really liking the look of Mirko's SDK, but I've got a few quick questions for anyone who cares to answer them:

1-
The following is from example.256color:

// Palette format: %RRRRRGGGGGBBBBBI (5551)
// I : Intensity Bit 1=on 0=off

With regards to the "intensity" bit in 256 colour mode: what does this actually /do/? Are we talking some sort of halfbright thing like on the Amiga?

2-
Is there any way to run code on horizontal line interrupts? To be specific, I want to try coding a simple copper effect, and so I need to be able to change the palette on each scanline. Any ideas with regards to this would be appreciated. The most ideal situation would be a way to implement an interrupt handler function, as that would work the best with my existing code. Actually, having a handler for vertical blanks would be very handy as well.

3-
Is there plans to explicitely handle multiple sound channels with Miro's SDK? Right now, it looks like you just get access to one channel, but I seem to recall the official SDK supporting 4?

4-
What's the proper way to allocate memory with Miro's SDK? For instance, if I have a char pointer, and want to allocate it a chunk of RAM large enough to hold 640x240 pixels, what would I need to do?

5-
Is there plans for an 8bit version of gp_clearFramebuffer16? I'd like to have fast screen clears, but I'm not at the point where I want to write the ASM myself. ;)

Thanks in advance, guys!
 
Hey all,

Well, the shakeups in my life seem to have calmed down, so I'm trying to get back on track with all the GP32 development I had planned. *sigh*

Anyway, I'm really liking the look of Mirko's SDK, but I've got a few quick questions for anyone who cares to answer them:

1-
The following is from example.256color:

// Palette format: %RRRRRGGGGGBBBBBI (5551)
// I : Intensity Bit 1=on 0=off

With regards to the "intensity" bit in 256 colour mode: what does this actually /do/? Are we talking some sort of halfbright thing like on the Amiga?

2-
Is there any way to run code on horizontal line interrupts? To be specific, I want to try coding a simple copper effect, and so I need to be able to change the palette on each scanline. Any ideas with regards to this would be appreciated. The most ideal situation would be a way to implement an interrupt handler function, as that would work the best with my existing code. Actually, having a handler for vertical blanks would be very handy as well.

3-
Is there plans to explicitely handle multiple sound channels with Miro's SDK? Right now, it looks like you just get access to one channel, but I seem to recall the official SDK supporting 4?

4-
What's the proper way to allocate memory with Miro's SDK? For instance, if I have a char pointer, and want to allocate it a chunk of RAM large enough to hold 640x240 pixels, what would I need to do?

5-
Is there plans for an 8bit version of gp_clearFramebuffer16? I'd like to have fast screen clears, but I'm not at the point where I want to write the ASM myself. ;)

Thanks in advance, guys!
1) I bit on, is normal mode, i bit off, is the complete color, only half bright.

2) horizontal line interrupts are possible, but you need assembler knowlege for this

3) gp32 offers only 1 stereo channel in hardware. If you want more, you must mix it... ( the gamepark SDK has a Software mixer build in ) Iam planing writing a mixer too.

4) like normal c, malloc and free

5) i never was thinking someone really wants to use the 8bit mode, but i can add it.

BTW: Using the 16Bit mode is mutch easier, and also very fast...
 
Last edited by a moderator:
1) I bit on, is normal mode, i bit off, is the complete color, only half bright.

2) horizontal line interrupts are possible, but you need assembler knowlege for this

3) gp32 offers only 1 stereo channel in hardware. If you want more, you must mix it... ( the gamepark SDK has a Software mixer build in ) Iam planing writing a mixer too.

4) like normal c, malloc and free

5) i never was thinking someone really wants to use the 8bit mode, but i can add it.

BTW: Using the 16Bit mode is mutch easier, and also very fast...
A reply from the man himself. Thanks! :)

Ok, let's just make sure I'm clear on everything... I've already started using your SDK, and it's as easy as promised, but I'd still like to make sure I can actually do what I have in mind. ;)

1) So, it's something like the Amiga's 64-colour halfbright mode, where you had 32 colours at 2 different brightness levels? I assume this means that we have a palette of 16, rather than 15 bits to chose from, because of this?

2) Something was troubling me about the horizontal / vertical interrupt issue... namely, that the GP32 seems to read in a weird coordinate system from the framebuffer, where framebuffer[0] is the bottom-left corner of the screen, and framebuffer[x] (where x < 240) is actually x vertical pixels up from the bottom left corner... if it's reading in vertical scanlines, does this mean there's vertical scan breaks, and then a horizontal refresh, rather than horizontal scanlines and vertical refresh like on the PC / Amiga / Mac? Or is the GP32 hardware refreshing the screen in the same manner as normal computers, and just reads the framebuffer out of order? It seems very confusing to me.

Anyway, do you know of any sample code that can show how to do this? My assembler isn't great, but I can probably stumble through it. Also, do you have to write the whole interrupt routine in ASM, or can you just have the ASM call your C function?

3) Aha! The official SDK threw me off, I just assumed there were 4 hardware channels. That makes more sense though, since the GP32 design was pretty much "there's no hardware assisted anything, do it all in software with the processor".

4) Excellent, that should make things easy.

5) I'm in an oldschool mood, I've been playing a bunch of my old Amiga 500 games recently, and I thought that I'd give a shot at reproducing some old school effects on the GP32. A lot of them are based on palette tricks, so I wanted to play in 8-bit mode. If it looks like it'll just be easier to use the 16-bit mode, I'll probably do that in the future, but I'd really like to play with the 8-bit mode too. :)

Anyway, thanks for the tips, I'm going to start writing my (personal) game SDK, and I'll encorporate copper and other effects as I determine just how to do them on the GP32. Any resource sites for this kind of stuff that you can suggest would be greatly appreciated, as are your comments and suggestions in this forum.
 
Last edited by a moderator:
1)  I bit on, is normal mode, i bit off, is the complete color, only half bright.

2)  horizontal line interrupts are possible, but you need assembler knowlege for this

2) Something was troubling me about the horizontal / vertical interrupt issue... namely, that the GP32 seems to read in a weird coordinate system from the framebuffer, where framebuffer[0] is the bottom-left corner of the screen, and framebuffer[x] (where x < 240) is actually x vertical pixels up from the bottom left corner... if it's reading in vertical scanlines, does this mean there's vertical scan breaks, and then a horizontal refresh, rather than horizontal scanlines and vertical refresh like on the PC / Amiga / Mac? Or is the GP32 hardware refreshing the screen in the same manner as normal computers, and just reads the framebuffer out of order? It seems very confusing to me.
Heh.. gotta jump in to this.. First of all the GP32 screen is rotated 90 degrees to left. This means that horizontal lines become vertical <_< Unfortunately there is no hblank or vbalnk interrupts but both can be emulated to some extent with timer interrupts. You don't need assembler for that.
If you want to make true GP32 like horizontal copper bars you need to do them by drawing gfx (there are tricks for that so one only one pixel needs to be drawn to get a line of screen witdh). For wicked hardware raster effects check http://www.cs.helsinki.fi/u/jikorhon/conde...dl/lcdblast.fxe for some effort of raster effects :blink:
 
Last edited by a moderator:
1)  I bit on, is normal mode, i bit off, is the complete color, only half bright.

2)  horizontal line interrupts are possible, but you need assembler knowlege for this

3)  gp32 offers only 1 stereo channel in hardware. If you want more, you must mix it... ( the gamepark SDK has a Software mixer build in ) Iam planing writing a mixer too.

4) like normal c, malloc and free

5) i never was thinking someone really wants to use the 8bit mode, but i can add it.

BTW: Using the 16Bit mode is mutch easier, and also very fast...
A reply from the man himself. Thanks! :)

Ok, let's just make sure I'm clear on everything... I've already started using your SDK, and it's as easy as promised, but I'd still like to make sure I can actually do what I have in mind. ;)

1) So, it's something like the Amiga's 64-colour halfbright mode, where you had 32 colours at 2 different brightness levels? I assume this means that we have a palette of 16, rather than 15 bits to chose from, because of this?

2) Something was troubling me about the horizontal / vertical interrupt issue... namely, that the GP32 seems to read in a weird coordinate system from the framebuffer, where framebuffer[0] is the bottom-left corner of the screen, and framebuffer[x] (where x < 240) is actually x vertical pixels up from the bottom left corner... if it's reading in vertical scanlines, does this mean there's vertical scan breaks, and then a horizontal refresh, rather than horizontal scanlines and vertical refresh like on the PC / Amiga / Mac? Or is the GP32 hardware refreshing the screen in the same manner as normal computers, and just reads the framebuffer out of order? It seems very confusing to me.

Anyway, do you know of any sample code that can show how to do this? My assembler isn't great, but I can probably stumble through it. Also, do you have to write the whole interrupt routine in ASM, or can you just have the ASM call your C function?

3) Aha! The official SDK threw me off, I just assumed there were 4 hardware channels. That makes more sense though, since the GP32 design was pretty much "there's no hardware assisted anything, do it all in software with the processor".

4) Excellent, that should make things easy.

5) I'm in an oldschool mood, I've been playing a bunch of my old Amiga 500 games recently, and I thought that I'd give a shot at reproducing some old school effects on the GP32. A lot of them are based on palette tricks, so I wanted to play in 8-bit mode. If it looks like it'll just be easier to use the 16-bit mode, I'll probably do that in the future, but I'd really like to play with the 8-bit mode too. :)

Anyway, thanks for the tips, I'm going to start writing my (personal) game SDK, and I'll encorporate copper and other effects as I determine just how to do them on the GP32. Any resource sites for this kind of stuff that you can suggest would be greatly appreciated, as are your comments and suggestions in this forum.
1. The Color format in 8 Bit mode is
%RRRRR GGGGG BBBBB I

This means you can have 32 colors for each RGB channel.
You have a palette, with 256 entrys in it.

If oyu set the I BIT, the intensity is normal.
If you dont set the I bit, the intensity is only the half.

So you can change one bit, ( instead of 3 bits ) to change it.

!!!! It will not give you more colors !!!

2.the gp32 screen is rotated 90deg left.
this means is starts at bottom left, and goes to upper left. ( framebuffer[x++] )
So if you are talking about vertical, you must first rotate your gp32 by 90deg to the right.
so you have 320 scanlines, and 240 points every line.
The tft screen is refreshed automatic by the hardware, you can only set the refreshrate.
have a look at: http://www.deadcoderssociety.tk
for vertical irq examples

3. yes, the hardware is very cheap, so you must do all in software.

5. all palette tricks there only made to get more colors on the screen, but in 16 bit mode, you can have them all, without any irq tricks, so its the best mode...
 
Last edited by a moderator:
I'm just going to respond to both valuable posts simultaneously. :)

First, Mr.Spiv:

What I had in mind was having paletted images and doing interesting dynamic shading / lighting tricks by modifying the intensity of the palette colours (make them brighter / darker) on a line-by-line basis. From what I'm hearing, this isn't going to really work, as there's no real line interrupts, so there's no way to modify the palette between line draws?

--update
I just checked out the hblank emu stuff at deadcoder's, and that looks like exactly what I'm looking for! And idea when some docs on how to do this will be out?
--

I'll check out that linked demo when I get home (I'm at work ATM, and as such, my Gamepark isn't here ;) ), and I'll post any questions if I have 'em. ;)

Next, Mr. Mirkos:

1) I was a little mixed up, but I see how that works. Mind you, I can't see that setting 3 bits instead of one is that big of a deal on a machine this speed, but I can see how you could do neat tricks to do quick changes of brightness.

2) The stuff on deadcoderssociety looks very interesting. I assume that with the counter-clockwise rotation, the GP32 updates vertical lines from left to right, and that the LCDCON1 holds which line number it's on?

3) The reason I was interested in 8 bit mode was more for memory consumption reasons, seeing as the thing only has 8MB of RAM, and because I want to play with raster tricks. I know that 16 bit mode is much easier, but it won't be as satisfying for me as a programmer. ;)

Thanks once again to both of you!
 
Back
Top