[Hanoch]

Which emulator are you using?

What I don't understand is, how can different emulators produce different effects. Are they like how operation systems vary from each other (how Linux is different than microsoft, gens is different than kega etc) or maybe there's something else im missing?

[FraGag]

A video game console is a complex system, just like any computer, and each of the components are themselves complex. Emulating correctly every single detail of the MC68000, for example, is certainly not easy to do. Some details have been left unimplemented because it was faster to do so and didn't cause problems in commercial games; for example, the authors of Gens and Kega choose not to crash when the 68000 does word or longword accesses on odd addresses, because it slows down emulation on every memory access, and the chance that such an error happens is fairly small. 0-length DMA operations (and other specific lengths) are also misinterpreted by Gens because it's additional logic that slows down emulation (no 'if' is faster than an 'if). This is why more accurate emulators are usually slower.

[ColinC10]

Some details have been left unimplemented because it was faster to do so and didn't cause problems in commercial games

This is a good point. The original Sonic games have an advantage because the emulators are designed to play them! When porting Sonic 1 objects to Sonic 2, I've spotted one or two occasions where the designers happened to get away with some slightly dodgy programming by sheer chance - in other words, it's right on the limit of what should work, and obviously is fine on hardware, but emulators trying to cut corners as FraGag described might struggle. However, any emulators that crashed would have been fixed in order to allow the popular Sonic games to be playable. Unfortunately, when I've changed the way the code runs ever so slightly, this kind of "almost bug" has caused a crash and I've been forced to fix it. If I recall correctly, the code that cancels the Buzzbomber's missile when you destroy it was an example of this - in Sonic 2 it crashed in Fusion but not Gens (or vice versa, I can't remember, but it was a bastard to find). The reason wasn't a problem with what I'd ported, but because the missile tried to display itself for one frame after it was deleted. Displaying null objects like this was a problem for one emulator but not the other.

Since I was unable to reproduce the bug you're quoting, it helps to narrow things down if I can get an idea of which emulators in works in and which it doesn't, in case it's a problem like the one above. Plus, I might get lucky and the person who raised the bug will say some weird emulator I've never heard of, in which case I can blame that!

[tokumaru]

how can different emulators produce different effects.

It might come as a shock to some of the internet's ROM pirates (I'm not calling you that BTW), but emulators are not perfect replicas of the consoles they are emulating. A lot of popular emulators are just "good enough" to run existing commercial games, and do not emulate every little intricate detail of the hardware. Each emulator author takes different shortcuts to get the most games working (if 100% of the hardware was emulated at the lowest level, emulators would be painstakingly slow). Because of this, when something doesn't behave as expected the problem should be analyzed in different emulators and specially on real hardware, so that it can be identified as a software issue or an emulation issue.

This post has been edited by tokumaru: 12 September 2010 - 08:07 PM

[GerbilSoft]

Regarding the zero-length DMA bug, Gens/GS r7 correctly handles it by interpreting it as a 65,536-word transfer instead of a 0-word transfer. (There's a hidden configuration option to disable this for broken hacks.)

Gens/GS II uses the VDP code from Gens/GS r7+ (not released), so it also correctly handles this quirk.

For address exceptions, a single test/jnz combination shouldn't cause too much overhead, especially since branch prediction on most modern CPUs will mark it as a no-follow branch in most cases, in which case you only lose a few cycles. Gens/GS II doesn't emulate this yet, since it's still using the Starscream 68000 CPU core; however, since Starscream uses byteswapped memory, the results for a non-word-aligned word access will be incorrect.

By the way, to any hackers who complain about newer emulators being more accurate and thus "breaking" their broken ROMs: Learn how to program and stop thinking that simply copypastaing everything like a crappy VB program is "programming". Read the 68000 programmer's reference manual and the Genesis Software Manual so you can actually learn how the system works.

This post has been edited by GerbilSoft: 13 September 2010 - 04:49 PM

[tokumaru]

By the way, to any hackers who complain about newer emulators being more accurate and thus "breaking" their broken ROMs: Learn how to program and stop thinking that simply copypastaing everything like a crappy VB program is "programming". Read the 68000 programmer's reference manual and the Genesis Software Manual so you can actually learn how the system works.

As a long time programmer (not 68000 or MD though), I must admit that I find this site's approach to "hacking tutorials" really weird. You know, a bunch of "copy this code over that code in disassembly X and you'll have this new feature" guides, that many people follow without having a clue of what is actually going on. And it seems to me that many "hackers" get to the point of trying things at random until the desired effect is (apparently) reached. I can only imagine how many broken Sonic ROMs exist because of this.

I honestly thing that hacking and programming are the kinds of things for which there are no shortcuts. You have to study and practice a lot if you ever plan on doing something great. Reusing the works of others and making poor quality games as a result is a shameful thing that I wish wouldn't happen so often.

Don't get me wrong, I think that people sharing their findings about the games is a great thing, I just think that it would make more sense if they took the time to explain how things work, which variables are used for what, and to give clues on how to manipulate certain behaviors rather than making copy/paste guides, which have poor educational value.

[ColinC10]

Για τις εξαιρέσεις διεύθυνση, μία και μόνη δοκιμασία / συνδυασμός jnz δεν θα πρέπει να προκαλέσει πάρα πολύ γενικά, ειδικά δεδομένου ότι η πρόβλεψη υποκατάστημα επί πλέον σύγχρονες CPUs θα το σήμα ως μια "μη ακολουθήσει υποκατάστημα στις περισσότερες περιπτώσεις, σε οπότε χάνετε μόνο από μερικούς γύρους. Gens / GS II δεν μιμηθούν αυτό ακόμα, δεδομένου ότι είναι ακόμα χρησιμοποιώντας ο Starscream 68000 core CPU; ωστόσο, δεδομένου ότι Starscream χρησιμοποιεί byteswapped μνήμη, τα αποτελέσματα για ένα μη λέξη-ευθυγραμμισμένο πρόσβαση λέξη θα είναι ανακριβής.

Yes, that's exactly what I thought. (Shit, I thought I was a Tech Member?)

By the way, to any hackers who complain about newer emulators being more accurate and thus "breaking" their broken ROMs: Learn how to program and stop thinking that simply copypastaing everything like a crappy VB program is "programming". Read the 68000 programmer's reference manual and the Genesis Software Manual so you can actually learn how the system works.

Are you referring to me with that statement? Because I did a lot of copypastaing for my last hack, and it works really well, without any bugs whatsoever, and I haven't had to rush out any kind of "revision 1" nonsense to make the game playable. Does anyone want a wall of text to explain how the system stack works? No? I'll just leave then.

[GerbilSoft]

Are you referring to me with that statement? Because I did a lot of copypastaing for my last hack, and it works really well, without any bugs whatsoever, and I haven't had to rush out any kind of "revision 1" nonsense to make the game playable. Does anyone want a wall of text to explain how the system stack works? No? I'll just leave then.

No, I'm referring to the people who complain about new emulators "breaking" their ROMs. (There's been a lot less of this lately, but it happened quite a bit back in the day, especially with regards to the zero-length DMA quirk.)

This post has been edited by GerbilSoft: 13 September 2010 - 05:29 PM

[ColinC10]

Cool, just checking. Joking aside, though, I just want to be clear that any dodgy programming is entirely my fault, and not because of the emulator!

I must admit that I find this site's approach to "hacking tutorials" really weird. You know, a bunch of "copy this code over that code in disassembly X and you'll have this new feature" guides, that many people follow without having a clue of what is actually going on.

I definitely agree with this. For the small number of people I've tried to help with coding issues, I've always tried to explain what to do rather than giving them some code to copy. Many guides are worse than useless, because the hacker thinks they have a working feature, but there's some bug under the surface that they have no hope of finding because they don't understand what the code does. That's when people really do start blaming the emulator, because they copied the code perfectly and it still doesn't work!

[Covarr]

Are you referring to me with that statement? Because I did a lot of copypastaing for my last hack, and it works really well, without any bugs whatsoever, and I haven't had to rush out any kind of "revision 1" nonsense to make the game playable. Does anyone want a wall of text to explain how the system stack works? No? I'll just leave then.

No, I'm referring to the people who complain about new emulators "breaking" their ROMs. (There's been a lot less of this lately, but it happened quite a bit back in the day, especially with regards to the zero-length DMA quirk.)

But isn't it the right, even obligation, of every lazy unskilled hacker in the world to hold you personally responsible for their own sloppy programming? Next thing you know, people will be blaming Mozilla because their standards-bastardizing pages work just fine in IE but not in Firefox!