|
Joined: May 2009
Posts: 2,222 Likes: 387
Very Senior Member
|
Very Senior Member
Joined: May 2009
Posts: 2,222 Likes: 387 |
Kale and JD have a good point in this discussion because they are the current SNES driver developers, and they are doing lots of improvements to it, spending their spare time to try to fix the whole thing instead of saying what should be done from today forward. For what it's worth, the SuperFX, etc. cores were all a few days' work, tops. Including me in the list of current SNES driver developers is giving me too much credit, I think.
|
|
|
|
Joined: Mar 2007
Posts: 298
Senior Member
|
Senior Member
Joined: Mar 2007
Posts: 298 |
I just don't know if Kale knows how to deal with that cycle issues, otherwise he can fall in a dead end with his current code...
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
Question to sfc experts: Somebody addressed to me that the game Deae Tonosama Appare Ichiban refuses to run on some kind of xbox emulator that I don't know and don't want to know about...anyway, it displays the following message: That basically means that the copy protection failed*, I've investigated a little and found that it does the following: 7F20CB: BF 0A FF 89 LDA $89ff0a,X 7F20CF: 9F 38 00 70 STA $700038,X 7F20D3: DF 38 00 70 CMP $700038,X 7F20D7: F0 01 BEQ 7f20da ($1) ;if the branch is true, then the copy protection fails 7F20D9: 6B RTL 7F20DA: CA DEX 7F20DB: D0 EE BNE 7f20cb (-$12)As you may know, $700038 is "reserved" memory, so that should return open bus / fixed value on the real HW anyway...now the question is: if they putted that kind of check, that means that is supposed to fail somehow on bootleg software, but why 0x7000xx? Some kind of Internal RAM for these copy devices (since that gets written with 0 then read back)? *thanks to Gridle & DFJustin to translate that .
Last edited by Kale; 10/19/09 04:54 PM.
|
|
|
|
Joined: Mar 2006
Posts: 1,079 Likes: 6
Very Senior Member
|
Very Senior Member
Joined: Mar 2006
Posts: 1,079 Likes: 6 |
It means, much like the snes pokemon bootleg/pirate original, that the pirates added some circuitry (probably a gal and some 74xx logic) to force specific values to specific open bus addresses. Hence the cart can be considered a custom 'mapper' with added protection.
LN
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
|
|
Joined: Mar 2001
Posts: 17,234 Likes: 260
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,234 Likes: 260 |
Isn't 7000xx battery RAM? That seems like a bog-standard "fail if there's NVRAM and we don't want it" check that was effective against many early copiers (which always provided the max amount that would fit in the mapping mode).
Also, is the problem that it fails on MESS, or just on some xbox thing?
|
|
|
|
Joined: Aug 2009
Posts: 1,261 Likes: 193
Very Senior Member
|
OP
Very Senior Member
Joined: Aug 2009
Posts: 1,261 Likes: 193 |
Nah, it's not happening in MESS, only on that xbox thing...I've asked just for curiosity
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
Senior Member
Joined: Jun 2008
Posts: 205 |
::bump:: I found a way to get Super Game Boy support up and running in full. The cheap, easy way: the SNES sets $2181-3 to a screen index where it expects $7800 to read from. It's offset by either $5000+ or $6800+, as the screen is apparently double-buffered. Subtract that, divide by 320 (size of a tile row), and set the read index there. The hard way: it seems that reads are always linear across the screen, but certain actions cause one to miss four or more tile rows (eg entering the menu, processing certain SGB commands, etc.) When this happens, it doesn't tell the ICD2 chip anything, so I believe the chip also knows that $7800 hasn't been read and four tile rows have passed. Meaning it's probably buffering at most 1,280 bytes. So after reading $7800 again after so much time has passed in the LY counter, jump ahead to the current position. Looks like $6000 is the GB-level LY counter, too. If you try and simulate the counter via cycle ticks, the video gets desynchronized and starts flickering really badly. Just feed it the real LY counter and you're good. The Space Invaders arcade mode game sucks, too. Not at all worth the effort :P
|
|
|
|
Joined: Mar 2001
Posts: 17,234 Likes: 260
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,234 Likes: 260 |
Very nice
|
|
|
|
Joined: May 2009
Posts: 2,222 Likes: 387
Very Senior Member
|
Very Senior Member
Joined: May 2009
Posts: 2,222 Likes: 387 |
byuu, can I use your source code to try implementing full SGB support in MESS?
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
Senior Member
Joined: Jun 2008
Posts: 205 |
Of course. I think it'd be great to have two full SGB emulators, in case certain games only work in one or the other. Plus I could use help with the multi-player support. I'm not entirely sure how you increment to choose the next gamepad. The pandocs method breaks games and seems to increment way too much.
All you really need for my work is supergameboy/interface. The stuff under bsnes/src/chip/supergameboy is just the DLL passthru and my $7800 access trick.
The fun part will be using MESS' GB support instead of Gambatte (which is GPLv2.) You'll need to be able to read out the LY counter, hook DMG $ff00 accesses, and make sure all video up to the current scanline is rendered when reading from $7800.
If you take the easy way like I did, you'll need to feed the S-CPU $2180 access address to the SGB core. And if you take the hard way, please do share if you can figure it out, heh.
Feel free to ask any questions and I'll do my best to explain.
|
|
|
0 members (),
183
guests, and
1
robot. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,328
Posts122,128
Members5,074
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|