Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - SMS Test Suite - work in progress homebrew

Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
  • Joined: 30 Jun 2016
  • Posts: 194
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Tue Jun 26, 2018 4:37 am
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

EDIT 2: Oh... you did account for aspect ratio. Bugger. :D
alexkiddsmstest.png (4.68 KB)
alexkiddsmstest.png

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Tue Jun 26, 2018 5:59 am
I shouldn't complain that this is Enchanted Castle Alex :) It's hard to find equivalent art for Master System era stuff. The closest is probably colourised manual art.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jun 26, 2018 8:21 am
@bsittler: the "happy accident" one isn't bad ;)

@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...
AlexKidd.png (5.72 KB)
the dithered image I'd like to replace...
AlexKidd.png

  View user's profile Send private message Visit poster's website
  • Joined: 30 Jun 2016
  • Posts: 194
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Tue Jun 26, 2018 9:18 am
Would you be wanting it squished horizontally for aspect ratio shenanigans, or done in the way directly presented?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Jun 26, 2018 10:02 am
sverx wrote
@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...

SMS 1 (new VDP) --> VDP Rev = SMS II / Port 0 = 00
SMS II --> VDP Rev = SMS II / Port 0 = 00
Game gear --> VDP Rev = SMS II / Port 0 = ff
Mega Drive II = --> VDP Rev = SMS / Port 0 = ff (Gemitas doesn't run properly so VDP is reporting correctly)

Edit : These tests were done using the same ever drive on all consoles, and adapters to suit each console where needed
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jun 26, 2018 11:53 am
... so I suspect it was just a typo in Charles docs :|
Maybe we can somehow check if the card port is present?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Jun 26, 2018 12:20 pm
I guess you could still use that test to tell if its a game gear?

Not sure you can use the card slot as youll only be able to read from it if a card is inserted. On an sms ii you can still select it but just get an empty slot.
  View user's profile Send private message
  • Joined: 30 Mar 2009
  • Posts: 282
Reply with quote
Post Posted: Tue Jun 26, 2018 1:45 pm
Here is my attempt in the Alex Kidd image.
This is based on the drawing of the japanese Miracle World boxart.

I tried to keep dithering to a minimum.

See if it's better.
alexkidd_.png (3.81 KB)
alexkidd_.png

  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Wed Jun 27, 2018 3:27 am
@tibone - that's an awesome SMS/MkIII-era Alex :)

@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
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jun 27, 2018 7:54 am
@tibone: thanks - I'll test that ASAP :)

@bsittler: mmm... not at the moment, as they would work only on SMS II (and 240 lines only on PAL ones...) - I might add them later, now I want to reach ver 1.00 with all the basic stuff in place.

@Flygon: I'll test how tibone's Alex Kidd works - thank you!

@Maxim: do you approve tibone's Alex? ;)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Wed Jun 27, 2018 9:59 am
Nearly :) I would hand fix a few pixels. I have a similar file hanging around somewhere from when I was working on the Alex Kidd 2 ending sequence. Japanese box art Alex is the best :)
  View user's profile Send private message Visit poster's website
  • Joined: 30 Mar 2009
  • Posts: 282
Reply with quote
Post Posted: Wed Jun 27, 2018 11:40 am
Yeah, there are few places (like the belt and left knee) that could be cleaned up a bit. I can probably try and hand-fix those places, if anyone wants.

but yeah, japanese box art Alex is the best. agreed. :)



Edit:
Cleaner version made. The shading is little flatter, but i think it looks better on reduced number of colors. No dithering.
alexkidd_cleaned.png (3.14 KB)
alexkidd_v2
alexkidd_cleaned.png

  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 28, 2018 9:32 am
@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.
TestSuite.rar (16.88 KB)
SMS Test Suite v. 0.18 ROM

  View user's profile Send private message Visit poster's website
  • Joined: 07 Sep 2013
  • Posts: 58
  • Location: Finland
Reply with quote
Post Posted: Thu Jun 28, 2018 11:16 am
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:

https://www.dropbox.com/s/0ylrwtxi2blyhti/VolumeTest.rar?dl=0

I included recordings from my SMS2 & MD2 for example.
You'll hear the volume fluctuating if it works correctly and just a constant tone if the output is flattened.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Thu Jun 28, 2018 8:30 pm
Last edited by bsittler on Fri Jul 06, 2018 12:37 am; edited 1 time in total
sverx wrote
@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
hardware-test-screen-on-nomad.jpg (24.1 KB)
Hardware tests screen on Nomad
hardware-test-screen-on-nomad.jpg
hardware-test-screen-on-non-mcwill-game-gear.jpg (19.99 KB)
Hardware tests screen on non-McWill Game Gear: "Master System II/EUR/PAL/50Hz"
hardware-test-screen-on-non-mcwill-game-gear.jpg
mcwill-game-gear-1.jpg (23.52 KB)
McWill Game Gear #1: "Master System II/USA/NTSC/60Hz"
mcwill-game-gear-1.jpg
mcwill-game-gear-2.jpg (22.34 KB)
McWill Game Gear #2: "Master System II/EUR/PAL/50Hz"
mcwill-game-gear-2.jpg
mcwill-ntsc-par.jpg (11.8 KB)
McWill defaults to NTSC pixel aspect ratio and slightly cropped edges
mcwill-ntsc-par.jpg
non-mcwill-par.jpg (11.77 KB)
Non-McWill Game Gear has wider-than-NTSC pixel aspect ratio and slightly cropped edges
non-mcwill-par.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jun 29, 2018 9:10 am
@bsittler: I'm not aiming to GG (yet) - we also might create a separate (native) GG Test Suite later, eventually.

@TomyS: thanks! Is "Volume clipping test" OK?

edit: BTW I'm wondering why two different GG with the same McWill mod do report different screen timing :|
  View user's profile Send private message Visit poster's website
  • Joined: 07 Sep 2013
  • Posts: 58
  • Location: Finland
Reply with quote
Post Posted: Sat Jun 30, 2018 8:59 am
sverx wrote
@TomyS: thanks! Is "Volume clipping test" OK?


I think that sounds good.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Sat Jun 30, 2018 11:16 am
I recommend you switch to a frame length check - see http://www.smspower.org/Development/TVTypeDetection - as it is much less sensitive to implementation details of the line counter overflow.

Having said that, it might be good to run http://www.smspower.org/Homebrew/SMSVDPTest-SMS on those GGs to see what they produce.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Sat Jun 30, 2018 9:55 pm
Maxim wrote
I recommend you switch to a frame length check - see http://www.smspower.org/Development/TVTypeDetection - as it is much less sensitive to implementation details of the line counter overflow.

Having said that, it might be good to run http://www.smspower.org/Homebrew/SMSVDPTest-SMS on those GGs to see what they produce.


Nice test suite, don't think I had found that one previously!

The first page of "SMS VDP Test" all pass on all three Game Gears I have here.

On the second page ("SMS VDP misc test"), all three give "Error." for "Counter correct", "Counter chg time", "Frame IRQ HCount", "Line IRQ HCount", and "VINT flag HCount". On the third page ("SMS VDP sprite test"), all three give "Error." for "Spr col correct HC" and "Spr ovr correct HC".

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.

All three show "Line value: 1B" / "HBlank value: 85" / "VBlank value: 7F"

"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.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jul 02, 2018 8:01 am
Maxim wrote
I recommend you switch to a frame length check - see http://www.smspower.org/Development/TVTypeDetection - as it is much less sensitive to implementation details of the line counter overflow.


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?

edit: no, I misread - three devices identified as PAL? Bummer.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Jul 02, 2018 8:07 am
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?

bsittler, can you try http://www.smspower.org/Homebrew/VCounterTest-SMS next? Maybe best to use the VGA out to save your eyesight. I had thought flubba's test included this.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jul 02, 2018 8:12 am
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...)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Jul 02, 2018 8:16 am
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.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Mon Jul 02, 2018 6:47 pm
Maxim wrote
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.

00 10 20 30 40 50 60 70
01 11 21 31 41 51 61 71
02 12 22 32 42 52 62 72
03 13 23 33 43 53 63 73
04 14 24 34 44 54 64 74
05 15 25 35 45 55 65 75
06 16 26 36 46 56 66 76
07 17 27 37 47 57 67 77
08 18 28 38 48 58 68 78
09 19 29 39 49 59 69 79
0A 1A 2A 3A 4A 5A 6A 7A
0B 1B 2B 3B 4B 5B 6B 7B
0C 1C 2C 3C 4C 5C 6C 7C
0D 1D 2D 3D 4D 5D 6D 7D
0E 1E 2E 3E 4E 5E 6E 7E
0F 1F 2F 3F 4F 5F 6F 7F


In page 1 the count is biased by -6 after DA:

80 90 A0 B0 C0 D0 DA EA
81 91 A1 B1 C1 D1 DB EB
82 92 A2 B2 C2 D2 DC EC
83 93 A3 B3 C3 D3 DD ED
84 94 A4 B4 C4 D4 DE EE
85 95 A5 B5 C5 D5 DF EF
86 96 A6 B6 C6 D6 E0 F0
87 97 A7 B7 C7 D7 E1 F1
88 98 A8 B8 C8 D8 E2 F2
89 99 A9 B9 C9 D9 E3 F3
8A 9A AA BA CA DA E4 F4
8B 9B AB BB CB D5 E5 F5
8C 9C AC BC CC D6 E6 F6
8D 9D AD BD CD D7 E7 F7
8E 9E AE BE CE D8 E8 F8
8F 9F AF BF CF D9 E9 F9


In page 2 the count starts at FA, wraps from FF to 00, and ends at 32 - after that it's all 00s.

FA 0A 1A 2A 00 00 00 00
FB 0B 1B 2B 00 00 00 00
FC 0C 1C 2C 00 00 00 00
FD 0D 1D 2D 00 00 00 00
FE 0E 1E 2E 00 00 00 00
FF 0F 1F 2F 00 00 00 00
00 10 20 30 00 00 00 00
01 11 21 31 00 00 00 00
02 12 22 32 00 00 00 00
03 13 23 00 00 00 00 00
04 14 24 00 00 00 00 00
05 15 25 00 00 00 00 00
06 16 26 00 00 00 00 00
07 17 27 00 00 00 00 00
08 18 28 00 00 00 00 00
09 19 29 00 00 00 00 00


The second Game Gear (McWill-modded) using a Master 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.

00 10 20 30 40 50 60 70
01 11 21 31 41 51 61 71
02 12 22 32 42 52 62 72
03 13 23 33 43 53 63 73
04 14 24 34 44 54 64 74
05 15 25 35 45 55 65 75
06 16 26 36 46 56 66 76
07 17 27 37 47 57 67 77
08 18 28 38 48 58 68 78
09 19 29 39 49 59 69 79
0A 1A 2A 3A 4A 5A 6A 7A
0B 1B 2B 3B 4B 5B 6B 7B
0C 1C 2C 3C 4C 5C 6C 7C
0D 1D 2D 3D 4D 5D 6D 7D
0E 1E 2E 3E 4E 5E 6E 7E
0F 1F 2F 3F 4F 5F 6F 7F


In page 1 the count is biased by -6 after DA:

80 90 A0 B0 C0 D0 DA EA
81 91 A1 B1 C1 D1 DB EB
82 92 A2 B2 C2 D2 DC EC
83 93 A3 B3 C3 D3 DD ED
84 94 A4 B4 C4 D4 DE EE
85 95 A5 B5 C5 D5 DF EF
86 96 A6 B6 C6 D6 E0 F0
87 97 A7 B7 C7 D7 E1 F1
88 98 A8 B8 C8 D8 E2 F2
89 99 A9 B9 C9 D9 E3 F3
8A 9A AA BA CA DA E4 F4
8B 9B AB BB CB D5 E5 F5
8C 9C AC BC CC D6 E6 F6
8D 9D AD BD CD D7 E7 F7
8E 9E AE BE CE D8 E8 F8
8F 9F AF BF CF D9 E9 F9


In page 2 the count starts at FA, wraps from FF to 00, and ends at 32 - after that it's all 00s.

FA 0A 1A 2A 00 00 00 00
FB 0B 1B 2B 00 00 00 00
FC 0C 1C 2C 00 00 00 00
FD 0D 1D 2D 00 00 00 00
FE 0E 1E 2E 00 00 00 00
FF 0F 1F 2F 00 00 00 00
00 10 20 30 00 00 00 00
01 11 21 31 00 00 00 00
02 12 22 32 00 00 00 00
03 13 23 00 00 00 00 00
04 14 24 00 00 00 00 00
05 15 25 00 00 00 00 00
06 16 26 00 00 00 00 00
07 17 27 00 00 00 00 00
08 18 28 00 00 00 00 00
09 19 29 00 00 00 00 00


The third Game Gear (non-McWill) using a Game Gear EverDrive:

[ 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.

00 10 20 30 40 50 60 70
01 11 21 31 41 51 61 71
02 12 22 32 42 52 62 72
03 13 23 33 43 53 63 73
04 14 24 34 44 54 64 74
05 15 25 35 45 55 65 75
06 16 26 36 46 56 66 76
07 17 27 37 47 57 67 77
08 18 28 38 48 58 68 78
09 19 29 39 49 59 69 79
0A 1A 2A 3A 4A 5A 6A 7A
0B 1B 2B 3B 4B 5B 6B 7B
0C 1C 2C 3C 4C 5C 6C 7C
0D 1D 2D 3D 4D 5D 6D 7D
0E 1E 2E 3E 4E 5E 6E 7E
0F 1F 2F 3F 4F 5F 6F 7F


In page 1 the count is biased by -6 after DA:

80 90 A0 B0 C0 D0 DA EA
81 91 A1 B1 C1 D1 DB EB
82 92 A2 B2 C2 D2 DC EC
83 93 A3 B3 C3 D3 DD ED
84 94 A4 B4 C4 D4 DE EE
85 95 A5 B5 C5 D5 DF EF
86 96 A6 B6 C6 D6 E0 F0
87 97 A7 B7 C7 D7 E1 F1
88 98 A8 B8 C8 D8 E2 F2
89 99 A9 B9 C9 D9 E3 F3
8A 9A AA BA CA DA E4 F4
8B 9B AB BB CB D5 E5 F5
8C 9C AC BC CC D6 E6 F6
8D 9D AD BD CD D7 E7 F7
8E 9E AE BE CE D8 E8 F8
8F 9F AF BF CF D9 E9 F9


In page 2 the count starts at FA, wraps from FF to 00, and ends at 32 - after that it's all 00s.

FA 0A 1A 2A 00 00 00 00
FB 0B 1B 2B 00 00 00 00
FC 0C 1C 2C 00 00 00 00
FD 0D 1D 2D 00 00 00 00
FE 0E 1E 2E 00 00 00 00
FF 0F 1F 2F 00 00 00 00
00 10 20 30 00 00 00 00
01 11 21 31 00 00 00 00
02 12 22 32 00 00 00 00
03 13 23 00 00 00 00 00
04 14 24 00 00 00 00 00
05 15 25 00 00 00 00 00
06 16 26 00 00 00 00 00
07 17 27 00 00 00 00 00
08 18 28 00 00 00 00 00
09 19 29 00 00 00 00 00
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jul 03, 2018 7:20 am
...so it looks like they all count $00-$DA, $D5-$FF - which is exactly what NTSC (60Hz) SMS do.
I've got to double check my detection code to see if I'm doing some silly mistakes, then :|
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jul 03, 2018 9:49 am
no actual silly mistake, but indeed not a very good code from the start.

bsittler, can you please test the attached ROM on one/all of those 'misdetected' GameGears? Thanks.
TestSuite.rar (17.09 KB)
SMS Test Suite v. 0.19 ROM

  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Tue Jul 03, 2018 3:15 pm
sverx wrote
no actual silly mistake, but indeed not a very good code from the start.

bsittler, can you please test the attached ROM on one/all of those 'misdetected' GameGears? Thanks.


With the new 0.19 ROM all three are identified as Model:Master System II / Region:USA TV:60Hz (NTSC)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Tue Jul 03, 2018 3:42 pm
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? :|
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Tue Jul 03, 2018 4:01 pm
sverx wrote
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.

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


I think this image is a good default for Game Gears, it should "look right" on the original (stock) screen with round circles filling the maximum GG-SMS-addressable part of the virtual screen:

http://www.smspower.org/forums/files/new_actual_gg_sms_linearity_256x192_156.png

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:

http://www.smspower.org/forums/files/new_gg_sms_linearity_256x192_204.png

The McWill mod actually defaults GG-SMS to NTSC SMS pixel aspect ratio, but the visible + addressable part of the screen remains smaller than SMS:

http://www.smspower.org/forums/files/new_gg_sms_linearity_256x192_128.png

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.

http://www.smspower.org/forums/files/gg_sms_pal_177.png

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:

http://www.smspower.org/forums/files/new_gg_sms_linearity_256x192_128.png

sverx wrote
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.

edit: generated and attached the missing GG PAL-PAR linearity test and simulated appearance

edit 2: corrected pixel alignment (apologies, I guess I didn't save the final version of my previous workflow!)

edit 3: corrected broken grey curve
gg-sms-pal.png (1.08 KB)
GG-SMS PAL linearity test for VGA
gg-sms-pal.png
gg-sms-pal-appearance.png (1.98 KB)
GG-SMS PAL linearity simulation for VGA
gg-sms-pal-appearance.png

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jul 04, 2018 7:36 am
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!
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Thu Jul 05, 2018 6:31 pm
sverx wrote
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

edit 3: non-unity PAR images use GG 4bit grey ramp to compensate visually for non-uniform edge thickness
gg-square-linearity.png (1 KB)
GG square-pixel linearity test (one of the McWill LCD modes) — 1:1 PAR
gg-square-linearity.png
gg-square-appearance.png (1.39 KB)
GG square-pixel linearity simulation (one of the McWill LCD modes) — 1:1 PAR
gg-square-appearance.png
gg-linearity.png (1.2 KB)
GG original screen linearity test — 1.218 PAR
gg-linearity.png
gg-appearance.png (2.82 KB)
GG original screen linearity simulation — 1.218 PAR
gg-appearance.png
gg-ntsc-linearity.png (1.19 KB)
GG NTSC linearity test (McWill LCD default) — 1.141 PAR
gg-ntsc-linearity.png
gg-ntsc-appearance.png (3.29 KB)
GG NTSC linearity simulation (McWill LCD default) — 1.141 PAR
gg-ntsc-appearance.png
gg-pal-linearity.png (1.21 KB)
GG PAL linearity test (McWill VGA option) — 1.352 PAR
gg-pal-linearity.png
gg-pal-appearance.png (3.55 KB)
GG PAL linearity simulation (McWill VGA option) — 1.352 PAR
gg-pal-appearance.png
gg-grid.jpg (24.91 KB)
the grid test is already useful in GG-native mode to make sure the original GG screen mostly works :)
gg-grid.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jul 06, 2018 8:00 am
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
  View user's profile Send private message Visit poster's website
  • Joined: 30 Jun 2016
  • Posts: 194
  • Location: Melbourne, Australia
Reply with quote
Post Posted: Fri Jul 06, 2018 8:19 am
Is there an API available to directly write to the SD card?
There's also a Support Forum available, if necessary, for assistance.

I'd be testing with my X7 right now, if I wasn't having some minor issues my end preventing this.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jul 06, 2018 8:57 am
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...
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Fri Jul 06, 2018 5:24 pm
sverx wrote
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


I see mentions of 32KB SRAM at least for the Master EverDrive X7. From https://krikzz.com/store/home/51-master-everdrive.html :
Quote
Max SAVE RAM size: 32KByte


Mine is still in the mail and I am still using an older Master EverDrive, though.

However, all the instructions I see for the older Master EverDrive talk about 32KB SRAM files, and that they need to be created in advance as empty 32KB files:

https://assemblergames.com/threads/how-do-you-save-sram-on-mastered.43847/

http://krikzz.com/forum/index.php?topic=281.msg2403#msg2403

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.

edit: also, are you using mapper slot 2 for both 16K halves of SRAM? I wouldn't be surprised if that were the only 32K SRAM mapping supported by the EverDrive; http://www.smspower.org/Development/Mappers#RAMMapping has more details

edit 2: Master EverDrive X7 arrived, seems to work the same except it uses \SMSSYS\SAVE rather than \SAVE and it feels a lot faster when switching games :)
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jul 09, 2018 7:31 am
@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 :)
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Jul 09, 2018 7:43 am
The save pre allocation was only necessary on earlier Everdrive OSes.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jul 09, 2018 8:53 am
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"):

const struct {
  const unsigned int id;
  const unsigned char *name;
} BIOSes[BIOSES_ITEMS] = {
  {0x9204,"Alex Kidd in Miracle World"},
  {0x8738,"Hang On & Safari Hunt"},
  {0x7f6f,"Hang On"},
  {0xde36,"Sonic the Hedgehog"},
  {0xef78,"US-European SMS BIOS V1.3 [f1]"},
  {0xef42,"US-European SMS BIOS V1.3 [h1]"},
  {0x95c3,"Japanese SMS BIOS v2.1"},
  {0x6ae3,"Emulicious (emulator) BIOS"},       //  ;)
};


I'm also attaching the simple C program I'm using to generate the 'checksums'.
sum8k.rar (31.44 KB)
sum8k - generates 8 KB 'checksums'

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14687
  • Location: London
Reply with quote
Post Posted: Mon Jul 09, 2018 12:23 pm
The "h" one is modified to not boot any game, so you can play it in an emulator. The "f" one is corrected. I suggest you collect good data from here: http://www.smspower.org/Development/BIOSes and also compare to http://www.smspower.org/forums/post102876#102876 which I think includes the display unit BIOS which is unreleased? There may be more display unit BIOSes, I'm not sure they're well explored.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jul 09, 2018 1:08 pm
#define BIOSES_ITEMS 13
const struct {
  const unsigned int sum8k;
  const unsigned char *name;
} BIOSes[BIOSES_ITEMS] = {
  {0x9204,"Alex Kidd in Miracle World"},
  {0x8738,"Hang On & Safari Hunt"},
  {0x7f6f,"Hang On"},
  {0xde36,"Sonic the Hedgehog"},
  {0xf124,"Missile Defense 3-D"},
  {0xaf19,"Samsung Gam*Boy/Aladdin Boy"},     // this has AKiMW game in it
  {0xef78,"US-European SMS BIOS v1.3"},
  {0x95c3,"Japanese SMS BIOS v2.1"},
  {0x934d,"M404 Prototype BIOS"},
  {0x5f04,"Prototype BIOS v1.0"},
  {0xe8b0,"SMS BIOS v2.0"},
  {0xdc4e,"Store Display Unit BIOS"},         // not sure this is really useful
  {0x6ae3,"Emulicious (emulator) BIOS"}       //  ;)
};


OK, this should be it. If one really has a M404 prototype anyway this ROM won't boot unless one uses this code:
const __at (0x7fe0) char __SMS_COPYRIGHT[]="COPYRIGHTSEGA";

which conflicts with SDSC header of course :|
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jul 11, 2018 8:07 am
here's v. 0.23:
- GameGear should be identified
- Master System BIOS is checksum'd and identification is then performed

I'm almost on holiday, so see you in a few weeks - in the while, I made the whole thing accessible here: https://github.com/sverx/SMSTestSuite
TestSuite.rar (18.78 KB)
SMS Test Suite v. 0.23 ROM

  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Sat Jul 14, 2018 6:07 am
sverx wrote
here's v. 0.23:
- GameGear should be identified
- Master System BIOS is checksum'd and identification is then performed

I'm almost on holiday, so see you in a few weeks - in the while, I made the whole thing accessible here: https://github.com/sverx/SMSTestSuite


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
original-gg-linearity-photo.jpg (19.7 KB)
Linearity test on ~original GG
original-gg-linearity-photo.jpg
original-gg-edgg-detection.jpg (21.52 KB)
Game Gear system detected with EverDrive GG
original-gg-edgg-detection.jpg
original-gg-edsms-detection.jpg (16.61 KB)
Game Gear system detected with Master EverDrive
original-gg-edsms-detection.jpg
original-gg-edsms-x7-detection.jpg (15.36 KB)
Game Gear system misdetected as "Master System II" with Master EverDrive X7
original-gg-edsms-x7-detection.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Wed Jul 18, 2018 8:46 am
ED x7 is probably doing something stupid ;)
I'm just checking port 0 if it returns 0xFF
Please run that other program so that we can see what is returned.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Aug 02, 2018 12:10 pm
I'm back and I'm resuming work on this.

@bsittler: please, check under System Info -> Port $00 value.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Sat Aug 04, 2018 5:01 am
sverx wrote
I'm back and I'm resuming work on this.

@bsittler: please, check under System Info -> Port $00 value.


Welcome back!

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?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Aug 06, 2018 8:09 am
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...
  View user's profile Send private message Visit poster's website
  • Joined: 12 Oct 2012
  • Posts: 4
Reply with quote
Post Posted: Fri Sep 07, 2018 2:00 pm
Sverx, would it be possible to quickly add in a simple pure white screen? I want to test some video signal stuff over the weekend.

Thank you again for the Test Suite!!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3761
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Sep 07, 2018 2:03 pm
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 :)
TestSuite_0.24.rar (19.02 KB)
SMS Test Suite v. 0.24 ROM

  View user's profile Send private message Visit poster's website
  • Joined: 12 Oct 2012
  • Posts: 4
Reply with quote
Post Posted: Fri Sep 07, 2018 2:40 pm
Red, green, and blue would be great too!

Full white is used to test video signals since it drives R,G,B at 100% equally.


Thanks again!

sverx wrote
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 :)
  View user's profile Send private message
  • Joined: 23 Apr 2014
  • Posts: 131
  • Location: NYC
Reply with quote
Post Posted: Tue Sep 11, 2018 2:34 pm
sverx wrote
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!

Thanks again sverx!
  View user's profile Send private message Visit poster's website
Reply to topic Goto page Previous  1, 2, 3, 4, 5, 6  Next



Back to the top of this page

Back to SMS Power!