problem with my repro

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.

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?

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?

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.

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.


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).

If you need to know the layout of an .NES ROM file, you can find the information here: http://wiki.nesdev.com/w/index.php/INES

If you can't figure out how to use a hex editor, that's a different problem, but a hex editor is not a complicated or obscure tool. There should be an "address" somewhere that indicates the location in the file where your selection starts or ends. Try to use this to determine how many bytes you have selected.

Math is the secret.

All hex editors I know of show the address of each row on the right. First you need to get rid of the header, which is 16 bytes. If you don't know hex, you can go to the Windows calculator, switch to the programmer layout and convert 16 from decimal to hex, and you get $10. So start by selecting and deleting everything between (and including) addresses $0 and $F ($10 -1). Then you want to remove the 128KB of PRG-ROM. 128KB is 131072 bytes, which converted to hex is $20000. Select and delete everything between $0 and $1FFFF ($20000 - 1). If the ROM is correct, the remaining 262144 ($40000) bytes will be the CHR-ROM data, which you can save and burn to an EPROM.

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 think my question has been badly interpreted. I know how to select and delete; I meant, how can I select a 128 kb of data? What indicates me when I selected 128kb?

Look at the addresses on the left! I gave you all the math.

Look at the status bar. HxD will show the length of your selection in that status bar.

Manually selecting all that data is too much work, though. Check out "select block" in the edit menu.

[quote="tokumaru"]

Sorry if I made you repeat, but when I wrote my last message, I was looking at the admin's message, thinking that no one replied. After my post, I saw that there had now 2 page (Yeah, I know, double face palm!).

Thanks for the info my friend (they were perfectly explicated)! I just modificated the rom and I'll program it tonight to see if it works.

Why would anyone recommend using a hex editor over my ReadNES3? Is there anything wrong? I'll go back, tidy up the code some more, make it better, and git it so anyone can fix/change to their liking.

In this particular case, a wrong header appears to be causing the CHR to be smaller than it should. Messing with bitfields just to use the splitter again may be more trouble than just getting the bytes with an hex editor. Anyway, a good feature for a NES ROM splitter is a warning in case the sizes in the header conflict with the size of the ROM file, so at least the user knows that something is wrong BEFORE he goes through the trouble of burning and soldering chips.

Also, if it's just a one time thing and you already have an hex editor you're used to, using it may be quicker than looking online for a tool to do this simple job. If you're doing this to a lot of files though, then sure, a specialized program will probably help get the job done faster.

Ah, I thought it was just difficulties in general splitting it, not because of a bad head. I'll que up the "File should be X size" for commit before I make a git for ReadNES3, I'll probably wait to git it until I'm done with my assembler. Should be here shortly!