 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| 0 users currently in ROM Hacking. |
| User | Post |
| magno Posts: 13/20 |
Thank you veru much, d4s! That is just what I wanted to know!
I did all these questions because I want to begin some project like Super Flash Card and those kind of dev cartridges. I think I worked too much in SNES ASM till now and wanted to try with real hardware. My aim is to develop that kind of generic dev cartridge and then release all information to public, as I think there is a lot of information about that but not really useful. I plan to release VHDL code, schematics, parts used and things like that. I have visited your web, d4s, and that SNES seems a hit, but there isn't any information about how you did it, and that's why I want to do something that may be useful to others. |
| PrincessPeach Posts: 170/381 |
Originally posted by d4s As much as I know is that a European System has two plastic things in the slot, wich prevents Japanese carts to be inserted completly, the same as used in the N64 Systems. |
| d4s Posts: 63/98 |
Originally posted by magno first of all, the snes hardware itself knows and does absolutely nothing with the info in the cartridge header. it doesnt know the region of the game, it doesnt know the size of the rom, it doesnt even know if the rom is hirom or lorom. all the snes does is jump to the adress specified in the 2-byte reset vector and execute program code from there, the rest is entirely up to the software on the cartridge. the snes has a version register that also has a bitflag indicating if its currently in pal or ntsc mode. by reading out this register, games can decide to halt gameplay and display an error message if they are running in the wrong mode. a pal system will have 50 NMIs per second as opposed to a ntsc system(japanese or american sfc/snes) that has 60 NMIs. this is due to the different video standards used and relates to the number of screen refreshes per second of the tv. because almost every snes game uses the nmi for its timing, ntsc games played on a pal system will play slower than on a ntsc one, thats the reason. apart from the speed difference, relatively few games show glitches or crash when they are running in the wrong mode. the only ones i can remember right now are sim city, final fantasy 3/6 and tales of phantasia.(the latter is sound-related, though) and for the record, japanese cartridges are NOT identical to pal carts. although the cartridge shape is the same, they have different lockout chips. you cant play sfc games on pal consoles or vice versa without modifying the unit or using adapters. as hyperhacker said, the only snes that can change the video mode according to the inserted cartridge is the one i built a year ago or so. you can read it up on my homepage if you like.(link is in my signature) |
| magno Posts: 12/20 |
Well, actually SFC japanese cartridges are exactly as PAL ones so they fit in PAL consoles. I don't think a game can detect which system has been slotted in, as any game has such logic and I don't think it could be detected by software (maybe I am wrong and would delighted of being told about what is my mistake).
Anyway, you said something essential to understand the very source of my doubt: If you do manage to put a PAL game in an NTSC SNES, it will either run at the wrong speed Is that the only effect of playing a NTSC game on a PAL SNES? That's what I want to know and why. |
| HyperHacker Posts: 2296/5072 |
Well I'm not an expert on SNES, but I don't think the real hardware uses that byte at all; it's more for Nintendo's development tools and programmers. It doesn't need to know whether the game is NTSC or PAL, it just assumes every game is a given region. They're designed such that NTSC carts don't fit in PAL systems and vice-versa (though this can be defeated fairly easily). If you do manage to put a PAL game in an NTSC SNES, it will either run at the wrong speed, or the game will detect that it's an NTSC system and refuse to run at all.
AFAIK, you can switch which region the console will run in by rewiring a few things, but it won't automatically detect the game's region and switch itself. To do that you'd need to build in a bootROM and some extra logic to allow the region to be changed in software. (IIRC, d4s did this.) |
| magno Posts: 11/20 |
Maybe you don't get my point, HyperMackerl  My original question was what were the differences between a NTSC game/cartridge and a PAL one; I got to conclusion that SNES "knows" which type of game is reading the internal header (which other way could it use to figure it?) so if I change that byte, the only difference should be speed playback.
If you got my point and it is me the one who doesn't get yours, then tell me please what would be the problem in doing what I told last reply. |
| HyperHacker Posts: 2292/5072 |
No, the real hardware always runs in either NTSC or PAL mode, and if you get it to start a game from the other region, it just doesn't work very well. |
| magno Posts: 10/20 |
Changing the "Video Type" byte in the internal ROM header changes the video playback rate in ZSNES and SNES9x. I guess the real hardware must do the same thing to detect it. That means video subsystem will interrupt the CPU with NMI more often in NTSC than PAL but the code executed during that NMI will be the same, so the re-calculated position of any sprite will be the same too. Then, the animation of any movement will be slower in PAL.
If the programmers want to achieve the same animation speed in both version, PAL version code must be changed to re-calculate properly the position of any sprite. Am I wrong? |
| HyperHacker Posts: 2280/5072 |
Well I'm not sure how difficult it is to use the mouse, but it could be useful. For example in a game like Super Mario World you could use it to move Mario around the level. |
| FloBo Posts: 13/22 |
Well at least for a officially licensed game for the SNES, it was a Nintendo-requirement, that the game checked for not used input devices at startup, so no strange behaviour could occur when attaching a 4-player-adapter or super scope or mouse or stuff while unused by the game...
So maybe chances are low that a mouse was used for debugging as well... anyway, coding some engine for the mouse-klicking behaviour just for debugging purposes seems a bit unreal don't you think?! At least there was nothing like a Shell or a window manager that would easily let you utilize the mouse for debugging purposes... |
| PrincessPeach Posts: 167/381 |
Originally posted by HyperMackerelOriginally posted by PrincessPeach Or the Gun? na, not likely. But would the have some kind of debug-machines? |
| HyperHacker Posts: 2268/5072 |
Originally posted by PrincessPeach Hm, that gave me an interesting idea. I wonder if any SNES games might have used the mouse for debugging?  |
| PrincessPeach Posts: 166/381 |
It's not as today, as games where sometimes even more debugged or additional features or even multi language. |
| LocalH Posts: 64/65 |
Originally posted by MathOnNapkins I would imagine they had one base sourcecode, and either modified it for PAL, or inserted some sort of conditional assembly statements (depending on which assembler they used, it may or may not have supported such constructs) so that they could just change one define to determine which version will be built. |
| PrincessPeach Posts: 163/381 |
It depends on the game, per se is all SNES-Software runnable on all SNES and SF Systems.
Some Games have internal checks for speed or whatnot to only run on its targeted system. If you have a SNES-Copier, most non special chip games should work without any problems. Some have a SRAM-check, others do not run with a mouse attached to the system. |
| magno Posts: 9/20 |
So if I change the right byte in the internal header, could I be able to play a PAL game in an NTSC system or viceversa?
That means that if there are differences in some games, as MathOnNapkins says, that differences are programmer's whim, and not necessary for NTSC or PAL conversion, doesnt't it? |
| MathOnNapkins Posts: 585/1106 |
That's how they detect most if not all rom properties, is reading the internal header.
Since there are gameplay differences in Super Metroid between PAL and NTSC, I would not assume they are always the same source codes, however. |
| magno Posts: 8/20 |
So both NTSC and PAL game source code are the same?
Which way an SNES PC emulator does detect which type of ROM is then? Looking at ROM header at bottom of first bank? |
| PrincessPeach Posts: 162/381 |
What HH said is right. Also is there the problem with so called PAL-Borders, as PAL has a higher vertical resolution (100 more lines).
The resolution of the SNES is the same in both versions. |
| HyperHacker Posts: 2264/5072 |
There's hardware mods you can do to switch between NTSC and PAL mode. It's NES that has a different graphics chip for each; on SNES it's just a matter of switching modes. I think some games do another check in software to see if they're running at the right speed though. |
| This is a long thread. Click here to view it. | |
