logo
 drop

Main

Community

Submissions

Help

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - snarfblam

Pages: [1] 2 3 4 5 6 ... 29
1
I'm personally increasingly concerned that, given the quantity of ROM/ISO info additions listed as "Public Maintenance", the testing and/or verification of the info being added is minimal if it's being done at all. I hope I'm wrong, but if not, the information being added is no more useful or accurate than a general suggestion to use a verified good dump.

2
Personal Projects / Re: Newer Super Mario Bros. DS
« on: May 06, 2016, 09:39:10 pm »
I'm gonna take a wild guess and say xdelta

3
You need to know how the ROM is mapped into CPU address space. That depends on the mapper used by the game. For example, MMC1 (Zelda, Metroid, etc., etc.) divides the ROM into $4000-byte banks. The last bank is mapped to $C000-$FFFF, and any other bank can be mapped into $8000-$BFFF. So, suppose you're looking to break when the byte at 0x13056 is read.

First subtract $10 to account for the iNES header, giving you 0x13046. Divide that by $4000 to get the bank number, which gets you 4. Then, keep subtracting $4000 to get the location within the bank within question. Stop when you get a number that is less than $4000. (In other words, you want the modulus, i.e. remainder of the division we did.) In this case it will be 3046. Since bank 4 isn't the last bank, it will be mapped in the $8000 region, thus our address is $8000 + $3046 = $B046. If you create a breakpoint for reads on $B064, the emulator will break when you want. (It will also break if the same location is read in a different bank, but that usually doesn't create a problem.)

That might sound like a pretty big headache for every time you need to convert a ROM location to a CPU address, but with some practice you'll get to the point where you can do it in your head in a second. Again, this is just an example using MMC1. Different mappers will use different bank sizes in different configurations. You can look up detailed documentation on sites like NESDev for the various mappers.

How does an assembly opcode read from ROM? Can anyone shed some light on this?

The CPU doesn't know anything about mappers or banks. That's all handled by the cartridge. In effect, every time the CPU accesses the ROM, the cartridge does the above conversion.

4
Newcomer's Board / Re: FCEUX Hex editing question
« on: April 14, 2016, 07:17:54 am »
The byte is frozen or you have cheats on? Try right-clicking the byte.

5
o_O  This was one of the biggest and most popular games when it came out.  Everyone I knew growing up loved it.

I knew of it, but never once played it as a kid.

6
As far as I am aware, the auto-merge counts as an edit, and an edit to the most recent post of a thread flags it as unread.

7
ROM Hacking Discussion / Re: Proposal: IPS Revision for CRC checking
« on: April 03, 2016, 10:08:57 am »
Looks pretty good to me. One or two nitpicks:

Quote from: Original
        To correct this, new patches should give a faux-offset for the metadata which will put the mangled data in a section
        of the file that will be overwritten by a future normal Data block.

Perhaps:

Quote from: Suggestion
        To correct this, new patches must use a faux-offset for the metadata that will place the mangled data in a section
        of the file that will be completely overwritten by the following normal Data blocks.

And although it is implied by the above, for clarity it might be best to add:

Quote from: Suggestion
        Faux-offsets for metadata blocks must place the mangled data within the bounds of the resulting file.

8
I'm guessing it's a "Communist Mario" hack, as it's been called when people have done Super Mario World hacks like it.

Like so.

9
Front Page News / Re: ROM Hacks: Communist Mario 3 Released!
« on: April 01, 2016, 05:29:47 pm »
When I'm done I'll see if I can remember to dig up this thread and post reaults. If anyone else is interested in getting a cartridge, let me know.

Consider yourself letted knowed.

10
ROM Hacking Discussion / Re: Proposal: IPS Revision for CRC checking
« on: March 31, 2016, 05:56:09 pm »
I think it would totally be worth it. It doesn't make the current patch format mess any more complicated. Worst case scenario, it doesn't catch on and we end up with a handful of patches that are slightly bigger than they need to be, best case scenario it supersedes LIPS and the world is a better place. Regardless of the final details, I'd definitely incorporate the functionality into my own IPS code.

11
Gaming Discussion / Re: Favorite Roguelikes/Dungeon Crawlers
« on: March 30, 2016, 01:59:30 pm »
I'd never played any Roguelikes until I found Pixel Dungeon for Android (free and ad free, but I enjoyed it enough to donate a few bucks). Since then I've tried a couple others, but nothing that appealed to me much. I wouldn't mind trying more. I'd just rather it be something relatively clean and simple, though.

12
ROM Hacking Discussion / Re: Proposal: IPS Revision for CRC checking
« on: March 30, 2016, 01:42:47 pm »
I think if you really wanted to get technical you could try to make the assertion that overlapping patches invoke undefined behavior. (Every spec I've looked at only explained file structure.) A patcher that is thrown off by unexpected data after EOF, on the other hand, is ill-behaved.

In reality, any patcher that is remotely worth using will tolerate either condition. Neither approach is any harder to implement, and neither has any significant drawback. (Who cares if you have to traverse the entire file to get the checksum? How many IPS patches have you run into that can't be applied virtually instantly?)

It's really a matter of personal preference, and since you're taking the initiative, I'd say it's really your call, Disch.

13
ROM Hacking Discussion / Re: Proposal: IPS Revision for CRC checking
« on: March 29, 2016, 07:31:20 pm »
There is already an extension to the IPS format that appends data after EOF. No reason you can't further extend it. It's a simple 3-byte file length specifier to allow a patch to truncate the ROM. Just to be super-duper-extra-mega-safe, you should include a file truncation entry that specifies the correct file size. That way, a patcher checking for that info won't be thrown off when it encounters something else following EOF. It should be relatively safe to include additional metadata following the truncate entry, giving you backwards compatible patches.

14
ROM Hacking Discussion / Re: Ever notice weird things in a ROM?
« on: March 28, 2016, 09:50:28 pm »
But that site is not about game coding weirdness.

Is that what this topic is about? Thought it was just about general weird things noticed in ROMs.

There's no verification either. Almost everything on TCRF about the unused Industrial Area stage in SNES Final Fight is incorrect.

It's a wiki. Go fix it. Or just take it for what it is: a community maintained catalog of unused game content that is neither complete nor perfect.

Anyways, since people were talking about unused assets, hidden messages, extra code, etc. I figured I'd point out a place dedicated to that stuff. Sorry?

15
ROM Hacking Discussion / Re: Ever notice weird things in a ROM?
« on: March 28, 2016, 05:30:23 pm »
Just in case anyone hasn't stumbled upon it, just wanna point out that The Cutting Room Floor exists, and is full of things like this.

16
ROM Hacking Discussion / Re: Snow in SMB2
« on: March 20, 2016, 06:41:55 pm »
...Nope. The result was ugly and incomplete. I was just checking to make sure it works.

How to fish: Open game in FCEUX, open Name Table Viewer. Placing the mouse over a sky tile shows the following:

Spoiler:

Note the Tile ID: FA. Now open the PPU viewer:

Spoiler:

The background tiles are on the right. Find tile FA. It is below the water, to the right of the question mark and two dots.

Now open up YY-CHR, Tile Layer Pro, or whatever your preferred tile editor may be. Find the same arrangement of tiles:

Spoiler:

Note that the tiles are repeated, once for each frame of animation. Now you can either draw your own tiles or copy tiles from another ROM.

Now you know how to fish.

Spoiler:

17
ROM Hacking Discussion / Re: Snow in SMB2
« on: March 20, 2016, 03:48:08 pm »
I don't know anything about the SMB2 Christmas Special, but I opened SMB2 in a tile editor, slapped some white dots on the sky tiles, and snow happened.

18
Front Page News / Re: ROM Hacks: New Hacks Added to the Database
« on: March 11, 2016, 05:46:18 pm »
maker code, checksum, rom revision...how is that in any way useful in telling if you have the correct rom file? ... the title with the (j), [c], and [!] are relevant pieces of info needed to find the correct rom for a romhack. i don't see how anyone will be able to find the correct rom for that street fighter hack.

The CRC-32 is good enough to identify the ROM (SHA-1 or SHA-256 would be preferable), but most of the other info is just noise. I don't even know what "marker" or "old header" mean.

Spoiler:

I'll submit an edit to add this info:

Quote from: Hasher
No-Intro Name: Super Street Fighter II (USA)
(No-Intro version  20130701-030720)
ROM/File SHA-1: 8E67787988024503C4ADEADD5FE50A340AA860D7

19
Gaming Discussion / Re: 3DNES is a thing?
« on: March 10, 2016, 06:00:59 pm »
It's done in Unity. The technique is pretty obvious... and they are definitely using per-game settings.
It's impossible to get those effects in those circumstances without some sorta labeling scheme.

No, it's done entirely on the fly. He has been refining the heuristics for generating 3D shapes and guessing depth.

http://forums.nesdev.com/viewtopic.php?f=3&t=13552

20
That does seem to be the case. I sent the author a PM. If the patch doesn't get updated, then we'll most likely remove the download link.

Pages: [1] 2 3 4 5 6 ... 29