nesdev.org

Hi!
I did a little flintstones repro (dinosaur version) with the inlprogrammer and a tlrom board (256 KB of prg and chr), no wram. The problem is: my graphics are bugged. The first 2-3 levels are ok, but the cinematics and the rest of the other levels are bugged. I belive the problem comes from the prg doubling step? To double it, I selected all the code in hexeditor, and pasted it at the end. I did the same thing for the chr and the characters are all ok. Weird.

Do you guys have an idea what is the problem? Thanks for the help!
mario

If the game runs correctly but the graphics are wrong, it is most likely a problem with the CHR-ROM.

mario wrote:my graphics are bugged.

the characters are all ok. Weird.

Those are conflicting bits of information, so you might have to describe in greater detail (or use pictures) how the graphics are bugged.

tokumaru wrote:

mario wrote:my graphics are bugged.

the characters are all ok. Weird.

Those are conflicting bits of information, so you might have to describe in greater detail (or use pictures) how the graphics are bugged.

By bugged, i mean that all the scenario is glitched with weirds colors and quares. its similar to this picture: http://tcrf.net/images/a/af/CastlevaniaProjGlitch.png
We can see the main traject, characters and objects, but the environment is bugged.

Rephrased: sprites look fine, background CHR data looks wrong (specifically wrong tile data, wrong CHR page referenced, etc. -- nametable/layout data looks correct, at least in the screenshot, but again -- "similar" != "identical").

Possibilities here are still many. Is it just not possible for you to take a picture of a display/television set?

mario wrote:We can see the main traject, characters and objects, but the environment is bugged.

You should know that CHR-ROM is not just for the entities you perceive as characters in the game, it actually contains the tiles necessary to draw everything, sprites and background.

Anyway, if the game is fully playable, apart from the background looking messed up, the problem is most likely in the CHR-ROM chip (it could be programmed wrong or wired wrong) or the mapper is not an exact match, although that's unlikely if part of the game is fine.

As requested, here are the pics!

http://i58.tinypic.com/xddt7p.jpg

http://i61.tinypic.com/fbz3o2.jpg

http://i58.tinypic.com/2iqkbi0.jpg

http://i59.tinypic.com/2m5kxmu.jpg

http://i61.tinypic.com/21981tk.jpg

http://i61.tinypic.com/zjb5lk.jpg

http://i62.tinypic.com/scdwn6.jpg

http://i61.tinypic.com/70jj0n.jpg

Thanks for your time and knowledge guys! Its really appreciated!

It really does look like the wrong tiles are being mapped in. If you pay attention, you'll notice that the glitches are not random, the tiles are still arranged in the expected shapes and colors, it's just the wrong tiles.

You said you doubled up the CHR, but looking at bootgod's database it appears that the game already uses 256KB of CHR, so there should be no need to double it, right?

tokumaru wrote:It really does look like the wrong tiles are being mapped in. If you pay attention, you'll notice that the glitches are not random, the tiles are still arranged in the expected shapes and colors, it's just the wrong tiles.

You said you doubled up the CHR, but looking at bootgod's database it appears that the game already uses 256KB of CHR, so there should be no need to double it, right?

Yes, you are right, but strangely, when I auto split my rom with nesmapper, it gives me 128 ko prg and chr... I think we found the bug's source? xD how can I fix that now?

Maybe the header is fucked up and indicates the wrong CHR size... ROM splitters are stupid anyway, just open the ROM in an hex editor and remove the first 16 bytes (that's the header). The next 128KB is the PRG-ROM, and the remaining 256KB is the CHR-ROM.

This will sounds like a ridiculous question but.... Can you tell me How I do this please? xD thanks

tokumaru explained exactly, and clearly, what to do in his previous post.

The exact keys you need to push to split them up depends on how your particular hex editor implements copy and paste.

koitsu wrote:tokumaru explained exactly, and clearly, what to do in his previous post.

You know what I hate with people like you? Taking a space to say something that no one need/want to hear. It's a useless pollution. You should keep quiet if what you brings won't make progress the forum. thank you to refrain next time! No offense btw.

tepples wrote:The exact keys you need to push to split them up depends on how your particular hex editor implements copy and paste.

I know... this question could have been posted in newbie center. But this forum is made for that, and I see that some guys between you are more focused to offer their assistance than others. I appreciate this.
My program is Hexedit. In fact, I have search in the entire program and I did not find a way to do it. I can select bytes, but I have not find a way to select a quantity of data. What is the secret? :O

Offense absolutely intended, and absolutely taken that way. Just because I'm a forum admin doesn't mean you can't scream at me -- go right ahead, but what you're asking for is quite literally "how do I use the hex editor I chose?". There's a general expectation that folks doing repros kinda have a basic understanding of what it is they're doing (especially considering they're working with EPROM/EEPROM writers). I'd suggest you skim the 1900+ posts of mine to see if what I've said has "brought progress" to the forum (not to mention I hosted this site for over 15 years).

But anyway, is there some reason you didn't refer to the Hexedit help files?

http://www.hexedit.com/help/Hexedit.htm
http://www.hexedit.com/help/cmd_misc/hid_del.htm
http://www.hexedit.com/hex-edit-shots.htm

It looks like you just select the bytes you want to get rid of using the mouse/keyboard and press Delete. It works this way in HxD as well: http://mh-nexus.de/en/hxd/

I should add that if the game you're trying to make repros of is The Flinstones - The Surprise at Dinosaur Peak! (and it looks like it is, based on the screenshots (it doesn't appear to be The Rescue of Dino & Hoppy)), the ROM archives I've seen of this game are all questionable:
Reference: http://en.wikipedia.org/wiki/GoodTools#Standard_codes

[!p] means the ROM dump is still semi-questionable, meaning the dumper either didn't know what they were doing or they didn't have a way to verify the results, so there's not necessarily a way to guarantee the dump was 100% correct.

[o1] means the dump is faulty (overdumped by 128 bytes, but how/where the overdumping happens is unknown) -- and this one would surely be broken in some way if you were to use it, not to mention I'm not sure how an EPROM/EEPROM writer wouldn't throw a fit (either PRG or CHR would be too large vs. the actual chip size, unless the chip was larger than it needed to be).

[p1][!] means the dump is verified but it's a pirated version of the game (rather than an original) (the game starts by showing "1994" with nothing else, as in someone modified the title screen copyright and changed the year). However, the dump is verified as good (funny that).