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 1, 2, 3, 4, 5, 6  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
SMS Test Suite - work in progress homebrew
Post Posted: Wed Jun 20, 2018 3:20 pm
Last edited by sverx on Fri Sep 06, 2019 2:58 pm; edited 1 time in total
*********************

Latest version can be found here.
Current version features quite a number of video tests, audio tests, input tests (SMS and MD pads). Check the last posts in this very thread to see what's new.

*********************


Original post with original images follows:
Largely inspired by Artemio's 240p, but not a fork of it, yesterday I started writing a test suite for all the stuff regarding our loved machine.
So far (version 0.10) I only implemented a few of the basic video tests and the pad test, which is actually my old 'controllers' test integrated into this (still no audio tests are present).

I'm open to your suggestions and I need your feedback. ROM is attached. Source will be on GitHub as soon as this reaches version 1.00
SMS Test Suite - main menu.png (5.94 KB)
SMS Test Suite - main menu screenshot
SMS Test Suite - main menu.png
SMS Test Suite - video tests menu.png (6.3 KB)
SMS Test Suite - video tests menu screenshot
SMS Test Suite - video tests menu.png
color bleed test.png (1.22 KB)
SMS Test Suite - color bleed test screenshot
color bleed test.png
pad test.png (6 KB)
SMS Test Suite - pad test screenshot
pad test.png
TestSuite.rar (10.6 KB)
SMS Test Suite v. 0.10 ROM

  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Wed Jun 20, 2018 8:14 pm
Looks wonderful! :-D
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Wed Jun 20, 2018 10:46 pm
I guess for the audio test you can copy Heliophobe's SMS Sound Test, which always had a bug (it writes to the PSG registers every frame instead of only when the values change, which affects the noise channel). Making an equivalent for FM is a whole lot harder.
  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: Thu Jun 21, 2018 1:57 am
Thats pretty awesome, i do like it. Ill have a play with it tonight when i get home.

Having the system region could be handy at the bottom too. Not sure how hard that would be to add.
  View user's profile Send private message
Revo
  • Guest
Reply with quote
Post Posted: Thu Jun 21, 2018 6:04 am
Would be nice to be able to test some peripheral like Light Phaser, Handle Controller, Paddle Control, Sports Pad, Rapid Fire.
 
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 7:18 am
Last edited by Maxim on Wed Aug 25, 2021 9:10 am; edited 1 time in total
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 quite 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.

Detecting the other peripherals would be interesting too. I understand that the paddle and sports pad(s) produce quite noisy output so it'd be interesting again to see raw data alongside a smoothed result (paddle games seem to use an exponential moving average by summing the new value to the previous result and dividing by 2).

It's getting away from the 240p purposes, but 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.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 8:17 am
@Maxim: for the PSG audio test I was thinking about something simpler like having a small tune played on channel 0 or 1 or 2 or 3 (noise) according to a button press (of course tune on channel 3 would be different). No idea how to test FM.

@wasup: I don't know how region detection works - any hint?

@Revo: I'll work on Light Phaser, Handle Controller, Paddle Control, Sports Pad tests too, but probably after version 1.00. Rapid fire can be tested already in Pad Test.

If anybody wants to help providing sources (asm and/or C) for other tests - it's welcome (I'm looking at your Light Phaser test, Maxim! ;) )
  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: Thu Jun 21, 2018 8:21 am
Theres a bit of info and some sample code for region detection here...

http://www.smspower.org/Development/RegionDetection
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 8:30 am
Ha, I'd write it in assembly I'm afraid! The cognitive load to get going in C may be too much for me.

The SMS test ROM we found plays PSG tones during the button test (while the button is held), which serves to confirm that audio is working at all.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 8:52 am
wasup wrote
Theres a bit of info and some sample code for region detection here...

http://www.smspower.org/Development/RegionDetection


Thanks, that works just perfectly!
I was wondering anyway if one can have a 50/60Hz mod in a Japanese hardware.
Also, how this code behave in a MegaDrive?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 8:53 am
Maxim wrote
Ha, I'd write it in assembly I'm afraid!


No problem, I can inline asm quite easily :)
  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: Thu Jun 21, 2018 8:59 am
Can you even region mod a mega drive for sms compatability mode? Im working on a master system at the moment.. ill have a look at modding a mega drive shortly if you like
  View user's profile Send private message
Revo
  • Guest
Reply with quote
Post Posted: Thu Jun 21, 2018 9:06 am
If you have problems with the Sports Pad, contact Vingazole, he made a little test rom for it few years ago ;)
 
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 10:00 am
I'm reading about the linearity test and I'm a bit puzzled.
I suspect the TV is supposed to show perfectly square pixels both in 50Hz/60Hz modes, right? 256x192 is exactly 4:3...
  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: Thu Jun 21, 2018 10:27 am
There's borders on the top and bottom of the screen. Pretend that the screen is actually between 224 and 240 pixels tall.

The aspect ratio that the Master System actually displays is somewhat stretched horizontally.
Whilst not totally accurate, I pretend that the pixel aspect ratio is around 4 wide/3 tall. Or around 25% wider than it is tall.
  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: Thu Jun 21, 2018 10:57 am
sverx wrote
Also, how this code behave in a MegaDrive?


Ive just done a region and 50/60Hz mod to a megadrive. Your test identifies it as a mega drive and also detects 50/60Hz properly. If i have the region set to JP and run Phantasy star it loads with a MkIII screen first and if the region is EXP it doesnt load with a MkIII screen. So.. looks like it behaves the same on a mega drive.

On a game gear it identifies as a master system II, and on a master system 1 it also identifies as a master system II. Not sure if you can actually detect the difference between them in software though.
20180621_224054.jpg (86.89 KB)
20180621_224054.jpg
20180621_224326.jpg (93.05 KB)
20180621_224326.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 11:03 am
@wasup: SMS II detection is bound to VDP version detection, it checks the sprite zoom bug that was present on the 1st revision thus:
- it's correct that the GG in SMS mode is identified as a SMS II
- your SMS could be one of those having a new VDP - if you can run Gemitas properly, it's so - otherwise there's a problem in my detection routine.

@Flygon: really??? I thought the pixels were supposed to be almost perfect squares!

edit: region detection added - ROM attached
TestSuite-0.11.rar (10.66 KB)
SMS Test Suite v. 0.11 ROM

  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: Thu Jun 21, 2018 11:37 am
Gemitas ran properly so must be a new VDP on mine then.

Have checked the region detection on the mega drive and it worked fine.

Great work!
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 12:59 pm
We've seen recently that's not so uncommon, 'new' VDP in 'old' shells - the other way around is instead a rarity.
Thanks for the checks!
  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: Thu Jun 21, 2018 2:03 pm
My own SMSI uses a newer VDP, itself.
Was somewhat surprised when I found out, in fact!

sverx wrote
@Flygon: really??? I thought the pixels were supposed to be almost perfect squares!


The pixels start being square when the resolution itself, for 240p machines, is around 320 pixels wide.
Naturally, that scales up and down.

So 256x240 isn't Square Pixels, but 320x240 is Square Pixels.
The Master System's 256x192 mode is just very confusing thanks to the borders it has on the top and the bottom.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 2:20 pm
The pixels are not square, you can calculate the aspect ratio from the timings - PAL (1.352) and NTSC (1.141). See http://www.smspower.org/forums/11870-PALNTSCBordersAndColor#57854 for timing numbers and http://www.smspower.org/forums/13601-RecordingVideosOfSMSGames#97215 for some mocked up pictures using those aspect ratios.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 3:02 pm
Last edited by sverx on Fri Jun 22, 2018 11:35 am; edited 1 time in total
so I guess I need some help to create a proper 256x192 image for the linearity test - two images if ratio is different on PAL/NTSC systems. Any volunteer? :)

then, speaking about SMS revisions, I've been asked if there's a way to detect if the hardware is a SMSII or not, not just the VDP version. I'm not sure it's really needed (I mean, you can see yourself which machine you've got in front of you...) but nonetheless it's intriguing.

also, here's a small update - "drop shadow" and "striped sprite" tests added. (attachment removed - we don't want Sonic in there ;) )
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Thu Jun 21, 2018 3:10 pm
See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 6:14 pm
Could you avoid the dithering on flat areas of the image? Oh, and replace it with Alex Kidd or Opa Opa or similar. That's a post 8 bit Sonic...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Jun 21, 2018 8:19 pm
Sure - sorry I'm not very knowledgeable.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Thu Jun 21, 2018 8:49 pm
I'm no artist - my homebrew can attest to that - but I've been criticised for the same thing in the past. Maybe we can get some help from someone on the forum?
  View user's profile Send private message Visit poster's website
  • Joined: 20 Feb 2008
  • Posts: 118
  • Location: Saintes, France
Reply with quote
Post Posted: Thu Jun 21, 2018 9:48 pm
Revo wrote
If you have problems with the Sports Pad, contact Vingazole, he made a little test rom for it few years ago ;)

SPORTSPAD is just a struct{char x,y;} :

//       fonctions pour lire les sportspads (trackballs)

extern void read_sportspad1(SPORTSPAD * p_sportspad);
extern void read_sportspad2(SPORTSPAD * p_sportspad);


void read_sportspad_asm() {
  __asm

  _read_sportspad1::                                 ; TRACKBALL #1

          ld        a,#0x0D             ; STROBE 1 LOW       (%00001101)      ; READ X1
          out    (#0x3f),a        ;

          ld     b,#25            ; wait 80 microseconds
   1$:     djnz   1$                 ;

          in     a,(#0xdc)             ; read X1 high nibble
          and    #0x0f                 ;         ( bits 0..3 from port #0xdc)

          rrca
          rrca
          rrca
          rrca
          ld     d,a


          ld     a,#0x2D        ; STROBE 1 HIGH      (%00101101)
        out    (#0x3f),a           ;

          ld     b,#13                ; wait 40 microseconds
   2$:     djnz   2$               ;

          in     a,(#0xdc)               ; read X1 low nibble
          and    #0x0f                   ;         ( bits 0..3 from port #0xdc)
          or     d

                neg
          ld     (hl),a                ;
          inc    hl


          ld     a,#0x0D             ; STROBE 1 LOW        (%00001101)      ; READ Y1
          out    (#0x3f),a        ;

          ld     b,#13                ; wait 40 microseconds
   3$:     djnz   3$                 ;

          in     a,(#0xdc)             ; read Y1 high nibble
          and    #0x0f                   ;         ( bits 0..3 from port #0xdc)

          rrca
          rrca
          rrca
          rrca
          ld     d,a


          ld     a,#0x2D              ; STROBE 1 HIGH      (%00101101)
          out    (#0x3f),a       ;

          ld     b,#13                 ; wait 40 microseconds
   4$:     djnz   4$

          in     a,(#0xdc)               ; read Y1 low nibble
          and    #0x0f                   ;         ( bits 0..3 from port #0xdc)

          or     d

          neg
          ld     (hl),a           ;

                ret


  _read_sportspad2::

          ld     a,#0x07        ; STROBE 2 LOW         (%00000111)   ; READ X2
          out    (#0x3f),a        ;

          ld     b,#25                 ; wait 80 microseconds
   5$:     djnz   5$

          in     a,(#0xdc)               ; read X2 high nibble
          and    #0xc0                   ;         (bits 6,7 from port #0xdc)
          rrca
          rrca
          ld     e,a

          in     a,(#0xdd)
          and    #0x03                   ;         (bits 0,1 from port #0xdd)
          rrca
          rrca
          or     e
          ld     d,a


          ld     a,#0x87        ; STROBE 2 HIGH       (%10000111)
          out    (#0x3f),a           ;

          ld     b,#13               ; wait 40 microseconds
   6$:     djnz   6$

          in     a,(#0xdc)               ; read X2 low nibble
          and    #0xc0                   ;         (bits 6,7 from port #0xdc)

          ld     e,a

          in     a,(#0xdd)
          and    #0x03                   ;         (bits 0,1 from port #0xdd)
          or     e
          rlca
          rlca
          or     d

          neg
          ld     (hl),a            ; pad_x2 = -X2
                inc    hl

          ld     a,#0x07         ; STROBE 2 LOW         (%00000111)   ; READ Y2
          out    (#0x3f),a              ;

          ld     b,#13                ; wait 40 microseconds
   7$:     djnz   7$

          in     a,(#0xdc)               ; read Y2 high nibble
          and    #0xc0                ;         (bits 6,7 from port #0xdc)
          rrca
          rrca
          ld     e,a

          in     a,(#0xdd)
          and    #0x03                   ;         (bits 0,1 from port #0xdd)
          rrca
          rrca
          or     e
          ld     d,a


          ld     a,#0x87         ; STROBE 2 HIGH       (%10000111)
          out    (#0x3f),a               ;

          ld     b,#13                 ; wait 40 microseconds
   8$:     djnz   8$

          in     a,(#0xdc)               ; read Y2 low nibble
          and    #0xc0                   ;         (bits 6,7 from port #0xdc)
          ld     e,a

          in     a,(#0xdd)
          and    #0x03                   ;         (bits 0,1 from port #0xdd)
          or     e
          rlca
          rlca
          or     d

          neg
                ld     (hl),a               ; pad_y2 = -Y2

      ret
  __endasm;
}



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

I can't check if this is the good ROM (my phaser is at ichigo's...) :
phaser.zip (470 B)

  View user's profile Send private message
  • Joined: 20 Feb 2008
  • Posts: 118
  • Location: Saintes, France
Reply with quote
Post Posted: Thu Jun 21, 2018 10:18 pm
Maxim wrote
I guess for the audio test you can copy Heliophobe's SMS Sound Test, which always had a bug (it writes to the PSG registers every frame instead of only when the values change, which affects the noise channel).



I always wondered why it didn't work ! I wrote this to test the "periodic noise" :
PSG_control.zip (4.1 KB)

  View user's profile Send private message
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Fri Jun 22, 2018 4:34 am
sverx wrote
so I guess I need some help to create a proper 256x192 image for the linearity test - two images if ratio is different on PAL/NTSC systems. Any volunteer? :)

then, speaking about SMS revisions, I've been asked if there's a way to detect if the hardware is a SMSII or not, not just the VDP version. I'm not sure it's really needed (I mean, you can see yourself which machine you've got in front of you...) but nonetheless it's intriguing.

also, here's a small update - "drop shadow" and "striped sprite" tests added.


That's awesome!

How are you determining 50 Hz vs. 60 Hz and model?

I notice some odd behavior on the various system × (optionally) adapter × flash cart combinations I've tried. How should Game Gear be identified? AFAIK no Game Gear actually generates 50 Hz vertical retrace or PAL, yet the tester identifies one of my Game Gears (with a McWill mod) as PAL/EUR/50 Hz when I use EverDrive GG (but NTSC/USA/60 Hz when I use EverDrive SMS!) Stranger still, my other Game Gear (no McWill mod) is identified reliably as NTSC/USA/60 Hz.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jun 22, 2018 8:04 am
bsittler wrote
How are you determining 50 Hz vs. 60 Hz and model?


V-counter is a 8 bit register that counts up to a given number and then 'skips back' (see http://www.smspower.org/Development/ScanlineCounter ) - so I'm discriminating just checking that difference.

  do {
    old_value=VDPVCounterPort;        // wait until VCounter 'goes back'
  } while (old_value<=VDPVCounterPort);
  if (old_value>=0xE7)
    TV=PAL;                  // old value should be 0xF2
  else
    TV=NTSC;                 // old value should be 0xDA


Game Gears aren't identified (yet...?) - if running in SMS mode, they should be identified as SMS II / USA / NTSC, because that's what they will 'emulate'...

@vingazole: thanks. I can't test that anyway - would you test that for me please? :)

@Bock: wow - that's great. Let see if it actually detects differently than the VDP version, I'll prepare a small test ROM ASAP.

edit:
@wasup (and others with a 'first version' SMS identified as an SMS II) : could you run the attached small ROM and tell me what values appear on the screen?
ModelTest.rar (2.96 KB)
small test ROM that just checks VDP revision and port $0 value...

  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: Fri Jun 22, 2018 10:43 am
sverx wrote
@wasup (and others with a 'first version' SMS identified as an SMS II) : could you run the attached small ROM and tell me what values appear on the screen?


It shows as SMSII. The menu from my everdrive gets garbled and is left on screen but thats probably not of concern.

  View user's profile Send private message
  • Joined: 07 Sep 2013
  • Posts: 58
  • Location: Finland
Reply with quote
Post Posted: Fri Jun 22, 2018 10:45 am
vingazole wrote
I always wondered why it didn't work ! I wrote this to test the "periodic noise" :


Thank you for this program. I was very curious to check out the highest frequencies and see how different trackers work:

VGM Music Maker: Can't reach the 2 highest frequencies.
Deflemask: Somebody more experienced maybe help me with this one? I'm not familiar with the software but what I could work out was that you can reach the highest frequency but not the following 6 frequencies below that.
SnevenTracker: You can reach all the frequencies. Sadly the .vgm export of this program is not the best possible, you have to trim the exported file yourself.

Those high frequencies are very important for nice PSG cymbal and snare instruments. I feel that the third highest frequency you can reach with VGM MM is just barely enough.

I tested my SMS1 with the ModelTest program:
VDP rev = [SMSII]
Port 0 = [00]

I wish I had a SMS1 VDP, I'm curious if there are any differences in sound? I know that MD PSG differs so much from SMS PSG that most of my SMS optimized tracks are pretty much unlistenable on MD. Filtering etc. might be a reason, not sure.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jun 22, 2018 11:34 am
@wasup and TomyS:so you both got an SMS I with the new VDP and you both got Port0 = 00! That's nice, I'll run a few tests myself at home this evening and we'll see if we can really identify all the 4 cases:

- 'original' SMS
- 'original' SMS with 'new' VDP
- SMS II
- SMS II with 'old' VDP (very rare!)

edit: while we wait, here's a small update. Audio Tests enabled, Sonic replaced with Alex Kidd in shadow/striped sprite tests.
TestSuite.rar (20.28 KB)
SMS Test Suite v. 0.14 ROM

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Fri Jun 22, 2018 1:45 pm
I suspect what we are able to test is the behaviour of the chips - IO and VDP. The mapping to real systems is a bit arbitrary but it may be the case that each combination maps to a unique set of hardware. There's board pictures in the development section, you can search for 315-5124 and 315-5246.

I believe you can tell a Master System from a Game Gear by checking the Z80 for CMOS vs NMOS behaviour for the out (c),0 opcode. Maybe better just to report that as the Z80 type. You can also try swapping in the BIOS ROM and see what's there. Actually, that might be an interesting thing to add - do a little checksum of the BIOS and report if it is a know type.

There is different 50/60Hz detection code in games which counts how many times a loop runs between frame interrupts. This will be less sensitive to unusual behaviour in the vcount.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jun 22, 2018 2:27 pm
Yes, I'm going to check IO and VDP and try to infer the model from there.
I'm not going to add any detecting of a Game Gear for now, that might become eventually interesting later. But the BIOS checksum might indeed be interesting - do we already have a list of known BIOSes with checksum?
As for 50/60Hz detection, I'll keep the current system until proven there are cases where it's not working properly (and Game Gear doesn't yet count ;) )
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Fri Jun 22, 2018 2:41 pm
Here are the known bioses (with CRC32)

SMS cf4a09ea Alex Kidd in Miracle World [BIOS]/FLAGS=BIOS
SMS 9c5bad91 Alex Kidd in Miracle World [BIOS]/FLAGS=BIOS/COUNTRY=KR
SMS 8edf7ac6 Hang On [BIOS]/FLAGS=BIOS
SMS 91e93385 Hang On / Safari Hunt [BIOS]/FLAGS=BIOS
SMS e79bb689 Missile Defense 3-D [BIOS]/FLAGS=BIOS/EMU_INPUTS=LIGHTPHASER/EMU_3D
SMS 81c3476b Sonic The Hedgehog [BIOS]/FLAGS=BIOS
SMS 0072ed54 SMS (v1.3) [BIOS]/COUNTRY=US,EU/FLAGS=BIOS
SMS b3d854f8 SMS (v2.0) [BIOS]/COUNTRY=EU/FLAGS=BIOS
SMS 48d44a13 SMS Japanese (v2.1) [BIOS]/COUNTRY=JP/FLAGS=BIOS
SMS 1a15dfcc SMS Prototype (M404) [BIOS]/FLAGS=BIOS
SMS 72bec693 SMS Prototype (v1.0) [BIOS]/FLAGS=BIOS
SMS ee2c29ba SMS Store Display Unit [BIOS]/EMU_MAPPER=10/COUNTRY=US/FLAGS=BIOS/COMMENT=This is not properly emulated.

Doing a SUM of the first a few kb should be more than enough (no need to scan everything).

I would suggest display raw tests results (e.g. "VDP test xxxx = 1, IO test 2 = pass etc..") and only after deriving the system from those tests. But having all the raw tests results displayed will help understand what's going on and help with testing on variety of systems.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Fri Jun 22, 2018 2:52 pm
Bock wrote
Doing a SUM of the first a few kb should be more than enough (no need to scan everything).


OK - I can try that. We'll need to create a table with those values (you mean a 16 bit SUM of bytes I believe)

Bock wrote
I would suggest display raw tests results (e.g. "VDP test xxxx = 1, IO test 2 = pass etc..") and only after deriving the system from those tests. But having all the raw tests results displayed will help understand what's going on and help with testing on variety of systems.


I may add a separate page with all the raw test results, sure.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Fri Jun 22, 2018 4:28 pm
The Sega checksum is a 16-bit sum. You can spend a bit more time to make it Adler or CRC but there's not much point - we are trying to identify from a known set, not detect bit level changes.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
SG-1000 VDP modes too?
Post Posted: Fri Jun 22, 2018 6:10 pm
Any interest in exercising the SG-1000 VDP graphics modes too, for those systems that have them?

I see someone made a set of color tests for the similar ColecoVision graphics modes and posted them to the AtariAge forums linked from the thread on citrus's new ColecoVision RGB mod (maybe somehow adaptable to SG-1000? really I do not know yet) but so far I have not found anything analogous to the 240p test suite for MSX1, SG-1000, SMS-in-SG 1000 mode, ColecoVision, or TI-99/4A. Obviously these machines (other than SMS) are not really "RGB-native", so some of the tests would have to be fairly different from the more modern true-RGB suites, similar to the situation addressed by the NES/Famicom test suite but of course with a greener palette ;)
  View user's profile Send private message
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Fri Jun 22, 2018 6:49 pm
Last edited by bsittler on Fri Jun 22, 2018 11:46 pm; edited 7 times in total
sverx wrote
I'm reading about the linearity test and I'm a bit puzzled.
I suspect the TV is supposed to show perfectly square pixels both in 50Hz/60Hz modes, right? 256x192 is exactly 4:3...


I think that at least for NTSC the linearity test images here should be effectively identical to the ones from the SNES 240p suite except with the top 16 pixels and bottom 16 pixels cut off

edit: n/m, i see that with the truncation measuring distortion becomes impossible, so indeed a new image is needed.

edit 2-4: maybe these work better? feel free to use; small circles have radius 1/4th of the large circle

edit 5: is PAL SMS really letterboxed that much?!? that usable area is even shorter than 16:9!

edit 6: added a couple Game Gear SMS mode linearity tests, but the actual GG pixel aspect ratio is just a guess (need to check this on the real hardware in SMS mode)

edit 7: just measured on an actual Game Gear (non-McWill) in GG-SMS subpixel color-bleed mode, SMS pixel aspect ratio is actually around 1.218 !

edit 8: corrected pixel grid alignment

edit 9: added a test image with partial compensation for GG-SMS subpixel mapping — this still needs testing on real hardware
linearity-256x192.png (785 B)
screenshot from SNES 240p test suite truncated to 256x192
linearity-256x192.png
new-1-1-gg-sms-linearity-256x192.png (1.1 KB)
GG-SMS hypothetical square pixel linearity test
new-1-1-gg-sms-linearity-256x192.png
new-1-1-linearity-256x192.png (1.2 KB)
SMS square pixel linearity test
new-1-1-linearity-256x192.png
new-pal-linearity-256x192.png (1.04 KB)
SMS PAL linearity test
new-pal-linearity-256x192.png
new-linearity-256x192.png (1.09 KB)
SMS NTSC linearity test
new-linearity-256x192.png
new-gg-sms-linearity-256x192.png (1.1 KB)
GG-SMS linearity test
new-gg-sms-linearity-256x192.png
new-gg-sms-linearity-256x192.png (1.09 KB)
GG-SMS hypothetical NTSC linearity test
new-gg-sms-linearity-256x192.png
new-actual-gg-sms-linearity-256x192.png (6.88 KB)
GG-SMS linearity test with partial subpixel compensation
new-actual-gg-sms-linearity-256x192.png

  View user's profile Send private message
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Fri Jun 22, 2018 9:27 pm
Maxim wrote
The Sega checksum is a 16-bit sum. You can spend a bit more time to make it Adler or CRC but there's not much point - we are trying to identify from a known set, not detect bit level changes.


I would argue that checking the whole ROM would be wise in case we stumble across new and unknown ROMs; or if the user has a faulty ROM.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Sat Jun 23, 2018 6:02 am
The goal is to detect what's there (including anything unknown), not to dump it. Checksumming the whole thing would require detecting the size too.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Dec 2013
  • Posts: 200
Reply with quote
Post Posted: Sat Jun 23, 2018 8:23 am
How do you know a ROM needs dumping unless there's a program out there people can run that could tell them what ROM they have? Surely throwing up a message like "Unknown ROM, please contact us about dumping it!" would help you in the long-run. That said, I can't comment on the practicality and size issue.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Sat Jun 23, 2018 8:28 am
Identifying among known BIOS dump is probably a matter of scanning about 1 KB, then in the event it is useful to dig further, there can be an option for displaying SUM of each 16 KB page + maybe an HEX viewer.

Realistically we don't find BIOS variations that have matching first few KB and the rest is different.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14685
  • Location: London
Reply with quote
Post Posted: Sat Jun 23, 2018 10:08 am
...although that could be plausible for a minor patch. The point is, someone running this will be capable of running another program to dump the ROM if necessary.

Do we have useable libraries to write to the Everdrive SD card? I seem to remember the old released source had some FAT code but it has since changed to FAT32, I believe.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Sat Jun 23, 2018 9:47 pm
Maxim wrote
Do we have useable libraries to write to the Everdrive SD card? I seem to remember the old released source had some FAT code but it has since changed to FAT32, I believe.


we can already write up to 32 KB to SD exploiting the SRAM save feature

@bsittler: thanks, I'll try them. Could you please tell me the ratio applied to each one? I want to check if it's the same I expected.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Sat Jun 23, 2018 11:00 pm
sverx wrote
Maxim wrote
Do we have useable libraries to write to the Everdrive SD card? I seem to remember the old released source had some FAT code but it has since changed to FAT32, I believe.


we can already write up to 32 KB to SD exploiting the SRAM save feature

@bsittler: thanks, I'll try them. Could you please tell me the ratio applied to each one? I want to check if it's the same I expected.


NTSC uses 1.141 PAR from Maxim's comment.

PAL uses 1.352 PAR from Maxim's comment.

Non-hypothetical GG SMS uses 1.218 PAR from my own measurements. I wouldn't be surprised if this number turns out to be slightly off.

Square uses 1.000 PAR.

All GG SMS leave left and right 8 pixels blank as they are off-screen on original hardware.

Partial subpixel compensation means image was originally generated for SMS-addressable subset of whole-pixel GG screen resolution, then upscaled to corresponding SMS resolution for that region prior to adding 8 pixel borders.

In every case I attempted to leave one pixel black borders around the screen edge. Edge widths are not PAR-adjusted, as that would look weirder. Images are mapped to greyscale subset of the SMS palette but have not been adjusted for tile mapping feasibility

edit: added images showing how each test image *should* look, more or less (not actually simulating Game Gear original display awfulness, though)
pal-sms-appearance.png (16.24 KB)
SMS PAL linearity simulation
pal-sms-appearance.png
ntsc-sms-appearance.png (15.16 KB)
SMS NTSC linearity simulation
ntsc-sms-appearance.png
square-sms-appearance.png (12.53 KB)
SMS square pixel linearity simulation
square-sms-appearance.png
unscaled-gg-sms-appearance.png (15.97 KB)
GG-SMS linearity simulation
unscaled-gg-sms-appearance.png
downscaled-gg-sms-appearance.png (15.09 KB)
GG-SMS linearity simulation with partial subpixel compensation
downscaled-gg-sms-appearance.png
ntsc-gg-sms-appearance.png (15.65 KB)
GG-SMS hypothetical NTSC linearity simulation
ntsc-gg-sms-appearance.png
square-gg-sms-appearance.png (12.69 KB)
GG-SMS hypothetical square pixel linearity simulation
square-gg-sms-appearance.png

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Jun 25, 2018 8:36 am
Bock wrote
See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea.


mmm... is that info reliable? My small test returns $00 both on wasup and TomyS first revision SMS (both with 'new' VDP) - as expected - but it also returns $00 on my SMS II.

unsigned char port0 (void) __naked {
  __asm
    in a,(#0)
    ld l,a
    ret
  __endasm;
}


should I do anything special before reading port 0 ?

@bsittler: thanks, I'm putting them in :)

edit: more help needed. Can anyone turn this image to SMS format without using dithering? I seems I can't - colors always turn ugly :(
  View user's profile Send private message Visit poster's website
  • Joined: 22 Apr 2018
  • Posts: 530
Reply with quote
Post Posted: Mon Jun 25, 2018 4:51 pm
Last edited by bsittler on Tue Jun 26, 2018 1:11 am; edited 3 times in total
sverx wrote
Bock wrote
See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea.


mmm... is that info reliable? My small test returns $00 both on wasup and TomyS first revision SMS (both with 'new' VDP) - as expected - but it also returns $00 on my SMS II.

unsigned char port0 (void) __naked {
  __asm
    in a,(#0)
    ld l,a
    ret
  __endasm;
}


should I do anything special before reading port 0 ?

@bsittler: thanks, I'm putting them in :)

edit: more help needed. Can anyone turn this image to SMS format without using dithering? I seems I can't - colors always turn ugly :(


Colors do indeed turn ugly. How about one of these? Made with some variations similar to

ppmcolors -maxval=3 > sms-palette.ppm ; wget -O- https://uploa
.wikimedia.org/wikipedia/en/e/ec/Alex-Kidd-in-Miracle-World-game-screenshot.png |
ngtopnm > akimw-palette.ppm ;wget -O- https://upload.wikimedia.org/wikipedia/en/3/
0/Alex_Kidd_EnchantedCastle.png | pngtopnm | ppmbrighten -s 20 | ppmquant -mapfile
akimw-palette.ppm | pnmscale -xscale 0.7 -yscale 0.8 | ppmquant -mapfile sms-palet
e.ppm | pnmtopng > akimw.png


or

convert Alex_Kidd_EnchantedCastle.png -despeckle -resize '168x
92!' -posterize 4 -despeckle - | anytopnm  | ppmquant -mapfile akimw-palette.ppm |
pnmremap -mapfile sms-palette.ppm | pnmtopng > akimw2.png

akimw.png (4.54 KB)
Early unsuccessful attempt
akimw.png
akimw (1).png (4.32 KB)
Early unsuccessful attempt #2
akimw (1).png
akimw (2).png (4.44 KB)
Just a little Floyd-Steinberg, but we can pretend it's pixel art, right?
akimw (2).png
akimw (3).png (6.17 KB)
Ordered dither comparison
akimw (3).png
akimw2 (1).png (3.51 KB)
Happy accident?
akimw2 (1).png
akimw2 (3).png (5.81 KB)
Ordered dither with quite a bit of despeckling
akimw2 (3).png
akimw2 (4).png (3.92 KB)
Slightly vectorized
akimw2 (4).png
akimw-gg.png (4.24 KB)
GG-native, for comparison
akimw-gg.png

  View user's profile Send private message
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Post Posted: Mon Jun 25, 2018 6:56 pm
sverx wrote
Bock wrote
See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea.


mmm... is that info reliable? My small test returns $00 both on wasup and TomyS first revision SMS (both with 'new' VDP) - as expected - but it also returns $00 on my SMS II.


Perhaps it is tied to the VDP type? Or maybe the description is faulty and it would mainly differentiate GG from SMS or possibly MD from SMS?
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2, 3, 4, 5, 6  Next



Back to the top of this page

Back to SMS Power!