nesdev.parodius.com

[SecretServiceDude]

I've tried to set the mapper number to 2 in the iNES header, and I've toyed around with the ld65 linker config file, but I don't really know what I'm doing. Nestopia gives me a "Corrupt file!" message when I try to load the ROM.

Has anyone got an example handy that could help get me up and running?

If it helps at all, here are the current header and linker config I'm using for NROM:

[Bregalad]

More or less. CHRRAM is that, just a RAM chip. When you power the console, it contains garbage (likely FFs). Usually, you'd want to store your CHR data in PRG ROM, and have a routine that copies it to RAM via $2006/$2007 updates. You don't have to updload it by 8kb chunks, but you can update any amount of tiles you want in any order, that's the big (and sole) advantage of CHRRAM, you're free to re-arrange tiles like you want, and even to change them by software.

I'm no CA64 expert, but you should probably remove the "ROM2" line in order to get it to work.

You should NOT set any CHRROM when doing this, let the byte in iNES header to $00. Only PRGROM data should be present.

[tokumaru]

I believe that Nestopia requires UNROM games to have 128KB of ROM, and it's probably complaining about your 32KB.

Of course you don't have to use the whole 128KB if you don't want to, you could just use the last 32KB. But be sure to place your vectors and reset code in the last 16KB bank, because that's the one UNROM keeps mapped at $C000-$FFFF at all times. Before using the lower half ($8000-$BFFF), be sure to map the correct bank in there.

I'm sorry if I can't help you with assembler settings (my assembler of choice doesn't need any settings).

As Bregalad said, you must define 0 CHR-ROM pages in the header, and where you'll store the data is up to you. Since you're moving from NROM, what would make the most sense would be using one of the 6 new 16KB PRG-ROM banks you got for graphics, and have a simple routine to copy 8KB from it during start up, so it will pretty much feel like NROM for a while, until you decide to take more advantage of the extra ROM space and CHR-RAM freedom.

[Dwedit]

I've seen 64k sized games which work as Mapper #2 (Bee 52). I'd think it was just complaining that the size in the header does not match the filesize.

[tokumaru]

[SecretServiceDude]

Okay, I've updated the header and linker config file. Nestopia no longer displays the "Corrupt file!" message; however, now all I've got is a blank screen.

My CHR data is located in the BANK2 segment. I suspect one of my problems is that I'm not successfully copying the data to CHR-RAM. This is my first attempt at bank switching, so I don't really know how to do it. If improper bank switching is the culprit, how do I set it up properly?

Below are my current header and linker config for UNROM:

[SecretServiceDude]

[SecretServiceDude]

YESSSS!!!

After much struggling and frustration, I finally built a working UNROM project! I can now write to CHR-RAM, which I intend to exploit shamelessly for maximum kicking of ass.

Thank you all for your suggestions; I'd have been completely lost without them.

The sky's the limit. I'm stoked.

[clueless]

I'm just curious... what was the problem? What did you change to make it work?

[SecretServiceDude]

[clueless]

It is great that you've got it to work. Please don't take the following as any sort of detraction of your skill.

You don't have to use a batch file. The ld65 linker is fully capable of creating a properly laid out .nes file in iNes format.

At the moment my project uses MMC1 (16K banks) with 4 banks. Three (ROM0, ROM1, TILES) are at $8000 and the non-swappable (ROMK and ROMV) at $c000.

It appears to me that the order the segments are listed in the "SEGMENTS" block does not matter. What appears to matter is the order of the sections "MEMORY" that have the attribute "file = %O". They are written to the output file in that order.

[1] https://www.ecoligames.com/trac/nes-game/nes-game/browser/trunk/src/linker.cfg

[SecretServiceDude]

Everything you said is absolutely correct. In fact, until recently I was using the "file = %O" attribute to have the linker generate the NES file directly. It's true that the order of the segments doesn't matter, only the memory sections.

But still, as a matter of personal preference, I like having the banks separated into distinct files. That way, I can easily throw a bank into a hex editor and immediately see its contents. Also, I imagine that having separate files might make it easier to transfer the game to an actual cartridge later on.

I'm still pretty new at this stuff, so the project will undoubtedly evolve for a while before everything coalesces. At this point, I'm just happy to have something that works, because wrestling with that linker config was a real pain.

EDIT: If anyone else out there is struggling to understand how ld65 config files work, this site is pretty useful.

[clueless]

(going off topic)

Linkers are indeed a dark art. Second only to the dreaded "scsi chain".

http://74.125.45.104/search?q=cache:plYiNfv4MCwJ:https://0x55517066.adsl.cybercity.dk/quotes/+quote+goat+scsi+chain&hl=en&ct=clnk&cd=2&gl=us&client=firefox-a

Search for "John Woods".

Than read the quote immediately above that one and immediately below it.

[clueless]

SecretServiceDude,

Interesting idea about keeping ROM segments separate to make them easier to "explore" using a hex-editor. You inspired me to hack my build scripts.

I now have two linker files and two build targets: The full NES game and just the tiles as if it were a CHRROM game with 16K of tiles.

[SecretServiceDude]

Glad to be of service. After all, it's in my name!

I really love this place because of all the great ideas everyone presents. If these forums didn't exist, I may have given up on my project already, because there are so many things I never could have figured out without all the helpful information/suggestions found here.