Author Message

sverx

Joined: 05 Sep 2013

Posts: 2739

SMS Test Suite - work in progress homebrew 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

kusfo

Joined: 29 Mar 2012

Posts: 613

Location: Spain Posted: Wed Jun 20, 2018 8:14 pm

Looks wonderful! :-D

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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.

Revo

Joined: 26 Jan 2014

Posts: 510

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.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London Posted: Thu Jun 21, 2018 7:18 am

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



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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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! ;) )

wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

Posted: Thu Jun 21, 2018 8:52 am

wasup wrote



http://www.smspower.org/Development/RegionDetection Theres a bit of info and some sample code for region detection here...



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?

sverx

Joined: 05 Sep 2013

Posts: 2739

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 :)

wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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

Revo

Joined: 26 Jan 2014

Posts: 510

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 ;)

sverx

Joined: 05 Sep 2013

Posts: 2739

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

Flygon

Joined: 30 Jun 2016

Posts: 143

Location: Melbourne, Australia 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.

wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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_224326.jpg (93.05 KB)



sverx

Joined: 05 Sep 2013

Posts: 2739

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 SMS Test Suite v. 0.11 ROM TestSuite-0.11.rar (10.66 KB)



wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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!

sverx

Joined: 05 Sep 2013

Posts: 2739

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!

Flygon

Joined: 30 Jun 2016

Posts: 143

Location: Melbourne, Australia 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.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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 ;) )

Bock Site Admin

Joined: 08 Jul 2001

Posts: 8223

Location: Paris, France Posted: Thu Jun 21, 2018 3:10 pm

See http://www.smspower.org/Development/WonderBoyInMonsterWorld-SMS for an idea.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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...

sverx

Joined: 05 Sep 2013

Posts: 2739

Posted: Thu Jun 21, 2018 8:19 pm

Sure - sorry I'm not very knowledgeable.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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?

vingazole

Joined: 20 Feb 2008

Posts: 117

Location: Saintes, France 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)



vingazole

Joined: 20 Feb 2008

Posts: 117

Location: Saintes, France 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)



bsittler

Joined: 22 Apr 2018

Posts: 229

Posted: Fri Jun 22, 2018 4:34 am

sverx wrote



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

sverx

Joined: 05 Sep 2013

Posts: 2739

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? small test ROM that just checks VDP revision and port $0 value... ModelTest.rar (2.96 KB)



wasup

Joined: 05 Nov 2014

Posts: 358

Location: Auckland - NZ 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. 20180622_223922.jpg (63 KB)



TomyS

Joined: 07 Sep 2013

Posts: 51

Location: Finland 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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. SMS Test Suite v. 0.14 ROM TestSuite.rar (20.28 KB)



Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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 ;) )

Bock Site Admin

Joined: 08 Jul 2001

Posts: 8223

Location: Paris, France 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

bsittler

Joined: 22 Apr 2018

Posts: 229

SG-1000 VDP modes too? 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 ;)

bsittler

Joined: 22 Apr 2018

Posts: 229

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 suspect the TV is supposed to show perfectly square pixels both in 50Hz/60Hz modes, right? 256x192 is exactly 4:3... 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 screenshot from SNES 240p test suite truncated to 256x192 linearity-256x192.png (785 B) GG-SMS hypothetical square pixel linearity test new-1-1-gg-sms-linearity-256x192.png (1.1 KB) SMS square pixel linearity test new-1-1-linearity-256x192.png (1.2 KB) SMS PAL linearity test new-pal-linearity-256x192.png (1.04 KB) SMS NTSC linearity test new-linearity-256x192.png (1.09 KB) GG-SMS linearity test new-gg-sms-linearity-256x192.png (1.1 KB) GG-SMS hypothetical NTSC linearity test new-gg-sms-linearity-256x192.png (1.09 KB) GG-SMS linearity test with partial subpixel compensation new-actual-gg-sms-linearity-256x192.png (6.88 KB)



Kroc

Joined: 08 Dec 2013

Posts: 200

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.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

Kroc

Joined: 08 Dec 2013

Posts: 200

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.

Bock Site Admin

Joined: 08 Jul 2001

Posts: 8223

Location: Paris, France 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.

Maxim Site Admin

Joined: 19 Oct 1999

Posts: 13354

Location: London 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.

sverx

Joined: 05 Sep 2013

Posts: 2739

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.

bsittler

Joined: 22 Apr 2018

Posts: 229

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. 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) SMS PAL linearity simulation pal-sms-appearance.png (16.24 KB) SMS NTSC linearity simulation ntsc-sms-appearance.png (15.16 KB) SMS square pixel linearity simulation square-sms-appearance.png (12.53 KB) GG-SMS linearity simulation unscaled-gg-sms-appearance.png (15.97 KB) GG-SMS linearity simulation with partial subpixel compensation downscaled-gg-sms-appearance.png (15.09 KB) GG-SMS hypothetical NTSC linearity simulation ntsc-gg-sms-appearance.png (15.65 KB) GG-SMS hypothetical square pixel linearity simulation square-gg-sms-appearance.png (12.69 KB)



sverx

Joined: 05 Sep 2013

Posts: 2739

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 :(

bsittler

Joined: 22 Apr 2018

Posts: 229

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

Bock Site Admin

Joined: 08 Jul 2001

Posts: 8223

Location: Paris, France Posted: Mon Jun 25, 2018 6:56 pm