Forums

No problem. I've just tested MDKEY15 and the results are the same as 16.
Also, in both versions all six buttons are registered, plus start and select.

so, let's see if using the new info collected by Calindro's test ROMs I can fix the detection routines so that they work both with your adapter and the regular MD pads.

please check with the attached ROM

SMSTestSuite_v0.30b.sms.zip (21.12 KB)

SMS Test Suite ver. 0.30b

Thank you, guys!
Now all buttons are detected on a megadrive 2!

thanks for your feedback
now I hope it still works with a regular 6-button MD pad - anyone has a chance to test it? I have no access to my hardware atm...

i thought i had a 6 button controller about but don't seem to be able to find it

I have a 6 button controller from a PAL asian megadrive 2. It's properly detected by sms test suite on a megadrive 2.

so looks like I didn't break previous compatibility, good...

thank you!

sverx wrote

so looks like I didn't break previous compatibility, good...

thank you!

Thank you, too!

Z80 type detection added (NMOS/CMOS)

every Master System's Z80 should be NMOS, but a few Game Gears could have CMOS instead.

... not a big deal, I would say, unless the program uses the undocumented

OUT (C), 0

instruction. A CMOS Z80 would output 255 ($FF) instead of 0 (and that's how I'm detecting it).

I don't think any official game uses that instruction, though. But homebrew programs in fact might...

SMSTestSuite_v0.31.png (14.18 KB)

showing Z80 type

SMSTestSuite_v0.31.sms.zip (22.25 KB)

SMS Test Suite ver. 0.31

Is there a way in software to determine a 2 asic vs 1 asic game gear?

wasup wrote

Is there a way in software to determine a 2 asic vs 1 asic game gear?

I really have no idea. If they are completely functionally equivalent, we surely can't. But some Game Gears use CMOS CPU - is the CPU embedded in the ASIC?

Ive dug out some working game gears and they all detect as cmos. Ive opened them up to see what they are and i have...

1 x 2 asic with no bios
1 x 1 asic with no bios
4 x 1 asic with bios

sverx wrote

wasup wrote

Is there a way in software to determine a 2 asic vs 1 asic game gear?

I really have no idea. If they are completely functionally equivalent, we surely can't.

Ive done a bit of research and it looks lile we may be able to detect between them. There apprars to be 3 separate types.

- 2 asic (315-5377 + 315-5378)
- early 1 asic (315-5535)
- later 1 asic (315-5682)

Using the vdp test that was provided here..

https://www.smspower.org/forums/10695-SMSVDPTester?start=50#107039

I get 3 different results.

The 2 asic tests all pass on the 2 asic unit.
The 1 asic tests mostly pass on the 2 asic unit.

The 1 asic tests mostly pass on the 1 asic unit without a bios.

The 1 asic tests all pass on the 1 asic unit with the bios.

The 2 common tests that failed are "V-counter chg time" and "Frame irq H-count". Presumabily its expecting a set result and displaying fail if its different. Can we use the result from one of those tests to determine the asic type assuming a consistant result comes from each asic type?

It might also be cool to detect if a gg bios is present.

I will try to dig some info from there, there might be a few slight differences in VDP timing and if this prove consistent it might really give some ground to some asic test.

In the while, with a bit of help from Calindro, I could add (and test) GameGear BIOS detection and fingerprinting.

If you can test it also on hardware it would be wonderful :)

SMSTestSuite_v0.32(1).png (16.42 KB)

SMS Test Suite ver. 0.32 screenshot 1

SMSTestSuite_v0.32(2).png (16.52 KB)

SMS Test Suite ver. 0.32 screenshot 2

SMSTestSuite_v0.32(3).png (15.94 KB)

SMS Test Suite ver. 0.32 screenshot 3

SMSTestSuite_v0.32.sms.zip (22.72 KB)

SMS Test Suite ver. 0.32

Nice work, seems to work fine.

My 2 asic and 1 asic without a bios both detect as no bios correctly.

My other three 1 asic units with a bios detects as a majesco bios correctly.

I'm so glad you're developing this. Testing tools like this are so incredibly helpful for old Hardware repairs :)

Hi guys,

This is an EXTREMELY useful tool !! THANK YOU VERY MUCH !!!

is it possible to test hardware such as RAM/VRAM ?

Also, if needed I can test it against a Sega Mega Jet, let me know if this will be a useful test.

EDIT:

Well I tested it against my sega Nomad and Sega Mega Jet also changing the region (the chip inside Mega Jet is 315-5660-10). I also added the 1st page result of GenTestV2.4.bin test rom.

One notice: the pad button test does not show MODE button while when pressing the RESET button on the mega jet it goes to a black screen at 1st press and I need to re-press it to go backt the button test.

20200529_093001.jpg (857.87 KB)

20200529_093516.jpg (801.11 KB)

20200529_093800.jpg (1.95 MB)

20200529_093842.jpg (1.81 MB)

20200529_094009.jpg (3.69 MB)

20200529_093924.jpg (4.04 MB)

This software is amazing sverx. You are now immortally famous on youtube:
.be

real hardware test on GG with stock screen and McWill screen.

Feedback in the video. Great work!

=== Wish List for Future Versions ===

**Light Phaser, Paddle and Sports Pad testing**

I know some of these would be really hard to do, just dreaming!

segasonicfan wrote

=== Wish List for Future Versions ===

**Light Phaser, Paddle and Sports Pad testing

Paddle controller tests are there.. its just only shown when a paddle controller is detected.

segasonicfan wrote

sonic icon on main screen instead of southpark :)

That's not just a southpark character. It's his avatar. ;)
Why would he put Sonic there? Just because you are segasonicfan? :D

segasonicfan wrote

GG SMS / GG mode test

What do you mean by that? It works in both GG SMS mode and detects it accordingly.

segasonicfan wrote

GG McWill resolution modes testing (like a square for pixel aspect ratio changes)

There already is the test called "Linearity" that renders circles. They look like circles with GG PAR and like eggs with 1:1 PAR.
Ironically, it seems to be the only video test you did not run in your video.

A mode to make it work in GG mode (native resolution) would be nice, I guess you can use the GG low ports to detect that. It seems to mostly work except for the palette and the incorrect linearity test.

It seems the linearity test does not differ between PAL and NTSC modes, which I guess is a mistake?

What about a ram/vram test?

Quote

Why would he put Sonic there?

cause it's sega! or something sega-related. just a minor preference. I didnt know it was an avatar..

Quote

A mode to make it work in GG mode (native resolution) would be nice, I guess you can use the GG low ports to detect that. It seems to mostly work except for the palette and the incorrect linearity test.

This is what I meant by GG / SMS mode.

There already is the test called "Linearity" that renders circles.

Cool, I'll check it out.

Quote

One of my project ideas is to make a light phaser program which shows an all white screen, then captures the phaser data for a single frame, then plots that on the screen, and repeats. You should in theory see a half circle pattern drawn with radius depending on the distance from the screen. Emulators will probably look better different. Then you can experiment with algorithms to determine the centre of the circle - I think some games use (y of min x, x of min y) but I'm sure you could do better. By doing it every second frame, you'd get real-time updates without a full screen flash.

+1 would be amazing.

Quote

it might be nice to integrate some of the work done in things like http://www.smspower.org/Homebrew/SMSVDPTest-SMS and also to demonstrate some of the VDP differences like tilemap mirroring and sprite doubling limits.

+1. more debugging options the better!

Quote

Paddle control tests just added, for (Japanese) paddle controls.
You can plug paddle(s) in port 1 and/or port 2. (In case you need to start the ROM with normal pads connected you can do that and switch to paddle(s) when in the main menu and press PAUSE to restart the ROM).
If two paddles are connected at the same moment, the paddle tests will run automatically, but no other test will be available.

HUGE thanks to Kagesan for his invaluable help.

Very cool! Maybe a note on screen saying it is supported would be nice? If it's not too much work.

UPDTED WISH LIST
*RAM/VRAM test
*Light Phaser test
*Sport pad test
*Combine with VDPTest software
*GG video resolution mode / or larger text for GG screens
*GG battery LED test
*GG battery voltage and / or system voltages (if possible)
*Clock testing / display CPU, VDP, Master CLK
*GG brightness / contrast testing (not sure how to do this, options available may already be enough)

Im just dreaming big, this is already an AMAZING project!!

Displaying clocks and voltages are not possible, in fact the 50/60Hz detection relies on not overclocking (because it can only detect the ratio between the two frequencies). The grey scale test could be more fine grained on GG (or even focus on the 16 darkest and lightest tones) for contrast testing.

@segasonicfan : Maybe you'll find this useful :

phaser.zip (470 B)

although SMS Test Suite can identify if it runs on a Game Gear or on a MegaDrive, it's aimed at Master Systems, so tests are there to check if your hardware / your TV set up / your controllers works fine

Thanks for your suggestions on how to improve the suite, I will surely add more tests as more time becomes available.

Also, if there's need, I might also fork a Game Gear specific version, I mean expressly aimed at Game Gear hardware.

vingazole wrote

@segasonicfan : Maybe you'll find this useful :

That’s my idea :) it would be good to also dump out the raw data and record results at a few distances from the screen. We can then compute the result of some of the algorithms to compare to what you’d expect.

The algorithms include some scaling and offsets to the data, are you applying those before painting? I guess not as it seems offset to the left of the gun. It does seem quite distance invariant too.

I was trying to simulate what the test suite (and many other SMS programs) would look like on a Game Gear with the original screen in terms of aspect ratio, RGB subpixel geometry, GG-SMS color channel dropping + averaging, and tile cropping, but without actually drawing the subpixel elements — instead I wanted something that would look a little more natural, similar to the screen viewed from a typical viewing distance where the subpixel elements may not be obvious but their impact on color is still apparent

I attempted to simulate it using a transformation of a screenshot originally captured from Emulicious in "square pixel" mode. The only very glaringly unrealistic part here AFAIK is that the top and bottom border are always black rather than their actual colors, but that's because Emulicious doesn't draw or store the top and bottom border of the GG-SMS screen in its screenshots

Horizontal GG-SMS to subpixel mapping seems to behave like the real hardware, at least to my untrained eye.

I don't know how the combination of successive GG-SMS rows works. 3 such rows are mapped to each 2 LCD pixel rows. I simulated it using averaging but it seems like my result doesn't quite match what I see on real hardware in the vertical dimension. Does anyone know how this worked on the original hardware?

To approximate the 4:3 display aspect ratio I scaled the image up to 960x720, so it should be easily viewable on a 720p display

Example pipeline used:

anytopnm \
< Emulicious/screenshots/SMSTestSuite_v0.32.png | \
pnmmargin -black 12 | \
pamcut -left $((12+8)) -right $((12+247)) | \
pamenlarge -xscale 2 | \
ppmtorgb3 ; \
rgb3toppm \
<( pnmpad -left 3 -right 0 noname.red ) \
<(pnmpad -left 2 -right 1 noname.grn ) \
<(pnmpad -left 1 -right 2 noname.blu ) | \
pamscale -xscale 0.333333333333333333333333333 -nomix | \
pamcut -left 1 | \
pamscale -yscale 0.666666666666666666666666666 | \
pamscale -nomix -yscale 5 | \
pamstretch -xscale 6 | \
ppmtorgb3; \
rgb3toppm \
<( pnmpad -left 0 -right 6 noname.red ) \
<(pnmpad -left 2 -right 4 noname.grn ) \
<(pnmpad -left 4 -right 2 noname.blu ) | \
pamcut -left 3 -right 962 | \
pamtopng \
> SMSTestSuite_v0.32-linearity.png

edit: typo corrected, previously said "right border" instead of the correct "bottom border"

SMSTestSuite_v0.32-title-emulicious.png (4.03 KB)

SMSTestSuite_v0.32-linearity-emulicious.png (2.43 KB)

SMSTestSuite_v0.32-title.png (34.22 KB)

SMSTestSuite_v0.32-linearity.png (26.95 KB)

Old discussion here:

https://www.smspower.org/forums/9562-GameGearSMSModeVideoScaling

bsittler wrote

The only very glaringly unrealistic part here AFAIK is that the top and right border are always black rather than their actual colors

I don't get why you're trying to show borders, I think you can't see them on a Game Gear at all... or am I wrong?

sverx wrote

bsittler wrote

The only very glaringly unrealistic part here AFAIK is that the top and right border are always black rather than their actual colors

I don't get why you're trying to show borders, I think you can't see them on a Game Gear at all... or am I wrong?

In Game Gear SMS mode 12 SMS pixels of top and bottom border are indeed visible in 192-line mode (the SMS content area is scaled down to 128 GG pixel rows, with the top and bottom border each scaled down to 8 GG pixel rows, for a total of 144 GG pixel rows). So overall a 240x216 SMS pixel area is visible. I don't know yet which pixel rows are shown when the SMS content uses 224-line mode

edit: also, this applies to the original hardware, both Sega-era and Majesco-era. Modern replacement screens (McWill etc.) behave differently to this and are not what I'm describing here

edit 2: meant to write top and bottom border, I'll go back and correct the typo!

Maxim wrote

Old discussion here:

https://www.smspower.org/forums/9562-GameGearSMSModeVideoScaling

Thank you! This is exactly the info I was trying to find. I'll see whether I can use it in order to more closely approximate the behavior I observe on original hardware

Author	Message
gorgyrip Joined: 11 Mar 2006 Posts: 72	Posted: Fri Mar 27, 2020 10:07 pm
gorgyrip Joined: 11 Mar 2006 Posts: 72	No problem. I've just tested MDKEY15 and the results are the same as 16. Also, in both versions all six buttons are registered, plus start and select.

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Sat Mar 28, 2020 10:52 am
sverx Joined: 05 Sep 2013 Posts: 2908	so, let's see if using the new info collected by Calindro's test ROMs I can fix the detection routines so that they work both with your adapter and the regular MD pads. please check with the attached ROM SMSTestSuite_v0.30b.sms.zip (21.12 KB) SMS Test Suite ver. 0.30b

gorgyrip Joined: 11 Mar 2006 Posts: 72	Posted: Sat Mar 28, 2020 11:06 am
gorgyrip Joined: 11 Mar 2006 Posts: 72	Thank you, guys! Now all buttons are detected on a megadrive 2!

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Sat Mar 28, 2020 12:15 pm
sverx Joined: 05 Sep 2013 Posts: 2908	thanks for your feedback now I hope it still works with a regular 6-button MD pad - anyone has a chance to test it? I have no access to my hardware atm...

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Sun Mar 29, 2020 12:57 am
	i thought i had a 6 button controller about but don't seem to be able to find it

gorgyrip Joined: 11 Mar 2006 Posts: 72	Posted: Sun Mar 29, 2020 9:39 am
gorgyrip Joined: 11 Mar 2006 Posts: 72	I have a 6 button controller from a PAL asian megadrive 2. It's properly detected by sms test suite on a megadrive 2.

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Sun Mar 29, 2020 11:56 am
sverx Joined: 05 Sep 2013 Posts: 2908	so looks like I didn't break previous compatibility, good... thank you!

gorgyrip Joined: 11 Mar 2006 Posts: 72	Posted: Sun Mar 29, 2020 12:06 pm
gorgyrip Joined: 11 Mar 2006 Posts: 72	sverx wrote so looks like I didn't break previous compatibility, good... thank you! Thank you, too!

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Fri Apr 03, 2020 10:12 am
sverx Joined: 05 Sep 2013 Posts: 2908	Z80 type detection added (NMOS/CMOS) every Master System's Z80 should be NMOS, but a few Game Gears could have CMOS instead. ... not a big deal, I would say, unless the program uses the undocumented OUT (C), 0 instruction. A CMOS Z80 would output 255 ($FF) instead of 0 (and that's how I'm detecting it). I don't think any official game uses that instruction, though. But homebrew programs in fact might... SMSTestSuite_v0.31.png (14.18 KB) showing Z80 type SMSTestSuite_v0.31.sms.zip (22.25 KB) SMS Test Suite ver. 0.31

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Sun Apr 05, 2020 12:36 am
	Is there a way in software to determine a 2 asic vs 1 asic game gear?

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Sun Apr 05, 2020 12:38 pm
sverx Joined: 05 Sep 2013 Posts: 2908	wasup wrote Is there a way in software to determine a 2 asic vs 1 asic game gear? I really have no idea. If they are completely functionally equivalent, we surely can't. But some Game Gears use CMOS CPU - is the CPU embedded in the ASIC?

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Mon Apr 06, 2020 2:32 am
	Ive dug out some working game gears and they all detect as cmos. Ive opened them up to see what they are and i have... 1 x 2 asic with no bios 1 x 1 asic with no bios 4 x 1 asic with bios

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Mon Apr 06, 2020 8:45 am
	sverx wrote wasup wrote Is there a way in software to determine a 2 asic vs 1 asic game gear? I really have no idea. If they are completely functionally equivalent, we surely can't. Ive done a bit of research and it looks lile we may be able to detect between them. There apprars to be 3 separate types. - 2 asic (315-5377 + 315-5378) - early 1 asic (315-5535) - later 1 asic (315-5682) Using the vdp test that was provided here.. https://www.smspower.org/forums/10695-SMSVDPTester?start=50#107039 I get 3 different results. The 2 asic tests all pass on the 2 asic unit. The 1 asic tests mostly pass on the 2 asic unit. The 1 asic tests mostly pass on the 1 asic unit without a bios. The 1 asic tests all pass on the 1 asic unit with the bios. The 2 common tests that failed are "V-counter chg time" and "Frame irq H-count". Presumabily its expecting a set result and displaying fail if its different. Can we use the result from one of those tests to determine the asic type assuming a consistant result comes from each asic type? It might also be cool to detect if a gg bios is present.

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Mon Apr 06, 2020 9:39 am
sverx Joined: 05 Sep 2013 Posts: 2908	I will try to dig some info from there, there might be a few slight differences in VDP timing and if this prove consistent it might really give some ground to some asic test.

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Tue Apr 07, 2020 1:57 pm
sverx Joined: 05 Sep 2013 Posts: 2908	In the while, with a bit of help from Calindro, I could add (and test) GameGear BIOS detection and fingerprinting. If you can test it also on hardware it would be wonderful :) SMSTestSuite_v0.32(1).png (16.42 KB) SMS Test Suite ver. 0.32 screenshot 1 SMSTestSuite_v0.32(2).png (16.52 KB) SMS Test Suite ver. 0.32 screenshot 2 SMSTestSuite_v0.32(3).png (15.94 KB) SMS Test Suite ver. 0.32 screenshot 3 SMSTestSuite_v0.32.sms.zip (22.72 KB) SMS Test Suite ver. 0.32

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Wed Apr 08, 2020 1:00 am
	Nice work, seems to work fine. My 2 asic and 1 asic without a bios both detect as no bios correctly. My other three 1 asic units with a bios detects as a majesco bios correctly.

segasonicfan Joined: 05 Jan 2006 Posts: 339 Location: USA	Posted: Tue May 05, 2020 9:36 am
	I'm so glad you're developing this. Testing tools like this are so incredibly helpful for old Hardware repairs :)

asper Joined: 25 Nov 2015 Posts: 119	Hardware Test Posted: Thu May 28, 2020 8:24 pm
asper Joined: 25 Nov 2015 Posts: 119	Hi guys, This is an EXTREMELY useful tool !! THANK YOU VERY MUCH !!! is it possible to test hardware such as RAM/VRAM ? Also, if needed I can test it against a Sega Mega Jet, let me know if this will be a useful test. EDIT: Well I tested it against my sega Nomad and Sega Mega Jet also changing the region (the chip inside Mega Jet is 315-5660-10). I also added the 1st page result of GenTestV2.4.bin test rom. One notice: the pad button test does not show MODE button while when pressing the RESET button on the mega jet it goes to a black screen at 1st press and I need to re-press it to go backt the button test. 20200529_093001.jpg (857.87 KB) 20200529_093516.jpg (801.11 KB) 20200529_093800.jpg (1.95 MB) 20200529_093842.jpg (1.81 MB) 20200529_094009.jpg (3.69 MB) 20200529_093924.jpg (4.04 MB)

segasonicfan Joined: 05 Jan 2006 Posts: 339 Location: USA	Posted: Fri May 29, 2020 8:54 am
	This software is amazing sverx. You are now immortally famous on youtube: .be real hardware test on GG with stock screen and McWill screen. Feedback in the video. Great work! === Wish List for Future Versions === Light Phaser, Paddle and Sports Pad testing RAM test Larger text for stock GG screens (esp. for sound test) sonic icon on main screen instead of southpark :) Voltage readouts (if possible?) I know GG measures Vbatt. This would be amazing for testing units GG low batt LED test (blink) GG SMS / GG mode test GG McWill resolution modes testing (like a square for pixel aspect ratio changes) Overclock testing (and showing MAIN, CPU, and VDP clocks separate) GG brightness / contrast testing I know some of these would be really hard to do, just dreaming!

wasup Joined: 05 Nov 2014 Posts: 367 Location: Auckland - NZ	Posted: Fri May 29, 2020 10:03 am
	segasonicfan wrote === Wish List for Future Versions === **Light Phaser, Paddle and Sports Pad testing Paddle controller tests are there.. its just only shown when a paddle controller is detected.

Calindro Joined: 14 Apr 2013 Posts: 528	Posted: Fri May 29, 2020 11:11 am
Calindro Joined: 14 Apr 2013 Posts: 528	segasonicfan wrote sonic icon on main screen instead of southpark :) That's not just a southpark character. It's his avatar. ;) Why would he put Sonic there? Just because you are segasonicfan? :D segasonicfan wrote GG SMS / GG mode test What do you mean by that? It works in both GG SMS mode and detects it accordingly. segasonicfan wrote GG McWill resolution modes testing (like a square for pixel aspect ratio changes) There already is the test called "Linearity" that renders circles. They look like circles with GG PAR and like eggs with 1:1 PAR. Ironically, it seems to be the only video test you did not run in your video.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13650 Location: London	Posted: Fri May 29, 2020 3:15 pm
	A mode to make it work in GG mode (native resolution) would be nice, I guess you can use the GG low ports to detect that. It seems to mostly work except for the palette and the incorrect linearity test. It seems the linearity test does not differ between PAL and NTSC modes, which I guess is a mistake?

asper Joined: 25 Nov 2015 Posts: 119	Ram/vram Posted: Fri May 29, 2020 3:42 pm
asper Joined: 25 Nov 2015 Posts: 119	What about a ram/vram test?

segasonicfan Joined: 05 Jan 2006 Posts: 339 Location: USA	Posted: Fri May 29, 2020 9:55 pm
	Quote Why would he put Sonic there? cause it's sega! or something sega-related. just a minor preference. I didnt know it was an avatar.. Quote A mode to make it work in GG mode (native resolution) would be nice, I guess you can use the GG low ports to detect that. It seems to mostly work except for the palette and the incorrect linearity test. This is what I meant by GG / SMS mode. There already is the test called "Linearity" that renders circles. Cool, I'll check it out. Quote One of my project ideas is to make a light phaser program which shows an all white screen, then captures the phaser data for a single frame, then plots that on the screen, and repeats. You should in theory see a half circle pattern drawn with radius depending on the distance from the screen. Emulators will probably look better different. Then you can experiment with algorithms to determine the centre of the circle - I think some games use (y of min x, x of min y) but I'm sure you could do better. By doing it every second frame, you'd get real-time updates without a full screen flash. +1 would be amazing. Quote it might be nice to integrate some of the work done in things like http://www.smspower.org/Homebrew/SMSVDPTest-SMS and also to demonstrate some of the VDP differences like tilemap mirroring and sprite doubling limits. +1. more debugging options the better! Quote Paddle control tests just added, for (Japanese) paddle controls. You can plug paddle(s) in port 1 and/or port 2. (In case you need to start the ROM with normal pads connected you can do that and switch to paddle(s) when in the main menu and press PAUSE to restart the ROM). If two paddles are connected at the same moment, the paddle tests will run automatically, but no other test will be available. HUGE thanks to Kagesan for his invaluable help. Very cool! Maybe a note on screen saying it is supported would be nice? If it's not too much work. UPDTED WISH LIST RAM/VRAM test Light Phaser test Sport pad test Combine with VDPTest software GG video resolution mode / or larger text for GG screens GG battery LED test GG battery voltage and / or system voltages (if possible) Clock testing / display CPU, VDP, Master CLK *GG brightness / contrast testing (not sure how to do this, options available may already be enough) Im just dreaming big, this is already an AMAZING project!!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13650 Location: London	Posted: Sat May 30, 2020 7:07 am
	Displaying clocks and voltages are not possible, in fact the 50/60Hz detection relies on not overclocking (because it can only detect the ratio between the two frequencies). The grey scale test could be more fine grained on GG (or even focus on the 16 darkest and lightest tones) for contrast testing.

vingazole Joined: 20 Feb 2008 Posts: 118 Location: Saintes, France	Posted: Sat May 30, 2020 8:19 am
	@segasonicfan : Maybe you'll find this useful : phaser.zip (470 B)

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Sat May 30, 2020 10:58 am
sverx Joined: 05 Sep 2013 Posts: 2908	although SMS Test Suite can identify if it runs on a Game Gear or on a MegaDrive, it's aimed at Master Systems, so tests are there to check if your hardware / your TV set up / your controllers works fine Thanks for your suggestions on how to improve the suite, I will surely add more tests as more time becomes available. Also, if there's need, I might also fork a Game Gear specific version, I mean expressly aimed at Game Gear hardware.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13650 Location: London	Posted: Sat May 30, 2020 11:12 am
	vingazole wrote @segasonicfan : Maybe you'll find this useful : That’s my idea :) it would be good to also dump out the raw data and record results at a few distances from the screen. We can then compute the result of some of the algorithms to compare to what you’d expect. The algorithms include some scaling and offsets to the data, are you applying those before painting? I guess not as it seems offset to the left of the gun. It does seem quite distance invariant too.

bsittler Joined: 22 Apr 2018 Posts: 314	Posted: Sat Mar 13, 2021 7:50 am Last edited by bsittler on Mon Mar 15, 2021 7:54 pm; edited 2 times in total
bsittler Joined: 22 Apr 2018 Posts: 314	I was trying to simulate what the test suite (and many other SMS programs) would look like on a Game Gear with the original screen in terms of aspect ratio, RGB subpixel geometry, GG-SMS color channel dropping + averaging, and tile cropping, but without actually drawing the subpixel elements — instead I wanted something that would look a little more natural, similar to the screen viewed from a typical viewing distance where the subpixel elements may not be obvious but their impact on color is still apparent I attempted to simulate it using a transformation of a screenshot originally captured from Emulicious in "square pixel" mode. The only very glaringly unrealistic part here AFAIK is that the top and bottom border are always black rather than their actual colors, but that's because Emulicious doesn't draw or store the top and bottom border of the GG-SMS screen in its screenshots Horizontal GG-SMS to subpixel mapping seems to behave like the real hardware, at least to my untrained eye. I don't know how the combination of successive GG-SMS rows works. 3 such rows are mapped to each 2 LCD pixel rows. I simulated it using averaging but it seems like my result doesn't quite match what I see on real hardware in the vertical dimension. Does anyone know how this worked on the original hardware? To approximate the 4:3 display aspect ratio I scaled the image up to 960x720, so it should be easily viewable on a 720p display Example pipeline used: anytopnm \ < Emulicious/screenshots/SMSTestSuite_v0.32.png \| \ pnmmargin -black 12 \| \ pamcut -left $((12+8)) -right $((12+247)) \| \ pamenlarge -xscale 2 \| \ ppmtorgb3 ; \ rgb3toppm \ <( pnmpad -left 3 -right 0 noname.red ) \ <(pnmpad -left 2 -right 1 noname.grn ) \ <(pnmpad -left 1 -right 2 noname.blu ) \| \ pamscale -xscale 0.333333333333333333333333333 -nomix \| \ pamcut -left 1 \| \ pamscale -yscale 0.666666666666666666666666666 \| \ pamscale -nomix -yscale 5 \| \ pamstretch -xscale 6 \| \ ppmtorgb3; \ rgb3toppm \ <( pnmpad -left 0 -right 6 noname.red ) \ <(pnmpad -left 2 -right 4 noname.grn ) \ <(pnmpad -left 4 -right 2 noname.blu ) \| \ pamcut -left 3 -right 962 \| \ pamtopng \ > SMSTestSuite_v0.32-linearity.png edit: typo corrected, previously said "right border" instead of the correct "bottom border" SMSTestSuite_v0.32-title-emulicious.png (4.03 KB) SMSTestSuite_v0.32-linearity-emulicious.png (2.43 KB) SMSTestSuite_v0.32-title.png (34.22 KB) SMSTestSuite_v0.32-linearity.png (26.95 KB)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 13650 Location: London	Posted: Sat Mar 13, 2021 8:45 am
	Old discussion here: https://www.smspower.org/forums/9562-GameGearSMSModeVideoScaling

sverx Joined: 05 Sep 2013 Posts: 2908	Posted: Mon Mar 15, 2021 5:25 pm
sverx Joined: 05 Sep 2013 Posts: 2908	bsittler wrote The only very glaringly unrealistic part here AFAIK is that the top and right border are always black rather than their actual colors I don't get why you're trying to show borders, I think you can't see them on a Game Gear at all... or am I wrong?

bsittler Joined: 22 Apr 2018 Posts: 314	Posted: Mon Mar 15, 2021 5:32 pm Last edited by bsittler on Mon Mar 15, 2021 7:51 pm; edited 1 time in total
bsittler Joined: 22 Apr 2018 Posts: 314	sverx wrote bsittler wrote The only very glaringly unrealistic part here AFAIK is that the top and right border are always black rather than their actual colors I don't get why you're trying to show borders, I think you can't see them on a Game Gear at all... or am I wrong? In Game Gear SMS mode 12 SMS pixels of top and bottom border are indeed visible in 192-line mode (the SMS content area is scaled down to 128 GG pixel rows, with the top and bottom border each scaled down to 8 GG pixel rows, for a total of 144 GG pixel rows). So overall a 240x216 SMS pixel area is visible. I don't know yet which pixel rows are shown when the SMS content uses 224-line mode edit: also, this applies to the original hardware, both Sega-era and Majesco-era. Modern replacement screens (McWill etc.) behave differently to this and are not what I'm describing here edit 2: meant to write top and bottom border, I'll go back and correct the typo!

bsittler Joined: 22 Apr 2018 Posts: 314	Posted: Mon Mar 15, 2021 7:46 pm
bsittler Joined: 22 Apr 2018 Posts: 314	Maxim wrote Old discussion here: https://www.smspower.org/forums/9562-GameGearSMSModeVideoScaling Thank you! This is exactly the info I was trying to find. I'll see whether I can use it in order to more closely approximate the behavior I observe on original hardware

Forums

View topic - SMS Test Suite - work in progress homebrew