Might be worth approaching redrawing the image by hand.
I'd give it a go right now if I wasn't very busy today.

EDIT: Just did the thing I said I was not going to do.
Didn't account for aspect ratio because, well, your version didn't. :P

The skin tones are completely off, and the shading on the hair is also completely off, but this somehow looks closer aesthetically to the original image than using the closest colours to the actual base image.

No niceties such as anti-aliasing have been drawn in - Combination of this being done in 30 minutes, and the fact that doing so on this picture actually makes it look blurry. :D

@Flygon: that's great - but now you're going to kill me as I forgot to mention I needed it smaller :| ... some 75% to 80%, like the picture I'm using actually (attached here for reference)

@Maxim: if you provide a better source we'll take that into account :p

@Bock: I don't really know. Both my SMS II and their SMS I with 'new' VDP just return $00 which is what the first revision Master Systems should return, so I'm greatly puzzled. I guess what we can do is to actually test Wonder Boy in Monster World ROM and see if that 'TM' appears or if it doesn't. If we indeed get different results, then it's worth investigating more...

@Bock: I don't really know. Both my SMS II and their SMS I with 'new' VDP just return $00 which is what the first revision Master Systems should return, so I'm greatly puzzled. I guess what we can do is to actually test Wonder Boy in Monster World ROM and see if that 'TM' appears or if it doesn't. If we indeed get different results, then it's worth investigating more...

Have just tried this on my systems and get mixed results with the "TM" on the logo of Wonder boy in monster world. It doesn't quite match what is being suggested on that page.

Going back to your model test program, i get the following results on these systems...

@sverx - any interest in 224-line or 240-line SMS2 linearity test images? It would let you rename your suite "240p" I think ;) - and also adjusting for barrel distortion on a real CRT should actually be easier when more of the screen is covered by the test image. My assumption is that these modes use the same pixel aspect ratio (PAR) but just have less letterboxing. Of course you could just use the same images from other platforms for those modes, since AFAIK they are fairly common and the SMS does not use an unusual pixel width

I made a .vgm file to test if the high volume values are working correctly on your console. It's a constant looping tone that changes between the two highest volume values. If you want to add it to the Test Suite:

@tibone: thanks, it's perfect! This also just saved almost 4.5 KB in the ROM, compared to the dithered image I had in the first place.

Nice work! The new tests and info screens are nice :)

Would it be possible to allow overriding the TV detection during the linearity test (e.g. using direction pad)? Unfortunately it's still mis-detecting one of the Game Gears and (sometimes) the Nomad as PAL, and in any case the "real" (non-McWill) Game Gear has a pixel aspect ratio different from SMS, whereas McWill mods use the SMS pixel aspect ratio by default, but also allow 1:1 square pixels for both GG and GG-SMS modes

On the next page ("Testing X-Scroll latchtime") a one-pixel-tall slice of the column is offset rightward about halfway across the screen just below the middle of the display. I took pictures and can upload them if helpful.

On the next page ("HCounter Values") one of the McWill-modded Game Gears ends the sequence with "21 21 22 23 24 24 25 26 27 27" while the other two end with "21 22 22 23 24 25 25 26 27 28". I took pictures and can upload them if helpful. Rebooting the Game Gear and rerunning the test does not always give consistent results - running it again, the first Game Gear ends with "26 27 28 29 29 2A 2B 2C 2C 2D" while the other two end with "20 21 22 23 23 24 25 26 26 27".

In "HCount timing & more" the other "HCounter Values" screen also shows slight variation across Game Gears. Again, I took pictures and can upload them if helpful.

"Register Startup Values" vary across all three - note that three different EverDrives are in use, and those may also factor into this. I took pictures and can upload them if helpful.

The first Game Gear (a McWill-modded one with optional RGB+VGA out [not used for this test] and optional external controller ports [ditto]) is using a Game Gear EverDrive with CPLD Version 3, OS Version 9, Max Dir Size 512, Cart Type GG, and Asm date 25.01.2017. This is a Sega Game Gear with Model No. 2110-50, "MADE IN JAPAN", Serial No. B31243347.

The second Game Gear (a McWill-modded one with no VGA out and no external controller ports) is using (via an unmodified Beeshu Gear Master) a Master EverDrive with CPLD Version 2, OS Version 9, Max Dir Size 512, Cart Type SMS, and Asm date 16.01.2017. This is a Sega Game Gear with Model No. 2110-50, "MADE IN JAPAN", Serial No. K271112888.

The third Game Gear (a non-McWill one) is using another Game Gear EverDrive with CPLD Version 3, OS Version 9, Max Dir Size 512, Cart Type GG, and Asm date 01.02.2018. This is a Sega Game Gear with Model No. 2110, "MADE IN TAIWAN", Serial No. O31362818 (maybe that's a 0 rather than an O at the beginning, I don't know.)

All three Game Gears show the BIOS startup screen "PRODUCED BY OR UNDER LICENCE FROM SEGA ENTERPRISES LTD." when booting the everdrive, but not when starting the test suite.

edit: tried VGA out on the Game Gear where that is an option. Results were no different (as expected, given what I understand about how that mod works.) Didn't try RGB out, but no reason to believe that would cause different results.

Sure, I'll consider that - but I'm really puzzled, as I guess there shouldn't be any particular reason why counter overflow shouldn't be accurate.
We should instead focus on bsittler's GameGear which seems to be the only one piece of hardware failing. Any chance that it's 'malfunctioning'? I mean, after all to switch from 60 Hz to 50 Hz all it takes is a single VDP chip pin lifted/shorting... or does some other test identify that as 60 Hz?

The frame length test determines "does this system have more or less CPU cycles per vblank", the vcount test determines "does this system's line counter overflow at this number or not". Which is the better question to answer for your purposes?

I really don't know - maybe we should instead suppose that the line counter overflow values on GameGears are different from the SMS? The check I'm doing doesn't fail on any Master System (until proved wrong...)

The VCounter test I linked above is (I think) what Charles used to make his doc, but he may not have had a large enough corpus of Game Gears to test it on.

All three Game Gears give identical results for that test, and they seem to be consistent across runs too.

Ran my three Game Gears through the "256x192 Mode 4" test with "Lines to scan: 312". Results:

The first Game Gear (McWill-modded) using a Game Gear EverDrive:

Reg: 66 E0 VBL: C1

Page 0 is a completely regular 8x16 grid, with hex digits 0-F progressing vertically in the "ones" column of each cell and hex digits 0-7 progressing horizontally in the "sixteens" column of each cell.

Page 0 is a completely regular 8x16 grid, with hex digits 0-F progressing vertically in the "ones" column of each cell and hex digits 0-7 progressing horizontally in the "sixteens" column of each cell.

[ This is the original screen that could really benefit from VGA clarity but lacks it! ]

Reg: 66 E0 VBL: C1

Page 0 is a completely regular 8x16 grid, with hex digits 0-F progressing vertically in the "ones" column of each cell and hex digits 0-7 progressing horizontally in the "sixteens" column of each cell.

Good! Now they finally get identified as NTSC/60Hz (and I'm still doing it checking vCounter...) so next step is to identify them as GGs (using port0 and discriminating the MD using that bit in the second PAD port...)

bsittler: can you provide an image for the linearity test on GameGear? Of course 256x192, as we're running in SMS mode...

edit: mmm... wait... what's the meaning to test that on a device that has its own screen? :|

There is also a "high resolution" version of that (same actual image dimensions, just using one-pixel lines) which will look better on pixel-addressable modded screens, but it will show color fringes on the original screen:

The McWill mod's VGA output can be switched to an approximately-PAL pixel aspect ratio too, but again the visible + addressable part of the screen remains smaller than SMS. This is frequently used by users of "consolized" Game Gears.

Finally, the McWill mod is switchable to "square pixel" mode, which is the only output without discontinuities during scrolling. For that, again, the visible + addressable part of the screen remains smaller than on a real SMS:

edit: mmm... wait... what's the meaning to test that on a device that has its own screen? :|

For the internal screen it's helpful to determine which pixel aspect ratio your device has and whether all the edges of the addressable screen are in fact visible - I suspect Game Gear modders may in the future use this to ensure replacement screens are making all the correct parts visible (often the new screens involve bezel removal or a new custom bezel) and with the correct pixel aspect ratio (whether that is GG-authentic or NTSC or PAL - again I wouldn't be surprised if future mods allow that to be adjusted at runtime so different games can each look "as the author intended".)

Also, some Game Gears have been modified for RGB out and/or VGA out (this is, for instance, a standard option in the McWill mod) - for those I think the same linearity tests make sense in its original form, but the VGA output is horizontally truncated compared to the output of an SMS, so the Game Gear-adjusted linearity test images still make sense. However the pixel aspect ratio may match PAL or NTSC rather than GG-native in this case (which one depends on video mode, selected in McWill with Start+1+2), so being able to cycle between the different pixel aspect ratios (e.g. with joypad) would be helpful as AFAIK the test suite can't determine which output mode the McWill is using, nor even whether a McWill mod is present.

I'll take the first of the provided image (for the un-modded GG) and we'll add the options for modded GGs at a later stage, OK? :)
Thank you!

Sounds good! Will you make a RAM trampoline and from it toggle bit six of port $3E and check for known cartridge data to differentiate GG-SMS and SMS 2, or is there some better way?

edit: also, your suite is already fairly usable in native-GG mode, both on real hardware using a GG flash cart and in emulators. The only major part missing is palette setup, at the moment it's always using RGB222 but I think for a first pass at native-GG (once you detect native-GG mode using in($00) & $3F == $00, that is ignoring the START button bit and the region bit — again, maybe there is a better way?) you can just expand each color channel to a full nibble by duplicating the bits, like b11 -> b1111, b10 -> b1010, b01 -> b0101, and b00 -> b0000 to fill twice as much VRAM, and your suite could be like 90% ported for (I hope!) very minimal additional programming. It is true GG-native mode unlocks additional color depth, but even without really exercising that the test suite could be helpful.

edit 2: with that in mind, I attached some GG-native linearity test images — load these into VRAM as if it were an SMS, but with GG palette entries, and they should look good on the original screen, with a McWill mod, or with RGB or VGB output. Simulated appearance is provided for each to give an idea of how it should look

I plan on making a GameGear native mode test suite later, forking from this one when it's complete :)

As for RAM 'trampolines', I'm already testing BIOS checksum/BIOS dumping - but it seems I can't convince my Master EverDrive to save a 32 KB save file. Maybe it's me seeing things and it had 16 KB only? I can't find a trace of that info on the Internet, even using Archive.org

There might be an API, but I'm not thinking to support just a single adapter - I'll instead dump into SRAM (and my test with the wonderful Emulicious were already successful...)

BTW I just noticed that known BIOSes are either 8 KB or much more than 32 KB (128 KB or 256 KB depending on the built-in game) so I guess dumping 16 KB would be fine - and if we ever find an unknown BIOS bigger than 16 KB we will find a way to dump that for sure :)

edit: maybe I should sum the first 8 KB of the BIOS instead of just the 1st KB? It doesn't take so much time after all...

I plan on making a GameGear native mode test suite later, forking from this one when it's complete :)

As for RAM 'trampolines', I'm already testing BIOS checksum/BIOS dumping - but it seems I can't convince my Master EverDrive to save a 32 KB save file. Maybe it's me seeing things and it had 16 KB only? I can't find a trace of that info on the Internet, even using Archive.org

For pre-X7 Master EverDrive (or GG EverDrive) running OS v9 — apologies if some or all of this is old news:

Make sure you have a top-level directory named 'SAVE' on the SD card, and ensure you have empty SRAM files from one of the above threads somewhere on your SD card. Load (but do not start!) the test suite ROM. Then select the empty SRAM file, and use the menu entry for "Copy File to SRAM". You only need to do this once per game. Finally, select a different-named ROM and load it. The old SRAM contents (copied from the empty file) should now be written to a new file inside 'SAVE' with the name TestSuite.srm, and from now on each time you load the test suite ROM from the SD card the EverDrive should automatically load the corresponding srm file, and each time you switch to some other ROM (with a different base name!) the test suite should automatically save the contents of SRAM to the file.

Note that the automatic SRAM ⇆ SD synchronization only happens when switching games, and the top-level SAVE directory must already exist, and that you need to either have already manually created a suitably-named empty file in SAVE, or have loaded SRAM data from another file while the game ROM was already loaded in order to signal to the EverDrive that SRAM is in use, since there's apparently no way for the EverDrive to figure that out by itself automatically.

@bsittler: thanks, I had found the same, but it didn't worked even pre-allocating the 32 KB file. But I really never before had to pre-allocate any file to make the save work, so I tried again using only 16 KB saves and -in fact- this way it works with no problems, no pre-allocation needed, and I dumped the first 16 KB of my BIOS and it matches perfectly with the expected AKiMW BIOS - so for me it's fine this way :)

Now I'll create a short table with all the known BIOSes 'checksums' (just from the first 8 KB) and we'll see if it works :)

I'm using OS v7 and I never had to pre-allocate anything - anyway when I did it with the 32 KB file, it didn't change anything. BTW I really don't care ;)

Speaking about the 'checksum', I'm not sure where I can find a list of *all the known* BIOSes, and where I can eventually download them to create my small table. So far I've got only these (and I don't know why I've got two "US-European SMS BIOS V1.3"):

That's really neat! It correctly identifies three different Game Gears as Game Gears when booted from EverDrive GG or Master EverDrive, but misidentifies them as Master System II when booted from Master EverDrive X7. Any idea why? How do you identify the model?

Linearity test looks fairly round on the original screen, but I should probably generate a new version that aligns more consistently with the R/G/B subpixels, I guess by using integer expansion rather than linear interpolation

I'll definitely take a look, but my previous experience with port $00 in a SG-1000 to GG palette patcher strongly suggested that it's only actually mapped when the Game Gear is in native-GG mode, and otherwise it behaves like an unmapped port — in fact reading $00 is precisely how the patcher decides whether the Game Gear is in native-GG mode or GG-SMS mode, which in turn determines whether 12-bit-wide (2 byte) or 6-bit-wide (1 byte) palette data entries will be written to CRAM, and this detection does in fact work reliably on several instances of the Game Gear hardware across four different EverDrives.

edit: clarified, the useful part of each palette data entry is only 3/4 as wide, the remaining 1/4 is unused AFAICT

edit 2: tried it — with the two GG EverDrives and with the Master Everdrive all in GG-SMS mode, your test suite reads 0xFF from port $00. With the Master EverDrive X7, though, it reads 0x00 from port $00. With the two GG EverDrives in native-GG mode, it reads 0xC0 from port $00. I verified this across the three Game Gears I have.

In all cases where it actually displays the BIOS sum, it's showing "** unidentified BIOS found! **" with BIOS sum 0x82EA. I also verified this across the three Game Gears I have.

Which instruction do you execute immediately prior to the port $00 read, and from what address? Do you read from port $00 only once (at start-up?), or each time the main menu is shown?

I'm reading from port $00 just once when the ROM starts. Apart from GG native mode, which I'm not addressing in this suite, I'm wondering if it's a bug with EDx7 or actually if it's correct that way and it's the Master ED which isn't behaving correctly. I mean, in SMS mode, shouldn't the port read just what it reads on a real SMS? If so, I shouldn't be able to tell from the program if it's running on a SMS or on a GG in SMS mode by checking port $00...

full white? you need some other colors (reg/green/blue)? I might cycle them at the press of a button...

edit: see if this suites you :)

Thanks so much for adding this! If you ever do video testing on an oscilloscope, 100% color bars are a help too; You can use them to test voltage just like a white screen and you'll also be able to detect certain issues in the rise and fall of the signal. The HDRetrovision test software has them and the source code is included: http://www.hdretrovision.com/free-stuff#gentst

I believe it's public domain, so feel free to take what you need from it. Ste is much like Artemio in that he's happy to see his software used in other places!