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  Next
Author Message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Thu Nov 28, 2019 11:00 am
ichigobankai wrote
Maybe VRAM needs to be cleared.


well, not really so much important - but I'm wondering where those seemingly random numbers you see come from! Are you using a donor cart or some PCB you developed yourself? I'm reading I/O ports $00-$3F (upper part) and ports $C0-$FF (the lower part) after having disabled I/O chip (in this second part only) - so random data is unexpected to me, according to Charles MacDonald's doc "smstech.txt"

Also, they seems the same numbers on the first two images - or are they two pictures from the same system by mistake?
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 321
  • Location: Angers, France
Reply with quote
Post Posted: Thu Nov 28, 2019 11:44 am
I'm not really a mistake guy with simple tasks (I hope ^^).
SMS1 and SMS2 with the same bios (AK) gave the same result on screen.

Its one my simple flash cart (not a everdrive or a complex from my "collection"). I can try latter with a simpler cart (no mapper on it).
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Thu Nov 28, 2019 5:23 pm
ichigobankai wrote
I'm not really a mistake guy with simple tasks (I hope ^^).


we're all human, I wouldn't blame you for anything :)

what puzzles me now is *IF* a cartridge might change the outcome of an I/O operation. I mean, is it possible?
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1151
Reply with quote
Post Posted: Sun Dec 01, 2019 5:29 pm
sverx wrote
what puzzles me now is *IF* a cartridge might change the outcome of an I/O operation. I mean, is it possible?


You're right, it can definitely happen. When you read an unused memory or I/O location there are no devices actively driving the data bus high or low so the lines 'float'; taking on a voltage level defined by how they are loaded in terms of resistive loading (pull up or pull down resistors),capacitive loading (connections to other chips), and other factors.

So cartridge that has say a ROM, RAM, and mapper chip vs a cartridge with a single ROM will load the data bus differently, and this can influence the values read back. If it actually does to some appreciable degree is another story.

For that reason reading an unused location is risky because the results can't be guaranteed. Certainly there will be some values/patterns that come up more often then not, and I suppose some kind of imprecise matching could take advantage of that. But looking for specific values or sequences of values is probably not reliable.

As an example I have eight pull-up resistors in my development cart, so every unused location returns $FF consistently. But it's specific to that cartridge only, and plugging in a different cartridge will change those results when reading an unused I/O port.
  View user's profile Send private message Visit poster's website
  • Joined: 28 Sep 1999
  • Posts: 1151
Reply with quote
Post Posted: Sun Dec 01, 2019 5:32 pm
sverx wrote
I'm now trying to identify the MegaDrive's VDP by testing the sprite zoom capabilities, instead.

I have no way to test this myself so I'm just leaving it here...


Hmm this is interesting. You could also test by switching into mode 5 and verifying there is 64K of VRAM instead of 16K perhaps?

Likewise you could prepare a sprite overflow or sprite collision in the TMS9918 mode and as they aren't supported on the Genesis I believe no overflow/collision would occur in the status flags.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Dec 02, 2019 10:40 am
Charles MacDonald wrote
For that reason reading an unused location is risky because the results can't be guaranteed. Certainly there will be some values/patterns that come up more often then not, and I suppose some kind of imprecise matching could take advantage of that. But looking for specific values or sequences of values is probably not reliable.


So I am really wondering if there's a way to detect which I/O chip is in there. I had expected to read either $ff or $78 but if in both case the values are pretty random and depending on the cartridge more than on the I/O chip, I think I'm again in a cul-de-sac.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Jan 27, 2020 10:58 pm
v0.29 just released, you can find it here.
Paddle control tests just added, for (Japanese) paddle controls.
You can plug paddle(s) in port 1 and/or port 2. (In case you need to start the ROM with normal pads connected you can do that and switch to paddle(s) when in the main menu and press PAUSE to restart the ROM).
If two paddles are connected at the same moment, the paddle tests will run automatically, but no other test will be available.

HUGE thanks to Kagesan for his invaluable help.

Feedback appreciated.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Jan 28, 2020 3:06 am
That sounds nice.. i will test this later on when i get a chance.
  View user's profile Send private message
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Thu Jan 30, 2020 8:35 am
I had a quick play with the new version. The paddle test is good. The marker wobbles about a bit when the paddle isnt being moved, the knob doesnt show as yellow while its wobbling, so not sure what that means. It might just be my paddle tho.. the pot it very likely to be dirty.

I didnt see a way to exit the test apart from powering off and on again. The pause button could be a good way to exit.

Also, in the main menu the selector scrolls up or down or just randomly moves if the paddle controller is plugged in and not at either extreme. Maybe you could ignore direction inputs if TR is toggling to resolve that.

The system info detects the paddle, which is a nice feature too.

Have you looked at a sports pad test too? I have US and JP versions of the sports pad so could help test that if your interested.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Thu Jan 30, 2020 10:27 am
Thanks for testing! The marker wobbling means that even when you're not touching the knob, the position reads a bit differently. This is totally expected, as the ADC isn't always returning exactly the same value - let's call that simply noise. As I'm trying to cut the noise, you won't see the knob light up when you don't rotate that. So as long as the knob lights up only when you rotate it, I'd say the test is correct.

About not having a way of leaving the test: the test should terminate by itself if you don't do anything for approx. 3 seconds... and about the fact that the arrow selector scrolls up and down in the main menu, well, there was a bug that caused both problems. I just fixed it now - I also added the PAUSE key as a way to leave the test, in case faulty paddles keep on registering knob movements. This should be better.

So I'm attaching a fixed version here, please let me know if you spot any other problem.

Also, I am interested in adding sports pad tests, of course. Let's talk about that later.
SMSTestSuite_v0.29.sms.zip (21.09 KB)
SMS Test Suite ver. 0.29 (hopefully fixed)

  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Thu Jan 30, 2020 8:52 pm
Cool.. i can test the updated version for you later on.

Ill open my controller up and give the pot a clean and see if that sorts it out and it exits after a few seconds too. Given the age its rather likely to be all over the place and rather noisy as mentioned, so its probably showing a lot of movement thats not real.
  View user's profile Send private message
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Sat Feb 01, 2020 6:06 am
sverx wrote
About not having a way of leaving the test: the test should terminate by itself if you don't do anything for approx. 3 seconds... and about the fact that the arrow selector scrolls up and down in the main menu, well, there was a bug that caused both problems. I just fixed it now - I also added the PAUSE key as a way to leave the test, in case faulty paddles keep on registering knob movements. This should be better.


Great work.. that works perfectly now. :) Even with a "noisy" controller it still exits properly after the 3 seconds.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Sun Feb 02, 2020 5:25 pm
nice! also, some noise is totally expected, I believe.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Mar 17, 2020 9:36 am
Just tried this on a new sms1 i got. Its detected as a megadrive with a 315-5313 vdp, obviously thats not likely to be right. Ive opened it up and its got a 315-5124 vpd, 315-5216 io chip and a v2.0 bios. The board is a M4 power base/pal. The reset button doesnt work in the pad test and it doesnt want to exit after a few seconds like it should. Im wondering if its got a problem related to the io chip.

Are you still using the state of the cont pin to decide if its a megadrive? If so, do you check the vdp or just assume its a 315-5313 from there? It also doesnt do a bios checksum but i assume thats because it thinks its a megadrive which doesnt have the sms bios.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Tue Mar 17, 2020 9:51 am
wow, that's totally unexpected.
MegaDrive hardware is now (in the latest versions) inferred from VDP detection, so if it reports your hardware as a MegaDrive, it means it has detected a VDP that can't do sprite zoom, as that's a feature MegaDrive's VDP is lacking.
So it's either a 'broken' VDP or a bug in my code, even if that part didn't change lately.
If you can check the same ROM on an another M4 power base we might find which case is this.
Thanks for letting me know!
  View user's profile Send private message Visit poster's website
  • Joined: 29 Mar 2012
  • Posts: 604
  • Location: Spain
Reply with quote
Post Posted: Tue Mar 17, 2020 10:07 am
I'm not an expert, but I would say that Megadrive VDP can zoom sprites, only that it has the first 4 sprites only bug. Isn't it?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Tue Mar 17, 2020 10:32 am
no, the MegaDrive's VDP can't zoom sprites in Mode 4.
"Sprites cannot be zoomed using bit 0 of register #1, this bit does nothing", in Charles' words.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Mar 17, 2020 10:38 am
Its v0.29.. the same one we used to test my sports pad a few weeks back. Its the only sms1 i have thats an m4. Maybe some one else has one that can test it?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Tue Mar 17, 2020 11:02 am
also, you could try with v.0.28 too.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13293
  • Location: London
Reply with quote
Post Posted: Tue Mar 17, 2020 11:13 am
If it’s really a 2.0 BIOS then it’s only the second one found.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Wed Mar 18, 2020 7:24 am
Ok, ive done some more tests now. Oddly the reset button seems ok now and the pad test seems to exit properly too. Possibly it just had dirt in it, dunno, seems fine now anyway, so assume that has nothing to do with it.

v0.27 detects it correctly and also confirms the bios is V2.0
v0.28 detects it incorrectly as a megadrive
v0.29 detects it incorrectly as a megadrive

Reading back several posts, it looks like from 0.28 and on the VDP is being tested instead of using the cont pin. Like you say, either my VDP is broken or theres a bug. Does any one else have a sms 1 with a 315-5124 VDP they can try this on?
0.27.jpg (252.17 KB)
0.27.jpg
0.28.jpg (243.31 KB)
0.28.jpg
0.29.jpg (276.52 KB)
0.29.jpg
20200317_220818.jpg (139.69 KB)
20200317_220818.jpg

  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 13293
  • Location: London
Reply with quote
Post Posted: Wed Mar 18, 2020 9:31 am
Can you try Earthworm Jim? The status area uses doubled sprites and that’ll show what your VDP does for those.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Wed Mar 18, 2020 10:57 am
wasup wrote
v0.27 detects it correctly and also confirms the bios is V2.0
v0.28 detects it incorrectly as a megadrive
v0.29 detects it incorrectly as a megadrive

Reading back several posts, it looks like from 0.28 and on the VDP is being tested instead of using the cont pin. Like you say, either my VDP is broken or theres a bug.


Occam's razor suggest I probably have a bug in my code, even thought it looks correct

  SMS_VRAMmemset (0x0000, 0xFF, 32);         // a 'full' tile
  SMS_useFirstHalfTilesforSprites(true);
  SMS_setSpriteMode (SPRITEMODE_ZOOMED);
 
  SMS_initSprites();
  SMS_addSprite (0, 0, 0);    // first sprite
  SMS_addSprite (15, 0, 0);   // second sprite, one pixel 'too' to the left
  SMS_waitForVBlank();           // wait VBlank
  SMS_copySpritestoSAT();        // copy sprites to SAT
  SMS_waitForVBlank();           // wait next VBlank...
  // ... and if it's a MD the collision flag will be OFF
  if (!(SMS_VDPFlags & VDPFLAG_SPRITECOLLISION))
    return (SZC_ABSENT);


what puzzles me is that no SMS emulator I'm using does report me a MegaDrive VDP chip - if it was a simple bug in my code I would likely get that too, and I don't. So what Maxim suggested is actually a nice idea. (Anyway if the sprites do appear zoomed then I might suggest the sprite collision flag might be broken...)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Wed Mar 18, 2020 11:01 am
Maxim wrote
If it’s really a 2.0 BIOS then it’s only the second one found.


Checksum confirmed this.
You may dump 16 KB from BIOS by pressing the DOWN key while on that page, and we could compare it with what we have, I'm pretty sure it's going to be the same (even if checksum only reads 8 KB so in theory we might have differences after that...)
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Thu Mar 19, 2020 7:04 am
Maxim wrote
Can you try Earthworm Jim? The status area uses doubled sprites and that’ll show what your VDP does for those.


Is this what we would expect?
20200319_200202.jpg (3.69 MB)
20200319_200202.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Thu Mar 19, 2020 9:53 am
this is exactly what you should get, with the zoom bug (you can see that only some of the sprites in the HUD are zoomed both horizontally and vertically)

so again, it might be my code failing OR the VDP isn't reporting collision when it should. I think we need other SMS I users (the models with old VDP) to test the Test Suite v0.29 (or v0.28) and report. I have no hardware available here.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Fri Mar 20, 2020 2:47 pm
sverx wrote
this is exactly what you should get, with the zoom bug (you can see that only some of the sprites in the HUD are zoomed both horizontally and vertically)

so again, it might be my code failing OR the VDP isn't reporting collision when it should. I think we need other SMS I users (the models with old VDP) to test the Test Suite v0.29 (or v0.28) and report. I have no hardware available here.


Just catching up to the thread here. What are the specific steps you need us SMS 1 users to do?
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Fri Mar 20, 2020 3:00 pm
I would say - if you have an SMS I that is detected properly (and NOT as a SMS II) in version 0.27, we want to know if version 0.29 detects it as a MegaDrive or still as a SMS I.

This should clarify if it's a bug in my code.
  View user's profile Send private message Visit poster's website
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Sat Mar 21, 2020 4:30 pm
Here are my results from a US SMS I with Tim Worthington FM Sound mod. 0.29 detects the SMS I incorrectly as a Megadrive/Genesis.
027.jpg (3.13 MB)
0.27 on SMS I
027.jpg
028.jpg (3.19 MB)
0.28 on SMS I
028.jpg
029.jpg (2.65 MB)
0.29 on SMS I
029.jpg

  View user's profile Send private message
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Mon Mar 23, 2020 12:43 am
Looks like mine is likely ok then. I guess that leaves it to either a issue with that flag in the earlier sms1 vdp or a code bug.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Mar 23, 2020 10:32 am
a very interesting result indeed

since I am checking the sprite collision flag to tell SMS I and II apart even in version 0.27, I am wondering if the collision flag is really working the same way in both VDP revisions.

because if it is, I'm still not getting why it isn't set when I put two zoomed sprites too close to each other - this is making me think the so called 'sprite zoom bug' could be worse than expected

it's probably worth making a small test ROM to investigate this further. I'll do this ASAP.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Mar 23, 2020 2:49 pm
Here's a basic sprite collision flag test ROM. Expected output is what shown on image, let's see if the SMS I VDP confirms that.

this puts a solid sprite at 0,0 and a second one a few pixels to the right, or down

'!' means a collision is detected by the hardware and '-' means no collision has been detected
sprite_collision_test.png (9.28 KB)
expected output
sprite_collision_test.png
VDPcoltest.sms.zip (4.5 KB)
VDP collision test

  View user's profile Send private message Visit poster's website
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 23, 2020 3:03 pm
Here are my results. Note: you might want to start including a version number in this VDP test program, in case there are multiple iterations and we need to figure out which one we're talking about.
IMG_6490.jpg (1.81 MB)
US SMS 1
IMG_6490.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Mar 23, 2020 4:37 pm
very very interesting results!

let's study this curious outcome a bit more. Here's the next test, ver. 2
sprite_collision_test_v2.png (10.18 KB)
expected output
sprite_collision_test_v2.png
VDPcoltest2.sms.zip (4.62 KB)
VDP collision test v. 2

  View user's profile Send private message Visit poster's website
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 23, 2020 6:49 pm
Here we go!
IMG_6491.jpg (757.05 KB)
US SMS 1
IMG_6491.jpg

  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Mon Mar 23, 2020 7:31 pm
wonderful, now I know how to fix the MD/SMS/SMSII VDP detection routine!

so this seems to confirm the infamous VDP zoom bug is even worse than what Charles described - apart from not drawing properly the 5th, 6th, 7th and 8th zoomed sprite on a scanline, it looks like the collision flag doesn't 'see' the horizontal zoom even on the first two sprites - OK somewhat less tragic that the 'zoomed sprites draw' bug, as many games doesn't even bother checking the collision flag anyway.

Thanks for your help, SavagePencil. Now, if somebody else can run the same test program on his first revision SMS to confirm the results we see here, that would be lovely.

edit: SMS Test Suite v. 0.30 attached - now it probes zoom capability using vertical overlap instead of horizontal.
SMSTestSuite_v.0.30.sms.zip (21.12 KB)
SMS Test Suite ver. 0.30

  View user's profile Send private message Visit poster's website
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 23, 2020 7:54 pm
Just so you have confirmation of my machine with 0.30...
IMG_6492.jpg (902.06 KB)
US SMS 1
IMG_6492.jpg

  View user's profile Send private message
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Mon Mar 23, 2020 8:18 pm
Oh nice.. the above all looks promising! I can test this later on aswell, once i get back home. Everything is a bit mental here at the moment. The whole country is going into lock down for a month, or more, starting thursday. Just trying to get things ready to shut down at work..
  View user's profile Send private message
  • Joined: 23 Aug 2009
  • Posts: 119
  • Location: Seattle, WA
Reply with quote
Post Posted: Mon Mar 23, 2020 8:22 pm
I have a second SMS 1 that I could dig out and test, if that would be of any value? It's another US one with FM sound mod, so not sure if it would produce any different results.
  View user's profile Send private message
  • Joined: 05 Nov 2014
  • Posts: 344
  • Location: Auckland - NZ
Reply with quote
Post Posted: Tue Mar 24, 2020 6:34 am
Looks good here too.

- SMS1 with old VDP now detected as SMS1.
- SMS1 with new VDP still detected correctly as SMS II.
- Game gear still detected correctly as game gear
- Dont have a mega drive set up at the moment to test that on
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Tue Mar 24, 2020 9:49 am
we're in lockdown too since yesterday evening

well, at least seems I have fixed that VDP detection routine... :rolleyes:
  View user's profile Send private message Visit poster's website
  • Joined: 11 Mar 2006
  • Posts: 70
Reply with quote
Post Posted: Thu Mar 26, 2020 12:17 pm
Can you please add support for the raphnet snes controller adapter? It is detected as a 3 button controller. The adapter works as 6 button controller in street fighter (on a chinese everdrive).

https://www.raphnet.net/electronique/snes2md/index_en.php
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Thu Mar 26, 2020 3:50 pm
that's unexpected - so A, B and C buttons work but X, Y and Z don't?
and still street fighter works fine?
I'm going to check how street fighter reads the controller...
  View user's profile Send private message Visit poster's website
  • Joined: 11 Mar 2006
  • Posts: 70
Reply with quote
Post Posted: Thu Mar 26, 2020 3:54 pm
sverx wrote
that's unexpected - so A, B and C buttons work but X, Y and Z don't?
and still street fighter works fine?
I'm going to check how street fighter reads the controller...


Yes. In street fighter all six button works.
Sms test suite is on an actual sms cart pcb+27c512.
The test was done on sms2 and on megadrive 2.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Fri Mar 27, 2020 10:51 am
I've read some more details about the adapter you're using and I had a quick test with Street Fighter... but you probably meant you're playing that on a MegaDrive, because I didn't find any code that reads MD pads in the Master System version.

so I suspect the adapter you're using isn't sending the correct values of zeroes for the d-pad keys at the correct moment (you can check my code on this line)

so I'm curious how Street Fighter code can correctly support both 3 and 6 buttons models without telling them apart. If you can somehow help me providing me the relevant piece of code I can try reading that even if I'm no expert on 68000 assembly...
  View user's profile Send private message Visit poster's website
  • Joined: 11 Mar 2006
  • Posts: 70
Reply with quote
Post Posted: Fri Mar 27, 2020 2:03 pm
Yes, I was refering to the megadrive version of street fighter.
Sadly I have zero knowledge about coding.
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2711
Reply with quote
Post Posted: Fri Mar 27, 2020 2:48 pm
I'm still investigating this, I might ask you to run some tests in case...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 528
Reply with quote
Post Posted: Fri Mar 27, 2020 5:06 pm
@gorgyrip can you run the attached testroms on your hardware with the Raphnet Adapter and send us photos of your screen? Ideally one photo without pressing any button, one photo while pressing the START button, one photo while pressing the UP button and one photo while pressing the B button.
MDKEY.zip (1.85 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 11 Mar 2006
  • Posts: 70
Reply with quote
Post Posted: Fri Mar 27, 2020 7:50 pm
Here are the test results:
NO button: F3FFF0FFFFFFF3FFF3
START: D3FFD0FFFFFFD3FFD3
UP: F2FEF0FFFFFEF2FEF2
B: F3EFF0FFEFEFF3EFF3

Used setup: megadrive 2 + everdrive+MDKEY16.sms
I don't know if it matters, but when I made the adapter, for the fuses i used: hi=C9, low=9F

So street fighter and mortal kombat 2 (both megadrive versions) work in six button mode.
Interesting is Forgotten Worlds. If i remember correctly, the game should hang when a 6 button controller is used. But with this snes adapter it doesn't hang.
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 528
Reply with quote
Post Posted: Fri Mar 27, 2020 8:44 pm
gorgyrip wrote
Here are the test results:
NO button: F3FFF0FFFFFFF3FFF3
START: D3FFD0FFFFFFD3FFD3
UP: F2FEF0FFFFFEF2FEF2
B: F3EFF0FFEFEFF3EFF3

Used setup: megadrive 2 + everdrive+MDKEY16.sms
I don't know if it matters, but when I made the adapter, for the fuses i used: hi=C9, low=9F

So street fighter and mortal kombat 2 (both megadrive versions) work in six button mode.
Interesting is Forgotten Worlds. If i remember correctly, the game should hang when a 6 button controller is used. But with this snes adapter it doesn't hang.

Thank you! Could you please also post the results of MDKEY15? :)
  View user's profile Send private message Visit poster's website
Reply to topic Goto page Previous  1, 2, 3, 4, 5  Next



Back to the top of this page

Back to SMS Power!