|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2, 3, 4, 5, 6 Next |
Author | Message |
---|---|
|
Posted: Fri Mar 27, 2020 10:07 pm |
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. |
|
|
Posted: Sat Mar 28, 2020 10:52 am |
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 |
|
|
Posted: Sat Mar 28, 2020 11:06 am |
Thank you, guys!
Now all buttons are detected on a megadrive 2! |
|
|
Posted: Sat Mar 28, 2020 12:15 pm |
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... |
|
|
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 | |
|
Posted: Sun Mar 29, 2020 9:39 am |
I have a 6 button controller from a PAL asian megadrive 2. It's properly detected by sms test suite on a megadrive 2. | |
|
Posted: Sun Mar 29, 2020 11:56 am |
so looks like I didn't break previous compatibility, good...
thank you! |
|
|
Posted: Sun Mar 29, 2020 12:06 pm |
Thank you, too! |
|
|
Posted: Fri Apr 03, 2020 10:12 am |
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... |
|
|
Posted: Sun Apr 05, 2020 12:36 am |
Is there a way in software to determine a 2 asic vs 1 asic game gear? | |
|
Posted: Sun Apr 05, 2020 12:38 pm |
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? |
|
|
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 |
|
|
Posted: Mon Apr 06, 2020 8:45 am |
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. |
|
|
Posted: Mon Apr 06, 2020 9:39 am |
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. | |
|
Posted: Tue Apr 07, 2020 1:57 pm |
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 :) |
|
|
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. |
|
|
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 :) | |
|
Hardware Test
Posted: Thu May 28, 2020 8:24 pm
|
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. |
|
|
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**
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! |
|
|
Posted: Fri May 29, 2020 10:03 am |
Paddle controller tests are there.. its just only shown when a paddle controller is detected. |
|
|
Posted: Fri May 29, 2020 11:11 am |
That's not just a southpark character. It's his avatar. ;) Why would he put Sonic there? Just because you are segasonicfan? :D
What do you mean by that? It works in both GG SMS mode and detects it accordingly.
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. |
|
|
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? |
|
|
Ram/vram
Posted: Fri May 29, 2020 3:42 pm
|
What about a ram/vram test? | |
|
Posted: Fri May 29, 2020 9:55 pm |
cause it's sega! or something sega-related. just a minor preference. I didnt know it was an avatar..
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.
+1 would be amazing.
+1. more debugging options the better!
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!! |
|
|
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. | |
|
Posted: Sat May 30, 2020 8:19 am |
@segasonicfan : Maybe you'll find this useful :
|
|
|
Posted: Sat May 30, 2020 10:58 am |
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. |
|
|
Posted: Sat May 30, 2020 11:12 am |
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. |
|
|
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 |
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" |
|
|
Posted: Sat Mar 13, 2021 8:45 am |
Old discussion here:
https://www.smspower.org/forums/9562-GameGearSMSModeVideoScaling |
|
|
Posted: Mon Mar 15, 2021 5:25 pm |
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? |
|
|
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 |
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! |
|
|
Posted: Mon Mar 15, 2021 7:46 pm |
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 |
|
|
Posted: Wed Aug 25, 2021 8:45 am |
When using this on a game gear, is region detection still done using port $3f or is it using port $00 instead? | |
|
Posted: Wed Aug 25, 2021 12:46 pm |
Currently the suite runs correctly only in GG-SMS mode, in which case it's using port 3f primarily |
|
|
Posted: Sat Sep 04, 2021 8:12 am |
Yes please! |
|
|
Posted: Mon Sep 13, 2021 3:09 pm |
I'm sort of halfway through this, now. I am wondering if the 'Linearity' test is needed at all, given that I believe there's no way to calibrate the LCD screen. In case we want to retain that test anyway, I'll gladly accept submissions for the 160×144 image to use ;) |
|
|
Posted: Mon Oct 04, 2021 5:32 pm |
GG Test Suite preview (v. 0.10)
Native Game Gear mode Test Suite - Linearity test still missing (I still wonder if that's useful at all) |
|
|
Posted: Mon Oct 04, 2021 9:12 pm |
The linearity test is good for emulators to show them using the wrong pixel aspect ratio, and I guess replacement LCDs which do it wrong. | |
|
Posted: Wed Oct 06, 2021 1:08 pm |
Oh, so I definitely need to enable that test. Now, if anyone could provide the image I need... edit: sorry I had forgotten there is one already available here! edit again: GG Test Suite 0.11 attached. Linearity test now works. |
|
|
Posted: Thu Oct 07, 2021 1:25 pm Last edited by thatawesomeguy on Thu Oct 07, 2021 3:54 pm; edited 1 time in total |
I don't know if you managed to figure this out yourself, but from testing this is how vertical scaling in SMS mode works: In 192 line mode there is a repeating pattern of pixel blending every 3 rows, it's easiest to represent this as groupings where [] are rows and all the numbers inside are row offsets relative to a +3 counter that are blended together at 50% opacity. [0,1], [1,2] Starting at the first visible row, this results in the following blending: Destination Row Source Rows ----------------- ------------- 0 0, 1 1 1, 2 2 3, 4 3 4, 5 4 6, 7 5 7, 8 ETC For 224 mode it uses the following offsets relative to a +6 counter: [-3,-2,-1],[-1,0] Again starting at the first visible row you get: Destination Row Source Rows ----------------- ------------- 0 3, 4, 5 1 5, 6 2 6, 7, 8 3 8, 9 4 9, 10, 11 5 11, 12 ETC |
|
|
Posted: Thu Oct 07, 2021 2:30 pm |
This doesn't appear to be correct, or I am missing something. For instance, what's the content of the destination row #143? It can't be source rows #217 and #218 in 192 line mode of course... but you wrote that destination row n = avg(source row [truncate(n*1.5)], next source row)
|
|
|
Posted: Thu Oct 07, 2021 2:54 pm Last edited by thatawesomeguy on Thu Oct 07, 2021 3:40 pm; edited 1 time in total |
There's 8 pix padding top and bottom of the LCD so you only get a total of 128 actual rows. (192 / 3) * 2= 128 The other way to look at it is 192 is 3:2 mapping and 224 is -8 with 6:4 mapping, both with blending. |
|
|
Posted: Thu Oct 07, 2021 3:29 pm |
oh, that explains it! Are those padding rows a solid black or do they pick the color somewhere, like from an entry in the sprite palette? What's the padding for 224 rows mode, if there's one? BTW if I got this correctly you have: output row (n) | input rows (k0, k1)
0 to 7 | none, padding 8 to 135 | k0 = trunc((n-8)*1.5), k1=k0+1 => output is avg(row[k0], row[k1]) 136 to 143 | none, padding |
|
|
Posted: Thu Oct 07, 2021 3:46 pm Last edited by thatawesomeguy on Thu Oct 07, 2021 9:03 pm; edited 1 time in total |
Padding is pure black, no overscan colour.
No padding in 224 mode, first and last 4 rows are not visible and it outputs exactly 144 rows. ((224 - 8) / 6) * 4 = 144 Padding is correct in your algorithm, as for the rest no idea, math is not my strong point, I have no idea what that formula does. Just realised I had destination rows incorrect in the 224 table, I was thinking of source row 4 is the first visible row, but it renders on row 0 of the LCD. |
|
|
Posted: Thu Oct 07, 2021 6:51 pm |
((224 - 8) / 6) × 4 = 144 Also:
Not saying that either of you is wrong, I don't know the correct answer myself, I'm only quoting. |
|
|
Posted: Thu Oct 07, 2021 9:07 pm |
Fixed my typo.
Aren't all codemasters games 256x240? I could be wrong about 192 mode padding colour but all the games I tested it wss black (could just be they all set background as black). |
|
|
Posted: Thu Oct 07, 2021 10:25 pm |
Codemasters SMS games use 224 row mode (except for the boot splash screen). | |
|
Posted: Mon Oct 11, 2021 12:23 pm |
so it's likely taking 216 rows from the 'original' image, that is 192 rows 'central' image and 12 rows from both the top and bottom border |
|
|
Posted: Tue Jan 04, 2022 3:47 pm |
GG Test Suite 0.12
This should no longer have any missing characters on screen, on any Game Gear model with any cartridge adapter. If you still get some missing characters, I surely want to hear from you. |
|
Goto page Previous 1, 2, 3, 4, 5, 6 Next |