Forums

Hi, folks. It's been a fun week. I learnt better how the SMS and GG's internals worked thanks to some of Maxim's programming tutorials, and I found out how much the GG's VDP can handle when written to during screen refresh. So, I'd like to release the product of my labour.

It's a high-colour ("hicolor") demo that will show 7 images in sequence. Technically, this demo can display up to 288 colours on-screen at once, which is 9 times more than the GG regularly does. Perhaps more colours can be squeezed out by someone else, but I dunno...

Please download and tell me what you think!
http://disgruntleddesigner.com/chrisc/data/GGHicolor.zip

ccovell wrote

I learnt better how the SMS and GG's internals worked thanks to some of Martin's programming tutorials

*cough*

(unless Martin made some tutorials I don't know about)

Nice! Looks cool.

Did you try it on a real system? Others have had difficulty avoiding artefacts with mid-frame palette updates, although the GG screen size makes it easier. Meka's paletted video display will tend to make this kind of demo break, so you're helping move us towards a more advanced Meka :)

As Maxim mentionned, MEKA supports mid-screen raster palette effects, but it has a buffer of 64 colors per frame (due to palette constraints). That's twice the 32. It suffise for commercial games I tested (the Sonic games often uses this features to switch mid-screen to get a water-palette).

Now that I'm decided to drop 8-bit paletted mode, maybe I should work it out and make a definitive switch to hi-color.

Nice demo.

Bock wrote

As Maxim mentionned, MEKA supports mid-screen raster palette effects, but it has a buffer of 64 colors per frame (due to palette constraints). That's twice the 32. It suffise for commercial games I tested (the Sonic games often uses this features to switch mid-screen to get a water-palette).

Now that I'm decided to drop 8-bit paletted mode, maybe I should work it out and make a definitive switch to hi-color.

Nice demo.

I too am curious to see how the GG handles the color updates. I imagine it should turn out alright, by the time the CRAM updates are actually posted the VDP should already have started drawing outside of the visible area (I don't remember exactly where we figured the h-int fires, I think it was around pixel 176 of the 256 pixel display, but the archives should hold the answer somewhere). As I recall, the VDP's that do have a problem with screen corruption on cram updates will still recover by the next scanline, and I think it's only the SMS1's VDP that's so sensitive.

Just a quick (newbie) question:

In the "Graphics now follow!!!!!" section at the bottom of the source code, what does the palhed.bin file do? And secondly, how come you've got this far already? I'm still trying to work out the VDP instructions :)

Hi folks,

Yes, I tested this on my GG system (using Tototek's SMS Flash cartridge), and it is intended to be used on the real hardware (the GG's screen smoothes the dithering in the 2nd image, for instance.)

I didn't know where the H-Sync interrupt was triggered; I had assumed it was off-screen on the left side, and that my interrupt code was a little slow :). But if it actually is at pixel 176, then it does make sense. I first tested the H-ints with a single write to the palette on the SMS, and there was a solid band of corruption/jumping palette noise right around there, going down the screen. So, with just a little more code in the h-int handler, the palette writing is safely offscreen on the GG.

One interesting thing that helped me: My GG has a video output (hacked like Victor Kemp's) so I can check the graphics of the GG on my TV. And even though it's in black&white, I can check for graphics corruption on the main screen easily. Also, curiously, though there are no graphics visible on the TV past the GG's borders, background palette data and "snow" appear precisely where the palette is being changed mid-frame. So that did help too.

Dodginess: I was lazy and didn't trigger the palette writing just from the start of the GG screen; I had h-ints (and palette writing) start from the vertical retrace. So, above the GG screen, the palette is being written to (with unimportant data). This is the data contained in palhed.bin, since it is the same for each pic (individual pictures' tiles and palettes are different.)

Even though this is my first Z80 coding project, I have done similar things on the NES and Turbografx-16 before. So the techniques are the same, even if I still don't yet know what each Z80 instruction does. ;-)

Impressive. Humm, can I play the Mario64 scene?

ccovell wrote

Also, curiously, though there are no graphics visible on the TV past the GG's borders, background palette data and "snow" appear precisely where the palette is being changed mid-frame. So that did help too.

It is interesting how it masks the screen in GG mode; perhaps they had hopes for consumer-level TV output at some point, or maybe they just made the VDP restrict itself to drawing there to give a bit more time in the HBlank to write to VRAM without restrictions.

However, in this region it's still drawing the background/border colour, in the same way as the SMS, so it is still actively doing stuff there, just not as much stuff and requiring less VRAM/CRAM reads. In the event of writes to VRAM above a certain rate, it loses out in the bus collisions and outputs bad data. You see this all the time on the SMS when games are writing to VRAM after the active display has finished, but before the beam has actually reached the bottom of the screen, in the form of similar flashing pixels.

Hi, folks. I've discovered (to my embarrassment) that this demo will not work properly on older GGs (without the BIOS) because I forgot to clear an important variable on startup. (The BIOS clears RAM beforehand, I'll bet.)

So, I've updated my demo and it should work fine on all Game Gear models.

Author	Message
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	My first Game Gear demo Posted: Mon Apr 11, 2005 1:58 pm Last edited by ccovell on Mon Apr 11, 2005 4:25 pm; edited 1 time in total
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Hi, folks. It's been a fun week. I learnt better how the SMS and GG's internals worked thanks to some of Maxim's programming tutorials, and I found out how much the GG's VDP can handle when written to during screen refresh. So, I'd like to release the product of my labour. It's a high-colour ("hicolor") demo that will show 7 images in sequence. Technically, this demo can display up to 288 colours on-screen at once, which is 9 times more than the GG regularly does. Perhaps more colours can be squeezed out by someone else, but I dunno... Please download and tell me what you think! http://disgruntleddesigner.com/chrisc/data/GGHicolor.zip

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Apr 11, 2005 4:05 pm
	ccovell wrote I learnt better how the SMS and GG's internals worked thanks to some of Martin's programming tutorials cough (unless Martin made some tutorials I don't know about)

S.F Joined: 08 Apr 2005 Posts: 474 Location: Netherlands	Posted: Mon Apr 11, 2005 4:18 pm
S.F Joined: 08 Apr 2005 Posts: 474 Location: Netherlands	Nice! Looks cool.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Mon Apr 11, 2005 4:34 pm
	Did you try it on a real system? Others have had difficulty avoiding artefacts with mid-frame palette updates, although the GG screen size makes it easier. Meka's paletted video display will tend to make this kind of demo break, so you're helping move us towards a more advanced Meka :)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8652 Location: Paris, France	Posted: Mon Apr 11, 2005 7:34 pm
	As Maxim mentionned, MEKA supports mid-screen raster palette effects, but it has a buffer of 64 colors per frame (due to palette constraints). That's twice the 32. It suffise for commercial games I tested (the Sonic games often uses this features to switch mid-screen to get a water-palette). Now that I'm decided to drop 8-bit paletted mode, maybe I should work it out and make a definitive switch to hi-color. Nice demo.

Heliophobe Site Admin Joined: 25 Oct 1999 Posts: 2029 Location: Monterey, California	Posted: Mon Apr 11, 2005 8:29 pm
	Bock wrote As Maxim mentionned, MEKA supports mid-screen raster palette effects, but it has a buffer of 64 colors per frame (due to palette constraints). That's twice the 32. It suffise for commercial games I tested (the Sonic games often uses this features to switch mid-screen to get a water-palette). Now that I'm decided to drop 8-bit paletted mode, maybe I should work it out and make a definitive switch to hi-color. Nice demo. I too am curious to see how the GG handles the color updates. I imagine it should turn out alright, by the time the CRAM updates are actually posted the VDP should already have started drawing outside of the visible area (I don't remember exactly where we figured the h-int fires, I think it was around pixel 176 of the 256 pixel display, but the archives should hold the answer somewhere). As I recall, the VDP's that do have a problem with screen corruption on cram updates will still recover by the next scanline, and I think it's only the SMS1's VDP that's so sensitive.

dodginess Joined: 21 Mar 2005 Posts: 51 Location: United Kingdom	Posted: Mon Apr 11, 2005 10:00 pm
	Just a quick (newbie) question: In the "Graphics now follow!!!!!" section at the bottom of the source code, what does the palhed.bin file do? And secondly, how come you've got this far already? I'm still trying to work out the VDP instructions :)

ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Posted: Tue Apr 12, 2005 2:00 am
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Hi folks, Yes, I tested this on my GG system (using Tototek's SMS Flash cartridge), and it is intended to be used on the real hardware (the GG's screen smoothes the dithering in the 2nd image, for instance.) I didn't know where the H-Sync interrupt was triggered; I had assumed it was off-screen on the left side, and that my interrupt code was a little slow :). But if it actually is at pixel 176, then it does make sense. I first tested the H-ints with a single write to the palette on the SMS, and there was a solid band of corruption/jumping palette noise right around there, going down the screen. So, with just a little more code in the h-int handler, the palette writing is safely offscreen on the GG. One interesting thing that helped me: My GG has a video output (hacked like Victor Kemp's) so I can check the graphics of the GG on my TV. And even though it's in black&white, I can check for graphics corruption on the main screen easily. Also, curiously, though there are no graphics visible on the TV past the GG's borders, background palette data and "snow" appear precisely where the palette is being changed mid-frame. So that did help too. Dodginess: I was lazy and didn't trigger the palette writing just from the start of the GG screen; I had h-ints (and palette writing) start from the vertical retrace. So, above the GG screen, the palette is being written to (with unimportant data). This is the data contained in palhed.bin, since it is the same for each pic (individual pictures' tiles and palettes are different.) Even though this is my first Z80 coding project, I have done similar things on the NES and Turbografx-16 before. So the techniques are the same, even if I still don't yet know what each Z80 instruction does. ;-)

Jan_Solrac Guest	humm Posted: Tue Apr 12, 2005 8:00 am
Jan_Solrac Guest	Impressive. Humm, can I play the Mario64 scene?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14745 Location: London	Posted: Tue Apr 12, 2005 9:20 am
	ccovell wrote Also, curiously, though there are no graphics visible on the TV past the GG's borders, background palette data and "snow" appear precisely where the palette is being changed mid-frame. So that did help too. It is interesting how it masks the screen in GG mode; perhaps they had hopes for consumer-level TV output at some point, or maybe they just made the VDP restrict itself to drawing there to give a bit more time in the HBlank to write to VRAM without restrictions. However, in this region it's still drawing the background/border colour, in the same way as the SMS, so it is still actively doing stuff there, just not as much stuff and requiring less VRAM/CRAM reads. In the event of writes to VRAM above a certain rate, it loses out in the bus collisions and outputs bad data. You see this all the time on the SMS when games are writing to VRAM after the active display has finished, but before the beam has actually reached the bottom of the screen, in the form of similar flashing pixels.

ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Demo updated! (Bugfixed) Posted: Thu Jun 16, 2005 4:17 pm
ccovell Joined: 26 Dec 2004 Posts: 374 Location: Japan	Hi, folks. I've discovered (to my embarrassment) that this demo will not work properly on older GGs (without the BIOS) because I forgot to clear an important variable on startup. (The BIOS clears RAM beforehand, I'll bet.) So, I've updated my demo and it should work fine on all Game Gear models.

Forums

View topic - My first Game Gear demo