## Why? - You want to make a suggestion on something that could be improved. - You want to report a bug, something that doesn't work as expected. - You know of a sick 6502 assembly technique that could be applied. I am open for discussion and welcome any help! ## How? [Like this](https://jo.mssola.com/en/contributing.html). ## Tooling In general, rely on `make deps` to tell you what you need for development. Other than that, if you are typing code, follow [this code style](https://git.mssola.com/nes/style.nes). It's what I'm trying to follow here and it plays well with the tooling I have on [tools.nes](https://git.mssola.com/nes/tools.nes). ## Development cycle In order to test your changes, I'd go this way: 1. Make sure that you have the toolchain installed. For this you can call `make deps` and it will error out if you are missing anything. 2. Make your changes in the code and run `make`. This will produce the ROM inside of the `out` directory. 3. Run the ROM that was produced with an emulator of your choosing. Make sure that things run as expected. ### Customizing the build process You can pass the following arguments to `make`: - `CC65`: the compiler to use (defaults to [xa65](https://git.mssola.com/nes/tools.nes) if that exists, otherwise `cl65`). - `CCOPTS`: the options to use for the compiler (defaults to `--target nes` and it adds `--strict` if using `xa65`). - `RUBY`: the ruby to use (defaults to `ruby`). ## Modifying assets I am using [NEXXT studio 3](https://frankengraphics.itch.io/nexxt) for managing the assets. This is why you will find a [sessions.nss](./assets/sessions.nss) file from which you will be able to load the same environment I have been using in order to manage my assets. All of that being said, whenever you are done modifying the assets, do the following: 1. Save the session so it can be viewed on Git. 2. Save the 8KB of pattern data from sets A+B and save them into [./assets/jetpac.chr](./assets/jetpac.chr). 3. Save both screens into `.nam` files, as you can see on [./assets](./assets).