|
ForumsSega Master System / Mark III / Game GearSG-1000 / SC-3000 / SF-7000 / OMV |
Home - Forums - Games - Scans - Maps - Cheats - Credits Music - Videos - Development - Hacks - Translations - Homebrew |
Goto page Previous 1, 2, 3, 4, 5, 6 Next |
Author | Message |
---|---|
|
Posted: Thu Nov 28, 2019 11:00 am |
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? |
|
|
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). |
|
|
Posted: Thu Nov 28, 2019 5:23 pm |
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? |
|
|
Posted: Sun Dec 01, 2019 5:29 pm |
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. |
|
|
Posted: Sun Dec 01, 2019 5:32 pm |
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. |
|
|
Posted: Mon Dec 02, 2019 10:40 am |
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. |
|
|
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. |
|
|
Posted: Tue Jan 28, 2020 3:06 am |
That sounds nice.. i will test this later on when i get a chance. | |
|
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. |
|
|
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. |
|
|
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. |
|
|
Posted: Sat Feb 01, 2020 6:06 am |
Great work.. that works perfectly now. :) Even with a "noisy" controller it still exits properly after the 3 seconds. |
|
|
Posted: Sun Feb 02, 2020 5:25 pm |
nice! also, some noise is totally expected, I believe. | |
|
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. |
|
|
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! |
|
|
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? | |
|
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. |
|
|
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? | |
|
Posted: Tue Mar 17, 2020 11:02 am |
also, you could try with v.0.28 too. | |
|
Posted: Tue Mar 17, 2020 11:13 am |
If it’s really a 2.0 BIOS then it’s only the second one found. | |
|
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? |
|
|
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. | |
|
Posted: Wed Mar 18, 2020 10:57 am |
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...) |
|
|
Posted: Wed Mar 18, 2020 11:01 am |
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...) |
|
|
Posted: Thu Mar 19, 2020 7:04 am |
Is this what we would expect? |
|
|
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. |
|
|
Posted: Fri Mar 20, 2020 2:47 pm |
Just catching up to the thread here. What are the specific steps you need us SMS 1 users to do? |
|
|
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. |
|
|
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.
|
|
|
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. | |
|
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. |
|
|
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 |
|
|
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.
|
|
|
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 |
|
|
Posted: Mon Mar 23, 2020 6:49 pm |
Here we go!
|
|
|
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. |
|
|
Posted: Mon Mar 23, 2020 7:54 pm |
Just so you have confirmation of my machine with 0.30...
|
|
|
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.. | |
|
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. | |
|
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 |
|
|
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: |
|
|
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 |
|
|
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... |
|
|
Posted: Thu Mar 26, 2020 3:54 pm |
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. |
|
|
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... |
|
|
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. |
|
|
Posted: Fri Mar 27, 2020 2:48 pm |
I'm still investigating this, I might ask you to run some tests in case... | |
|
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.
|
|
|
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. |
|
|
Posted: Fri Mar 27, 2020 8:44 pm |
Thank you! Could you please also post the results of MDKEY15? :) |
|
Goto page Previous 1, 2, 3, 4, 5, 6 Next |