Forums

I've tried running a few tests on a Majesco GG, and came up with the following: (all in SMS mode)

To display SMS graphics on the GG screen, the first and last 8 pixels of each scanline are omitted, leaving 240 pixels. Of these, each one is displayed using only two of the three RGB elements in each pixel. I was able to test this by displaying a white stripe and scrolling it horizontally, the stripe is never shown as white and instead cycles through yellow, magenta, and cyan. This makes sense if you view the display as being 480 dots wide (160 pixels x 3 elements), by using 2 of them you are left with a 240-pixel resolution.
On lines where there are multiple pixels of the same color, this effect isn't very noticable. But it does explain the color problems around the edges of graphics, especially text, in SMS games.

As for the vertical aspects, I'm not too sure. The default resolution appears to be around 224 lines, as games using 192 lines leave a border at the top and bottom of the screen. (So the Codemasters games work fine) The 240-line mode causes the display to roll and the machine locks up, just like with a NTSC SMS2.
But it's not really clear how all that fits into 144 rows.

Some PAL games run incorrectly, so apparently the Game Gear has the same kind of timing that an NTSC machine has.

Colors in the TMS9918 modes are incorrect; not writing to CRAM or writing $00 gives a black display, but trying to write a close approximation of the TMS9918 palette or all $30's resulted in the same set of wrong colors (compared to nothing at all). So it's not really clear if the CRAM values have any influence on the display, maybe it just matters if they are nonzero or not.
Bock, would it be possible to get a dump of the multicart you talked about which sets up CRAM before running SG-1000 games? I'd like to see how the colors look on my machine.

I'll try to add a SMS/GG switch so I can test the Game Gear side of things, and report on that later. ;)

My Homepage

I hacked up my SMS adapter to add a SMS/GG switch, and have done some more tests in GG mode:

When CRAM is written to at even addresses, the value isn't written to CRAM and is saved in a buffer. When you write to an odd address, the contents of the buffer and the new byte written are written as an entire word to CRAM.
This means that you could load the buffer by writing to $C03E, but then write to $C001 and use the buffered byte and the new byte to set a color. Obviously this kind of thing would be important to emulate. The buffer is unrelated to the VRAM read buffer.

Writing to CRAM during the active display period causes flicker, just like a normal SMS. Also, even though I had a hunch this was the case, each color element in CRAM is four bits wide, not 3. And the upper four bits of the second CRAM byte really do nothing, they are unused.

If M2 is set and M1,M3 are used to change the screen resolution, the name table will start at a boundary of $0700 (like the SMS2), but the physical resolution does not change. Using the 240-line mode causes the screen to roll.

The lower 5 bits of the VDP control port value seem to be related to the sprites (like the TMS9918). If the sprite table is filled with garbage, the lower 5 bits hold garbage values, and if the table is filled with $D0 the lower five bits return $10, always. I haven't figured out the exact relationship between the two, but it seems that the status flags do indicate something about the sprites.

For the I/O ports, the player 1 controls are at $C0 and $DC only. All other ports return $FF, and the top 2 bits of $C0/$DC are '1', indicating the player 2 up and down buttons are not pressed. Even if the I/O port disable bit in port $3E is set to '0', the I/O port layout does not change at all.

For ports $00-$3F, the first 6 ports return the following: 'C0 7F FF 00 FF 00'. Port $00 is $C0 normally, or $40 if the START button is pressed. Port $06 (stereo control) is write only and always returns $FF. I'll try to check ports $01-$05 later on.

The other ports work as expected, $40-$7F is the V counter (H counter is always $00), and $80-BF are the VDP control and data ports.

I'm going to add all of this information (and stuff from my other post) to my VDP and SMS documents, but I figure in the meantime it would be better to post here. ;)

My Homepage

Here's a program to demonstrate high resolution graphics on the Game Gear:

http://cgfm2.emuviews.com/zip/hidemo.zip

It uses the same technique that was mentioned elsewhere (I forgot the URL) where the individual RGB elements of each pixel on an LCD screen can be thought of pixels themselves, tripling the horizontal resolution from 160 pixels to 480.
The demo program displays the message "SMS Power!", and pressing start cycles through different palettes to show how the graphics look if the 'pixels' aren't aligned to each RGB element within each real pixel.

If anybody decides to run this on a Game Gear or one with TV output, I'd like to know if the 6th screen (which is mostly black) shows the SMS Power logo in gray, or not at all. If the text is visible, it is probably very hard to see.

My Homepage

Author	Message
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Game Gear stuff Posted: Fri Feb 15, 2002 5:10 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	I've tried running a few tests on a Majesco GG, and came up with the following: (all in SMS mode) To display SMS graphics on the GG screen, the first and last 8 pixels of each scanline are omitted, leaving 240 pixels. Of these, each one is displayed using only two of the three RGB elements in each pixel. I was able to test this by displaying a white stripe and scrolling it horizontally, the stripe is never shown as white and instead cycles through yellow, magenta, and cyan. This makes sense if you view the display as being 480 dots wide (160 pixels x 3 elements), by using 2 of them you are left with a 240-pixel resolution. On lines where there are multiple pixels of the same color, this effect isn't very noticable. But it does explain the color problems around the edges of graphics, especially text, in SMS games. As for the vertical aspects, I'm not too sure. The default resolution appears to be around 224 lines, as games using 192 lines leave a border at the top and bottom of the screen. (So the Codemasters games work fine) The 240-line mode causes the display to roll and the machine locks up, just like with a NTSC SMS2. But it's not really clear how all that fits into 144 rows. Some PAL games run incorrectly, so apparently the Game Gear has the same kind of timing that an NTSC machine has. Colors in the TMS9918 modes are incorrect; not writing to CRAM or writing $00 gives a black display, but trying to write a close approximation of the TMS9918 palette or all $30's resulted in the same set of wrong colors (compared to nothing at all). So it's not really clear if the CRAM values have any influence on the display, maybe it just matters if they are nonzero or not. Bock, would it be possible to get a dump of the multicart you talked about which sets up CRAM before running SG-1000 games? I'd like to see how the colors look on my machine. I'll try to add a SMS/GG switch so I can test the Game Gear side of things, and report on that later. ;) My Homepage

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	More information... Posted: Sat Feb 16, 2002 3:43 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	I hacked up my SMS adapter to add a SMS/GG switch, and have done some more tests in GG mode: When CRAM is written to at even addresses, the value isn't written to CRAM and is saved in a buffer. When you write to an odd address, the contents of the buffer and the new byte written are written as an entire word to CRAM. This means that you could load the buffer by writing to $C03E, but then write to $C001 and use the buffered byte and the new byte to set a color. Obviously this kind of thing would be important to emulate. The buffer is unrelated to the VRAM read buffer. Writing to CRAM during the active display period causes flicker, just like a normal SMS. Also, even though I had a hunch this was the case, each color element in CRAM is four bits wide, not 3. And the upper four bits of the second CRAM byte really do nothing, they are unused. If M2 is set and M1,M3 are used to change the screen resolution, the name table will start at a boundary of $0700 (like the SMS2), but the physical resolution does not change. Using the 240-line mode causes the screen to roll. The lower 5 bits of the VDP control port value seem to be related to the sprites (like the TMS9918). If the sprite table is filled with garbage, the lower 5 bits hold garbage values, and if the table is filled with $D0 the lower five bits return $10, always. I haven't figured out the exact relationship between the two, but it seems that the status flags do indicate something about the sprites. For the I/O ports, the player 1 controls are at $C0 and $DC only. All other ports return $FF, and the top 2 bits of $C0/$DC are '1', indicating the player 2 up and down buttons are not pressed. Even if the I/O port disable bit in port $3E is set to '0', the I/O port layout does not change at all. For ports $00-$3F, the first 6 ports return the following: 'C0 7F FF 00 FF 00'. Port $00 is $C0 normally, or $40 if the START button is pressed. Port $06 (stereo control) is write only and always returns $FF. I'll try to check ports $01-$05 later on. The other ports work as expected, $40-$7F is the V counter (H counter is always $00), and $80-BF are the VDP control and data ports. I'm going to add all of this information (and stuff from my other post) to my VDP and SMS documents, but I figure in the meantime it would be better to post here. ;) My Homepage

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Demo program Posted: Mon Feb 18, 2002 3:50 am
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Here's a program to demonstrate high resolution graphics on the Game Gear: http://cgfm2.emuviews.com/zip/hidemo.zip It uses the same technique that was mentioned elsewhere (I forgot the URL) where the individual RGB elements of each pixel on an LCD screen can be thought of pixels themselves, tripling the horizontal resolution from 160 pixels to 480. The demo program displays the message "SMS Power!", and pressing start cycles through different palettes to show how the graphics look if the 'pixels' aren't aligned to each RGB element within each real pixel. If anybody decides to run this on a Game Gear or one with TV output, I'd like to know if the 6th screen (which is mostly black) shows the SMS Power logo in gray, or not at all. If the text is visible, it is probably very hard to see. My Homepage

Forums

View topic - Game Gear stuff