[question4477]

I had the same feeling.  Conceptually speaking the PS1 library in general is a goldmine, so there's a lot of potentially cool stuff on the list.  A few devs hit their experimental periods during this time, Squaresoft felt that they could do no wrong for example.  Not all of it worked out, but I'll be damned if the ideas aren't fun to experience.
Yep, that was it.

I found a lot of the classics that I grew up with to be tedious now, it's quite simply due to the fact that I have overplayed them. To see basically a new version of the first installation of Rayman and a few others would be great - I think as others have mentioned it's probably too time consuming and complicated.

[tvtoon]

As for N64, I think it's because it's one of those systems that's hard to program and emulate.

Emulation is still unreliable HLE, but the programming part surely isn't the main problem. N64 case is just a lack of overall interest, the system didn't get more than 20 mythic games, and for these that matters, I recall Resident Evil 2, Conker, and Sin and Punishment not getting any love.

As for PlayStation, like most CD systems, it is just the size bumper that takes most people off...

[Zoinkity]

PSX documentation:  http://www.problemkaputt.de/psx-spx.htm

I wasn't going to start this rant, but whatever...
N64 has several LLE plugins for the common emulators, plus MAME and Cen64.  There are varying degrees of support for features; for example, only Cen64 implements the cache.  64DD has been implemented in several emulators over the last couple years as well at a somewhat high level, good enough to run retails disks.  Hardware needs to be developed to read disks at a lower level, and the microsequencer needs to be decapped/reversed.

That said, state of emulation is no impediment to hacking N64 titles--and I'm saying that as poster-child for managing to hit every possible edge-case there is.  The idea this is an issue is utter nonsense.

Honestly, you don't even need to understand half the hardware.  It helps, sure, but for the most part you won't need to touch any of that yourself.  What is important is understanding threading and messaging.  For instance, a common problem is when people seem to think they can just jump out of a function and write in their own DMA.  They don't realize that there's a thread that manages E/PI requests and it uses messaging to ensure that the device is not utilized until it's ready, delaying requests until they can be filled.  When you do things behind it's back you could sporadically execute a DMA when the device isn't ready, and the results range from bugginess to full-on crash.  Not fun to debug.  The alternative is to figure out which message queue takes requests and send it one.  It's foolproof and much lazier.

Number one issue preventing most hacking attempts are compression-related, number two is shoving files back in, number three is that the sheer volume of data you need to deal with can be overwhelming, and number four is time.

N64 hackers don't really come here, and neither do people come here for N64 patches.  GE:X is hosted across several sites; rhdn's download count is 2% that of GEvault.  Contrasting the stats at mediafire and the counts for my patches here, rhdn averages out to 5% total downloads.  In fact, most of my work either isn't or can't be submitted here for one reason or another.  For the most part, N64 hackers congregate on IRC, on boards dedicated to particular titles, and collaborations through Github.

[CM30]

I'd say it comes down to four things:

1. They require more skill to get a good looking hack working. I mean, on a NES, it's pretty simple. Eight bit graphics, only a few colours per sprite/tile, mostly chiptune music. Either way, it's possible for a programmer/tech guy to do well without any real 'art' skills.

On the other end of the scale you've got more modern consoles, which can be developed for with easier to use tools and (usually for an indie game/hack) near unlimited resources.

The Nintendo 64 and PlayStation fall between the two extremes. You need some sense of artistic skill to make a game or hack that looks and sounds good (if you want to use new graphics/music), but you're also rather limited in terms of how many resources you can use and what kind of games you can run on the system. So it offers neither the ease of use of NES hacking, nor the freedom of developing for a modern console or PC.

2. Less resources/help available. Scenes do exist for Super Mario 64 and the Zelda games, but outside of that, you're often on your own.

3. Nostalgia. ROM hackers tend to be people who grew up in the 80s or 90s with 2D games like the original Super Mario Bros, Zelda, Mega Man, Metroid, Castlevania, etc. Especially when it comes to the types on ROM Hacking.net. So they might not care as much about modifying games made later.

4. Design complexity. 3D level design is a whole different ballpark to 2D level design.

[Kallisto]

This is a bit random, but I would ask Dr.Abrasive about the PS1 since he is fully capable of this type of thing (The Sega Saturn Breathrough for example)

[goldenband]

The 3DO has at least one Japanese game -- recently translated -- where the script is found in plaintext (Shift-JIS IIRC) in a text file right on the disc. Are there any PlayStation games that are so exposed, or does something preclude it (disc format, Sony requirements, etc.)?

[AWJ]

For instance, a common problem is when people seem to think they can just jump out of a function and write in their own DMA.  They don't realize that there's a thread that manages E/PI requests and it uses messaging to ensure that the device is not utilized until it's ready, delaying requests until they can be filled.  When you do things behind it's back you could sporadically execute a DMA when the device isn't ready, and the results range from bugginess to full-on crash.  Not fun to debug.  The alternative is to figure out which message queue takes requests and send it one.  It's foolproof and much lazier.

That sounds closely analogous to all those SNES translations that jump out of the original game's text printing routine and try to write the translated text directly into VRAM (which works on ZSNES, but not on real hardware or accurate emulators)

[RandomHeretic]

Comment removed.

[Jorpho]

The 3DO has at least one Japanese game -- recently translated -- where the script is found in plaintext (Shift-JIS IIRC) in a text file right on the disc. Are there any PlayStation games that are so exposed, or does something preclude it (disc format, Sony requirements, etc.)?

As I recall, the text for Tobal No. 2 was exceptionally accessible.

[IIMarckus]

Perhaps some kind of collaborative disassembly for certain popular games might change this.

I’ve started one. So far it’s just data extraction though. I don’t know N64 very well.

[salvadorc17]

I have seen some save editing for PS One and also hacking via Cheat engine.

[Zoinkity]

I’ve started one. So far it’s just data extraction though. I don’t know N64 very well.

You still haven't updated it with the breakdown for the cart checksum tables.

Code: [Select]

In 0x23A5000:
0x0 2 #comparison table entries
0x2 2 #header entries
0x4 6ea. comparison table entries; note these are not in sequential order
0x0 4 offset
0x4 2 size
If trailing data after compressed file is nonzero, treated as patch data.

0x53E 3 offset to comparison banks

0x54C 0x20ea. header entries
0x0 1 game version (1:'Red', 2:'Green', 3:'Blue', 4:'Yellow', 5:'Gold', 6:'Silver', 7:'Crystal')
0x1 0xF internal name
0x10 1 region (0:'Japan', 1:'International')
0x11 1 version
0x12 2 ROM checksum
0x14 4 4 bytes at 0x9C001
0x18 4 offset to checksum table
0x1C 2 flags(?)
0010 True if colors, not metals
000F first tested entry in bank list (after 0, 1, and SRAM)
0x1E 2 RESERVED

0x94C 0x420ea. checksum tables
0x0 2ea. correspondance table entry for bank or 0xFEFE if ignored
0x100 2ea. bank index; 0x8*** are saveram banks
0x220 4ea. half-bank checksums; 2 bytes for lower 0x2000, 2 bytes for upper 0x2000
0xFEFE + sum of each byte except bytes 0x14E and 0x14F


[IIMarckus]

You still haven't updated it with the breakdown for the cart checksum tables.

Thanks, it’s there now. Anything else I should add?

[Trax]

On the initial question on why newer consoles games are not hacked as much, apart from what was already stated, like complexity of programming and graphics, my first thought is that the sheer size of the ROMs can be very daunting for many people. For comparison, the Super Mario Bros. ROM is 40 KB (40976 bytes). Super Mario 64 is 8 MB. The ROM I have on disk is 8.4 MB, or 8 388 608 bytes. That's more than 200 times larger. That's a lot of bytes to analyze.

[FAST6191]

If you are brute forcing your way through a ROM like that then you have gone wrong somewhere.

[Kallisto]

So it is just a matter of accessibility due to the size, and it's just a matter on how to solve this old problem.

[Lilinda]

On the initial question on why newer consoles games are not hacked as much, apart from what was already stated, like complexity of programming and graphics, my first thought is that the sheer size of the ROMs can be very daunting for many people. For comparison, the Super Mario Bros. ROM is 40 KB (40976 bytes). Super Mario 64 is 8 MB. The ROM I have on disk is 8.4 MB, or 8 388 608 bytes. That's more than 200 times larger. That's a lot of bytes to analyze.

Consoles with file systems don't necessarily have that issue. The code can be in a file much smaller than 8.4 Megabytes.

[julayla]

What I wouldn't mind seeing is someone hacking the Conker game and use the models of the Conker characters that aren't playables like Berri, Batula, Rodent, and the Panther King. Heck, I wouldn't mind seeing the models of the weasels either. One can dream though.